听我一句劝,业务代码中,别用多线程

开发 前端
Http 调用或者 RPC 调用,框架中本来就已经有一个线程池了,而且也给你提供了对应的性能调优参数配置,那么首先考虑的应该是把这个线程池充分利用起来。

你好呀,我是歪歪。

前几天我在网上冲浪,看到一个哥们在吐槽,说他工作三年多了,没使用过多线程。

虽然八股文背的滚瓜烂熟,但是没有在实际开发过程中写的都是业务代码,没有使用过线程池,心里还是慌得一比。

我只是微微一笑,这不是很正常吗?

业务代码中一般也使不上多线程,或者说,业务代码中不知不觉你以及在使用线程池了,你再 duang 的一下搞一个出来,反而容易出事。

所以提到线程池的时候,我个人的观点是必须把它吃得透透的,但是在业务代码中少用或者不用多线程。

关于这个观点,我给你盘一下。

Demo

首先我们还是花五分钟搭个 Demo 出来。

我手边刚好有一个之前搭的一个关于 Dubbo 的 Demo,消费者、生产者都有,我就直接拿来用了:

图片图片

这个 Demo 我也是跟着网上的 quick start 搞的:https://cn.dubbo.apache.org/zh-cn/overview/quickstart/java/spring-boot/

图片图片

可以说写的非常详细了,你就跟着官网的步骤一步步的搞就行了。

我这个 Demo 稍微不一样的是我在消费者模块里面搞了一个 Http 接口:

图片图片

在接口里面发起了 RPC 调用,模拟从前端页面发起请求的场景,更加符合我们的开发习惯。

而官方的示例中,是基于了 SpringBoot 的 CommandLineRunner 去发起调用:

图片图片

只是发起调用的方式不一样而已,其他没啥大区别。

需要说明的是,我只是手边刚好有一个 Dubbo 的 Demo,随手就拿来用了,但是本文想要表达的观点,和你使不使用 Dubbo 作为 RPC 框架,没有什么关系,道理是通用的。

上面这个 Demo 启动起来之后,通过 Http 接口发起一次调用,看到控制台服务提供方和服务消费方都有对应的日志输出,准备工作就算是齐活儿了:

图片图片

上菜

在上面的 Demo 中,这是消费者的代码:

图片图片

这是提供者的代码:

图片图片

整个调用链路非常的清晰:

图片图片

来,请你告诉我这里面有线程池吗?

没有!

是的,在日常的开发中,我就是写个接口给别人调用嘛,在我的接口里面并没有线程池相关的代码,只有 CRUD 相关的业务代码。

同时,在日常的开发中,我也经常调用别人提供给我的接口,也是一把梭,撸到底,根本就不会用到线程池。

所以,站在我,一个开发人员的角度,这个里面没有线程池。

合理,非常合理。

但是,当我们换个角度,再看看,它也是可以有的。

比如这样:

图片图片

反应过来没有?

我们发起一个 Http 调用,是由一个 web 容器来处理这个请求的,你甭管它是 Tomcat,还是 Jetty、Netty、Undertow 这些玩意,反正是个 web 容器在处理。

那你说,这个里面有线程池吗?

在方法入口处打个断点,这个 http-nio-8081-exec-1 不就是 Tomcat 容器线程池里面的一个线程吗:

图片图片

通过 dump 堆栈信息,过滤关键字可以看到这样的线程,在服务启动起来,啥也没干的情况下,一共有 10 个:

图片图片

朋友,这不就是线程池吗?

虽然不是你写的,但是你确实用了。

我写出来的这个 test 接口,就是会由 web 容器中的一个线程来进行调用。所以,站在 web 容器的角度,这里是有一个线程池的:

图片图片

同理,在 RPC 框架中,不管是消费方,还是服务提供方,也都存在着线程池。

比如 Dubbo 的线程池,你可以看一下官方的文档:

https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/advanced-features-and-usage/performance/threading-model/

图片图片

而对于大多数的框架来说,它绝不可能只有一个线程池,为了做资源隔离,它会启用好几个线程池,达到线程池隔离,互不干扰的效果。

比如参与 Dubbo 一次调用的其实不仅一个线程池,至少还有 IO 线程池和业务线程池,它们各司其职:

图片图片

我们主要关注这个业务线程池。

反正站在 Dubbo 框架的角度,又可以补充一下这个图片了:

图片图片

那么问题来了,在当前的这个情况下?

当有人反馈:哎呀,这个服务吞吐量怎么上不去啊?

你怎么办?

你会 duang 的一下在业务逻辑里面加一个线程池吗?

