设计模式：基于线程池的并发Visitor模式
1.前言
第二篇设计模式的文章我们谈谈Visitor模式。
当然，不是简单的列个的demo，我们以电商网站中的购物车功能为背景，使用线程池实现并发的Visitor模式，并聊聊其中的几个关键点。
- 一，基于线程池的实现并发Visitor模式。
- 二，讨论下并发场景下的一些细节处理。
- 三，用模拟数据测试并做补充说明。
2.背景
当从网站的某个页面进入购物车时，服务端需要做各种数据处理，比如刷新商品价格，计算促销价、校验库存等等。这些操作会随着业务的增加不断扩展，那么Visitor模式就适合这种场景，这也是它的优点之一，易于新增操作。
3.实现
上图是书上的UML原图，原生实现这里就不重复了，我们直接进入正题。
3.1 并发的visit操作
先来看关键的visit方法
public void visit(Cart cart) {
// 当商品数量不超过两个时，不做并发处理，直接主线程执行，避免浪费线程资源
if (cart.getItems().size() <= 2) {
for (AbstractItem item : cart.getItems()) {
item.accept(this);
}
} else {
//CountDownLatch 用来保证并发执行之后的同步，计数器为商品数量，只有所有visit操作完成后才继续主流程
CountDownLatch countDownLatch = new CountDownLatch(cart.getItems().size());
// 提交task到线程池
cart.getItems().forEach(item -> {
threadPoolExecutor.submit(new SubVisitor(item, countDownLatch));
});
try {
// 等待所有子线程执行完毕
countDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
SubVisitor很简单，实现Runnalbe接口，负责执行具体的visit逻辑，并在执行完成之后同步操作。
private class SubVisitor implements Runnable {
CountDownLatch countDownLatch;
AbstractItem abstractItem;
public SubVisitor(AbstractItem abstractItem, CountDownLatch countDownLatch) {
this.abstractItem = abstractItem;
this.countDownLatch = countDownLatch;
}
@Override
public void run() {
abstractItem.accept(AbstractCartVisitor.this);
// 执行完毕之后同步countDownLatch，即计算器减一
countDownLatch.countDown();
}
}
这里只需注意两点，
- 在商品数量不超过两个时不使用线程池，以避免浪费资源。
- 通过并发包中CountDownLatch来同步所有操作。
3.2 线程池配置
另外一个核心的配置是线程池，代码如下。
int availableProcessors = Runtime.getRuntime().availableProcessors();
threadPoolExecutor = new ThreadPoolExecutor(availableProcessors, availableProcessors,
10, TimeUnit.MINUTES, new SynchronousQueue<Runnable>(), new ThreadPoolExecutor.CallerRunsPolicy());
corePoolSize和maximumPoolSize配置为当前cpu核数，之所以一致是因为这样可以让线程池一直处于最大运行状态，我们追求的是最大效率，不需要销毁一部分来达到减少内存占用。
接下来的参数workQueue是线程池的缓冲队列，超出容量的任务会被放入此队列，这里使用SynchronousQueue，它是一个零容量队列，意味着线程池没有缓冲区。
RejectedExecutionHandler是则是拒绝策略，当线程池和缓冲区都满了后将会执行拒绝策略。这里我们使用CallerRunsPolicy，翻译过来就是主线程直接执行，我们可以看下它的实现。
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
r.run();
}
}
这样的RejectedExecutionHandler和workQueue的配置可以达到我们想要的一个效果:
如果线程池未满，则将任务提交给线程池执行；
线程池满了后，不缓冲，由主线程直接执行任务，不阻塞请求。
3.3 测试
我们模拟一个刷新价格的测试场景来看一下效果。
为了简单起见，我们将corePoolSize设为4。
new ThreadPoolExecutor(4, 4 ...
并假设价格查询接口耗时20ms：
public double queryPriceByItemId(int id) {
//模拟调用时间20毫秒
try {
Thread.sleep(20);
} catch (InterruptedException e) {
}
return 1;
}
以下为1~6个商品时执行结果
数量 1 金额 1.0 耗时 23
数量 2 金额 2.0 耗时 40
数量 3 金额 3.0 耗时 20
数量 4 金额 4.0 耗时 20
数量 5 金额 5.0 耗时 21
数量 6 金额 6.0 耗时 40
2个及以下商品时耗时为线性增长，这是由于我们对这种场景没做并发处理。
4个商品时耗时为20ms，符合我们的预期。
为什么5个的时候也是20ms？
其原因在于我们的执行策略是SynchronousQueue+CallerRunsPolicy，第5个商品被主线程直接处理了，因此相当于我们实际的执行线程是5个，也达到了预期效果。
#
以上为并发的Visitor模式的全部内容，完成demo见Github:
https://github.com/wchukai/basic-practice
作者：初开
原文链接:https://wchukai.com/article/design-patterns-concurrent-visitor-patterns-based-on-thread-pools
本文由MetaCLBlog于2017-10-24 09:00:51自动同步至cnblogs
本文基于 知识共享-署名-非商业性使用-禁止演绎 4.0 国际许可协议发布，转载必须保留署名及链接。
