系统性能优化的几种常用手段是异步和缓存。因此我们常常使用线程池异步处理一些业务。
线程池的使用还是相对比较简单的，首先创建一个线程池，然后通过execute或submit执行任务。
但魔鬼往往藏于细节之中，稍有不慎就会出错。本文将会详细总结线程池容易出错的五大坑
一、拒绝策略参数知多少
二、拒绝策略使用不当，系统阻塞不可用
三、多任务get()异常时,结果获取有误
四、ThreadLocal与线程池搭配使用，上下文缺失
五、父子任务共用同一线程池，系统”饥饿”死锁
以下为线程池的核心流程【具体内容参考：线程池原理】
一、拒绝策略参数知多少
我们都知道，当任务过多，线程池处理不过来时会被拒绝，进入拒绝策略
public interface RejectedExecutionHandler {
void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}
通过实现RejectedExecutionHandler，就可以作为线程池的拒绝策略使用。
目前官方提供了四种拒绝策略，分别为：
- CallerRunsPolicy：由任务调用方执行
- AbortPolicy：抛出异常，同样也是由任务调用方处理异常
- DiscardPolicy：丢弃当前任务
- DiscardOldestPolicy：丢弃队列中最老的任务，并执行当前任务
线程池有execute和submit两种方法执行任务：
execute执行我们最原始的任务；
而submit则不同，先是将我们最原始的任务封装成FutureTask任务，然后将FutureTask任务交由execute执行
线程池拒绝策略中Runnable r就是execute执行的任务，因此 当使用r时就要注意它是我们最原始的任务还是FutureTask任务
二、拒绝策略使用不当，系统阻塞不可用
前面我们讲到submit方法执行任务时，线程池会先封装任务到FutureTask中，然后我们通过FutureTask的get()方法获取任务处理的结果
【具体内容参考：一张动图，彻底懂了execute和submit】
Possible state transitions:
NEW -> COMPLETING -> NORMAL（任务执行完成）
NEW ->COMPLETING -> EXCEPTIONAL（任务抛出异常）
NEW -> CANCELLED（任务被取消）
NEW -> INTERRUPTING -> INTERRUPTED（任务被打断）
FutureTask在被创建时状态为NEW，任务执行到某个阶段就会修改成相应状态，直到达到最终态。
FutureTask根据状态变更来标识任务执行进度的，因此get()方法也是在状态达到最终态（任务执行成果/异常/被取消/被打断）时才能返回结果，否则挂起当前线程等待到达最终态。
问题原因：
1、当任务通过submit方法执行时，会创建FutureTask（此时状态为NEW）
2、任务被拒绝且拒绝策略为丢弃任务（DiscardOleddestPolicy或DiscardPolicy）时，任务直接被线程池丢弃（此时状态仍为NEW）
3、当执行get()方法时，由于任务一直处于NEW状态，没有达到最终态，线程会一直处于阻塞状态
解决方案：
问题原因在于：任务无法变成最终态，导致阻塞。
因此我们可以 重写rejectedExecution方法，将任务置为最终态
FutureTask的cancel方法可以将任务状态置为CANCELLED或INTERRUPTED
public static RejectedExecutionHandler customDiscardPolicy () {
return new DiscardPolicy() {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
if (r != null && r instanceof FutureTask) {
((FutureTask) r).cancel(true);
}
}
}
};
}
三、多任务get()异常时,结果获取有误
submit方法中，futureTask会捕获异常，在get()时抛出。
若批量执行多个方法，且for循环get()结果时，捕获异常要在循环内，而不是循环外。否则会影响其他任务的结果输出
捕获异常在循环外，当一个任务get异常时，后续其他任务就不能再获取结果
List taskResultList = new ArrayList<>();
try {
for (Future future : futureList) {
if (future == null) {continue;}
TaskResult result = future.get();
taskResultList.add(result);
}
} catch (Throwable t) {
//这种场景下，当一个任务get异常时，后续其他任务就不能再获取结果
LOGGER.error("任务执行异常", t);
}
因此 在循环内捕获异常，各个任务互相不受影响
List taskResultList = new ArrayList<>();
for (Future future : futureList) {
try {
if (future == null) {continue;}
TaskResult result = future.get();
taskResultList.add(result);
} catch (Throwable t) {
LOGGER.error("任务执行异常", t);
}
}
四、ThreadLocal与线程池搭配使用，上下文缺失
ThreadLocal的使用一般都是这几个方法：
private final static ThreadLocal cacheInfoThreadLocal = new ThreadLocal();
cacheInfoThreadLocal.set(cacheInfo);
cacheInfoThreadLocal.get();
cacheInfoThreadLocal.remove();
为防止内存泄漏，在使用完ThreadLocal后都会调用remove()清除数据
问题描述：
1、当任务需要调用方线程的ThreadLocal信息时，通用方式就是将调用方ThreadLocal信息赋值到执行任务的线程中，在任务执行结束后调用remove()清除数据
2、同时任务恰好被线程池拒绝，且使用的拒绝策略是CallerRunsPolicy时，任务会被调用方线程执行。
3、若此时任务执行结束后仍调用remove()清除数据，清除的就会是调用方的ThreadLocal数据。
调用方ThreadLocal数据被清除，数据丢失在工作中将会是灾难性的。
解决方案：
问题出现的原因是任务由于被拒绝，导致误删除了调用方ThreadLocal数据
因此可以在任务执行时判断执行线程是否为调用方线程。
若是则不用set()复制和remove()清空数据
public abstract class ParallelCallableTask implements Callable {
//调用方线程名称
private String mainThreadName;
public ParallelCallableTask() {
mainThreadName = Thread.currentThread().getName();
}
@Override
public V call() throws Exception {
//是否为同一线程
boolean sameThread = sameThread();
return proccess(sameThread);
}
/**判断 调用方线程 和 执行线程 是否为同一线程*/
private boolean sameThread () {
String curThreadName = Thread.currentThread().getName();
return curThreadName.equals(mainThreadName);
}
//任务重写这个方法并根据sameThread判断是否需要set和remove调用方线程的ThreadLocal数据
public abstract V proccess(boolean sameThread);
}
待执行的任务通过重写process方法，并根据sameThread判断是否和主线程一致，一致则不重复设置相同的threadLocal和删除threadLocal
五、父子任务共用同一线程池，系统”饥饿”死锁
A方法调用B方法，AB方法称为父子任务。
当他们都被同一个线程池执行时，一定条件下会出现以下场景：
1、父任务获取到线程池线程执行，而子任务则被暂存到队列中
2、当父任务占满了线程池所有的线程，等待子任务返回结果后，结束父任务
3、此时子任务由于在队列中，一直不能等到线程来处理，导致不能从队列中释放
4、父子任务互相等待，从而造成”饥饿”死锁
我们举一个简单例子：
假设线程池参数设置为：核心和最大线程数为1，队列容量为1
A方法内调用B方法：
A（） {
B（）；
}
现在父子任务都被同一个线程池进行调用，整个流程为（如图所示）：
1、线程池创建核心线程，并执行A方法
2、执行到B方法时，将B交给线程池执行，由于没有多余线程，因此暂存队列
3、A任务等待B任务执行完，B任务等待A任务释放线程。从而互相等待，造成”饥饿”死锁
解决方案：
问题原因在于互相等待，因此只要保证类似的 父子任务不要被同一线程池执行即可
Original: https://www.cnblogs.com/mlwy/p/15491795.html
Author: zy苦行僧
Title: 细数线程池五大坑，一不小心线上就崩了
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/576374/
转载文章受原作者版权保护。转载请注明原作者出处！