欢迎访问 如意编程网!

如意编程网

当前位置: 首页 > 运维知识 > windows >内容正文

windows

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

发布时间:2023/11/16 windows 3 coder
如意编程网 收集整理的这篇文章主要介绍了 听我一句劝,业务代码中,别用多线程。 小编觉得挺不错的,现在分享给大家,帮大家做个参考.

你好呀,我是歪歪。

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

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

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

业务代码中一般也使不上多线程,或者说,业务代码中不知不觉你以及在使用线程池了,你再 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 调用,框架中本来就已经有一个线程池了,而且也给你提供了对应的性能调优参数配置,那么首先考虑的应该是把这个线程池充分利用起来。

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

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

下面这个环节叫做[荒腔走板],技术文章后面我偶尔会记录、分享点生活相关的事情,和技术毫无关系。我知道看起来很突兀,但是我喜欢,因为这是一个普通博主的生活气息。

荒腔走板

不知道你看完文章之后,有没有产生一个小疑问:最开始部分的 Demo 似乎用处并不大?

是的,我最开始构思的行文结构是是基于 Demo 在源码中找到关于线程池的部分,从而引出其实有一些我们“看不见的线程池”的存在的。

原本周六我是有一整天的时间来写这篇文章,甚至周五晚上还特意把 Demo 搞定,自己调试了一番,该打的断点全部打上,并写完 Demo 那部分之后,我才去睡觉的,想得是第二天早上起来直接就能用。

刚好 Max 同学休年假,就回老家了,周日才回来,所以整个周六我一个人在家。

按照惯例周六睡个懒觉的,早上 11 点才起床,自己慢条斯理的做了一顿午饭,吃完饭已经是下午 1 点多了。

本来想着在沙发上躺一会,结果一躺就是一整个下午。期间也想过起来写一会文章,坐在电脑前又飞快的躺回到沙发上,就是觉得这个事情索然无味,当下的那一刻就想躺着,然后无意识的刷手机,原本是拿来写文章中关于源码的部分的时间就这样浪费了。

像极了高中时的我,周末带大量作业回家,准备来个悬梁刺股,弯道超车,结果变成了一睡一天,捏紧刹车。

高中的时候,时间浪费了是真的可惜。

现在,不一样了。

荒腔走板这张图片,就是我躺在沙发上的时候,别人问我在干什么时随手拍的一张。

我并不为躺了一下午没有干正事而感到惭愧,浪费了的时间,才是属于自己的时间。

很久以前我看到别人在做一些浪费时间的事情的时候,我心里可能会嘀咕几句,劝人惜时。

这两年我不会了,允许自己做自己,允许别人做别人。

总结

以上是如意编程网为你收集整理的听我一句劝,业务代码中,别用多线程。的全部内容,希望文章能够帮你解决所遇到的问题。

如果觉得如意编程网网站内容还不错,欢迎将如意编程网推荐给好友。