阻塞队列这个名字乍看像是Java并发包里一个小知识点但真要在生产环境里写多线程代码你会发现它几乎是无处不在的底座线程池任务排队靠它生产者消费者解耦靠它就连RPC框架里做异步转同步、请求削峰填谷背后也都是它在扛。我最早接触阻塞队列是从自己写一个“优雅停机”的任务调度器开始的当时用普通队列加锁手写了一个结果线程唤醒时机、锁竞争、并发边界各种踩坑最后老老实实换成了BlockingQueue代码量直接砍掉一大半这才意识到这个“简单认识”的背后其实藏着一整套经过实战检验的并发设计思想。这篇内容我会结合自己多年的日常编码经验把阻塞队列的核心设计、常用实现类的差别、以及线程池里到底该怎么选队列讲清楚。不管你是刚接触Java并发的小白还是已经写过一些多线程代码、但面对ArrayBlockingQueue和LinkedBlockingQueue选择困难症的开发者这篇文章都能给你一个直接可用的参考路径。1. 先搞清楚阻塞队列到底解决了什么问题在没有阻塞队列之前我们写“生产者→消费者”模型通常是自己维护一个共享容器再加锁、加条件变量。看起来逻辑简单但写起来非常容易翻车。1.1 手写等待唤醒的痛点假设你用ArrayList当缓冲区生产者和消费者都要往里放数据、取数据那就必须加锁不然两个线程同时操作会出事。加锁之后你还得处理“容器满了”和“容器空了”这两种边界满了生产者就得等空了消费者就得等。用synchronized配合wait/notify写出来大约是这个样子synchronized (lock) { while (list.size() maxSize) { lock.wait(); } list.add(item); lock.notifyAll(); }这段代码你看第一遍觉得没问题看第二遍就开始满头问号为什么wait要用while而不是if为什么notifyAll而不是notify如果多个生产者和多个消费者同时跑notify只唤醒一个线程万一唤醒的是同类线程整个程序就可能永久卡住。还有更隐蔽的问题比如notifyAll唤醒的线程重新抢锁之后容器条件可能已经变了必须再次检查条件。这些问题不是不能解决而是每次都要自己思考一遍非常容易出错。我记得有一次线上用这种手写模型消费者消费慢生产者疯狂生产结果所有线程全被wait挂起CPU看着不高但整个任务链路直接卡死。排查了大半天最后发现是notify唤醒错线程导致的。1.2 阻塞队列的现成契约BlockingQueue相当于JDK帮你把上面这套“等待-通知”机制封装好了。它的核心契约就两条当队列满时往里放数据的操作会被阻塞直到队列有空位当队列空时往外取数据的操作会被阻塞直到队列里有新数据。你不需要写任何wait/notify代码直接调用put()和take()线程的挂起和唤醒由队列内部去管理。用生活化类比来说这就像你去餐厅吃饭普通队列是你站在收银台前面挤着抢位置全部自己操心阻塞队列是拿了个号坐在候餐区等叫号轮到了自然通知你。这个设计解决了一个关键问题把“线程间的协作”从业务代码里抽离出来封装成队列的内置行为。写业务的人只需要关心“我生产了什么”“我消费了什么”至于队列满没满、消费者有没有就绪都是队列自己的事。这也是阻塞队列成为并发编程基础设施的根本原因。注意BlockingQueue是一个接口Java里常见的类如ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue都是它的实现但每种实现的行为细节差别很大后面会展开讲。2. 核心方法体系一组方法三种行为阻塞队列的接口方法乍一看很多其实可以按三类行为来记忆抛异常、返回特殊值、阻塞等待。JDK的BlockingQueue接口文档里有一张经典的对照表我先用实际使用的角度重新整理一遍。2.1 四组操作行为对照操作抛异常返回特殊值阻塞等待超时退出插入add(e)offer(e)put(e)offer(e, time, unit)移除remove()poll()take()poll(time, unit)检查element()peek()不支持不支持这个表值得你贴在工位上。在做技术选型时很多人问“add和offer到底用哪个”答案其实取决于你对队列满了这件事的态度add(e)队列满了直接抛IllegalStateException。适合你确信队列不会满、或者满了就是程序错误必须立刻暴露的场景。offer(e)队列满了返回false不会抛异常。适合“放不进去就算了我走别的逻辑”的场景。put(e)队列满了线程直接挂住直到有空位。适合强制要求每一条数据都必须被处理的场景比如任务不可丢弃。offer(e, 1, TimeUnit.SECONDS)等待一秒仍然满了就返回false。这是最灵活的一种适合“我可以等但不能无限等”的场景。我自己的习惯是生产环境核心链路一律不用add因为add抛出的异常往往发生在队列已满的瞬时处理不好会影响主流程如果任务一定不能丢就用put同时把队列大小监控起来如果任务可以降级或丢弃就用带超时的offer。2.2 take和poll的区别take()是取数据队列为空时线程会阻塞poll()是取数据队列为空时直接返回null。这两个的选择逻辑和上面类似但有一个容易踩的坑poll()返回null可能有两层含义——队列真的空了或者队列里存的本身就是null。虽然BlockingQueue不允许存null元素绝大多数实现会抛NullPointerException但用peek()检查队首元素时返回null也可能意味着队列空所以处理时要注意区分。还有一个实战里很有用的方法是drainTo(Collection c)它能一次性把队列里所有当前可达的数据排空到另一个集合中。批量消费场景下这个比循环poll()效率高很多因为它能减少锁竞争次数。比如你从队列里批量拉取消息去批量入库用drainTo一次拉100条和循环poll100次性能差距在高并发下非常明显。2.3 队列容量与剩余容量remainingCapacity()返回队列剩余容量size()返回当前元素个数。这两个方法可以用来做监控。但注意多线程环境下这两个数值是瞬时的不能作为精确的业务判断依据。比如你判断remainingCapacity() 0就认为队列满了但可能下一秒消费者立刻取走了一条数据。所以容量判断只能用来做粗粒度的报警不能当作业务逻辑的硬条件。3. 常用实现类逐个说清楚BlockingQueue的常见实现类有六七个每个都有自己的底层数据结构和适用场景。很多人只记住了“数组有界、链表无界”这是一个很粗糙的理解实际差很多。3.1 ArrayBlockingQueue有界数组公平可配ArrayBlockingQueue底层是Object数组创建时必须指定容量是一个严格的有界队列。它的内部维护了两个条件变量notFull和notEmpty分别负责生产者阻塞和消费者阻塞。它最大的特点是“单一锁”实现。什么意思就是生产者和消费者共用同一把锁。好处是实现简单、代码稳定坏处是在生产消费都比较频繁的场景下锁竞争会比较大。不过JDK对这个类的优化做得很好在低竞争和中等竞争下表现并不差。构造方法里有一个fair参数new ArrayBlockingQueue(100, true)fair为true时等待时间最长的线程会优先获得访问权可以避免线程饥饿。但公平策略需要额外的性能开销实测在高并发下吞吐会下降一些。所以除非你对“公平性”有硬性要求一般默认用非公平模式就行。3.2 LinkedBlockingQueue无界/有界随你定双锁提升并发度LinkedBlockingQueue底层是单向链表。如果创建时不指定容量默认是Integer.MAX_VALUE也就是“无界”队列指定了容量就是有界队列。它的实现比ArrayBlockingQueue精巧的地方在于用“双锁”一把putLock管入队一把takeLock管出队。生产者和消费者互不阻塞理论上并发度更高。实际场景里如果你的应用是“一写多读”或者“多写一读”LinkedBlockingQueue的吞吐通常优于ArrayBlockingQueue。但这里必须泼一盆冷水在Java 8之后的很多性能对比里当队列容量较小时LinkedBlockingQueue因为链表节点的频繁创建和销毁GC压力反而比数组实现更大。所以并不是“有界就用LinkedBlockingQueue”那么简单后面线程池选型部分会细说。3.3 SynchronousQueue没缓冲的手递手SynchronousQueue几乎没有内部容量准确说容量视为0。每个put操作必须等待一个take操作反之亦然。它不存储元素只负责“交接”。这个类初看很反直觉既然是队列怎么会没有容量但在某些场景下它恰恰是最合理的方案。举个例子Executors.newCachedThreadPool()用的就是SynchronousQueue。这个线程池的特点是来了任务就要交付给线程去执行如果当前没有空闲线程就新开一个线程如果有线程空闲就直接把任务交接过去。因为队列不存储任何任务它天然不存在“队列满了任务还在排队”这种情况也不会产生因积压导致的内存问题。代价是可能会创建非常多的线程线程数上限由你配置决定没配好就容易把系统资源打爆。3.4 PriorityBlockingQueue按优先级出队PriorityBlockingQueue是一个无界优先级队列底层是二叉堆出队顺序不按插入顺序而是按优先级排序。元素必须实现Comparable接口或者在构造时传入Comparator。这个类在“任务有优先级”的场景下特别好用。比如你有一个定时上报的任务、一个实时处理的任务、一个后台清理的任务三者的执行优先级不同就可以扔进同一个PriorityBlockingQueue让高优先级的任务先被消费。有一点要注意由于它是无界队列任务积压时会导致内存占用持续增长。使用时要结合业务建好监控在任务提交侧做限流或拒绝。3.5 DelayQueue延迟到期的才是我的DelayQueue底层用PriorityBlockingQueue实现队首元素是“延迟时间最早到期”的元素。元素必须实现Delayed接口核心方法是getDelay(TimeUnit unit)返回当前剩余延迟时间。它的经典应用场景是定时任务调度、订单超时关闭、缓存过期淘汰之类的延后执行需求。使用方式也很简单往队列里放一个延迟5秒的订单关闭任务消费者调用take()时会阻塞直到队首元素到期才能取出。这样你不需要起定时器反复扫描数据库一个消费者线程就能优雅地处理所有延迟任务。3.6 其他值得一提的成员LinkedTransferQueue可以看成SynchronousQueue和LinkedBlockingQueue的合体它支持“有等待者就直接交接没等待者就入队存储”的transfer()语义在实际框架如Netty里有用到。LinkedBlockingDeque则是双端队列支持两端插入和取出工作窃取算法Work Stealing的典型底层结构ForkJoinPool就用了类似的双端队列设计。4. 线程池的队列选择面试高频实战重灾区阻塞队列在普通业务代码里用得最多的地方还是配合线程池使用。很多人背了“线程池七大参数”但真到选队列时一脸懵。这一节我结合几个真实的生产案例把线程池和队列的配合讲透。4.1 线程池处理任务的完整逻辑先复习一下线程池的工作流程当提交一个任务到线程池时如果当前运行线程数小于corePoolSize直接新建线程执行如果线程数大于等于corePoolSize任务会先进入阻塞队列排队如果队列也满了且线程数小于maximumPoolSize才会新建非核心线程去执行如果线程数已经达到maximumPoolSize且队列还是满的就执行拒绝策略。这个流程里阻塞队列的大小直接决定了线程池在什么情况下才会扩容线程。理解这个关系以后很多配置问题就迎刃而解了。4.2 各种线程池默认用的什么队列线程池工厂方法使用的队列队列特性newFixedThreadPool()LinkedBlockingQueue无界默认容量Integer.MAX_VALUEnewCachedThreadPool()SynchronousQueue无缓冲交接newSingleThreadExecutor()LinkedBlockingQueue无界newScheduledThreadPool()DelayedWorkQueue延迟队列这里最值得警惕的是newFixedThreadPool。它创建一个固定线程数的线程池配上无界队列意味着当所有核心线程都在忙时新任务会无限排队永远不会触发拒绝策略也不会创建额外线程。好处是线程数稳定、不会被任务洪峰冲垮坏处是如果任务长期积压内存会被撑爆而且没有任何报警。我记得有一次线上项目用newFixedThreadPool(10)做异步消息推送某天下游服务变慢每条消息处理时间从20毫秒涨到2秒队列里积压了几十万条未发送消息内存直线上升最后Full GC频繁整个应用卡死。这就是无界队列的坑它用内存换时间一旦时间撑不住内存就先炸了。4.3 手动创建线程池时队列怎么选所以我现在写代码基本不直接用Executors的快捷方法而是手动创建ThreadPoolExecutor。选队列的核心原则有三条第一必须是有界队列以防内存被打爆。ArrayBlockingQueue或指定容量的LinkedBlockingQueue都可以我倾向用ArrayBlockingQueue因为它的性能在小容量下更稳定可预测。第二队列大小要和业务峰值匹配。假设核心线程数6队列大小1000每秒任务量500每个任务平均处理耗时100毫秒。那么每秒能处理的任务数约为6 / 0.1 60个队列会以每秒440个的速度积压大约2.3秒后队列就会满之后线程池会尝试扩容。如果你预期峰值持续5秒那队列至少得设到(500-60) * 5 2200左右配合合理的maximumPoolSize才能扛住。第三配套拒绝策略和监控。队列满了以后触发拒绝策略AbortPolicy默认抛异常CallerRunsPolicy则由提交任务的线程自己执行DiscardPolicy和DiscardOldestPolicy会静默丢弃任务。生产上我更推荐CallerRunsPolicy它让任务不丢同时天然起到背压限流作用——提交方自己执行执行完才会继续提交从源头限制任务涌入速度。4.4 DelayedWorkQueue在定时线程池里的作用ScheduledThreadPoolExecutor内部用的是DelayedWorkQueue它的作用是把任务按延迟时间排序线程池专门开线程取“到点”的任务去执行。这里有一个很多人不知道的细节DelayedWorkQueue本质上也是个无界队列所以定时任务线程池的任务也不能无限堆积。如果你的业务里有大量不同延迟时间的定时任务最好评估一下积压风险避免任务堆积造成延迟时间大面积失准。5. 实操手写一个生产者消费者模型理论讲完我们来点直接的。用一个真实可运行的例子展示put和take的阻塞效果以及选择不同队列时程序的整体表现差异。5.1 基础版本ArrayBlockingQueue实现先写一个最经典的生产者消费者模型public class BlockingQueueDemo { private static final int CAPACITY 5; public static void main(String[] args) { BlockingQueueInteger queue new ArrayBlockingQueue(CAPACITY); Thread producer new Thread(() - { for (int i 1; i 10; i) { try { queue.put(i); System.out.println([生产者] 放入: i 当前队列大小: queue.size()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }, producer); Thread consumer new Thread(() - { while (true) { try { Integer value queue.take(); System.out.println([消费者] 取出: value 当前队列大小: queue.size()); Thread.sleep(500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, consumer); producer.start(); consumer.start(); } }这段代码逻辑很简单生产者每秒放一个任务消费者每500毫秒消费一个任务。因为队列容量只有5消费者消费速度又慢于生产速度你能很直观地看到队列大小接近5时生产者会卡在put上直到消费者取走数据腾出空间。这个过程不需要任何显式锁和wait/notify代码可读性比手写模型好太多而且边界正确性由JDK保证。5.2 换成offer验证非阻塞行为如果我把put换成offer并且不处理返回值会怎么样队列满了offer直接返回false数据丢在队列外程序继续往下走。如果没有对应的逻辑兜底这批数据就悄无声息地丢了。这一点在日常开发中特别容易出问题——很多人图省事用offer却不检查返回值等到发现丢数据时已经线上出事故了。我的建议是用offer时返回值必须处理。哪怕只是打一条告警日志也比静默丢弃好。5.3 用SynchronousQueue感受交接语义把上面的队列换成SynchronousQueue再跑一次你会看到完全不同的现象队列永远没有积压因为put之后必须立刻有一个take来接收否则put就会一直阻塞。如果你只启动了生产者线程没有消费者程序直接卡死在第一次put。这个特性在需要“快速感知消费者状态”的场景下很有用但也要求你对消费端有足够的信心。如果消费端挂了生产端也会一起挂这就是SynchronousQueue的代价生产者和消费者是强耦合的不存在缓冲。6. 常见问题与排查技巧实录阻塞队列用多了自然会遇到一些典型问题。我把这几年踩过的坑和排查思路整理出来算是给后来者的一份避坑手册。6.1 队列积压导致OOM症状应用报OutOfMemoryError堆内存居高不下GC日志显示Full GC频繁。排查过程先看线程池配置发现用了newFixedThreadPool加默认无界队列再通过heap dump分析发现堆里大量LinkedBlockingQueue$Node对象最后定位到某个下游接口变慢导致任务消费速度远低于生产速度。解决方案手动创建线程池指定有界队列队列容量按业务峰值估算配好CallerRunsPolicy同时监控线程池的queue.size()超过阈值就告警。6.2 线程池不扩容症状线程池核心线程一直满载但任务处理延迟越来越大队列越来越长线程数却始终不增长。排查思路检查队列是否是有界队列。如果队列是无界的线程池永远不可能触发maximumPoolSize扩容逻辑——任务只会一直排队而不是开新线程。很多新手以为线程池会“自动伸缩”其实它的扩容前提是“队列满了”。解决方案给队列设置一个合理的容量上限让线程池在任务变多时能真正扩容而不是把压力全部转嫁给队列。6.3 take和poll混用的结果症状消费者线程偶尔空转系统日志出现大量“null data”处理记录但实际业务数据没有丢失。原因业务代码里同时使用了take()和poll(timeout)在队列为空时poll返回null被当成了正常业务数据进入后续处理链路。解决方案严格区分“队列空”和“业务数据为空”两种情况。如果业务上不允许null入队BlockingQueue本身也禁止那么poll返回null就只代表队列空业务处理前应当过滤。6.4 公平锁性能下降症状某个系统从单机迁移到高并发环境后吞吐量不升反降线程等待时间占比很高。原因代码里用了new ArrayBlockingQueue(100, true)公平锁虽然保证了线程调度的公平性但也引入了额外的上下文切换成本。解决方案默认使用非公平锁只有在线程饥饿问题已经发生的场景下再考虑公平策略。大多数业务场景的“公平”优先级远低于“吞吐量”。7. 个人实操中的一点体会写了这么多年并发代码我越来越觉得阻塞队列的精髓不在API本身而在“没有背压的队列本质上是在透支内存”。无论你选ArrayBlockingQueue还是LinkedBlockingQueue无论你配多大容量真正决定系统稳定性的永远是消费端的处理能力和异常时的兜底策略。我看过太多系统线程池参数调得很完美队列容量算得很精确结果消费端一抖动整个链路还是崩了。所以每次上线前我都会反问自己一句如果下游比预期慢十倍我的队列会用内存扛还是用拒绝策略挡想清楚这个答案阻塞队列就算真正用明白了。如果你后续还想深入建议去读一读ArrayBlockingQueue和LinkedBlockingQueue的源码重点看它们对锁的设计差异以及await和signal的调用时机。把这些底层机制吃透你在不同业务场景下选型时就会更有底气而不是靠背配置走天下。
阻塞队列这个名字乍看像是Java并发包里一个小知识点但真要在生产环境里写多线程代码你会发现它几乎是无处不在的底座线程池任务排队靠它生产者消费者解耦靠它就连RPC框架里做异步转同步、请求削峰填谷背后也都是它在扛。我最早接触阻塞队列是从自己写一个“优雅停机”的任务调度器开始的当时用普通队列加锁手写了一个结果线程唤醒时机、锁竞争、并发边界各种踩坑最后老老实实换成了BlockingQueue代码量直接砍掉一大半这才意识到这个“简单认识”的背后其实藏着一整套经过实战检验的并发设计思想。这篇内容我会结合自己多年的日常编码经验把阻塞队列的核心设计、常用实现类的差别、以及线程池里到底该怎么选队列讲清楚。不管你是刚接触Java并发的小白还是已经写过一些多线程代码、但面对ArrayBlockingQueue和LinkedBlockingQueue选择困难症的开发者这篇文章都能给你一个直接可用的参考路径。1. 先搞清楚阻塞队列到底解决了什么问题在没有阻塞队列之前我们写“生产者→消费者”模型通常是自己维护一个共享容器再加锁、加条件变量。看起来逻辑简单但写起来非常容易翻车。1.1 手写等待唤醒的痛点假设你用ArrayList当缓冲区生产者和消费者都要往里放数据、取数据那就必须加锁不然两个线程同时操作会出事。加锁之后你还得处理“容器满了”和“容器空了”这两种边界满了生产者就得等空了消费者就得等。用synchronized配合wait/notify写出来大约是这个样子synchronized (lock) { while (list.size() maxSize) { lock.wait(); } list.add(item); lock.notifyAll(); }这段代码你看第一遍觉得没问题看第二遍就开始满头问号为什么wait要用while而不是if为什么notifyAll而不是notify如果多个生产者和多个消费者同时跑notify只唤醒一个线程万一唤醒的是同类线程整个程序就可能永久卡住。还有更隐蔽的问题比如notifyAll唤醒的线程重新抢锁之后容器条件可能已经变了必须再次检查条件。这些问题不是不能解决而是每次都要自己思考一遍非常容易出错。我记得有一次线上用这种手写模型消费者消费慢生产者疯狂生产结果所有线程全被wait挂起CPU看着不高但整个任务链路直接卡死。排查了大半天最后发现是notify唤醒错线程导致的。1.2 阻塞队列的现成契约BlockingQueue相当于JDK帮你把上面这套“等待-通知”机制封装好了。它的核心契约就两条当队列满时往里放数据的操作会被阻塞直到队列有空位当队列空时往外取数据的操作会被阻塞直到队列里有新数据。你不需要写任何wait/notify代码直接调用put()和take()线程的挂起和唤醒由队列内部去管理。用生活化类比来说这就像你去餐厅吃饭普通队列是你站在收银台前面挤着抢位置全部自己操心阻塞队列是拿了个号坐在候餐区等叫号轮到了自然通知你。这个设计解决了一个关键问题把“线程间的协作”从业务代码里抽离出来封装成队列的内置行为。写业务的人只需要关心“我生产了什么”“我消费了什么”至于队列满没满、消费者有没有就绪都是队列自己的事。这也是阻塞队列成为并发编程基础设施的根本原因。注意BlockingQueue是一个接口Java里常见的类如ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue都是它的实现但每种实现的行为细节差别很大后面会展开讲。2. 核心方法体系一组方法三种行为阻塞队列的接口方法乍一看很多其实可以按三类行为来记忆抛异常、返回特殊值、阻塞等待。JDK的BlockingQueue接口文档里有一张经典的对照表我先用实际使用的角度重新整理一遍。2.1 四组操作行为对照操作抛异常返回特殊值阻塞等待超时退出插入add(e)offer(e)put(e)offer(e, time, unit)移除remove()poll()take()poll(time, unit)检查element()peek()不支持不支持这个表值得你贴在工位上。在做技术选型时很多人问“add和offer到底用哪个”答案其实取决于你对队列满了这件事的态度add(e)队列满了直接抛IllegalStateException。适合你确信队列不会满、或者满了就是程序错误必须立刻暴露的场景。offer(e)队列满了返回false不会抛异常。适合“放不进去就算了我走别的逻辑”的场景。put(e)队列满了线程直接挂住直到有空位。适合强制要求每一条数据都必须被处理的场景比如任务不可丢弃。offer(e, 1, TimeUnit.SECONDS)等待一秒仍然满了就返回false。这是最灵活的一种适合“我可以等但不能无限等”的场景。我自己的习惯是生产环境核心链路一律不用add因为add抛出的异常往往发生在队列已满的瞬时处理不好会影响主流程如果任务一定不能丢就用put同时把队列大小监控起来如果任务可以降级或丢弃就用带超时的offer。2.2 take和poll的区别take()是取数据队列为空时线程会阻塞poll()是取数据队列为空时直接返回null。这两个的选择逻辑和上面类似但有一个容易踩的坑poll()返回null可能有两层含义——队列真的空了或者队列里存的本身就是null。虽然BlockingQueue不允许存null元素绝大多数实现会抛NullPointerException但用peek()检查队首元素时返回null也可能意味着队列空所以处理时要注意区分。还有一个实战里很有用的方法是drainTo(Collection c)它能一次性把队列里所有当前可达的数据排空到另一个集合中。批量消费场景下这个比循环poll()效率高很多因为它能减少锁竞争次数。比如你从队列里批量拉取消息去批量入库用drainTo一次拉100条和循环poll100次性能差距在高并发下非常明显。2.3 队列容量与剩余容量remainingCapacity()返回队列剩余容量size()返回当前元素个数。这两个方法可以用来做监控。但注意多线程环境下这两个数值是瞬时的不能作为精确的业务判断依据。比如你判断remainingCapacity() 0就认为队列满了但可能下一秒消费者立刻取走了一条数据。所以容量判断只能用来做粗粒度的报警不能当作业务逻辑的硬条件。3. 常用实现类逐个说清楚BlockingQueue的常见实现类有六七个每个都有自己的底层数据结构和适用场景。很多人只记住了“数组有界、链表无界”这是一个很粗糙的理解实际差很多。3.1 ArrayBlockingQueue有界数组公平可配ArrayBlockingQueue底层是Object数组创建时必须指定容量是一个严格的有界队列。它的内部维护了两个条件变量notFull和notEmpty分别负责生产者阻塞和消费者阻塞。它最大的特点是“单一锁”实现。什么意思就是生产者和消费者共用同一把锁。好处是实现简单、代码稳定坏处是在生产消费都比较频繁的场景下锁竞争会比较大。不过JDK对这个类的优化做得很好在低竞争和中等竞争下表现并不差。构造方法里有一个fair参数new ArrayBlockingQueue(100, true)fair为true时等待时间最长的线程会优先获得访问权可以避免线程饥饿。但公平策略需要额外的性能开销实测在高并发下吞吐会下降一些。所以除非你对“公平性”有硬性要求一般默认用非公平模式就行。3.2 LinkedBlockingQueue无界/有界随你定双锁提升并发度LinkedBlockingQueue底层是单向链表。如果创建时不指定容量默认是Integer.MAX_VALUE也就是“无界”队列指定了容量就是有界队列。它的实现比ArrayBlockingQueue精巧的地方在于用“双锁”一把putLock管入队一把takeLock管出队。生产者和消费者互不阻塞理论上并发度更高。实际场景里如果你的应用是“一写多读”或者“多写一读”LinkedBlockingQueue的吞吐通常优于ArrayBlockingQueue。但这里必须泼一盆冷水在Java 8之后的很多性能对比里当队列容量较小时LinkedBlockingQueue因为链表节点的频繁创建和销毁GC压力反而比数组实现更大。所以并不是“有界就用LinkedBlockingQueue”那么简单后面线程池选型部分会细说。3.3 SynchronousQueue没缓冲的手递手SynchronousQueue几乎没有内部容量准确说容量视为0。每个put操作必须等待一个take操作反之亦然。它不存储元素只负责“交接”。这个类初看很反直觉既然是队列怎么会没有容量但在某些场景下它恰恰是最合理的方案。举个例子Executors.newCachedThreadPool()用的就是SynchronousQueue。这个线程池的特点是来了任务就要交付给线程去执行如果当前没有空闲线程就新开一个线程如果有线程空闲就直接把任务交接过去。因为队列不存储任何任务它天然不存在“队列满了任务还在排队”这种情况也不会产生因积压导致的内存问题。代价是可能会创建非常多的线程线程数上限由你配置决定没配好就容易把系统资源打爆。3.4 PriorityBlockingQueue按优先级出队PriorityBlockingQueue是一个无界优先级队列底层是二叉堆出队顺序不按插入顺序而是按优先级排序。元素必须实现Comparable接口或者在构造时传入Comparator。这个类在“任务有优先级”的场景下特别好用。比如你有一个定时上报的任务、一个实时处理的任务、一个后台清理的任务三者的执行优先级不同就可以扔进同一个PriorityBlockingQueue让高优先级的任务先被消费。有一点要注意由于它是无界队列任务积压时会导致内存占用持续增长。使用时要结合业务建好监控在任务提交侧做限流或拒绝。3.5 DelayQueue延迟到期的才是我的DelayQueue底层用PriorityBlockingQueue实现队首元素是“延迟时间最早到期”的元素。元素必须实现Delayed接口核心方法是getDelay(TimeUnit unit)返回当前剩余延迟时间。它的经典应用场景是定时任务调度、订单超时关闭、缓存过期淘汰之类的延后执行需求。使用方式也很简单往队列里放一个延迟5秒的订单关闭任务消费者调用take()时会阻塞直到队首元素到期才能取出。这样你不需要起定时器反复扫描数据库一个消费者线程就能优雅地处理所有延迟任务。3.6 其他值得一提的成员LinkedTransferQueue可以看成SynchronousQueue和LinkedBlockingQueue的合体它支持“有等待者就直接交接没等待者就入队存储”的transfer()语义在实际框架如Netty里有用到。LinkedBlockingDeque则是双端队列支持两端插入和取出工作窃取算法Work Stealing的典型底层结构ForkJoinPool就用了类似的双端队列设计。4. 线程池的队列选择面试高频实战重灾区阻塞队列在普通业务代码里用得最多的地方还是配合线程池使用。很多人背了“线程池七大参数”但真到选队列时一脸懵。这一节我结合几个真实的生产案例把线程池和队列的配合讲透。4.1 线程池处理任务的完整逻辑先复习一下线程池的工作流程当提交一个任务到线程池时如果当前运行线程数小于corePoolSize直接新建线程执行如果线程数大于等于corePoolSize任务会先进入阻塞队列排队如果队列也满了且线程数小于maximumPoolSize才会新建非核心线程去执行如果线程数已经达到maximumPoolSize且队列还是满的就执行拒绝策略。这个流程里阻塞队列的大小直接决定了线程池在什么情况下才会扩容线程。理解这个关系以后很多配置问题就迎刃而解了。4.2 各种线程池默认用的什么队列线程池工厂方法使用的队列队列特性newFixedThreadPool()LinkedBlockingQueue无界默认容量Integer.MAX_VALUEnewCachedThreadPool()SynchronousQueue无缓冲交接newSingleThreadExecutor()LinkedBlockingQueue无界newScheduledThreadPool()DelayedWorkQueue延迟队列这里最值得警惕的是newFixedThreadPool。它创建一个固定线程数的线程池配上无界队列意味着当所有核心线程都在忙时新任务会无限排队永远不会触发拒绝策略也不会创建额外线程。好处是线程数稳定、不会被任务洪峰冲垮坏处是如果任务长期积压内存会被撑爆而且没有任何报警。我记得有一次线上项目用newFixedThreadPool(10)做异步消息推送某天下游服务变慢每条消息处理时间从20毫秒涨到2秒队列里积压了几十万条未发送消息内存直线上升最后Full GC频繁整个应用卡死。这就是无界队列的坑它用内存换时间一旦时间撑不住内存就先炸了。4.3 手动创建线程池时队列怎么选所以我现在写代码基本不直接用Executors的快捷方法而是手动创建ThreadPoolExecutor。选队列的核心原则有三条第一必须是有界队列以防内存被打爆。ArrayBlockingQueue或指定容量的LinkedBlockingQueue都可以我倾向用ArrayBlockingQueue因为它的性能在小容量下更稳定可预测。第二队列大小要和业务峰值匹配。假设核心线程数6队列大小1000每秒任务量500每个任务平均处理耗时100毫秒。那么每秒能处理的任务数约为6 / 0.1 60个队列会以每秒440个的速度积压大约2.3秒后队列就会满之后线程池会尝试扩容。如果你预期峰值持续5秒那队列至少得设到(500-60) * 5 2200左右配合合理的maximumPoolSize才能扛住。第三配套拒绝策略和监控。队列满了以后触发拒绝策略AbortPolicy默认抛异常CallerRunsPolicy则由提交任务的线程自己执行DiscardPolicy和DiscardOldestPolicy会静默丢弃任务。生产上我更推荐CallerRunsPolicy它让任务不丢同时天然起到背压限流作用——提交方自己执行执行完才会继续提交从源头限制任务涌入速度。4.4 DelayedWorkQueue在定时线程池里的作用ScheduledThreadPoolExecutor内部用的是DelayedWorkQueue它的作用是把任务按延迟时间排序线程池专门开线程取“到点”的任务去执行。这里有一个很多人不知道的细节DelayedWorkQueue本质上也是个无界队列所以定时任务线程池的任务也不能无限堆积。如果你的业务里有大量不同延迟时间的定时任务最好评估一下积压风险避免任务堆积造成延迟时间大面积失准。5. 实操手写一个生产者消费者模型理论讲完我们来点直接的。用一个真实可运行的例子展示put和take的阻塞效果以及选择不同队列时程序的整体表现差异。5.1 基础版本ArrayBlockingQueue实现先写一个最经典的生产者消费者模型public class BlockingQueueDemo { private static final int CAPACITY 5; public static void main(String[] args) { BlockingQueueInteger queue new ArrayBlockingQueue(CAPACITY); Thread producer new Thread(() - { for (int i 1; i 10; i) { try { queue.put(i); System.out.println([生产者] 放入: i 当前队列大小: queue.size()); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }, producer); Thread consumer new Thread(() - { while (true) { try { Integer value queue.take(); System.out.println([消费者] 取出: value 当前队列大小: queue.size()); Thread.sleep(500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, consumer); producer.start(); consumer.start(); } }这段代码逻辑很简单生产者每秒放一个任务消费者每500毫秒消费一个任务。因为队列容量只有5消费者消费速度又慢于生产速度你能很直观地看到队列大小接近5时生产者会卡在put上直到消费者取走数据腾出空间。这个过程不需要任何显式锁和wait/notify代码可读性比手写模型好太多而且边界正确性由JDK保证。5.2 换成offer验证非阻塞行为如果我把put换成offer并且不处理返回值会怎么样队列满了offer直接返回false数据丢在队列外程序继续往下走。如果没有对应的逻辑兜底这批数据就悄无声息地丢了。这一点在日常开发中特别容易出问题——很多人图省事用offer却不检查返回值等到发现丢数据时已经线上出事故了。我的建议是用offer时返回值必须处理。哪怕只是打一条告警日志也比静默丢弃好。5.3 用SynchronousQueue感受交接语义把上面的队列换成SynchronousQueue再跑一次你会看到完全不同的现象队列永远没有积压因为put之后必须立刻有一个take来接收否则put就会一直阻塞。如果你只启动了生产者线程没有消费者程序直接卡死在第一次put。这个特性在需要“快速感知消费者状态”的场景下很有用但也要求你对消费端有足够的信心。如果消费端挂了生产端也会一起挂这就是SynchronousQueue的代价生产者和消费者是强耦合的不存在缓冲。6. 常见问题与排查技巧实录阻塞队列用多了自然会遇到一些典型问题。我把这几年踩过的坑和排查思路整理出来算是给后来者的一份避坑手册。6.1 队列积压导致OOM症状应用报OutOfMemoryError堆内存居高不下GC日志显示Full GC频繁。排查过程先看线程池配置发现用了newFixedThreadPool加默认无界队列再通过heap dump分析发现堆里大量LinkedBlockingQueue$Node对象最后定位到某个下游接口变慢导致任务消费速度远低于生产速度。解决方案手动创建线程池指定有界队列队列容量按业务峰值估算配好CallerRunsPolicy同时监控线程池的queue.size()超过阈值就告警。6.2 线程池不扩容症状线程池核心线程一直满载但任务处理延迟越来越大队列越来越长线程数却始终不增长。排查思路检查队列是否是有界队列。如果队列是无界的线程池永远不可能触发maximumPoolSize扩容逻辑——任务只会一直排队而不是开新线程。很多新手以为线程池会“自动伸缩”其实它的扩容前提是“队列满了”。解决方案给队列设置一个合理的容量上限让线程池在任务变多时能真正扩容而不是把压力全部转嫁给队列。6.3 take和poll混用的结果症状消费者线程偶尔空转系统日志出现大量“null data”处理记录但实际业务数据没有丢失。原因业务代码里同时使用了take()和poll(timeout)在队列为空时poll返回null被当成了正常业务数据进入后续处理链路。解决方案严格区分“队列空”和“业务数据为空”两种情况。如果业务上不允许null入队BlockingQueue本身也禁止那么poll返回null就只代表队列空业务处理前应当过滤。6.4 公平锁性能下降症状某个系统从单机迁移到高并发环境后吞吐量不升反降线程等待时间占比很高。原因代码里用了new ArrayBlockingQueue(100, true)公平锁虽然保证了线程调度的公平性但也引入了额外的上下文切换成本。解决方案默认使用非公平锁只有在线程饥饿问题已经发生的场景下再考虑公平策略。大多数业务场景的“公平”优先级远低于“吞吐量”。7. 个人实操中的一点体会写了这么多年并发代码我越来越觉得阻塞队列的精髓不在API本身而在“没有背压的队列本质上是在透支内存”。无论你选ArrayBlockingQueue还是LinkedBlockingQueue无论你配多大容量真正决定系统稳定性的永远是消费端的处理能力和异常时的兜底策略。我看过太多系统线程池参数调得很完美队列容量算得很精确结果消费端一抖动整个链路还是崩了。所以每次上线前我都会反问自己一句如果下游比预期慢十倍我的队列会用内存扛还是用拒绝策略挡想清楚这个答案阻塞队列就算真正用明白了。如果你后续还想深入建议去读一读ArrayBlockingQueue和LinkedBlockingQueue的源码重点看它们对锁的设计差异以及await和signal的调用时机。把这些底层机制吃透你在不同业务场景下选型时就会更有底气而不是靠背配置走天下。
