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 国际许可协议发布,转载必须保留署名及链接。