concurrentlinkeddeque 是基于 cas 的无锁线程安全双端队列，适用于多生产者-多消费者及双向流动场景；推荐使用 offer/poll 系列方法避免异常中断，禁用 add/remove 等抛异常操作，且不可依赖 size() 或遍历作流程判断。
ConcurrentLinkedDeque 是 Java 并发包中为高并发场景量身设计的无锁双端队列，它不依赖 synchronized 或 ReentrantLock，而是通过底层 CAS（Compare-and-Swap）原子操作实现线程安全。要真正用好它做流程控制，关键不是“能加减元素”，而是理解它的行为边界、适用模式和常见陷阱。
明确适用场景：多生产者-多消费者 + 双向流动需求
它不是通用替代品，适合以下典型流程控制场景：
- 任务分发系统中，既支持“优先处理新任务”（addLast），也支持“紧急插队”（addFirst）
- 工作流引擎里，节点可向前回滚（pollFirst）或向后推进（pollLast），形成双向调度链
- 日志缓冲区需同时支持：尾部追加写入（offerLast）、头部快速截断旧日志（pollFirst）
- 消息广播队列中，多个线程并行投递（offerFirst/offerLast），多个消费线程从任一端拉取（pollFirst/pollLast）
核心操作选型：区分「失败不抛异常」与「失败必须处理」
ConcurrentLinkedDeque 提供两套语义的方法，流程控制中必须按需选用：
- 推荐用于流程控制：offerFirst()、offerLast()、pollFirst()、pollLast() —— 它们失败时返回 null 或 false，不会中断线程，便于你做重试、降级或跳过逻辑
- 慎用于流程控制：addFirst()、addLast()、removeFirst()、removeLast() —— 它们在失败时直接抛 NoSuchElementException，一旦队列为空或操作被竞争干扰，就会打断当前流程
- 例如：消费者线程循环拉取任务，应写 while ((task = deque.pollFirst()) != null)，而不是 deque.removeFirst()，避免空队列导致崩溃
规避 size() 和遍历陷阱：流程控制不依赖实时长度
size() 方法在 ConcurrentLinkedDeque 中不是 O(1)，而是需要遍历链表计数，且结果可能在返回瞬间就已过期。流程控制中应避免：
- 用 size() 判断是否“有活干”——改用 peekFirst() != null 或 pollFirst() != null 更可靠
- 用 for-each 遍历队列做批量处理——并发修改下迭代器不保证一致性，可能漏项或重复；如需快照，应先 toArray() 再处理
- 依赖 size() 做限流或熔断——建议配合外部原子计数器（如 AtomicInteger）或使用有界替代方案（如 LinkedBlockingDeque + 自定义拒绝策略）
内存可见性与 happen-before 保障流程顺序
ConcurrentLinkedDeque 的插入操作对后续的访问/移除操作具有 happen-before 关系。这意味着：
- 线程 A 调用 offerLast("msg") 成功后，线程 B 后续调用 pollFirst() 或 pollLast() 一定能看到该元素（只要未被其他线程抢先移除）
- 无需额外 volatile 或 synchronized 来保障元素内容的可见性，但若元素本身是可变对象，仍需确保其内部状态线程安全
- 适合构建“发布-订阅”式流程管道：上游写入即刻对下游可见，天然支持事件驱动架构
