工作窃取队列需无锁双端结构，本地用LIFO（pop）、窃取用FIFO（pollFirst），核心是原子维护top/base索引与2的幂数组，任务须不可变并加内存屏障，满时应分层缓冲而非加锁。
Deque 的 pollFirst() 和 offerLast() 为什么不能直接用于工作窃取
因为标准 ArrayDeque 和 LinkedBlockingDeque 都不是线程安全的（前者完全无锁但非并发安全，后者加锁粒度大），而工作窃取要求「本地线程高频 push/pop，其他线程低频 steal」——必须分离读写路径，避免伪共享和 CAS 冲突。
常见错误现象：ConcurrentModificationException 或无限重试循环，尤其在高竞争下 pollFirst() 返回 null 却实际有任务，本质是缺乏内存可见性与原子状态判断。
- 本地执行用
pop()（LIFO）提升缓存局部性，窃取端必须用pollFirst()（FIFO）防饥饿，二者语义不能混用 -
ArrayDeque的扩容机制在多线程下会破坏数组连续性假设，导致cas失败后无法回退 - 别试图用
ConcurrentLinkedDeque：JDK 未提供该类，ConcurrentLinkedQueue是单端，不支持双端原子操作
用 AtomicReferenceArray 手写无锁双端栈的核心结构
工作窃取队列本质是「本地线程独占的栈 + 其他线程只读首尾的队列」，所以只需保证两个位置原子更新：栈顶索引（top）和底端索引（base）。所有操作围绕这两个 AtomicInteger 展开，数组本身只做存储容器。
关键设计点：本地 push/pop 操作只改 top；窃取线程尝试 CAS base，且仅当 top > base + 1 时才允许取走 base 位置的任务（留至少一个防竞争丢失）。
立即学习“Java免费学习笔记（深入）”；
- 数组长度必须是 2 的幂，用位运算替代取模：
index & (array.length - 1) - push 时先 CAS
top，成功后再写数组；pop 时先读top，再 CAS 递减，最后读数组 —— 顺序不能反，否则出现 ABA 问题 - 窃取失败不自旋，立即放弃：工作窃取本就是尽力而为，频繁失败说明负载已均衡
int t = top.get();
int b = base.get();
if (t > b + 1) {
if (base.compareAndSet(b, b + 1)) {
return array[b & mask];
}
}为什么 StealTask 必须是不可变对象 + 显式内存屏障
任务对象一旦入队，就可能被多个线程读取（本地执行、其他线程窃取），若任务含可变字段（如 status 字段），不同线程看到的值可能不一致，导致重复执行或漏执行。
常见错误场景：任务里调用 System.currentTimeMillis() 记录开始时间，结果窃取线程看到的是 0 —— 因为写操作没对其他 CPU 核心可见。
- 所有任务字段声明为
final，构造即完成初始化 - 若需运行时状态，改用
AtomicIntegerFieldUpdater控制特定字段，避免整个对象加锁 - 在
push()最后插入Unsafe.storeFence()（或 JDK9+ 的VarHandle.releaseFence()），确保数组写入对其他线程可见
本地队列满时的 fallback 策略比锁更关键
无锁结构无法动态扩容，数组大小必须预设。填满后若强行拒绝任务，会导致提交线程阻塞或丢任务；若退化为加锁队列，又破坏无锁设计初衷。
真实生产中更有效的做法是分层缓冲：本地无锁栈 → 线程组共享的 TransferQueue → 全局阻塞队列。只有前两层都满才触发第三层。
- 本地栈大小建议设为 4096（兼顾 L1 缓存行与空间利用率），超过后转交
ForkJoinPool.commonPool()的submit() - 避免用
synchronized包裹整个offer()，哪怕只有一行 —— 锁会把无锁队列变成串行瓶颈 - 监控指标重点看
stealCount和localQueueOverflow，前者持续为 0 说明负载不均，后者突增说明预估容量过小
真正难的不是写对那几个 CAS，而是让本地线程足够“懒”——只在必要时才检查其他队列是否可窃取，其余时间专注自己的栈。这点容易被忽略，但决定整体吞吐上限。
