asyncMode=true时任务按FIFO顺序提交和执行，适用于事件驱动类场景；而asyncMode=false时因LIFO本地队列和工作窃取可能导致后提交先执行。
asyncMode=true 时任务入队和执行顺序是 FIFO
ForkJoinPool 的 asyncMode 参数控制其内部双端队列（Deque）的任务调度策略。设为 true 后，线程从自己队列取任务时改为从**头部弹出（LIFO）**，而其他线程窃取时则从**尾部取（FIFO）**；但更重要的是：**外部提交的任务（如 execute()）会被直接压入全局提交队列（Submission Queue），该队列本身是 FIFO，且仅由一个专用线程轮询分发到工作线程本地队列尾部**。这意味着：任务提交顺序 ≈ 实际开始执行顺序，尤其适合事件驱动类场景中保持请求到达先后关系。
- 默认
asyncMode=false（即同步模式）下，invoke()和submit()提交的任务可能因工作窃取和本地队列 LIFO 特性导致“后提交先执行” -
asyncMode=true不改变任务计算逻辑，只影响调度行为；它不提供“优先级抢占”，而是通过 FIFO 保障提交时序的可预测性 - 该参数对
RecursiveTask/RecursiveAction子任务的fork()行为无直接影响——子任务仍走本地队列 LIFO，但外部初始任务的排队更线性
哪些任务适合开启 asyncMode
不是所有场景都受益于 asyncMode=true。它真正起作用的前提是：任务本身**不依赖深度递归拆分、不频繁调用 join()、且提交节奏接近实时事件流**。
- ✅ 适用：消息监听器回调、HTTP 请求预处理、事件总线中的简单转换任务（如 JSON 解析 + 字段校验）
- ❌ 不适用：归并排序、分治搜索等需大量
fork()/join()协作的 CPU 密集型任务——此时 LIFO 更利于局部性与缓存友好，asyncMode=true反而增加窃取开销 - ⚠️ 注意：
asyncMode对虚拟线程无实际意义——虚拟线程默认挂载的公共池（ForkJoinPool.commonPool()）已固定为asyncMode=true，且你无法修改它
如何验证 asyncMode 是否生效
不能只看代码里传了 true 就认为 FIFO 生效。关键要确认任务确实走的是外部队列路径，而非被某个工作线程直接“内联执行”。
- 用
pool.execute(runnable)提交任务，**不要用pool.invoke(task)** ——后者会尝试同步执行，绕过外部队列 - 避免在提交线程中立即调用
pool.awaitQuiescence()或shutdown()，这会干扰队列分发节奏 - 最简验证方式：连续提交 3 个带时间戳打印的任务，观察输出顺序是否严格按提交顺序（注意关闭 JVM 的 JIT 优化干扰，可用
-XX:-TieredStopAtLevel1启动）
asyncMode 的本质不是赋予任务“高优先级”，而是降低调度不确定性。真正需要优先级区分的业务逻辑，必须在任务内部实现（比如用 PriorityBlockingQueue 拉取子任务），ForkJoinPool 本身不支持 per-task 优先级字段或抢占式调度。
