ConcurrentLinkedQueue 的 size() 不保证实时准确且为 O(n) 时间复杂度，应优先使用 isEmpty()；offer() 永不失败，poll() 为空时返回 null 而非抛异常；Node 的 item 和 next 是 volatile，保障无锁可见性；适用高吞吐弱一致性场景，强顺序或批量需求需换其他队列。
ConcurrentLinkedQueue 为什么不能直接用 size()
它不保证返回实时准确的元素个数，调用 size() 会遍历整个链表，时间复杂度 O(n)，且遍历时可能因
ConcurrentModificationException（虽然文档没明说，但底层无锁遍历 + 链表结构导致结果不可靠）。实际业务中若用 size() == 0 判断空队列，不如直接用 isEmpty()——后者只检查 head 和 tail 节点是否相等，是常量时间、线程安全的。
- 别在循环里反复调用
size()做“取完所有元素”逻辑，容易漏数据或死循环 - 监控类场景需要近似长度时，可定期采样 + 记录日志，而非每次操作都查
- 真要强一致性计数，考虑*一个
AtomicLong，在offer()和poll()时手动增减（注意：这会削弱无锁优势，仅限必要场景）
offer() 和 poll() 的失败语义你可能误解了
ConcurrentLinkedQueue 的 offer() 永远不会失败（除非 OOM），返回 true 是确定性行为；poll() 在队列为空时返回 null，不是抛异常。很多人误以为它像 BlockingQueue 那样有阻塞/超时重载，其实没有——它纯粹是非阻塞、无等待的。
- 如果业务需要“等有元素再取”，不要硬套
poll()加 while 循环自旋，CPU 白耗；应换用LinkedBlockingQueue或加LockSupport.parkNanos()退让 -
poll()返回null只代表「此刻为空」，不代表之后一直空，也不代表其他线程没正在offer() - 避免用
poll() != null作为唯一成功标志来触发后续强依赖逻辑，建议搭配 CAS 标记或状态机做幂等控制
内存可见性陷阱：Node 内部字段没 volatile？
源码里 ConcurrentLinkedQueue.Node 的 item 和 next 字段确实是 volatile 的（JDK 8+），这是它能无锁工作的基础。但如果你自己扩展子类、或用反射绕过构造逻辑，就可能破坏这个契约。
- 别用
Unsafe直接写Node.item，跳过 volatile 写屏障，会导致其他线程看到陈旧值 - 自定义包装类持有
Node引用时，该包装类字段本身也建议声明为volatile（如缓存头节点引用） - 调试时用 JOL（Java Object Layout）验证
Node对象字段偏移和 volatile 语义，别只信 IDE 提示
替代方案选型：什么时候该换掉 ConcurrentLinkedQueue
它适合高吞吐、低延迟、允许“瞬时丢失精度”的生产者-消费者场景，比如日志缓冲、指标打点。但一旦出现以下任一情况，就得重新评估：
- 需要批量消费（如一次取 10 个）→ 用
LinkedTransferQueue配合tryTransfer()或改 Pull 模式 - 元素有优先级 →
PriorityBlockingQueue（注意它是基于锁的，吞吐略低） - 要求强顺序一致性（如金融流水严格 FIFO）→ 考虑单线程 Dispatcher + 无锁 RingBuffer（如 LMAX Disruptor）
- 内存受限且元素小 →
MPSC Queue（如 JCTools 的MpscUnboundedXaddArrayQueue），比 CLQ 更省内存、更快
真正难的不是写对代码，而是判断当前业务里“并发安全”和“性能损耗”的临界点在哪——CLQ 的无锁设计很美，但它的 ABA 问题、内存占用、以及无法阻塞的刚性，常常在压测后期才暴露出来。
