Java并发队列ConcurrentLinkedQueue使用教程

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《Java并发队列ConcurrentLinkedQueue详解》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

ConcurrentLinkedQueue是Java中基于CAS实现的非阻塞线程安全队列，适用于高并发、低延迟的生产者-消费者场景；其通过无锁算法避免线程阻塞，提供offer、poll、peek等方法操作元素，且不支持null值；相比BlockingQueue，它不阻塞线程，在队列空或满时立即返回，适合对吞吐量要求高的场景，但需自行处理空队列逻辑；底层采用单向链表结构，维护head和tail指针，利用CAS原子操作保证线程安全；使用时需注意size()方法在并发下不精确、迭代器为弱一致、队列无界可能导致内存溢出等问题，常见应用于日志收集、异步任务分发和轻量级消息队列等场景。

Java中的ConcurrentLinkedQueue是一个非常实用的非阻塞、线程安全的队列，它特别适合在多线程环境下，需要高性能、低延迟地进行生产者-消费者模式操作的场景。它的核心优势在于，在入队（offer）和出队（poll）操作时，通过巧妙的无锁算法（CAS操作）避免了传统锁机制可能带来的性能瓶颈和线程阻塞。

ConcurrentLinkedQueue的使用其实非常直观，它遵循了Queue接口的基本契约。

import java.util.concurrent.ConcurrentLinkedQueue;

// 创建一个ConcurrentLinkedQueue实例
ConcurrentLinkedQueue<String> queue = new ConcurrentLinkedQueue<>();

// 入队操作：添加元素到队列尾部
queue.offer("任务A");
queue.offer("任务B");
System.out.println("队列当前元素: " + queue); // 输出: [任务A, 任务B]

// 出队操作：获取并移除队列头部元素
String task1 = queue.poll(); // 获取并移除"任务A"
System.out.println("取出的任务: " + task1); // 输出: 取出的任务: 任务A
System.out.println("队列剩余元素: " + queue); // 输出: [任务B]

// 再次出队
String task2 = queue.poll(); // 获取并移除"任务B"
System.out.println("取出的任务: " + task2); // 输出: 取出的任务: 任务B
System.out.println("队列剩余元素: " + queue); // 输出: []

// 当队列为空时，poll()方法返回null
String emptyTask = queue.poll();
System.out.println("空队列取出的任务: " + emptyTask); // 输出: 空队列取出的任务: null

// 查看队列头部元素，但不移除
queue.offer("任务C");
String peekedTask = queue.peek();
System.out.println("窥视到的任务: " + peekedTask); // 输出: 窥视到的任务: 任务C
System.out.println("队列剩余元素 (peek后): " + queue); // 输出: [任务C]

// 判断队列是否为空
boolean isEmpty = queue.isEmpty();
System.out.println("队列是否为空: " + isEmpty); // 输出: 队列是否为空: false

// 获取队列大小（注意：在高并发环境下，此方法可能不准确）
int size = queue.size();
System.out.println("队列大小: " + size); // 输出: 队列大小: 1

// 遍历队列元素
System.out.print("遍历队列: ");
for (String s : queue) {
    System.out.print(s + " ");
}
System.out.println(); // 输出: 遍历队列: 任务C

从上面的示例可以看出，它的API设计非常简洁，和普通的Queue接口使用起来差别不大，但其内部实现却大有乾坤，这正是它在并发场景下表现出色的关键。

为什么在高并发场景下更推荐使用ConcurrentLinkedQueue？

我在实际开发中，尤其是在处理高并发任务分发或者日志收集这类场景时，经常会面临一个选择：到底是用BlockingQueue的实现，比如LinkedBlockingQueue，还是ConcurrentLinkedQueue？这背后其实是对“阻塞”和“非阻塞”两种哲学思潮的权衡。

BlockingQueue，顾名思义，当队列满时，生产者线程会阻塞；当队列空时，消费者线程会阻塞。这种机制在很多时候是很有用的，它能自然地进行流量控制，防止系统资源耗尽。但阻塞本身就是一种性能损耗，线程的挂起和唤醒都是需要开销的。

而ConcurrentLinkedQueue则走的是另一条路。它是一个非阻塞队列，这意味着在任何时候，入队和出队操作都不会导致线程阻塞。即使队列为空，poll()方法也只是返回null，而不是让消费者线程等待。这种设计基于CAS（Compare-And-Swap）操作，通过乐观锁的思路，在不加全局锁的情况下保证了操作的原子性和线程安全。

所以，当你需要极致的吞吐量，希望生产者和消费者尽可能地并行运行，并且能够容忍消费者在队列为空时立即返回null（而不是等待）时，ConcurrentLinkedQueue就成了那个更具吸引力的选项。它避免了锁竞争带来的上下文切换和调度开销，在多核处理器上能展现出更好的扩展性。当然，这种选择也意味着你需要自己处理队列为空时的逻辑，比如轮询或者配合其他机制进行等待。

ConcurrentLinkedQueue的底层实现原理是怎样的？

