队列这东西说简单也简单说复杂也真复杂。无论你是刚学 Java 的数据结构新手还是在生产环境里排查过消息堆积的老开发都绕不开“队列”这两个字。排队买奶茶是队列线程池里的任务排队也是队列Kafka 里堆积着几十万条日志的 topic 说到底还是队列。在 Java 里队列不仅是 java.util 包下一个接口更是并发编程、异步处理、解耦削峰这些工程方案的地基。这篇文章我想认真聊聊队列在 Java 里的实现从 Queue 接口到 LinkedList、ArrayDeque、ArrayBlockingQueue再到手写一个带循环数组的队列最后看看阻塞队列和消息队列在生产环境里怎么选型、踩过哪些坑。代码我会尽量完整贴出来每个实现背后的“为什么”也会解释清楚。适合刚学完 Java 基础、正在啃数据结构的人也适合工作了一段时间、想系统梳理队列知识点的人。1. 队列的基本概念与设计思路1.1 先进先出到底意味着什么队列是一种典型的线性数据结构核心规则只有一条最先进入的元素最先被取出也就是 First In First Out简称 FIFO。你可以想象成奶茶店门口的一排人谁先站到位谁就先点单后来的人只能跟在队伍末尾不能从中间插进去也不能从队尾直接拿走订单。这种约束听起来简单但它刻意把“操作顺序”和“元素内容”解耦了——你不需要关心队伍里排的是谁只需要遵守队首出、队尾入的规则。这个“不关心”恰恰是队列最大的价值。在计算机系统里资源总是有限的请求却是突发的。数据库连接不够用任务处理不过来网络请求瞬间暴涨都需要一个缓冲区把暂时处理不了的东西存起来等系统有空了再按顺序慢慢处理。队列就是这个缓冲区的抽象。它把生产者往队尾放数据的一方和消费者从队头取数据的一方之间的耦合关系拆开生产者不必知道消费者什么时候处理、怎么处理消费者也不必关心数据是哪个时刻产生的。从实现层面看队列需要支持的核心操作也不复杂入队enqueue、出队dequeue、查看队首元素、判断空和满。但为什么要分好几种实现因为“存储”这件事有数组和链表两条路“满”和“空”这两个边界条件在并发和阻塞场景下又会衍生出完全不同的问题。所以学习队列不能只背一个定义要把每种实现放在具体的资源约束里去理解。1.2 应用场景与选型思路队列在真实项目里的应用范围比大多数初学者想象的要广。最简单的是线程池里的任务队列提交到线程池的 Runnable 不会马上全部执行而是先排进队列等有空闲线程再来取。然后是生产者消费者模型比如日志收集系统里业务线程把日志写进队列后台线程批量刷盘避免每条日志都打一次磁盘。再往上走微服务之间的消息队列比如 Kafka、RabbitMQ、RocketMQ本质上是把单机内的队列做成了分布式的多机版本用来实现削峰、解耦和异步。选型思路的关键在于回答三个问题数据量有多大延迟要求有多高允许不允许丢数据。单机内用 ArrayBlockingQueue 还是 LinkedBlockingQueue取决于你是否需要无界存储分布式场景选 Kafka 还是 RabbitMQ取决于你的吞吐量目标和消息语义要求。所以队列不是“哪个好用用哪个”而是“在什么约束下哪个结构最合适”。这个思路会贯穿全文后面每一节手写实现和选型对比我都会把约束条件一并讲清楚。2. Java里的队列接口与现成实现2.1 Queue 接口和 Deque 接口怎么用Java 里队列的根接口是 Queue它在 Collection 基础上增加了一组专门的操作方法这些方法分成三类插入、删除和检查。每类又分两种写法一种操作失败时抛异常另一种返回特殊值。操作类型抛异常返回特殊值行为说明插入add(e)offer(e)向队尾添加元素删除remove()poll()从队头取出并移除元素检查element()peek()查看队头元素但不移除举个例子队列为空时掉用 remove() 会抛 NoSuchElementException调用 poll() 则返回 null队列满时 add() 抛 IllegalStateExceptionoffer() 返回 false。实际开发里我更习惯用 offer 和 poll因为可以优雅地处理边界情况。但要注意poll() 返回 null 有两种可能队列真的为空或者队头元素本身就是 null。这就是后文要说的“别用 null 值做业务数据”的原因之一。Deque 接口是 Queue 的增强版全称是 Double Ended Queue也就是双端队列允许在队头和队尾分别执行插入和删除。它也提供了两套方法比如 addFirst/addLast、offerFirst/offerLast、removeFirst/removeLast、pollFirst/pollLast、getFirst/getLast、peekFirst/peekLast。Java 里的 ArrayDeque 和 LinkedList 都实现了它。Deque 既能当队列用也能当栈用实际开发里需要 FIFO 或 LIFO 的时候都可以优先考虑。2.2 常见实现类的对比与选择Java 集合框架里最常见的队列实现类有这么几个LinkedList、ArrayDeque、PriorityQueue以及并发包里的 BlockingQueue 系列。下表从底层结构、容量、线程安全等方面做了对比。实现类底层结构容量线程安全特点LinkedList双向链表无界不安全同时也是 List支持随机访问场景但性能一般ArrayDeque循环数组可扩容不安全性能好不允许 null做栈和队列都合适PriorityQueue堆无界不安全按优先级出队不是严格 FIFOArrayBlockingQueue循环数组有界安全阻塞队列容量固定底层复用数组LinkedBlockingQueue单向链表可指定或有界安全常用无界场景注意内存风险SynchronousQueue无存储无容量安全生产者和消费者必须直接交接这里重点说两个容易选错的点。第一LinkedList 虽然实现了 Queue 接口但如果你的需求只是简单的队列不建议用 LinkedList 当主力。它的节点分散在内存各处对 CPU 缓存不友好而且 LinkedList 本身的实现比较重每个元素都要包装成 Node 对象。相比之下 ArrayDeque 用循环数组实现扩容和访问都更高效。第二PriorityQueue 虽然名字带 Queue但它的出队顺序是“最小元素优先”不是“先来先走”。如果你需要一个真正的 FIFO 队列别贪图 priority 字眼就用它。并发包里的 BlockingQueue 与普通 Queue 最大的不同是支持阻塞操作队列满时 put() 会一直等待队列空时 take() 会一直阻塞直到有新元素。这个特性后面单独开一节讲因为它是生产者消费者模型的基础。3. 手写一个能用的队列三种实现逐行拆解3.1 数组顺序队列最简单也最容易出问题先写一个最直觉的数组队列。我用 Object 数组存数据head 指向队首元素的下标tail 指向队尾的下一个空位。入队时把元素放到 tail 位置tail 加一出队时返回 head 位置的元素head 加一。代码看起来很短但它有一个致命问题随着 head 不断后移数组前面会空出一大块永远用不到的空间明明队列只有两三个元素tail 却可能已经顶到数组末尾了这就是“假溢出”。public class ArrayQueueT { private final Object[] data; private int head; private int tail; public ArrayQueue(int capacity) { data new Object[capacity]; } public boolean offer(T value) { if (tail data.length) { return false; } data[tail] value; return true; } SuppressWarnings(unchecked) public T poll() { if (head tail) { return null; } T value (T) data[head]; data[head] null; head; return value; } }这段代码的问题很清楚如果先入队 5 个元素再出队 5 个元素此时 head 和 tail 都等于 5队列为空但数组被 head 之前的空间浪费了。想要继续入队必须移动所有数据或者扩容这会使入队操作退化到 O(n)。所以数组顺序队列基本只适合“最多存 N 个、取完就废弃”的场景比如某些一次性缓冲。工程上很少直接用这种形态它是我们理解循环队列的铺垫。3.2 循环队列用取模化解假溢出循环队列的改进思路是让 tail 在到达数组末尾时自动绕回头部逻辑上把数组首尾相接成一个环。入队和出队都使用取模运算来移动下标因此只要数组还有空闲位置就不会出现假溢出。这里有一个经典约定在数组里留出一个空位用来区分队列“空”和“满”两种状态。如果不留这个位head tail 时既可能是空也可能是满无法判断。public class CircularQueueT { private final Object[] data; private int head; private int tail; private final int capacity; public CircularQueue(int capacity) { this.capacity capacity 1; this.data new Object[this.capacity]; } public boolean offer(T value) { if (isFull()) { return false; } data[tail] value; tail (tail 1) % capacity; return true; } SuppressWarnings(unchecked) public T poll() { if (isEmpty()) { return null; } T value (T) data[head]; data[head] null; head (head 1) % capacity; return value; } public boolean isEmpty() { return head tail; } public boolean isFull() { return (tail 1) % capacity head; } public int size() { return (tail - head capacity) % capacity; } }这个版本有几个细节值得背下来。第一构造函数里我声明的是 capacity 1因为要留一个空位所以实际数组长度比用户期望的容量大 1存入元素的最大数量恰好等于用户传入的 capacity。第二isFull 的判断条件是“tail 的下一个位置是不是 head”因为 tail 始终指向下一个空位当它绕一圈后顶到 head 时说明只剩最后一个空位而那个空位是专门用来区分状态的不能存数据。第三size() 用 (tail - head capacity) % capacity 计算这个公式在 tail 小于 head 时也能算出正确长度是你面试或者笔试时很容易被问到的点。循环队列是线程池和消息中间件里最常见的底层结构ArrayBlockingQueue 内部大致就是这个思路只不过加了锁和条件变量。自己写一遍再去看源码会轻松很多。3.3 链表队列真正无界的实现链表实现的关键是维护 head 和 tail 两个指针入队在 tail 后面追加新节点出队从 head 取出节点。链表有一个天然优势节点用完可以释放新节点动态创建队列大小不再受数组容量限制只要内存足够就能一直加。劣势也很明显每个节点都要额外存一个 next 引用内存开销比数组大而且频繁创建和销毁节点会产生 GC 压力。public class LinkedQueueT { private static class NodeT { T value; NodeT next; Node(T value) { this.value value; } } private NodeT head; private NodeT tail; private int size; public boolean offer(T value) { NodeT node new Node(value); if (tail null) { head tail node; } else { tail.next node; tail node; } size; return true; } SuppressWarnings(unchecked) public T poll() { if (head null) { return null; } T value head.value; head head.next; if (head null) { tail null; } size--; return value; } public boolean isEmpty() { return head null; } public int size() { return size; } }需要特别小心的是出队操作里那行if (head null) { tail null; }。如果队列里只剩一个节点出队后 head 变成 null但 tail 还指向那个已经被移除的节点。如果不重置 tail下一次入队时tail.next node会抛 NullPointerException。这个 bug 非常容易踩我见过不止一个新手在自测时会问“为什么 LinkedList 的实现不这样我却需要这样”原因是我们手写的尾指针是裸指针必须自己维护一致性而 JDK 源码有更复杂的哨兵节点设计。所以写链表结构时一定要在纸上画一遍“只剩一个节点时的出队过程”。4. 阻塞队列实战从生产者消费者到线程池4.1 BlockingQueue 的核心方法与阻塞原理BlockingQueue 接口在 Queue 基础上增加了阻塞语义。常用的方法有 put(e)、take()、offer(e, timeout, unit)、poll(timeout, unit)。put 在队列满时会阻塞调用线程直到队列有空间可写take 在队列空时会阻塞直到有新元素入队。带超时版本的 offer/poll 则只阻塞指定时间超时后放弃操作返回特殊值。正是这种“等”的能力让生产者和消费者可以解耦运行。阻塞队列的实现原理简单说就是锁加条件变量。以 ArrayBlockingQueue 为例它内部有一个 ReentrantLock 和两个 ConditionnotEmpty、notFull。put 时先加锁如果队列已满就在 notFull 上等待等消费者唤醒take 时先加锁如果队列为空就在 notEmpty 上等待等生产者唤醒。这个设计非常经典掌握了它对理解 Java 并发编程帮助很大。使用阻塞队列时有几个容易忽略的点。第一ArrayBlockingQueue 不允许放入 null因为内部要用 null 来标记空位插入 null 直接抛 NullPointerException。第二LinkedBlockingQueue 有界时和无界时行为不同无界时 put 永远不会阻塞但内存会一直增长。第三阻塞队列的迭代器和 toArray 拿到的是当前快照不保证实时一致性如果你在遍历时其他线程入队遍历结果可能不是最新的。4.2 一个可以直接跑的生产者消费者实例生产者消费者是阻塞队列最典型的应用。我写一个小例子生产者每隔一段时间往队列里放一个整数消费者从队列里取出来打印。这里最关键的是用 put 和 take而不是 offer 和 poll因为前者会正确地把生产者和消费者的节奏协调起来。import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.BlockingQueue; public class ProducerConsumerDemo { private static final BlockingQueueInteger queue new ArrayBlockingQueue(10); public static void main(String[] args) { Thread producer new Thread(() - { for (int i 0; i 50; i) { try { queue.put(i); System.out.println(生产者放入: i); Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, producer-thread); Thread consumer new Thread(() - { while (!Thread.currentThread().isInterrupted()) { try { Integer value queue.take(); System.out.println(消费者取出: value); if (value 49) { break; } } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, consumer-thread); producer.start(); consumer.start(); } }这里要注意 InterruptedException 的处理方式不要把它吞掉更不要打印完堆栈就假装无事发生。正确的做法是恢复中断标记Thread.currentThread().interrupt();让上层代码能感知到线程被中断。我见过很多线上偶发问题就是因为中断异常被吞掉线程状态一直挂在 wait 上业务任务流程整个卡死。另一个容易被忽略的细节是生产者的速度控制。早期我做日志收集的时候就踩过坑生产者线程写入速度远大于消费者处理速度ArrayBlockingQueue 的容量设得不够结果 put 一直阻塞业务接口的调用链被日志系统拖慢。后来学到经验生产者和消费者的速度问题不能靠无限加大队列容量解决要监控队列积压量一旦堆积就要考虑丢弃策略或横向扩容。4.3 线程池的阻塞队列怎么选线程池里面核心的参数除了核心线程数和最大线程数最容易被忽略的就是任务队列。JDK 默认提供的几种线程池内部队列选择各有不同理解它们的差异能帮你避开线上事故。线程池类型默认队列行为风险FixedThreadPool无界 LinkedBlockingQueue任务无限堆积可能 OOMSingleThreadExecutor无界 LinkedBlockingQueue同上CachedThreadPoolSynchronousQueue不存储任务线程数可无限扩张ScheduledThreadPoolDelayedWorkQueue支持延迟和周期任务但延迟队列实现复杂先说最经典的坑Executors.newFixedThreadPool 使用的是无界队列意思是不管提交多少任务都会先排队线程池永远不会触发拒绝策略。如果某天流量突然上来任务积压几百万个内存直接爆掉而且因为任务都在队列里排着看起来线程数正常、CPU 使用率也不高排查时很容易迷路。所以大流量场景我建议显式使用有界队列比如 new ArrayBlockingQueue(1000)配合自定义拒绝策略宁可丢弃也要保护主流程。再来说 SynchronousQueue它不是真正的存储队列生产者 put 时必须有一个消费者正在 take否则就一直阻塞。CachedThreadPool 用它是合理的因为线程池希望“来一个任务就立刻用一个线程处理”。但如果你手动给线程池配了 SynchronousQueue 又限制了最大线程数很容易出现任务卡住的现象。ExecutorService 的线程数已经用满新任务又无法进入队列就一直阻塞在那里。DelayedWorkQueue 是另一个有意思的存在。它是 ScheduledThreadPoolExecutor 内部使用的延迟队列元素按到期时间排序出队时会检查任务是否到了执行时间没到就阻塞等待。这个队列不能单独当普通队列使用更像是一个定时调度器的内部组件。理解它的存在你就能明白为什么 ScheduledThreadPoolExecutor 能实现 delay 和 period 任务了。5. 队列的工程化扩展从单机结构到消息队列5.1 Kafka、RabbitMQ、RocketMQ 选型对比单机队列解决的是进程内的异步问题一旦跨越进程边界就需要消息队列。Kafka、RabbitMQ、RocketMQ 是 Java 生态里最常见的三个选择。很多人一上来就问“哪个最好”其实这三个的定位并不一样选型要先看自己的业务形态。维度KafkaRabbitMQRocketMQ吞吐量极高百万级/秒一般万级/秒较高十万级/秒消息可靠性至少一次需配置较高支持确认机制较高支持事务消息路由能力弱按 topic 消费强Exchange 路由灵活中Tag 过滤事务消息较复杂不支持原生支持较好典型场景日志采集、大数据流企业级系统解耦电商、订单、金融我自己在电商订单系统里用过 RocketMQ因为它的事务消息能很好地保证“扣库存”和“发消息”这两步的一致性。而做日志采集时我偏向 Kafka因为它的高吞吐和分区顺序机制太适合海量日志了。RabbitMQ 更适合复杂路由策略的企业应用比如消息根据内容分发到不同交换机。选型不能只看网上评测的吞吐数字要结合你的消息量、团队维护能力、数据一致性要求综合判断。这里还要提一下“消息堆积”问题这在所有 MQ 里都会遇到。当消费者处理速度跟不上生产速度时消息会一直堆积在 broker 上导致延迟不断变大。排查消息堆积的基本思路是先看消费者实例是不是大面积挂了再看消费者单条消息处理时间是不是变长了最后看有没有某个分区出现热点导致负载不均。千万不要一上来就调大批量参数那是治标不治本。5.2 重复消费与消息幂等消息队列的另一个经典问题是重复消费。Kafka 的 at-least-once 语义下消费者在处理完消息但还没来得及提交 offset 时宕机重启后会从头重新消费这条消息。RabbitMQ 的消费者在 autoAck 开启时会自动确认关掉后如果处理超时不确认消息也会重新投递。也就是说重复消费是一个无法完全杜绝的问题工程上只能靠“幂等设计”来兜底。幂等方式常见的有三种第一种是全局唯一标识比如订单号、业务主键消息带一个 UUID消费端先去查重表存在就跳过第二种是数据库唯一约束直接把业务主键建唯一索引插入冲突就忽略第三种是乐观锁版本号每次更新前检查版本是否匹配。实际项目中我建议多条腿走路主键唯一索引是底线业务幂等表做兜底条件更新辅助校验。除此之外消费端的提交策略也要注意。Kafka 消费者如果每处理一条就提交一次 offset性能会很差如果批量拉取的 500 条里处理到第 300 条时挂了重启后前面 299 条会重新消费。所以要么接受重复消费并用幂等兜底要么把“处理完且提交 offset”做成原子操作没有中间状态可退。这才是消息队列里“数据一致性”问题的真正解药。5.3 单调队列一个容易被忽略的升级版队列还有一个进阶形态叫单调队列。它和普通队列不同的地方在于队列内部的元素按某种单调性排列比如从队首到队尾值递减。单调队列最经典的应用是滑动窗口最大值问题给定一个数组和一个窗口大小 k要求输出每个窗口内的最大值窗口每次向右移动一格。如果每次重新扫描窗口复杂度是 O(n*k)用单调队列可以把总复杂度降到 O(n)。public int[] maxSlidingWindow(int[] nums, int k) { if (nums null || nums.length 0 || k 0) { return new int[0]; } int n nums.length; int[] result new int[n - k 1]; DequeInteger deque new ArrayDeque(); for (int i 0; i n; i) { while (!deque.isEmpty() deque.peekFirst() i - k 1) { deque.pollFirst(); } while (!deque.isEmpty() nums[deque.peekLast()] nums[i]) { deque.pollLast(); } deque.offerLast(i); if (i k - 1) { result[i - k 1] nums[deque.peekFirst()]; } } return result; }这段代码的核心是维护一个“队首始终是当前窗口最大值”的队列。第二个 while 把队尾所有比当前元素小的下标都移除因为它们在后续窗口中不可能再成为最大值。第一个 while 剔除已经滑出窗口左界的过期下标。数组里存的是原数组下标而不是值这样既能拿到值又能判断是否过期。我在写单调队列时犯过一个错误在6 存值而不是下标结果窗口滑动时完全无法判断过期最后 debug 了很久才意识到问题。如果你要在算法题里手动实现单调队列建议统一存下标这是很多标准答案的惯例。6. 面试与实战中的常见坑和排查心得6.1 队列方法用错了会怎样面试和开发中经常被问到 add 和 offer、remove 和 poll 的区别前面已经用表格梳理过。这里补充一个真实的排查案例有个同事在处理请求超时重试时用 LinkedList 作为待重试队列出队时直接调 remove()结果某个时间点队列恰好为空remove() 抛了 NoSuchElementException异常处理逻辑又把这个异常当成业务失败继续重试最后形成死循环。要是用 poll()返回 null 后走正常的判断分支根本不会出现这种连锁反应。再提醒一个细节很多队列实现不允许 null 元素尤其是 ArrayDeque 和 ArrayBlockingQueue。如果你把 null 当作业务状态传入会在入队时直接抛异常而且错误信息可能不够直观。所以要么在入队前显式校验非空要么干脆约定 null 就是非法数据。这也能避免 poll() 返回 null 时分不清“队列为空”和“取到空数据”。6.2 并发场景下的队列安全边界普通队列比如 LinkedList 和 ArrayDeque线程都不安全。多线程同时 offer 和 poll 会出现数据错乱、size 不准确甚至链表结构被破坏。最简单的方法是加 synchronized 锁但加锁性能不够好。更好的是使用并发包里的并发队列阻塞场景用 BlockingQueue非阻塞场景可以用 ConcurrentLinkedQueue。ConcurrentLinkedQueue 是基于 CAS 的无锁队列入队出队都不阻塞吞吐量更高。无锁并发队列不是没有代价。它内部基于 Michael-Scott 算法的思想用 volatile 和 CAS 维护 head 和 tail 指针队列长度的 size() 需要在多线程环境下遍历计数如果要保证准确就要付出高昂代价。很多并发队列的 size() 在并发场景下是近似值不要依赖它的精确性来判断“是否还有任务需要处理”。我见过一个调度系统用 ConcurrentLinkedQueue 的 size 判断是否执行关闭逻辑结果因为 size 不准确把还没处理完的任务提前关掉了。这种场景应该用计数器或者 AtomicLong 额外维护一个精确的数量。如果系统里对队列的并发要求很高可以考虑 Disruptor 这类高性能队列框架它用环形数组和缓存行填充等技巧能打出单机百万级 TPS。我们早期做订单异步通知时试过 Disruptor 替换 LinkedBlockingQueue在高并发场景下延迟和吞吐确实提升明显。但它学习成本高调试也不方便对大多数业务来说并发包里的阻塞队列已经足够没必要一开始就上重武器。6.3 内存、性能与排查技巧队列使用中内存问题是最容易忽视的部分。数组实现如果出队后不把对应位置的引用置空被移除对象的引用会一直残留在数组里导致 GC 无法回收长期运行就可能内存泄漏。前面手写代码里我在 poll 中写了data[head] null;这个习惯要带到任何自定义容器实现里。用 JDK 提供的队列时也要注意如果队列本身从不清理积压的对象会一直堆在堆里。性能上不同队列的定位差异也很大。ArrayDeque 扩容时会复制整个数组如果初始容量设置不合理频率扩容会影响性能LinkedBlockingQueue 的锁粒度比 ArrayBlockingQueue 细读锁和写锁分开吞吐量在多数场景下更好。实际调优时不要凭感觉先在压测环境里拿不同队列跑一遍真实流量再结合 GC 日志和线程 dump 分析瓶颈。如果你遇到队列相关的问题不知道怎么排查我建议从三个地方入手一是队列积压量记录 offer 失败次数和阻塞 put 的等待时间二是消费者处理耗时看看单条消息处理是否变慢三是锁竞争情况通过 jstack 看线程状态如果大量线程 BLOCKED 在同一个锁上就要考虑换更细粒度的锁或者无锁队列。排查队列问题最忌讳“拍脑袋改队列类型”没有数据支撑的调优都是瞎忙。最后说几句实操体会队列这个数据结构看似基础但把它放到并发、分布式、消息系统里再看复杂度会一路增加。我实际工作中的体会是一定要先手写一遍数组队列、循环队列、链表队列理解了指针移动和取模边界再去看 JDK 源码里的 ArrayBlockingQueue你会发现很多注释和代码逻辑忽然就能读懂了面试时被追问细节也能从容应对。如果正准备面试建议把第 3 节的循环队列代码背熟把第 4 节的线程池队列选型理清楚再能说出消息队列重复消费的幂等方案这一块基本就通关了。如果是在做项目提醒一句任何需要跨进程传递数据的场景先想清楚是单机队列够用还是得上消息队列别把架构搞得过于复杂。队列选型和实现永远是“够用为佳稳定优先”。