工作窃取机制被io阻塞彻底破坏：阻塞线程挂起导致算力缺失、任务树冻结、无超时熔断，故io操作必须剥离至独立线程池。
因为这会严重拖垮整个 ForkJoinPool 的吞吐能力，甚至导致线程饥饿、任务积压和系统响应停滞。
工作窃取机制会被 IO 阻塞彻底破坏
ForkJoinPool 的核心优势在于“工作窃取”——空闲线程能主动从其他线程的双端队列尾部偷任务执行。但这个机制依赖所有线程持续可用、快速切换。一旦某个线程在 compute() 中发起文件读写、数据库查询或网络调用，它就会被操作系统挂起，长时间不返回。此时它既不完成当前任务，也不释放线程资源，更无法参与窃取，等于从并行计算网络中“消失”了一个节点。
commonPool 默认只配 CPU 核心数减 1 的线程
绝大多数未显式指定池的 ForkJoinTask（比如并行流、CompletableFuture 的 async 方法）都跑在 ForkJoinPool.commonPool() 上。该池默认线程数是 Runtime.getRuntime().availableProcessors() - 1，专为 CPU 密集型任务设计。它没有冗余线程来“等 IO”，一个阻塞就少一个有效算力。若 8 核机器上同时有 3 个任务做磁盘读取，可能瞬间卡住 3/7 ≈ 43% 的并行能力。
阻塞线程会传染式拖慢整个任务树
Fork/Join 是深度递归结构：父任务调用 fork() 提交子任务后，常紧跟着 join() 等待结果。如果任意一层子任务因 IO 阻塞，父任务就会在 join() 处停住，无法继续向下分解或合并。整棵任务树像被按了暂停键，后续所有依赖它的逻辑全部冻结——哪怕那些本可纯计算的部分也动不了。
没有超时控制与熔断，错误会静默放大
- ForkJoinTask 不支持设置 join 超时，join() 会无限等待
- 池内无健康检查，不会自动剔除或替换长期阻塞的线程
- 异常通常只抛给调用方，上游难以感知底层是 IO 卡死还是逻辑出错
结果就是问题难以定位：监控看到的是“任务耗时飙升”，日志里却找不到明显报错，排查时容易误判为算法低效或数据倾斜。
IO 密集操作必须剥离到独立线程池（如自定义的 CachedThreadPool 或固定大小的 ScheduledThreadPool），再通过 CompletableFuture.supplyAsync(..., ioPool) 衔接。ForkJoinPool 只应承载真正轻量、快速、纯内存的计算分支。
