前几天看到一个 JDK 线程池的 BUG,我去了解了一下,摸清楚了它的症结所在之后,我觉得这个 BUG 是属于一种线程池方法设计不合理的地方,而且官方在知道这个 BUG 之后表示:确实是个 BUG,但是我就不修复了吧,你就当这是一个 feature 吧。
在带你细嗦这个 BUG 之前,我先问一个问题:
JDK 自带的线程池拒绝策略有哪些?
这玩意,老八股文了,存在的时间比我从业的时间都长,得张口就来:
- AbortPolicy:丢弃任务并抛出 RejectedExecutionException 异常,这是默认的策略。
- DiscardOldestPolicy:丢弃队列最前面的任务,执行后面的任务
- CallerRunsPolicy:由调用线程处理该任务
- DiscardPolicy:也是丢弃任务,但是不抛出异常,相当于静默处理。
这次的这个 BUG 触发条件之一,就藏着在这个 DiscardPolicy 里面。
但是你一去看源码,这个玩意就是个空方法啊,这能有什么 BUG?
它错就错在是一个空方法,把异常给静默处理了。
别急,等我慢慢给你摆。
啥BUG啊?
BUG 对应的链接是这个:
标题大概就是说:噢,我的老伙计们,听我说,我发现线程池的拒绝策略 DiscardPolicy 遇到 invokerAll 方法的时候,可能会导致线程一直阻塞哦。
然后在 BUG 的描述部分主要先注意这两段:
这两段透露出两个消息:
- 1.这个 BUG 之前有人提出来过。
- 2.Doug 和 Martin 这两位也知道这个 BUG,但是他们觉得用户可以通过编码的方式避免永远阻塞的问题。
所以我们还得先去这个 BUG 最先出现的地方看一下。也就是这个链接:
从标题上来看,这两个问题非常的相似,都有 invokerAll 和 block,但是触发的条件不一样。
一个是 DiscardPolicy 拒绝策略,一个是 shutdownNow 方法。
所以我的策略是先带你先把这个 shutdownNow 方法嗦明白了,这样你就能更好的理解 DiscardPolicy 带来的问题。
本质上,它们说的是一回事儿。
现象
在 shutdownNow 相关的这个 BUG 描述里面,提问者给到了他的测试用例,我稍微改改,就拿来就用了。
代码贴在这里,你也可以那到你本地跑一下:
public class MainTest {
public static void main(String[] args) throws InterruptedException {
List<Callable<Void>> tasks = new ArrayList<>();
for (int i = 0; i < 10; i++) {
int finalI = i;
tasks.add(() -> {
System.out.println("callable "+ finalI);
Thread.sleep(500);
return null;
});
}
ExecutorService executor = Executors.