其他系列文章导航
文章目录
前言
在当今的软件开发中，多线程技术是一种常见的优化方式，可以显著提高程序的性能和响应能力。
然而，对于业务代码是否应该使用多线程，不同的开发者和专家可能会有不同的看法和经验。
在这篇文章中，我们将探讨多线程在业务代码中的应用，并分析其利弊。
一、dubbo场景下的多线程
先来讲讲dubbo场景，整个调用链路非常的清晰：
编辑
来，请你告诉我这里面有线程池吗？
没有！
是的，在日常的开发中，我就是写个接口给别人调用嘛，在我的接口里面并没有线程池相关的代码，只有 CRUD 相关的业务代码。
同时，在日常的开发中，我也经常调用别人提供给我的接口，也是一把梭，撸到底，根本就不会用到线程池。
所以，站在我，一个开发人员的角度，这个里面没有线程池。
但是，当我们换个角度，再看看，它也是可以有的。
比如这样：
编辑
反应过来没有？
我们发起一个 HTTP 调用，是由一个 web 容器来处理这个请求的，你甭管它是 Tomcat，还是 Jetty、Netty、Undertow 这些玩意，反正是个 web 容器在处理。
那你说，这个里面有线程池吗？
是有的！！
比如说Tomcat，虽然不是你写的，但是你确实用了。
会由 web 容器中的一个线程来进行调用。所以，站在 web 容器的角度，这里是有一个线程池的：
编辑
同理，在 RPC 框架中，不管是消费方，还是服务提供方，也都存在着线程池。
本篇文章侧重不在dubbo，我就不多说dubbo的线程池了。
我们主要关注这个业务线程池。
反正站在 Dubbo 框架的角度，又可以补充一下这个图片了：
编辑
那么问题来了，在当前的这个情况下？
当有人反馈：哎呀，这个服务吞吐量怎么上不去啊？
你怎么办？你会 duang 的一下在业务逻辑里面加一个线程池吗？
编辑
大哥，前面有个 web 容器的线程池，后面有个框架的线程池，两头不调整，你在中间加个线程池，加它有啥用啊？对吧。
可以对web容器进行调优，然后对dubbo框架也可以进行调优。
甚至，你在业务代码中加入一个线程池之后，反而会被“反噬”。
比如，你 duang 的一下怼个线程池在这里，我们先只看 web 容器和业务代码对应的部分：
编辑
由于你的业务代码中有线程池的存在，所以当接受到一个 web 请求之后，立马就把请求转发到了业务线程池中，由线程池中的线程来处理本次请求，从而释放了 web 请求对应的线程，该线程又可以里面去处理其他请求。
这样来看，你的吞吐量确实上去了。
在前端来看，非常的 nice，请求立马得到了响应。
但是，你考虑过下游吗？
你的吞吐量上涨了，下游同一时间处理的请求就变多了。如果下游跟不上处理，顶不住了，直接就是崩给你看怎么办？
编辑
而且下游不只是你一个调用方，由于你调用的太猛，导致其他调用方的请求响应不过来，是会引起连锁反应的。
所以，这种场景下，为了异步怼个线程池放着，我觉得还不如用消息队列来实现异步化，顶天了也就是消息堆积嘛，总比服务崩了好，这样更加稳妥。
或者至少和下游勾兑一下，问问我们这边吞吐量上升，你们扛得住不。
编辑
我们最开始的案例是想要在业务逻辑中增加一个线程池，对着一个下游服务就是一顿猛攻，不是所谓的串行改并行，而是用更多的线程，带来更多的串行。
二、适合用线程池的场景
2.1 多个模块收集信息场景
比如一个请求要经过若干个服务获取数据，且这些数据没有先后依赖，最终需要把这些数据组合起来，一并返回，这样经典的场景：
编辑
用户点商品详情，你要等半天才展示给用户，那用户肯定骂骂咧咧的久走了。
这个时候，八股文上是怎么说的：用线程池来把串行的动作改成并行。
编辑
这个场景也是增加了服务 A 的吞吐量，但是用线程池就是非常正确的，没有任何毛病。
2.2 定时任务触发调用场景
比如你有一个定时任务，要从数据库中捞出状态为初始化的数据，然后去调用另外一个服务的接口查询数据的最终状态。
编辑
如果你的业务代码是这样的：
//获取订单状态为初始化的数据(0:初始化 1:处理中 2:成功 3:失败) //select * from order where order_status=0; ArrayList initOrderInfoList = queryInitOrderInfoList(); //循环处理这批数据 for(OrderInfo orderInfo : initOrderInfoList){ //捕获异常以免一条数据错误导致循环结束 try{ //发起rpc调用 String orderStatus = queryOrderStatus(orderInfo.getOrderId); //更新订单状态 updateOrderInfo(orderInfo.getOrderId,orderStatus); } catch (Exception e){ //打印异常 } }
虽然你框架中使用了线程池，但是你就是在一个 for 循环中不停的去调用下游服务查询数据状态，是一条数据一条数据的进行处理，所以其实同一时间，只是使用了框架的线程池中的一个线程。
为了更加快速的处理完这批数据，这个时候，你就可以怼一个线程池放在 for 循环里面了：
//循环处理这批数据 for(OrderInfo orderInfo : initOrderInfoList){ //使用线程池 executor.execute(() -> { //捕获异常以免一条数据错误导致循环结束 try { //发起rpc调用 String orderStatus = queryOrderStatus(orderInfo.getOrderId); //更新订单状态 updateOrderInfo(orderInfo.getOrderId, orderStatus); } catch (Exception e) { //打印异常 } }); }
编辑
需要注意的是，这个线程池的参数怎么去合理的设置，是需要考虑的事情。
同时这个线程池的定位，就类似于 web 容器线程池的定位。
或者这样对比起来看更加清晰一点：
编辑
定时任务触发的时候，在发起远程接口调用之前，没有线程池，所以我们可以启用一个线程池来加快数据的处理。
而 Http 调用或者 RPC 调用，框架中本来就已经有一个线程池了，而且也给你提供了对应的性能调优参数配置，那么首先考虑的应该是把这个线程池充分利用起来。
如果仅仅是因为异步化之后可以提升服务响应速度，没有达到串行改并行的效果，那么我更加建议使用消息队列。
三、总结
综上所述，是否在业务代码中使用多线程需要根据具体情况来决定。
如果业务系统需要同时处理多个任务，并且每个任务都可以独立地执行，那么使用多线程可以提高系统的性能和响应能力。
然而，如果业务逻辑比较简单，或者系统的设计不允许使用多线程，那么使用单线程可能更加简单和安全。
在决定是否使用多线程时，需要考虑系统的需求、资源和设计等因素。
