concurrentlinkedqueue.offer() 返回true不保证其他线程立即可见，因依赖cas和volatile而非全量内存屏障；poll()返回null不表示队列空，可能是竞态导致的临时不一致；size()为o(n)且不可靠，应避免用于流程控制。
ConcurrentLinkedQueue.offer() 为什么有时像没生效？
它确实不会阻塞，但也不保证立即对其他线程可见——因为底层靠的是无锁的 CAS + volatile 语义，不是内存屏障全量刷写。你看到 offer() 返回 true，只代表当前线程成功把节点挂到了队尾，不代表其他线程立刻能从 poll() 拿到它。
- 常见错误现象：主线程
offer()后立刻在另一线程调用poll()，结果返回null，误以为丢数据了 - 真实原因：JVM 重排序 + 缓存未同步，尤其在低负载、单核或测试环境里更明显
- 正确做法：需要“可见性契约”时，别依赖“刚 offer 就能 poll 到”，改用带同步语义的场景（比如配合
CountDownLatch等等待信号） - 性能影响：强行加
Thread.yield()或短 sleep 来“等”是错的，反而破坏非阻塞优势
ConcurrentLinkedQueue.poll() 返回 null 不一定队列为空
poll() 是非阻塞的，但它在竞态下可能返回 null，即使队列其实有元素——比如另一个线程正在执行 poll() 并已摘下头节点，但还没完成指针更新，当前线程就查到了临时不一致状态。
- 典型场景：多线程密集消费，且没做空值重试逻辑，导致任务“消失”假象
- 参数差异：
poll()和peek()都可能返回null，但peek()不移除节点，更适合做“试探性检查” - 建议写法：用循环重试，而不是一次
if (q.poll() != null)就完事 - 示例：
while ((item = q.poll()) == null) { Thread.onSpinWait(); // JDK9+ 推荐，比 yield() 更轻量 }
不能用 size() 判断队列是否为空
size() 在 ConcurrentLinkedQueue 中是 O(n) 的，而且结果仅是快照——调用完瞬间队列可能已被修改。它既慢又不可靠，完全不适合用于控制流程。
- 常见错误：写
if (q.size() > 0) { q.poll(); }，结果并发下判空和取值之间被其他线程插队，poll()还是返回null - 正确替代：
!q.isEmpty()也只是个弱提示，真正安全的只有直接poll()并处理null - 兼容性注意：JDK 8 和 JDK 17 行为一致，别指望新版修复这个设计——这是无锁结构的固有限制
- 如果真要统计，用外部计数器（如
AtomicLong）配合每次offer/poll手动增减
ConcurrentLinkedQueue 不适合做“任务队列 + 线程池”组合
它没有阻塞能力，也没容量限制，和 ThreadPoolExecutor 默认的 LinkedBlockingQueue 行为完全不同。直接替换会导致拒绝策略失效、OOM 风险陡增。
立即学习“Java免费学习笔记（深入）”；
- 使用场景错配：比如用它作为
Executors.newFixedThreadPool()底层队列，提交暴增任务时不会触发拒绝，而是无限扩容节点对象 - 容易踩的坑：认为“并发安全=可直接替换所有 BlockingQueue”——错，
ConcurrentLinkedQueue没有take()、不响应中断、不支持超时 - 替代方案：真要无锁 + 限流，得自己包装，例如用
AtomicBoolean控制提交开关，或改用TransferQueue子类（如SynchronousQueue） - 性能陷阱：节点对象分配频繁时，GC 压力比阻塞队列高，尤其在小对象高频进出场景
