concurrentlinkedqueue 是基于cas的无锁非阻塞队列，不保证强一致性、不提供阻塞操作，offer()几乎总返回true，poll()为空时返回null而非阻塞或抛异常，size()不可靠，适用于高并发低延迟场景如日志收集。

ConcurrentLinkedQueue 是什么队列

它不是 synchronized 或 ReentrantLock 保护的阻塞队列，而是靠 Unsafe.compareAndSetObject 实现的无锁（lock-free）非阻塞队列。这意味着多线程入队、出队不会挂起线程，也不会因锁竞争拖慢吞吐——但代价是：它不保证强一致性，也不提供阻塞操作（比如 take() 或 put()）。

为什么 offer() 和 poll() 不会阻塞却可能返回 null

poll() 在队列为空时直接返回 null，不是抛异常，也不是等待；offer() 几乎总返回 true（仅在内存耗尽等极端情况下失败）。这是设计使然：它面向高并发、低延迟场景，比如事件缓冲、日志收集，而不是任务调度。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 常见错误：把 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 的关键区别

不是“更快”或“更安全”的通用替代品，而是适用面窄、假设强：要求元素操作本身无副作用、不依赖顺序强一致、能容忍瞬时不可见。

• CopyOnWriteArrayList：读多写少，每次写都复制数组，适合迭代频繁且写极少的场景；ConcurrentLinkedQueue 写吞吐高，但迭代器弱一致性（可能跳过刚入队未链接的节点）
• LinkedBlockingQueue：有锁 + 可选容量限制 + 支持阻塞，适合任务分发；而 ConcurrentLinkedQueue 容量无限、无界、不阻塞，失控增长可能 OOM
• 容易被忽略的一点：它不实现 BlockingQueue 接口，所以不能传给 ThreadPoolExecutor 构造函数（会编译报错）

实际用的时候，别只看“高性能”三个字——先想清楚你要不要阻塞、要不要精确 size、能不能接受 poll() 返回 null 且不通知。这些不是缺陷，是契约。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南