当前位置: 首页 > news >正文

Java避坑案例 - 线程池错误的混用引发的性能故障分析

文章目录

  • 问题现象
  • 问题分析
  • 问题修复
  • 线程池的混用策略
  • 任务类型与线程池配置
  • 最佳实践

在这里插入图片描述


问题现象

代码使用了线程池异步处理一些内存中的数据,但通过监控发现处理得非常慢,整个处理过程都是内存中的计算不涉及 IO 操作,也需要数秒的处理时间,应用程序 CPU 占用也不是特别高,有点不可思议


问题分析

经排查发现,业务代码使用的线程池,除了自身业务使用,同时还被一个后台的文件批处理任务用到了。

 private static ThreadPoolExecutor threadPool = new ThreadPoolExecutor(2, 2,1, TimeUnit.HOURS,new ArrayBlockingQueue<>(100),new ThreadFactoryBuilder().setNameFormat("batchfileprocess-threadpool-%d").build(),new ThreadPoolExecutor.CallerRunsPolicy());public int handleFile() throws ExecutionException, InterruptedException {return threadPool.submit(calcTask()).get();}

接下来我们模拟一下文件批处理的代码,在程序启动后通过一个线程开启死循环逻辑,不断向线程池提交任务,任务的逻辑是向一个文件中写入大量的数据