要理解ConcurrentLinkedQueue为什么能做到非阻塞，就得稍微探究一下它的“内脏”。它不像LinkedBlockingQueue那样使用ReentrantLock来保护整个队列，而是巧妙地利用了CAS（Compare-And-Swap）原子操作。

可以把ConcurrentLinkedQueue想象成一个由一个个节点（Node）组成的链表。每个节点包含一个元素值和一个指向下一个节点的引用。队列内部维护着两个关键的指针：head（头节点）和tail（尾节点）。

• 入队（offer）操作： 当一个元素要入队时，它会被封装成一个新的节点。这个新节点会尝试通过CAS操作，原子性地更新当前tail节点的next引用，让它指向新节点。同时，tail指针本身也会尝试通过CAS操作，原子性地指向这个新节点。如果多个线程同时尝试入队，只有一个线程能成功更新tail的next，其他失败的线程会重试，直到成功。这个过程中，没有哪个线程会被阻塞。

• 出队（poll）操作： 出队操作类似，它会尝试通过CAS操作，原子性地更新head指针，使其指向当前head节点的下一个节点。如果成功，那么原head节点中的元素就被“取出”了。同样，失败的线程会重试。

这个过程的关键在于CAS操作的原子性。它能在不加锁的情况下，确保某个内存位置的值被正确地更新。即使有多个线程同时操作，也只有一个能成功，其他失败的线程会通过自旋（循环重试）来等待下一次机会。这种“乐观”的并发控制方式，在高并发、低冲突的场景下，性能表现非常出色。但如果冲突非常频繁，自旋重试的开销也可能变得不容忽视。

它是一个单向链表结构，这意味着它只能从头部出队，从尾部入队。这种简洁的结构也为CAS操作提供了便利。

在实际项目中，ConcurrentLinkedQueue有哪些常见的应用场景和注意事项？

在实际项目里，ConcurrentLinkedQueue的身影并不少见，但用得好不好，关键在于你是否理解它的特性和局限性。

常见的应用场景：

1. 高并发日志收集/处理： 比如你的应用需要异步地收集大量的操作日志或事件，然后由一个或多个后台线程统一处理。ConcurrentLinkedQueue可以作为日志缓冲队列，生产者（业务线程）快速地将日志事件offer进去，消费者（日志处理线程）则不断poll出来进行持久化或其他操作。由于offer操作是非阻塞的，业务线程不会因为日志写入而受阻。
2. 异步任务分发： 当你有一个线程池，但又不想直接用ExecutorService默认的BlockingQueue行为时，可以自定义一个任务队列，使用ConcurrentLinkedQueue来存储待执行的任务。工作线程从队列中poll任务执行，如果队列为空，它们可以简单地返回null，然后进行短暂的休眠或者执行其他任务。
3. 消息队列的轻量级实现： 在一些对消息可靠性要求没那么高，但对吞吐量和延迟要求很高的场景，ConcurrentLinkedQueue可以作为内存消息队列的底层实现。
4. 无界生产者-有界消费者模式的变种： 如果你的生产者是无界的，而消费者处理能力有限，但你又不想阻塞生产者，那么ConcurrentLinkedQueue可以作为中间缓冲区。不过，这要求你对队列的增长有监控和控制，防止内存溢出。

使用注意事项：

1. size()方法的陷阱： 这是我个人觉得最容易踩坑的地方。ConcurrentLinkedQueue的size()方法在并发环境下，返回的值可能并不是实时的、精确的队列元素数量。它的实现需要遍历整个链表来计数，在这个遍历过程中，队列可能已经被其他线程修改了。因此，永远不要依赖size()方法来做关键的业务逻辑判断，比如判断队列是否已满或是否为空（用isEmpty()更可靠）。
2. 没有阻塞操作： ConcurrentLinkedQueue不提供put()和take()这样的阻塞方法。如果你需要生产者在队列满时等待，或者消费者在队列空时等待，那么你应该考虑使用BlockingQueue的实现，例如LinkedBlockingQueue或ArrayBlockingQueue。
3. 内存管理： 它是无界的，这意味着如果你只入队不及时出队，或者消费者处理速度远低于生产者，队列会无限增长，最终可能导致内存溢出（OOM）。在设计时，必须确保消费者的处理能力能够匹配或超过生产者的生产能力，或者有其他机制来限制队列的增长。
4. 不允许null元素： ConcurrentLinkedQueue不允许存储null元素。尝试添加null会抛出NullPointerException。这是为了区分poll()方法在队列为空时返回的null。
5. 迭代器是弱一致的： ConcurrentLinkedQueue的迭代器是“弱一致”（weakly consistent）的。这意味着迭代器在创建时会反映队列的某个状态，但在迭代过程中，队列的修改可能不会反映到迭代器中。这通常不是问题，但在某些需要强一致性视图的场景下需要注意。

总的来说，ConcurrentLinkedQueue是一个强大且高效的并发工具，但它并非银弹。理解其工作原理和适用场景，并注意其局限性，才能在项目中发挥它的最大价值。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~