forkjoinpool中没有随机队列，只有每个工作线程持有的双端队列workqueue；本地线程从top（lifo）操作，窃取线程从base（fifo）操作；scan()采用环形步进扫描而非遍历全部队列。
普通队列 vs 随机队列？ForkJoinPool 里根本没有“随机队列”
这是个常见误解——ForkJoinPool 不提供所谓“随机队列”，也不存在配置项叫 randomQueue 或类似名称。它只有一类队列：每个 ForkJoinWorkerThread 持有的 WorkQueue，本质是**双端队列（Deque）**，且严格区分访问端：本地线程从 top（头部，LIFO），窃取线程从 base（尾部，FIFO）。所谓“随机”，只是空闲线程在多个 workQueues 数组槽位中按固定步长轮询扫描，并非真随机。
scan() 怎么找可窃取的任务？不是遍历全部队列
scan() 方法（见 ForkJoinPool.scan(WorkQueue, int)）的查找过程高度优化，不暴力遍历所有 workQueues：
- 从一个起始索引
r & m（m = workQueues.length - 1）开始，按(k + 1) & m步进，形成环形扫描 - 每次只检查一个候选
WorkQueue q，先快速判断q.base - q.top （即队列非空） - 再用无锁方式读取尾部任务：
U.getObjectVolatile(a, (((a.length-1) & b) ，并双重校验 <code>q.base == b防止被修改 - 一旦成功窃取，立即返回；若绕一圈没找到，才触发
tryRelease尝试唤醒沉睡线程
为什么不能直接 queue.pollLast()？双端队列的指针设计是关键
真正实现“窃取不干扰本地执行”的，是 top 和 base 两个独立原子变量：
-
top：本地线程 push/pop 时仅修改它（栈顶），操作集中在数组高地址端 -
base：窃取线程只读+CAS 更新它（队尾），操作集中在低地址端 - 只要数组足够大、任务不极度倾斜，两者物理内存位置远离，CPU 缓存行冲突极小
- 如果强行用
ArrayDeque或ConcurrentLinkedDeque替代，会因共享状态导致严重竞争，性能反而暴跌
实际开发中容易忽略的三个细节
这些点不报错，但会让工作窃取“形同虚设”：
- 任务拆分阈值设得过大（比如
end - start > 1000000），导致子任务数远少于 CPU 核心数，大量线程闲置 - 在
compute()中调用了阻塞 I/O（如Thread.sleep()、File.read()），使线程卡住无法参与窃取，整个池吞吐骤降 - 误用
invoke()提交单个大任务后，又在外部用submit()批量扔任务——commonPool默认不扩容，新任务排队等待，窃取机制根本没机会启动
工作窃取不是自动生效的魔法，它依赖任务粒度、纯 CPU 计算、以及池的活跃线程数与负载动态匹配。少一个条件，就退回成普通线程池。
