ConcurrentLinkedQueue 是基于CAS的无锁非阻塞队列，不保证强一致性、不提供阻塞操作，offer()几乎总返回true，poll()为空时返回null而非阻塞或抛异常，size()不可靠，适用于高并发低延迟场景如日志收集。
ConcurrentLinkedQueue 是什么队列
它不是 synchronized 或 ReentrantLock 保护的阻塞队列，而是靠 Unsafe.compareAndSetObject 实现的无锁（lock-free）非阻塞队列。这意味着多线程入队、出队不会挂起线程，也不会因锁竞争拖慢吞吐——但代价是：它不保证强一致性，也不提供阻塞操作（比如 take() 或 put()）。
为什么 offer() 和 poll() 不会阻塞却可能返回 null
poll() 在队列为空时直接返回 null，不是抛异常，也不是等待；offer() 几乎总返回 true（仅在内存耗尽等极端情况下失败）。这是设计使然：它面向高并发、低延迟场景，比如事件缓冲、日志收集，而不是任务调度。
- 常见错误：把
ConcurrentLinkedQueue当作BlockingQueue用，写成while (queue.poll() == null) Thread.sleep(1)—— 这既浪费 CPU，又违背非阻塞本意 - 正确姿势：配合生产者-消费者模式中的“忙等待 + yield”或转投
LinkedBlockingQueue（如果真需要阻塞） -
size()方法不可靠：它遍历链表计数，过程中节点可能被其他线程修改，返回值仅作估算，不能用于条件判断（比如if (q.size() > 0)）
CAS 失败时它怎么重试
内部节点用 volatile 字段标记状态，所有结构变更（如 next 指针更新）都靠 UNSAFE.compareAndSwapObject 循环尝试。失败不报错，只是继续循环——这就是 lock-free 的核心：线程永不等待他人，只靠重试推进。
- 典型场景：多个线程同时
offer()，都试图更新 tail 节点的next，只有一个成功，其余自动重试指向新 tail - 性能影响：在极高争用下（比如单核超线程+密集写），CAS 自旋会抬高 CPU，但比锁竞争更可控
- 注意：JVM 必须支持
Unsafe，且 JDK 9+ 中部分Unsafe方法受限，但ConcurrentLinkedQueue已适配为使用VarHandle回退，无需用户干预
它和 CopyOnWriteArrayList / LinkedBlockingQueue 的关键区别
不是“更快”或“更安全”的通用替代品，而是适用面窄、假设强：要求元素操作本身无副作用、不依赖顺序强一致、能容忍瞬时不可见。
立即学习“Java免费学习笔记（深入）”；
-
CopyOnWriteArrayList：读多写少，每次写都复制数组，适合迭代频繁且写极少的场景；ConcurrentLinkedQueue写吞吐高，但迭代器弱一致性（可能跳过刚入队未链接的节点） -
LinkedBlockingQueue：有锁 + 可选容量限制 + 支持阻塞，适合任务分发；而ConcurrentLinkedQueue容量无限、无界、不阻塞，失控增长可能 OOM - 容易被忽略的一点：它不实现
BlockingQueue接口，所以不能传给ThreadPoolExecutor构造函数（会编译报错）
