Bendi新闻
>
多线程性能优化最大的坑,99%的人都不自知!

多线程性能优化最大的坑,99%的人都不自知!

6月前

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑,欢迎加入芋道快速开发平台知识星球。下面是星球提供的部分资料: 

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目,前端包括管理后台 + 微信小程序,后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能:

  • Boot 仓库:https://gitee.com/zhijiantianya/ruoyi-vue-pro
  • Cloud 仓库:https://gitee.com/zhijiantianya/yudao-cloud
  • 视频教程:https://doc.iocoder.cn
【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本 

来源:geekhalo


还原故障现场,挖掘通用场景,寻求最佳解决方案!!!

1. 问题&分析

当我们在处理慢接口问题时,经常会使用多线程技术,将能够并行处理的任务拆分到不同的线程中处理,等任务处理完成后,再收集各线程的处理结果,进行后续的处理。整体思路如下图所示:

这样可以将并行部分的总耗时从 sum 降为 max,从而大幅降低接口的响应时间。

1.1. 案例

订单详情页耗时严重,p99 将近3秒,已经验证影响用户体验,本次迭代小艾专门对该接口进行优化。迭代刚上线,该接口的响应时间大幅降低,p99 降低到 800 毫秒以内,大家纷纷向小艾发来祝贺。但好景不长,随着流量的增加,接口响应时间也在逐渐变长,p99 超过 5 秒,最后系统抛出大量的 RejectedExecutionException 异常,这个接口不可用。最终,QA伙伴火速进行回滚操作,系统恢复正常。

系统恢复后,小艾仔细查看系统监控,CPU使用率并不高,内存也处于正常水位,接口性能居然比优化前还差,真心不知道哪里出了问题。

优化前代码:

public RestResult<OrderDetailVO> getOrderDetail(@PathVariable Long orderId){
        Stopwatch stopwatch = Stopwatch.createStarted();
        OrderService.Order order = this.orderService.getById(orderId);
        if (order == null){
            return RestResult.success(null);
        }
        OrderDetailVO orderDetail = new OrderDetailVO();
        orderDetail.setUser(userService.getById(order.getUserId()));
        orderDetail.setAddress(addressService.getById(order.getUserAddressId()));
        orderDetail.setCoupon(couponService.getById(order.getCouponId()));
        orderDetail.setProduct(productService.getById(order.getProductId()));
        log.info("串行 Cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
        return RestResult.success(orderDetail);
}

优化前耗时:

优化后代码:

public RestResult<OrderDetailVO> getOrderDetailNew(@PathVariable Long orderId){
        Stopwatch stopwatch = Stopwatch.createStarted();
        OrderService.Order order = this.orderService.getById(orderId);
        if (order == null){
            return RestResult.success(null);
        }
        Future<UserService.User> userFuture = this.executorService.submit(() -> userService.getById(order.getUserId()));
        Future<AddressService.Address> addressFuture = this.executorService.submit(() -> addressService.getById(order.getUserAddressId()));
        Future<CouponService.Coupon> couponFuture = this.executorService.submit(() -> couponService.getById(order.getCouponId()));
        Future<ProductService.Product> productFuture = this.executorService.submit(() -> productService.getById(order.getProductId()));

        OrderDetailVO orderDetail = new OrderDetailVO();
        orderDetail.setUser(getFutureValue(userFuture));
        orderDetail.setProduct(getFutureValue(productFuture));
        orderDetail.setAddress(getFutureValue(addressFuture));
        orderDetail.setCoupon(getFutureValue(couponFuture));
        log.info("并行 Cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
        return RestResult.success(orderDetail);
    }

优化后耗时:

可见采用并行优化后,接口的响应时间从 4 秒 将至 1 秒,效果还是非常明显的。

但,继续加大请求量,系统便出现问题,如下图所示:

在流量逐渐增加的过程中,从日志中可以得到以下信息:

  1. 初期耗时稳定,基本在 1 秒左右
  2. 接口耗时逐渐增大,甚至远超串行处理的耗时(大于 4 秒)
  3. 有些请求直接抛出 RejectedExecutionException 异常

1.2. 问题分析

从代码中并未发现任何问题,设计思路也非常清晰,其核心问题在线程池使用上,项目线程池配置如下:

int coreSize = Runtime.getRuntime().availableProcessors();
executorService = new ThreadPoolExecutor(coreSize, coreSize * 5,
        5L, TimeUnit.MINUTES,
        new LinkedBlockingQueue<Runnable>(1024)
        );

核心配置为:

  1. 核心线程数为 cpu 核数
  2. 最大线程数为 cpu 核数的 5 倍
  3. 空闲线程存活时间为 5 分钟
  4. 任务队列为 LinkedBlockingQueue 大小为 1024

在这个配置下,我们推演下以上的三个现象。

1.2.1. 线程资源充足

如下图所示:

整体流程如下:

  1. 主线程向线程池提交 Task
  2. 由于线程处于空闲状态,立即接受并处理问题
  3. 线程池线程处理完任务,将最终的处理结果写回到 Future
  4. 主线程等待所有任务执行完成,获取所有执行结果,然后执行后续流程

这正是想要的执行结果,任务被并行执行,大幅降低接口耗时。

1.2.2. 任务进入等待队列

随着流量的增加,所有的核心线程都处于忙碌状态,此时新任务将进入等待队列,具体如下:

整体流入如下:

  1. 主线程向线程池提交任务

  2. 由于没有核心线程可用,任务被放置到任务队列

  3. 主线程进入等待状态,等待时间包括两部分:


    1. 任务在队列中等待线程调度时间
  4. 任务分配到线程后,任务实际执行时间

  5. 如果前面等待的任务非常多,那等待时间将变的非常长

主线程等待时间 = 队列等待时间 + 任务执行时间。当任务队列非常长时,整体时间将远超串行执行时间。

1.2.3. 资源耗尽触发拒绝策略

流量继续增加,线程池的任务队列已满并且线程数量也达到上限,此时会触发拒绝策略,具体如下:

线程池默认拒绝策略为:AbortPolicy,直接抛出 RejectedExecutionException,从而触发接口异常。

还有更可怕的情况,就是部分提交,也就是主线程已经成功提交几个任务,如下图所示:

核心流程如下:

  1. 主线程已经成功提交两个任务
  2. 在提交第三个任务时,由于资源不够触发拒绝策略,抛出异常导致主线程提前结束
  3. 已经成功提交的任务仍旧会被线程执行,由于主线程已经退出,执行结果没有任何意义,从而白白浪费系统资源

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/ruoyi-vue-pro
  • 视频教程:https://doc.iocoder.cn/video/

2. 解决方案

前面已经分析的很清楚,问题的本质就是线程池资源分配不合理,核心参数设置错误:

  1. 队列设置错误。在该场景下,需要充分利用线程资源,将任务放入队列会增加任务在队列的等待时间,队列长度越大对系统的伤害越大;
  2. 拒绝策略设置错误。直接抛出异常会中断主流程,导致部分无效任务(无意义任务)提交,白白浪费系统资源;

除线程池参数问题外,还有个小问题:主线程完成任务提交后处于等待状态,未执行任何有意义的操作,存在资源浪费。

2.1. 线程池改进方案

改进线程池如下所示:

int coreSize = Runtime.getRuntime().availableProcessors();
executorService = new ThreadPoolExecutor(coreSize, coreSize * 5,
        5L, TimeUnit.MINUTES,
        new SynchronousQueue<>(),
        new ThreadPoolExecutor.CallerRunsPolicy()
        );

线程池配置如下:

  1. 核心线程数不变,仍旧是 cpu 数;
  2. 最大线程数不变,仍旧是 cpu 数的5倍;
  3. 空闲线程存活时间不变,仍旧是 5 分钟;
  4. 使用 SynchronousQueue 替代 LinkedBlockingQueue(1024)。SynchronousQueue 是一个特殊的队列,其最大容量是1。也就是说,任何一次插入操作都必须等待一个相应的删除操作,反之亦然。如果没有相应的操作正在进行,则该线程将被阻塞;
  5. 指定拒绝策略为 CallerRunsPolicy。当线程池资源不够时,由主线程来执行任务;

在这个配置下,及时线程池中的所有资源全部耗尽,也只会降级到串行执行,不会让系统变的更糟糕。

新配置下,系统表现如下:

在最差的情况下也仅仅与串行执行耗时一致。

总体来说就一句话:线程池有资源可用,那就为主线程分担部分压力;如果没有资源可用,那就由主线程独自完成。

2.1. 充分利用主线程

上面提到一个小问题,在资源充足情况下,所有任务均有线程池线程完成,主线程一致处于等待状态,存在一定的资源浪费。

如下图所示:

3 个任务耗费 4 个线程资源:

  1. 线程池3个线程负责执行任务
  2. 主线程等待执行结果,一直处于阻塞状态

为了充分利用线程资源,可以让主线程负责执行任意一个任务。如下图所示:

主线程不在盲目等待,也负责一个任务的执行,这样 3 个任务只需 3 个线程即可。

代码上也非常简单,具体如下:

public RestResult<OrderDetailVO> getOrderDetailNew(@PathVariable Long orderId){
    Stopwatch stopwatch = Stopwatch.createStarted();
    OrderService.Order order = this.orderService.getById(orderId);
    if (order == null){
        return RestResult.success(null);
    }
    Future<UserService.User> userFuture = this.executorService.submit(() -> userService.getById(order.getUserId()));
    Future<AddressService.Address> addressFuture = this.executorService.submit(() -> addressService.getById(order.getUserAddressId()));
    Future<CouponService.Coupon> couponFuture = this.executorService.submit(() -> couponService.getById(order.getCouponId()));
//        Future<ProductService.Product> productFuture = this.executorService.submit(() -> productService.getById(order.getProductId()));

    OrderDetailVO orderDetail = new OrderDetailVO();
    // 由主线程负责运行
    orderDetail.setProduct(productService.getById(order.getProductId()));

    orderDetail.setUser(getFutureValue(userFuture));
    orderDetail.setAddress(getFutureValue(addressFuture));
    orderDetail.setCoupon(getFutureValue(couponFuture));
    log.info("并行 Cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
    return RestResult.success(orderDetail);
}

主线程执行不同的任务,会对接口的响应时间产生影响吗?

不会,并行执行整体耗时为 max(任务耗时),主线程必须获取全部结果才能运行,所以必须等待这么长时间。

  1. 如果主线程运行的任务不是最耗时任务,则需要等待最耗时任务执行完成才能执行后续逻辑;
  2. 如果主线程运行的是最耗时任务,则其他线程已经执行完成并提前释放资源;

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址:https://github.com/YunaiV/yudao-cloud
  • 视频教程:https://doc.iocoder.cn/video/

3. 示例&源码

https://gitee.com/litao851025/learnFromBug/tree/master/src/main/java/com/geekhalo/demo/thread/paralleltask


欢迎加入我的知识星球,全面提升技术能力。

👉 加入方式,长按”或“扫描”下方二维码噢

星球的内容包括:项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话,在看,转发吧。

谢谢支持哟 (*^__^*)

微信扫码关注该文公众号作者

来源:芋道源码

相关新闻

“最大”的美国大学!人多课挤,不喜勿入!Go应用性能优化的8个最佳实践,快速提升资源利用效率!99%的人都不知道!去超市买东西注意这个字母,否则容易被坑“羡慕走线的人,不用花这么多钱,来了美国就能工作”!中国留学生感叹留美太难...一家人就要腻歪在一起!今年见过最大的大大大横厅设计,主打陪伴最大化高铁最快40min,可能是五一人最少的地方!99%的人读不对名字,却隐藏真正的好山好水,好吃到被评为全球美食NO.1!“杀死尽可能多的人”!Taylor Swift演唱会恐有恐袭!极端分子自制炸弹、准备引爆演唱会!最强平替!温哥华搬到卡尔加里的人越来越多!网友:我真的活不起了!99%的人不知道!Woolworths自助结账超隐藏技能大揭秘!网友高呼学到了!暑期机票北美-日本含税往返仅需468美金起,650-750美金超级多!ZIPAIR的坑“有点多”,票帝教你怎么避开之!限量立减1000日元!99%人不知道的日本环球影城超值玩法第一次在USC租房震碎三观,99%的人都不知道!罕见!越来越多的美国人抛弃智能手机!改用“傻瓜机”!10年时间抑郁、焦虑症狂增50%…央行行长:就业市场降温,新移民和年轻人受到的冲击最大!5月份了,再这么搞下去,“返贫”的人会越来越多!到多伦多站了!世界最大的网红充气城堡来了:只停留2周~火速打卡属于晴雨天的浪漫!阻隔99%的紫外线+超强抗风+拒水伞面新毒王!最近发烧的人有点多,不是空调吹多了!13种传染病+罕见癌症涌现......百万美刀打水漂!出海被印度人坑的真实经历……朋友圈里生病的人又多了起来!纽约近期新冠感染率倍增 华人注意防护发现新大陆!墨尔本每天人流量最大的一座桥,上面竟然有这样东西……评论区爆笑!未来5年最大的机会之一!法律人不要错过!别误解!do bird 可不是“做鸟”,99%的人都搞错啦!彻底傻眼!好心人在多伦多街头救晕倒的人!一转身车被抢了
logo
联系我们隐私协议©2024 bendi.news
Bendi新闻
Bendi.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Bendi.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。