ConcurrentLinkedQueue 是 Java 中基于链表、无锁、线程安全的非阻塞队列，通过 CAS 实现高性能并发读写；适用于高吞吐、低延迟场景，不支持阻塞、size() 非实时、不可存 null。
ConcurrentLinkedQueue 是 Java 并发包（java.util.concurrent）中提供的一个基于链表实现的无锁（lock-free）、线程安全的队列，适用于高并发读写场景。它不依赖 synchronized 或 ReentrantLock，而是通过 CAS（Compare-And-Swap）操作实现原子性，因此在多线程环境下性能优异、扩展性好。
为什么选择 ConcurrentLinkedQueue 而不是 BlockingQueue？
ConcurrentLinkedQueue 属于非阻塞队列，add() 和 poll() 操作永不阻塞、不会抛出 InterruptedException，也不支持等待机制。适合以下场景：
- 生产者消费者模型中，消费者能快速响应，不允许因队列空而挂起
- 事件总线、日志缓冲、异步任务分发等对吞吐量敏感、容忍“尽力交付”的系统
- 需要极高并发写入（如每秒百万级 offer），且不希望锁竞争拖慢性能
注意：它不保证强一致性（如 size() 方法是非实时的，仅作估算），也不提供阻塞式取值（没有 take() 或 poll(timeout)），这点和 LinkedBlockingQueue、ArrayBlockingQueue 有本质区别。
核心用法与线程安全保障
所有 public 方法（offer, poll, peek, isEmpty）都是线程安全的，底层靠 volatile + CAS 实现。典型用法如下：
立即学习“Java免费学习笔记（深入）”；
ConcurrentLinkedQueuequeue = new ConcurrentLinkedQueue<>(); queue.offer("event-1"); // 线程安全插入 String event = queue.poll(); // 线程安全取出，为空时返回 null
关键细节：
- offer() 总是返回 true（不会失败，也不会阻塞）
- poll() 和 peek() 在队列为空时返回 null，需判空处理
- size() 方法遍历链表计数，可能不准；建议用 isEmpty() 判断空状态
- 不支持 null 元素，插入 null 会抛 NullPointerException
实际高并发场景中的使用建议
直接裸用 ConcurrentLinkedQueue 很简单，但在真实系统中要注意几个易忽略点：
- 避免在循环中频繁调用 size() —— 它是 O(n) 的，且结果滞后；可用 isEmpty() + poll() 组合替代“while (!queue.isEmpty())”
- 若需批量消费，可配合 poll() 循环 + 计数控制（例如一次最多取 100 条），防止单次处理过久影响响应
- 结合 ThreadLocal 或对象池减少 GC 压力（尤其存的是短生命周期对象时）
- 监控建议：通过 AtomicLong 记录 offer/poll 次数，或用 Dropwizard Metrics 包装队列操作埋点
和 CopyOnWriteArrayList / LinkedBlockingQueue 的对比
不是所有并发队列都适合“高并发写”：
- CopyOnWriteArrayList 写操作加锁+复制数组，写多时性能断崖下跌，只适合读远多于写的场景
- LinkedBlockingQueue 使用重入锁，虽支持阻塞和容量限制，但高并发下锁竞争明显，吞吐受限
- ConcurrentLinkedQueue 无锁、无容量限制、写性能随 CPU 核数近似线性提升，是纯内存高速通道的理想选择
不过它也意味着：你需要自己处理背压（如上游太快导致 OOM）、无界增长风险，以及无法做流量整形。
基本上就这些。ConcurrentLinkedQueue 不复杂，但容易忽略它的“无界”和“非实时 size”特性。用对了场景，它是高并发系统里最轻快的一条消息管道。
