【踩坑指南】线程池使用不当的五个坑

线程池是 Java 多线程编程中的一个重要概念，它可以有效地管理和复用线程资源，提高系统的性能和稳定性。但是线程池的使用也有一些注意事项和常见的错误，如果不小心，就可能会导致一些严重的问题，比如内存泄漏、死锁、性能下降等。
本文将介绍线程池使用不当的五个坑，以及如何避免和解决它们，大纲如下，

坑一：线程池中异常消失

线程池执行方法时要添加异常处理，这是一个老生常谈的问题，可是直到最近我都有同事还在犯这个错误，所以我还是要讲一下，不过我还提到了一种优雅的线程池全局异常处理的方法，大家可以往下看。
问题原因

1. @Test
2. public void test() throws Exception {
3.     ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
4.         5,
5.         10,
6.         60,
7.         TimeUnit.SECONDS,
8.         new ArrayBlockingQueue<>(100000));
9.     Future<Integer> submit = threadPoolExecutor.execute(() -> {
10.         int i = 1 / 0; // 发生异常
11.         return i;
12.     });
13. }

复制代码

如上代码，在线程池执行任务时，没有添加异常处理。导致任务内部发生异常时，内部错误无法被记录下来。
解决方法

在线程池执行任务方法内添加 try/catch 处理，代码如下，

1. @Test
2. public void test() throws Exception {
3.     ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
4.         5,
5.         10,
6.         60,
7.         TimeUnit.SECONDS,
8.         new ArrayBlockingQueue<>(100000));
9.     Future<Integer> submit = threadPoolExecutor.execute(() -> {
10.         try {
11.             int i = 1 / 0;
12.             return i;
13.         } catch (Exception e) {
14.             log.error(e.getMessage(), e);
15.             return null;
16.         }
17.     });
18. }

复制代码

优雅的进行线程池异常处理

当线程池调用任务方法很多时，那么每个线程池任务执行的方法内都要添加 try/catch 处理，这就不优雅了，其实 ThreadPoolExecutor 线程池类支持传入 ThreadFactory 参数用于自定义线程工厂，这样我们在创建线程时，就可以指定 setUncaughtExceptionHandler 异常处理方法。
这样就可以做到全局处理异常了，代码如下，

1. ThreadFactory threadFactory = r -> {
2.     Thread thread = new Thread(r);
3.     thread.setUncaughtExceptionHandler((t, e) -> {
4.         // 记录线程异常
5.         log.error(e.getMessage(), e);
6.     });
7.     return thread;
8. };
9. ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
10.     5,
11.     10,
12.     60,
13.     TimeUnit.SECONDS,
14.     new ArrayBlockingQueue<>(100000));
15. threadPoolExecutor.execute(() -> {
16.     log.info("---------------------");
17.     int i = 1 / 0;
18. });

复制代码

不过要注意的是上面 setUncaughtExceptionHandler 方法只能针对线程池的 execute 方法来全局处理异常。对于线程池的 submit 方法是无法处理的。
坑二：拒绝策略设置错误导致接口超时

在 Java 中，线程池拒绝策略可以说一个常见八股文问题。大家虽然都记住了线程池有四种决绝策略，可是实际代码编写中，我发现大多数人都只会用 CallerRunsPolicy 策略（由调用线程处理任务）。我吃过这个亏，因此也拿出来讲讲。
问题原因

曾经有一个线上业务接口使用了线程池进行第三方接口调用，线程池配置里的拒绝策略采用的是 CallerRunsPolicy。示例代码如下，

1. // 某个线上线程池配置如下
2. ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
3.         50, // 最小核心线程数
4.         50, // 最大线程数，当队列满时，能创建的最大线程数
5.         60L, TimeUnit.SECONDS, // 空闲线程超过核心线程时，回收该线程的最大等待时间
6.         new LinkedBlockingQueue<>(5000), // 阻塞队列大小,当核心线程使用满时，新的线程会放进队列
7.         new CustomizableThreadFactory("task"), // 自定义线程名
8.         new ThreadPoolExecutor.CallerRunsPolicy() // 线程执行的拒绝策略
9. );
11. threadPoolExecutor.execute(() -> {
12.     // 调用第三方接口
13.     ...
14. });

复制代码

在第三方接口异常的情况下，线程池任务调用第三方接口一直超时，导致核心线程数、最大线程数堆积被占满、阻塞队列也被占满的情况下，也就会执行拒绝策略，但是由于使用的是 CallerRunsPolicy 策略，导致线程任务直接由我们的业务线程来执行。
因为第三方接口异常，所以业务线程执行也会继继续超时，线上服务采用的 Tomcat 容器，最终也就导致 Tomcat 的最大线程数也被占满，进而无法继续向外提供服务。
解决方法

首先我们要考虑业务接口的可用性，就算线程池任务被丢弃，也不应该影响业务接口。
在业务接口稳定性得到保证的情况下，在考虑到线程池任务的重要性，不是很重要的话，可以使用 DiscardPolicy 策略直接丢弃，要是很重要，可以考虑使用消息队列来替换线程池。
坑三：重复创建线程池导致内存溢出


不知道大家有没有犯过这个问题，不过我确实犯过，归根结底还是写代码前，没有思考好业务逻辑，直接动手，写一步算一步
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！