线程池中的四种拒绝策略通常是指:
-
AbortPolicy(默认策略):这是默认的拒绝策略。当线程池无法接受新任务时,它会抛出RejectedExecutionException异常。
-
CallerRunsPolicy:在这种策略下,当线程池无法接受新任务时,会使用提交任务的线程来执行该任务。这样做的目的是为了降低新任务的提交速度,以便系统有时间处理现有的任务。
-
DiscardPolicy:这种策略下,当线程池无法接受新任务时,会直接丢弃被拒绝的任务,不会给出任何提示或警告。
-
DiscardOldestPolicy:在这种策略下,当线程池无法接受新任务时,会丢弃队列中等待时间最长的任务,并尝试将新任务添加到队列中。
线程池是 Java 多线程编程中的一个重要概念,它可以有效地管理和复用线程资源,提高系统的性能和稳定性。但是线程池的使用也有一些注意事项和常见的错误,如果不小心,就可能会导致一些严重的问题,比如内存泄漏、死锁、性能下降等。
本文将介绍线程池使用不当的五个坑,以及如何避免和解决它们,大纲如下,
坑一:线程池中异常消失
线程池执行方法时要添加异常处理,这是一个老生常谈的问题,可是直到最近我都有同事还在犯这个错误,所以我还是要讲一下,不过我还提到了一种优雅的线程池全局异常处理的方法,大家可以往下看。
问题原因
@Test
public void test() throws Exception {
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
5,
10,
60,
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100000));
Future<Integer> submit = threadPoolExecutor.execute(() -> {
int i = 1 / 0; // 发生异常
return i;
});
}
如上代码,在线程池执行任务时,没有添加异常处理。导致任务内部发生异常时,内部错误无法被记录下来。
解决方法
在线程池执行任务方法内添加 try/catch 处理,代码如下,
@Test
public void test() throws Exception {
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
5,
10,
60,
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100000));
Future<Integer> submit = threadPoolExecutor.execute(() -> {
try {
int i = 1 / 0;
return i;
} catch (Exception e) {
log.error(e.getMessage(), e);
return null;
}
});
}
优雅的进行线程池异常处理
当线程池调用任务方法很多时,那么每个线程池任务执行的方法内都要添加 try/catch 处理,这就不优雅了,其实 ThreadPoolExecutor 线程池类支持传入 ThreadFactory 参数用于自定义线程工厂,这样我们在创建线程时,就可以指定 setUncaughtExceptionHandler 异常处理方法。
这样就可以做到全局处理异常了,代码如下,
ThreadFactory threadFactory = r -> {
Thread thread = new Thread(r);
thread.setUncaughtExceptionHandler((t, e) -> {
// 记录线程异常
log.error(e.getMessage(), e);
});
return thread;
};
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
5,
10,
60,
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100000));
threadPoolExecutor.execute(() -> {
log.info("---------------------");
int i = 1 / 0;
});
不过要注意的是上面 setUncaughtExceptionHandler 方法只能针对线程池的 execute 方法来全局处理异常。对于线程池的 submit 方法是无法处理的。
坑二:拒绝策略设置错误导致接口超时
在 Java 中,线程池拒绝策略可以说一个常见八股文问题。大家虽然都记住了线程池有四种决绝策略,可是实际代码编写中,我发现大多数人都只会用 CallerRunsPolicy 策略(由调用线程处理任务)。我吃过这个亏,因此也拿出来讲讲。
问题原因
曾经有一个线上业务接口使用了线程池进行第三方接口调用,线程池配置里的拒绝策略采用的是 CallerRunsPolicy。示例代码如下,
// 某个线上线程池配置如下
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
50, // 最小核心线程数
50, // 最大线程数,当队列满时,能创建的最大线程数
60L, TimeUnit.SECONDS, // 空闲线程超过核心线程时,回收该线程的最大等待时间
new LinkedBlockingQueue<>(5000), // 阻塞队列大小,当核心线程使用满时,新的线程会放进队列
new CustomizableThreadFactory("task"), // 自定义线程名
new ThreadPoolExecutor.CallerRunsPolicy() // 线程执行的拒绝策略
);
threadPoolExecutor.execute(() -> {
// 调用第三方接口
...
});
在第三方接口异常的情况下,线程池任务调用第三方接口一直超时,导致核心线程数、最大线程数堆积被占满、阻塞队列也被占满的情况下,也就会执行拒绝策略,但是由于使用的是 CallerRunsPolicy 策略,导致线程任务直接由我们的业务线程来执行。
因为第三方接口异常,所以业务线程执行也会继继续超时,线上服务采用的 Tomcat 容器,最终也就导致 Tomcat 的最大线程数也被占满,进而无法继续向外提供服务。
解决方法
首先我们要考虑业务接口的可用性,就算线程池任务被丢弃,也不应该影响业务接口。
在业务接口稳定性得到保证的情况下,在考虑到线程池任务的重要性,不是很重要的话,可以使用 DiscardPolicy 策略直接丢弃,要是很重要,可以考虑使用消息队列来替换线程池。
坑三:重复创建线程池导致内存溢出
不知道大家有没有犯过这个问题,不过我确实犯过,归根结底还是写代码前,没有思考好业务逻辑,直接动手,写一步算一步
标签:JAVA,ThreadLocal,任务,线程,new,执行,ThreadPoolExecutor From: https://www.cnblogs.com/huliangqing/p/18008626