图片图片

大哥,前面有个 web 容器的线程池,后面有个框架的线程池,两头不调整,你在中间加个线程池,加它有啥用啊?

web 容器,拿 Tomcat 来说,人家给你提供了线程池参数调整的相关配置,这么一大坨配置,你得用起来啊:

https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html

图片图片

再比如 Dubbo 框架,都给你明说了,这些参数属于性能调优的范畴,感觉不对劲了,你先动手调调啊:

图片图片

你把这些参数调优弄好了,绝对比你直接怼个线程池在业务代码中,效果好的多。

甚至,你在业务代码中加入一个线程池之后,反而会被“反噬”。

比如,你 duang 的一下怼个线程池在这里,我们先只看 web 容器和业务代码对应的部分:

图片图片

由于你的业务代码中有线程池的存在,所以当接受到一个 web 请求之后,立马就把请求转发到了业务线程池中,由线程池中的线程来处理本次请求,从而释放了 web 请求对应的线程,该线程又可以里面去处理其他请求。

这样来看,你的吞吐量确实上去了。

在前端来看,非常的 nice,请求立马得到了响应。

但是,你考虑过下游吗?

你的吞吐量上涨了,下游同一时间处理的请求就变多了。如果下游跟不上处理,顶不住了,直接就是崩给你看怎么办?

图片图片

而且下游不只是你一个调用方,由于你调用的太猛,导致其他调用方的请求响应不过来,是会引起连锁反应的。

所以,这种场景下,为了异步怼个线程池放着,我觉得还不如用消息队列来实现异步化,顶天了也就是消息堆积嘛,总比服务崩了好,这样更加稳妥。

或者至少和下游勾兑一下,问问我们这边吞吐量上升,你们扛得住不。

有的小伙伴看到这里可能就会产生一个疑问了:歪师傅,你这个讲得怎么和我背的八股文不一样啊?

巧了,你背过的八股文我也背过,现在我们来温习一下我们背过的八股文。

什么时候使用线程池呢?

比如一个请求要经过若干个服务获取数据,且这些数据没有先后依赖,最终需要把这些数据组合起来,一并返回,这样经典的场景:

图片图片

用户点商品详情,你要等半天才展示给用户,那用户肯定骂骂咧咧的久走了。

这个时候,八股文上是怎么说的:用线程池来把串行的动作改成并行。

图片图片

这个场景也是增加了服务 A 的吞吐量,但是用线程池就是非常正确的,没有任何毛病。

但是你想想,我们最开始的这个案例,是这个场景吗?

图片图片

我们最开始的案例是想要在业务逻辑中增加一个线程池,对着一个下游服务就是一顿猛攻,不是所谓的串行改并行,而是用更多的线程,带来更多的串行。

这已经不是一个概念了。

还有一种场景下,使用线程池也是合理的。

比如你有一个定时任务,要从数据库中捞出状态为初始化的数据,然后去调用另外一个服务的接口查询数据的最终状态。

图片图片

如果你的业务代码是这样的:

//获取订单状态为初始化的数据(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 调用,框架中本来就已经有一个线程池了,而且也给你提供了对应的性能调优参数配置,那么首先考虑的应该是把这个线程池充分利用起来。

如果仅仅是因为异步化之后可以提升服务响应速度,没有达到串行改并行的效果,那么我更加建议使用消息队列。

好了,本文的技术部分就到这里啦。

责任编辑:武晓燕 来源: why技术
相关推荐

2021-05-19 10:09:23

消息队列架构

2011-03-24 10:24:45

批量数据绑定

2011-03-28 15:48:52

批量数据绑定

2012-02-09 09:41:22

2021-05-11 15:34:04

Task.Result代码Winform

2013-03-22 10:53:42

PyConPython

2011-06-13 09:25:01

断号

2009-03-10 18:10:12

LinuxUbuntu技巧

2013-05-10 10:56:09

2023-07-12 08:01:28

FOADMROADMOXC

2021-12-17 08:55:26

Python微博机器人

2023-09-05 23:34:52

Kubernetes云原生

2019-11-15 18:00:18

MySQLSQL数据库

2021-03-10 08:16:06

Nacos集群搭建微服务

2022-08-01 10:01:11

JavaScript语言代码库

2020-11-27 09:57:11

Python代码PyPy

2015-08-03 10:21:04

设计模式表达

2017-02-24 14:05:14

AndroidMVCMVP

2016-09-12 15:26:06

戴尔

2013-07-16 10:12:14

iOS多线程多线程概念多线程入门
点赞
收藏

51CTO技术栈公众号