Java 21结构化并发：ShutdownOnSuccess耗时反超ShutdownOnFailure原因探究

核心原因分析： #

• 中断的额外开销：ShutdownOnSuccess的核心逻辑是在首个任务完成后，向剩余子任务发送中断信号并等待它们终止。但中断不是“即时杀死”线程——线程需要在可中断操作（如Thread.sleep()、Lock.lockInterruptibly()）中抛出异常，或者主动检查Thread.interrupted()来响应中断。这个过程中，JVM需要协调线程状态、处理中断异常、清理任务上下文，这些操作都会产生额外开销。而ShutdownOnFailure如果是等待所有任务自然完成（比如测试中所有任务都成功的场景），没有中断相关的额外操作，反而更高效。

• 任务的可中断性不足：如果你的测试任务是CPU密集型且未处理中断（比如一个无限循环不检查Thread.interrupted()），或者使用了不可中断的阻塞操作（比如Object.wait()未被唤醒，或者某些IO操作不支持中断），那么ShutdownOnSuccess发送的中断信号根本无法让子任务提前终止。此时ShutdownOnSuccess不仅要等待所有任务完成，还多了中断调度的开销，总耗时自然比ShutdownOnFailure更长。

• 线程调度的不确定性：JVM的线程调度是抢占式的，单次测试的结果可能受调度延迟影响。比如，首个完成的任务可能因为调度优先级低，反而比其他任务晚完成；或者中断信号传递时遇到线程安全点延迟，导致剩余任务没有及时响应中断，最终等待时间和自然完成差不多，但加上中断开销后总耗时更长。

• 短任务场景下的管理开销占比过高：如果你的测试任务本身执行时间很短（比如几毫秒），那么ShutdownOnSuccess用于跟踪首个完成任务、触发中断的管理开销，会在总耗时中占比更大。相比之下，ShutdownOnFailure的逻辑更简单（等待所有任务），管理开销占比更低，反而显得更快。

验证建议： #

• 确保测试任务是可中断的：比如在任务中加入Thread.sleep()，或者在循环中定期检查Thread.interrupted()。
• 增加任务的执行时长：比如把任务sleep时间设置到几百毫秒甚至几秒，放大中断带来的时间收益，抵消管理开销的影响。
• 多次测试取平均值：消除线程调度带来的单次结果波动。

内容的提问来源于stack exchange，提问作者Abhishek