/*** 在Bean初始化完成后执行的方法* 此方法初始化线程池并启动一个新线程来执行特定任务*/
@PostConstruct
public void init() {// 打印线程池的初始状态和统计信息printStats(threadPool);// 创建并启动一个新的线程来执行批处理任务new Thread(() -> {// 生成一个由'a'字符组成的100万字符长的字符串作为负载String payload = IntStream.rangeClosed(1, 1_000_000).mapToObj(__ -> "a").collect(Collectors.joining(""));// 无限循环执行任务while (true) {// 使用线程池执行写入操作threadPool.execute(() -> {try {// 写入当前时间戳和负载到文件中Files.write(Paths.get("artisan.txt"), Collections.singletonList(LocalTime.now().toString() + ":" + payload), UTF_8, CREATE, TRUNCATE_EXISTING);} catch (IOException e) {// 打印异常信息e.printStackTrace();}// 记录日志,表示批处理任务完成log.info("batch file processing done");});}}).start();
}/*** 定期打印线程池的运行统计信息* 此方法内部创建了一个新的单线程调度器,用于定期执行打印线程池统计信息的任务* 它提供了线程池大小、活动线程数、已完成任务数和队列中任务数的信息* 这些信息有助于监控线程池的性能和工作负载* * @param threadPool 线程池对象,其统计信息将被打印*/
private void printStats(ThreadPoolExecutor threadPool) {Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> {// 打印分割线,用于区分不同的统计时间点log.info("=========================");// 打印线程池当前的线程数量log.info("Pool Size: {}", threadPool.getPoolSize());// 打印当前活动线程的数量log.info("Active Threads: {}", threadPool.getActiveCount());// 打印已完成任务的总数log.info("Number of Tasks Completed: {}", threadPool.getCompletedTaskCount());// 打印队列中等待执行的任务数量log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size());// 再次打印分割线,结束本次统计信息的打印log.info("=========================");}, 0, 1, TimeUnit.SECONDS);
}

流程如下:

初始化线程池统计信息
启动新线程
生成大字符串 payload
进入无限循环
使用 threadPool 执行任务
写入文件 artisan.txt
记录日志

通过 printStats 方法打印出的日志可以看到,这个线程池中的 2 个线程任务是相当重的。

在这里插入图片描述

  • 线程池的 2 个线程始终处于活跃状态,队列也基本处于打满状态

  • 因为开启了CallerRunsPolicy 拒绝处理策略,所以当线程满载队列也满的情况下,任务会在提交任务的线程,或者说调用 execute 方法的线程执行,也就是说不能认为提交到线程池的任务就一定是异步处理的。如果使用了 CallerRunsPolicy 策略,那么有可能异步任务变为同步执行。从日志的第四行也可以看到这点。这也是这个拒绝策略比较特别的原因


试想一下: 业务代码复用这样的线程池来做内存计算,会怎样???

写一段代码测试下,向线程池提交一个简单的任务,这个任务只是休眠 10 毫秒没有其他逻辑

/*** 创建一个计算任务,该任务在执行时会暂停一段时间然后返回固定的结果* * @return Callable<Integer> 一个计算任务,当运行时会暂停10毫秒,然后返回整数1*/
private Callable<Integer> calcTask() {return () -> {// 暂停10毫秒,模拟耗时操作或等待资源TimeUnit.MILLISECONDS.sleep(10);// 返回固定的结果1,表示任务完成return 1;};
}/*** 错误的异步任务处理示例* * 此方法展示了一个错误的异步任务处理方式,通过提交一个计算任务到线程池并立即获取结果的方式* 这种做法未能正确处理异步任务,因为它会导致线程池的线程阻塞,直到任务完成,从而降低了系统的整体性能和响应速度* * @return 计算任务的结果* @throws ExecutionException 如果计算任务执行失败* @throws InterruptedException 如果线程被中断*/
@GetMapping("wrong")
public int wrong() throws ExecutionException, InterruptedException {return threadPool.submit(calcTask()).get();
}

使用 wrk 工具对这个接口进行一个简单的压测,可以看到 TPS 为 75,性能的确非常差

在这里插入图片描述

细想一下,问题其实没有这么简单。因为 原来执行 IO 任务的线程池使用的是CallerRunsPolicy 策略,所以直接使用这个线程池进行异步计算的话,当线程池饱和的时候,计算任务会在执行 Web 请求的 Tomcat 线程执行,这时就会进一步影响到其他同步处理的线程,甚至造成整个应用程序崩溃


问题修复

解决方案很简单,使用独立的线程池来做这样的“计算任务”即可。计算任务打了双引号,是因为我们的模拟代码执行的是休眠操作,并不属于 CPU 绑定的操作,更类似 IO 绑定的操作,如果线程池线程数设置太小会限制吞吐能力

 /*** 创建一个固定大小的线程池用于异步计算任务* * 线程池的配置参数说明:* - 核心线程数和最大线程数都设置为200,意味着线程池只会创建200个线程来执行任务* - 线程空闲时间设为1小时,即线程在空闲1小时后将被终止* - 使用ArrayBlockingQueue作为任务队列,队列大小设为1000,这意味着在队列满的情况下,*   新提交的任务将等待直到队列中有空位* - 通过ThreadFactoryBuilder设置线程名称格式,以便于追踪和管理线程*/
private static ThreadPoolExecutor asyncCalcThreadPool = new ThreadPoolExecutor(200, 200,1, TimeUnit.HOURS,new ArrayBlockingQueue<>(1000),new ThreadFactoryBuilder().setNameFormat("asynccalc-threadpool-%d").build());/*** 使用异步方式计算并返回结果* 本方法通过提交一个计算任务到异步计算线程池,并等待任务完成后的结果* 如果任务抛出异常,将会被传播到调用者* * @return 计算结果* @throws ExecutionException 如果计算任务执行失败或被取消* @throws InterruptedException 如果等待结果时线程被中断*/
@GetMapping("right")
public int right() throws ExecutionException, InterruptedException {// 提交一个异步计算任务到线程池并获取Future对象,用于获取计算结果return asyncCalcThreadPool.submit(calcTask()).get();
}

使用单独的线程池改造代码后再来测试一下性能,TPS 提高到了 1727

在这里插入图片描述

在这个案例中,使用了一个只包含两个核心线程的线程池,同时被 I/O 密集型和 CPU 密集型任务共享,导致了性能瓶颈。由于采用了 CallerRunsPolicy 拒绝策略,当线程池达到饱和时,任务被回退到调用线程执行,进而影响了整个应用的性能。

这种配置的影响是显而易见的:异步任务的执行可能变成了同步执行,进一步降低了应用的响应能力。


线程池的混用策略

线程池的设计确实是为了复用资源,但这并不意味着所有任务都应共享同一个线程池。不同类型的任务(如 I/O 密集型与 CPU 密集型)对线程池的需求差异显著,因此需要谨慎选择线程池的配置和混用策略。


任务类型与线程池配置

  1. I/O 密集型任务:如网络请求或文件操作,通常需要更多的线程来处理潜在的阻塞,因此可配置较高的核心线程数,且队列大小适中。
  2. CPU 密集型任务:计算密集型任务应该限制线程数量,通常设置为 CPU 核数或 CPU 核数的两倍,以减少线程切换的开销。这类任务可能需要更大的队列来缓冲任务。

最佳实践

  • 任务隔离:为不同类型的任务创建独立的线程池,避免混用。
  • 合理配置:根据任务的特性(I/O 密集或 CPU 密集)合理设置线程池的核心参数。
  • 监控与调优:定期监控线程池的性能指标,根据实际需求进行调整。

在这里插入图片描述

http://www.lryc.cn/news/473480.html

相关文章:

  • 七种方法助你找到实用且免费的API服务
  • leetcode-74-搜索二维矩阵
  • 122.WEB渗透测试-信息收集-ARL(13)
  • 动态规划 —— 路径问题-下降路径最小和
  • 【Linux网络】TCP_Socket
  • NVR批量管理软件/平台EasyNVR多个NVR同时管理支持视频投放在电视墙上
  • Springboot集成阿里云通义千问(灵积模型)
  • 微信公众号(或微信浏览器)获取openId(网页授权)
  • C++算法第五天
  • 牛客网剑指Offer-树篇-JZ26 树的子结构
  • FFmpeg 4.3 音视频-多路H265监控录放C++开发六,使用SDLVSQT显示yuv文件
  • Spring 设计模式之适配器模式
  • 多传感器数字化分析系统
  • Java 基础教学:面向对象编程基础-封装、继承与多态
  • Ubuntu环境本地部署DbGate数据库管理工具并实现无公网IP远程访问
  • 【AI抠图整合包及教程】Meta SAM 2:视觉分割的革命性飞跃
  • 使用语言模型进行文本摘要的五个级别(llm)
  • ubuntu交叉编译libffi库给arm平台使用
  • 【jvm】空间分配担保策略
  • iQOO手机怎样将屏幕投射到MacBook?可以同步音频吗?
  • BUU usualCrypt1
  • 第十七章 标准库特殊设施
  • 【格言分享】程序员的经典名言解读
  • SpringBoot接收LocalDateTime参数
  • Typora配置GitHub图床--结合PicGo
  • 【书生.浦语实战营】——入门岛
  • WPF+MVVM案例实战(十四)- 封装一个自定义消息弹窗控件(下)
  • 嵌入式——STM32外设应用
  • HCIA(ACL)
  • react基础之reactHooks