ForkJoinTask 的取消机制依赖于协作标志而不是强制线程中断。这意味着 cancel() 仅仅设置一个内部的 volatile 状态，任务必须显式轮询以观察终止请求。因此，这种设计无法解锁等待大型 I/O 操作的线程，例如 FileChannel 读取或套接字 InputStream 操作。这些阻塞调用不会检查取消标志，且无法通过标准线程中断机制被中断。
为了防止在工作线程阻塞时池的饥饿，ForkJoinPool.managedBlock API 允许开发者注册一个 ForkJoinPool.ManagedBlocker 实例。该阻塞器向池发出信号以生成一个补偿工作线程，在阻塞工作时保持目标并行性水平。阻塞器的 isReleasable 方法提供了检查取消状态或以编程方式中断被阻塞操作的钩子。这使得池能够优雅降级，而不是在无响应的 I/O 上耗尽线程预算。
我们在构建一个并行日志处理器时遇到了这个限制，该处理器在自定义 RecursiveTask 中使用 Files.lines()。该任务解析来自网络挂载存储设备的 TB 级日志文件。当用户请求取消长期运行的分析作业时，ForkJoinPool 线程在阻塞的 read() 系统调用中停滞了几分钟。它们完全忽略了取消标志，导致无法启动新任务并造成严重的线程饥饿。
我们考虑了三种不同的方法来解决死锁。第一种方法是完全放弃 ForkJoinPool，改用缓存的 ThreadPoolExecutor。这提供了更简单的中断语义和即时的线程替换，但牺牲了对我们 CPU 密集型解析阶段至关重要的工作窃取效率。
第二种方法建议将每个 I/O 调用包装在 Thread.interrupt() 逻辑中，并切换到可中断的通道，如 SocketChannel。虽然这支持即时取消，但证明是侵入性的，并且与依赖于标准阻塞流和第三方解析器的遗留库代码不兼容。
第三种方法利用 ForkJoinPool.managedBlock，通过实现一个自定义的 ManagedBlocker 来包装文件读取循环。这个阻塞器定期检查 isCancelled()，同时允许池通过阻塞器协议生成补偿线程。我们选择了第三个解决方案，因为它保留了现有的并行流架构，同时明确向池通报阻塞操作。这确保了取消响应性和吞吐量之间的平衡，而无需重写整个 I/O 层。
结果是一个系统，其中取消请求在几秒钟内传播，而不是几分钟。该池在 I/O 峰值期间动态扩展至五十个线程，而无需手动配置。CPU 饱和度在整个工作负载中保持较高，即使在网络拥塞严重时，作业终止也变得可靠。
ForkJoinPool 如何在没有显式 managedBlock 调用的情况下检测线程阻塞，以及生成补偿线程的阈值是多少？
池内部通过一个 64 位的 ctl 字段跟踪工作线程状态，该字段表示活动与停放的计数。当工作线程执行任务时，它被计数为“活动”，但无法区分 CPU 密集型工作和阻塞 I/O，除非程序员提供提示。当工作线程在同步监视器或 I/O 上阻塞而不使用 managedBlock 时，池观察到的只是可窃取工作的减少和可用工作者的减少。如果达到并行性水平且未收到任何进展信号，它可能最终会停滞。只有在调用 managedBlock 或通过 Unsafe.park 计数器检测到内部 JVM 阻塞时，补偿线程才会可靠生成，但默认阈值对于自定义阻塞代码是不透明和不可靠的。
为什么 ForkJoinTask.join() 在任务被取消时不会立即返回，以及它与带超时的 Future.get() 有何不同？
join() 内部调用 doJoin()，它实现了一种“帮助”机制，调用线程执行或窃取其他工作，直到目标任务完成。这在任何情况下都发生，无论取消状态如何，因为取消仅仅阻止新的子任务分叉并设置完成标志。该方法在等待之前并不会轮询取消标志，也不会在入口处抛出 CancellationException。相比之下，Future.get() 在 ForkJoinTask （实现了 Future）上立即检查取消状态，并且可以在不等待的情况下抛出 CancellationException。这一区别至关重要，因为 join() 是为池内协作设计的，而 get() 是为了外部客户端期望标准 Future 语义。
ForkJoinPool 的并行性级别与 Runtime.availableProcessors() 之间的互动是什么，为什么将并行性设置为高于可用处理器可能会提高阻塞操作的吞吐量？
默认的公共池初始化为 availableProcessors() - 1 以保留一个核心用于应用程序线程或垃圾收集。并行性定义了活动线程的目标数量，而不是硬性上限；如果 managedBlock 表示阻塞工作，池可以创建更多线程，但旨在仅保持真正活动的 parallelism 线程。对于阻塞操作，将并行性设置为高于核心数量（例如：2 倍或 3 倍核心）允许调度程序在其他线程等待 I/O 时保持 CPU 忙碌。这通过确保每个核心都有可运行的任务来消除“每核心一个线程”的限制。但是，这需要仔细调整，以防止在阻塞比率估计不准确时造成过多的上下文切换开销。