当 ThreadPoolExecutor 饱和其核心线程和有界队列时，CallerRunsPolicy 将被拒绝的任务委托给提交者线程进行立即执行。如果该提交者线程调用 Future.get() 同步等待它刚提交的任务的结果，而提交的任务的逻辑内部向同一执行器提交额外的任务并等待其完成，就会发生循环等待。
提交者线程无法从 get() 返回，直到其任务完成，然而任务无法完成，因为它在等待排在它后面的子任务。没有工作线程可用来排空队列，因为所有线程都被其他任务占用。这有效地使提交者死锁，因为它既是能够执行排队的子任务的唯一线程（通过政策），又同时被阻塞在等待这些子任务完成。
我们在一个分布式文档处理管道中遇到了这个问题，其中 ThreadPoolExecutor 使用 CallerRunsPolicy 处理 PDF 渲染任务。每个文档任务解析元数据并生成用于图像提取的子任务，然后立即在这些子任务上调用 Future.get() 来组合最终结果。
在高负载下，队列饱和，触发 CallerRunsPolicy 在 web 请求处理线程中执行文档任务。该线程随后提交图像提取任务并在 get() 上阻塞，但所有工作线程都忙于其他文档。新的子任务在队列的尾部等待，没有被分配。
处理程序线程无法执行子任务，因为它被阻塞在等待它们，而子任务无法执行，因为没有线程空闲。这造成了一个自我加强的死锁，直到手动干预重启 JVM。
以下代码演示了这个危险的模式：
ExecutorService executor = new ThreadPoolExecutor( 2, 2, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<>(2), new ThreadPoolExecutor.CallerRunsPolicy() ); // 从主请求处理程序线程提交 Future<?> parent = executor.submit(() -> { // 当池饱和时，这在处理程序线程中运行 (CallerRunsPolicy) Future<?> child = executor.submit(() -> "生成的图像"); // 处理程序线程在此阻塞，等待子任务 // 但子任务在队列中，没有工作线程空闲 // 处理程序无法运行子任务，因为它被阻塞 return child.get(); }); parent.get(); // 死锁：处理程序线程永远等待
我们评估了四种不同的架构解决方案。第一种方法用 AbortPolicy 替换了 CallerRunsPolicy，并在客户端实现了指数退避重试循环。这保留了调用线程的可用性，但引入了瞬态故障和复杂的重试逻辑，使得幂等性保证变得复杂。
第二种解决方案扩展到一个无界的 LinkedBlockingQueue，以完全防止饱和。虽然这消除了拒绝，但在流量峰值下存在 OutOfMemoryError 的风险，并掩盖了背压信号，导致过高的延迟而不是明确的失败。
第三种选择保持有界队列，但显著增加了 maximumPoolSize，依赖线程繁殖来吸收负载。这提高了吞吐量，但代价是过多的上下文切换和内存消耗，最终因 CPU 缓存抖动而降低性能。
第四种方法重新构建了工作流程，使用 ExecutorCompletionService 和异步回调，而不是同步的 Future.get()。这使得原始文档任务能够在提交子任务后释放工作线程，并仅在 CompletionService 信号完成时恢复。
我们选择了第四种解决方案，因为它从根本上将提交与完成解耦。这保留了有界队列的背压，同时消除了循环等待条件，使工作线程能够回收并处理子任务，而原始任务在等待轻量级条件变量的通知。
这一变化解决了死锁，平均延迟减少了百分之四十，并在高峰负载下保持稳定的内存占用，而不牺牲有界队列的失败语义。
为什么当使用无界 BlockingQueue 配置时，ThreadPoolExecutor 拒绝实例化超过 corePoolSize 的线程？
执行器仅在 execute() 无法立即将任务交给等待的工作线程或将其插入队列时尝试创建新线程。无界队列的 offer() 方法永远不会返回 false，因此执行器从未感知到饱和，进而从未分配超过核心计数的线程。这一设计假设队列比线程创建更可取，但它创建了一个盲点，在这里尽管有待处理的工作，池看起来也未被充分利用。候选人经常错误地认为 maximumPoolSize 充当硬上限，而不考虑队列容量，未能认识到队列的有界性充当线程扩展的守门人。
如何 CallerRunsPolicy 作为隐式流控机制而不仅仅是拒绝处理程序？
通过在提交者线程中执行任务，该政策强迫该线程暂停其提交速率并进行工作，自然地限制了入站流量以匹配池的处理能力。这种背压向上传播到原始生产者，使其减缓速度，而没有显式的速率限制代码。许多候选人只将该政策视为丢失任务的安全措施，未能意识到它有意阻塞生产者以防止资源耗尽。理解这一语义区分对于设计在负载峰值下延迟比完全拒绝更可取的系统至关重要。
在 shutdown() 和 CallerRunsPolicy 之间有什么微妙的相互作用防止优雅降级？
一旦调用 shutdown()，执行器就会过渡到一个新的状态，在这个状态中，新提交将通过 RejectedExecutionException 被拒绝，完全绕过了已配置的拒绝策略。候选人常常假设 CallerRunsPolicy 会在关闭期间继续在调用者中执行任务，但执行器在查询策略之前会检查关闭状态。这意味着在优雅关闭阶段提交的任务立即失败，而不是由调用者执行，如果客户端不处理异常，这可能会导致正在进行的工作丢失。正确的关闭顺序需要通过 awaitTermination() 来排空队列，或者将被拒绝的任务捕获到故障转移结构中，因为一旦设置关闭标志，政策机制将被停用。