forkjoinpool.submit()在高频短任务场景下因反复触发线程唤醒、队列分配、任务封装和工作窃取等累积性开销而变慢；其非零成本提交路径、短任务下无效窃取、commonpool共享竞争及缺乏批处理机制共同导致延迟显著上升。

因为 forkjoinpool.submit() 在高频短任务场景下，会反复触发线程唤醒、队列分配、任务封装和工作窃取调度的轻量但累积性开销——这些操作单次极快，但每毫秒成百上千次调用时，就变成可观的延迟源。

任务提交本身不是“零成本”操作

ForkJoinPool 的 submit() 并非简单入队。它需完成：创建 ForkJoinTask 包装（哪怕只是 RunnableAdapter）、校验并入双端队列（deque）、检查当前线程是否为 ForkJoinWorkerThread、必要时唤醒闲置工作线程（unpark）。在短任务（如几十微秒级计算）下，这部分 JVM 内部路径耗时可能接近甚至超过任务本体执行时间。

工作窃取机制在短任务下反成负担

短任务生命周期极短，常在入队后立刻被同线程消费（LIFO 本地执行），极少需要跨队列窃取。但 ForkJoinPool 仍会按默认逻辑维护窃取尝试逻辑：检查其他线程队列状态、CAS 更新队列尾指针、处理空闲线程竞争。这些原子操作和分支预测失败，在高频率下带来显著 CPU cycle 消耗。

commonPool 共享竞争加剧延迟抖动

多数代码默认使用 ForkJoinPool.commonPool()。当多个虚拟线程或大量 short-lived 任务同时 submit，它们争抢同一个全局池的 ctl 控制变量、共享的 workQueues 数组槽位，引发缓存行失效（false sharing）和 CAS 自旋等待。实测显示：10K tasks/sec 提交下，平均 submit 延迟可从 50ns 升至 300–800ns，P99 延迟跳变明显。

JVM 层面对短任务缺乏“批处理”优化

ForkJoinPool 没有类似 Netty 的 flush 批量提交机制。每个 submit() 是独立调度单元，无法合并入队、无法预分配任务槽、也无法跳过中间状态检查。对比之下，结构化并发（如 Thread.ofVirtual().start() 直接执行）或专用短任务调度器（如 Loom 的 ScopedValue + 轻量循环）可绕过整个 ForkJoin 调度链路。

不复杂但容易忽略：真正拖慢系统的，往往不是大任务的执行，而是小任务提交时那一串“看不见”的簿记动作。