LinkedBlockingDeque 不处理工作窃取变量，而是提供线程安全、双端阻塞队列能力，支持通过takeFirst()/takeLast()分离消费与窃取操作，降低竞争，适用于定制化工作窃取场景。
LinkedBlockingDeque 本身不处理“工作窃取变量”，它不持有或管理所谓“窃取变量”——工作窃取（Work Stealing）是一种并发调度策略，而 LinkedBlockingDeque 是一种支持该策略的底层数据结构。它的价值在于提供线程安全、双端操作、可阻塞的队列能力，使开发者能基于它手动构建工作窃取逻辑，比如为每个线程配一个本地队列，并在空闲时从他人队列尾部取任务。
为什么 LinkedBlockingDeque 适合工作窃取场景
工作窃取的核心是降低竞争、提升吞吐：每个线程优先操作自己的队列，仅在空闲时才访问他人队列。LinkedBlockingDeque 的双向特性天然适配这一分工：
- 任务所有者始终从队头（first）takeFirst()消费，保证 FIFO 或局部顺序性，也便于实现优先级调度（如高优任务插队头）
- 窃取者则从其他队列的队尾（last）takeLast()获取任务，避免与原线程的头端操作冲突，显著减少锁竞争
- 内部使用单把 ReentrantLock，但因读写端点分离（头取 vs 尾取），实际并发冲突概率远低于单端队列
- 支持有界容量（构造时指定），防止内存无限增长，比无界队列更可控
关键方法在窃取逻辑中的角色
区别于普通 BlockingQueue，BlockingDeque 接口扩展了首尾对称的操作方法，这些是实现窃取行为的直接工具：
- putFirst(e) / putLast(e)：生产者可按语义选择插入位置。例如，紧急任务用 putFirst 插入队头，确保被优先处理
- takeFirst() / takeLast()：消费者线程调用 takeFirst 处理自有任务；发现本地队列为空时，调用其他队列的 takeLast 实现“窃取”
- peekFirst() / peekLast()：非阻塞探查，可用于轻量级状态判断（如预检是否值得发起窃取）
- isEmpty() + size()：配合使用可辅助判断窃取时机，但注意 size() 在并发下是近似值，不可用于强一致性决策
典型工作窃取代码结构示意
以下不是完整可运行示例，而是突出 LinkedBlockingDeque 在窃取流程中的职责边界：
- 每个工作线程持有一个私有 LinkedBlockingDeque，作为其本地任务队列
- 主生产者将初始任务分发到不同队列（如轮询 or 负载感知），使用 putLast 均匀追加
- 工作线程循环执行：
→ 先 try takeFirst() 消费自己队列的任务
→ 若失败（队列空），遍历其他线程队列，对每个尝试 takeLast()
→ 成功即执行，失败则继续下一个；全部失败可短暂休眠或退出 - 注意：takeLast() 是阻塞方法，若希望非阻塞窃取，应改用 pollLast() 配合超时或重试逻辑
和 ForkJoinPool 中工作窃取的区别
Java 的 ForkJoinPool 内置了高度优化的工作窃取机制，其内部使用的是专用的 WorkQueue（非 public 类），而非 LinkedBlockingDeque。二者关系是：
- LinkedBlockingDeque 是通用组件，需开发者自行组织窃取逻辑，灵活但需承担设计责任
- ForkJoinPool 是开箱即用的框架，自动完成队列分配、窃取调度、负载均衡、异常传播等，更适合递归分治类任务
- 不要用 LinkedBlockingDeque 替代 ForkJoinPool 去做 fork/join 场景；它更适合定制化调度、异构任务混合、或与现有线程池集成的场景
