看起来是线程池的BUG，但是我认为是源码设计不合理。

前几天看到一个 JDK 线程池的 BUG，我去了解了一下，摸清楚了它的症结所在之后，我觉得这个 BUG 是属于一种线程池方法设计不合理的地方，而且官方在知道这个 BUG 之后表示：确实是个 BUG，但是我就不修复了吧，你就当这是一个 feature 吧。

在带你细嗦这个 BUG 之前，我先问一个问题：

JDK 自带的线程池拒绝策略有哪些？

这玩意，老八股文了，存在的时间比我从业的时间都长，得张口就来：

• AbortPolicy：丢弃任务并抛出 RejectedExecutionException 异常，这是默认的策略。
• DiscardOldestPolicy：丢弃队列最前面的任务，执行后面的任务
• CallerRunsPolicy：由调用线程处理该任务
• DiscardPolicy：也是丢弃任务，但是不抛出异常，相当于静默处理。

这次的这个 BUG 触发条件之一，就藏着在这个 DiscardPolicy 里面。

但是你一去看源码，这个玩意就是个空方法啊，这能有什么 BUG？

它错就错在是一个空方法，把异常给静默处理了。

别急，等我慢慢给你摆。

啥BUG啊？

BUG 对应的链接是这个：

bugs.openjdk.org/browse/JDK-…

标题大概就是说：噢，我的老伙计们，听我说，我发现线程池的拒绝策略 DiscardPolicy 遇到 invokerAll 方法的时候，可能会导致线程一直阻塞哦。

然后在 BUG 的描述部分主要先注意这两段：

这两段透露出两个消息：

• 1.这个 BUG 之前有人提出来过。
• 2.Doug 和 Martin 这两位也知道这个 BUG，但是他们觉得用户可以通过编码的方式避免永远阻塞的问题。

所以我们还得先去这个 BUG 最先出现的地方看一下。也就是这个链接：

bugs.openjdk.org/browse/JDK-…

从标题上来看，这两个问题非常的相似，都有 invokerAll 和 block，但是触发的条件不一样。

一个是 DiscardPolicy 拒绝策略，一个是 shutdownNow 方法。

所以我的策略是先带你先把这个 shutdownNow 方法嗦明白了，这样你就能更好的理解 DiscardPolicy 带来的问题。

本质上，它们说的是一回事儿。

现象

在 shutdownNow 相关的这个 BUG 描述里面，提问者给到了他的测试用例，我稍微改改，就拿来就用了。

bugs.openjdk.org/browse/JDK-…

代码贴在这里，你也可以那到你本地跑一下：

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.newFixedThreadPool(2);
        Thread executorInvokerThread = new Thread(() -> {