多线程到底用不用在业务代码上？？？

绿毛龟

发布于 2024-01-19 11:22:54

1350

发布于 2024-01-19 11:22:54

文章被收录于专栏：学习道路指南

前言

在当今的软件开发中，多线程技术是一种常见的优化方式，可以显著提高程序的性能和响应能力。

然而，对于业务代码是否应该使用多线程，不同的开发者和专家可能会有不同的看法和经验。

在这篇文章中，我们将探讨多线程在业务代码中的应用，并分析其利弊。

一、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 调用，框架中本来就已经有一个线程池了，而且也给你提供了对应的性能调优参数配置，那么首先考虑的应该是把这个线程池充分利用起来。如果仅仅是因为异步化之后可以提升服务响应速度，没有达到串行改并行的效果，那么我更加建议使用消息队列。