1. 从单线程到并发为什么Queue的线程安全值得单独拎出来讲很多人第一次接触Java集合框架的时候会把ArrayList、LinkedList、HashMap这些结构用得滚瓜烂熟但一提到Queue和Deque的线程安全版本脑子里就只剩一个模糊的ConcurrentLinkedQueue名字具体它和BlockingQueue有什么区别、什么场景该用哪个、内部到底怎么保证安全基本说不清楚。我自己早期做服务端开发时就吃过这个亏——在一个生产者-消费者模型里随手用了LinkedList当队列本地测试一切正常压测一上来数据就开始错乱排查了大半天才反应过来LinkedList压根不是线程安全的。这篇内容就是想把Java里线程安全的Queue和Deque结构系统地梳理一遍。所谓Queue就是先进先出FIFO的队列Deque是双端队列两头都能进出所以它既能当队列用也能当栈用。而线程安全这四个字意味着多个线程同时读写这个结构时不需要你在外面额外加synchronized它自己就能保证数据不丢、不重、不乱。这套东西主要服务于并发编程场景尤其是生产者-消费者、任务调度、工作窃取这类模式。适合谁来读如果你已经会用基本的集合类但对java.util.concurrent包里的队列家族总是记混或者你在实际项目里遇到过并发队列选型纠结、性能瓶颈、内存溢出这些问题那这篇会比较对胃口。我会从整体分类讲起把每一类的设计意图、底层机制、适用边界都拆开说再补充一些源码阅读时容易忽略的细节和实操中的坑。整篇内容偏概述性质但该深的地方不会含糊读完你应该能对着一个具体需求快速判断该翻哪个类的牌子。2. 线程安全队列的家族谱系先搞清楚有哪几路人马2.1 两大分支阻塞与非阻塞Java并发包里的线程安全队列第一刀应该切在阻塞和非阻塞上。这个区分不是学术分类而是直接决定你代码怎么写、线程会不会被挂起。阻塞队列BlockingQueue的核心特征是当队列满的时候往里面放元素的线程会被阻塞等待当队列空的时候取元素的线程也会被阻塞等待。它提供了一套带超时的方法比如offer(e, timeout, unit)和poll(timeout, unit)让线程在等不到资源时可以优雅退出而不是死等。这套机制天然适配生产者-消费者模型——生产者不用自己写循环重试消费者也不用轮询空转队列本身就把等待-唤醒这件事包办了。非阻塞队列ConcurrentLinkedQueue这类则相反队列满或空的时候不会阻塞线程而是立刻返回一个失败信号比如offer返回falsepoll返回null。它靠CASCompare-And-Swap这类无锁算法保证并发安全吞吐量在高并发下往往更好但需要调用方自己处理没成功怎么办的逻辑。我个人的经验是如果你在做任务分发、消息缓冲这种典型的生产消费场景优先考虑阻塞队列代码简洁且不容易出错如果你追求极致吞吐、且能接受自己写重试逻辑再考虑非阻塞队列。选错了不是不能用而是会平白多写一堆控制代码。2.2 有界与无界一个容易被忽视的致命细节第二个关键维度是有界还是无界。这个点看起来不起眼但在生产环境里经常是事故源头。有界队列比如ArrayBlockingQueue在创建时就固定了容量队列满了之后生产者会被阻塞或拒绝。无界队列比如LinkedBlockingQueue默认构造、ConcurrentLinkedQueue理论上可以一直往里塞直到内存耗尽。这里有个特别容易踩的坑LinkedBlockingQueue如果不指定容量它的默认容量是Integer.MAX_VALUE约等于无界。很多人在生产者速度远大于消费者速度的场景下用了它结果队列越堆越长最后直接OOM。我见过不止一个项目因为这个原因在流量高峰挂掉。所以我的建议很直接生产环境里除非你有非常明确的理由否则一律用有界队列把容量设成一个合理值让背压back pressure机制自然生效而不是让内存替你扛。2.3 一张表看清主要成员把常见的线程安全队列列出来对比一下心里有个谱类名是否阻塞是否有界底层结构典型场景ArrayBlockingQueue阻塞有界数组固定容量的生产消费LinkedBlockingQueue阻塞可选链表高吞吐任务队列PriorityBlockingQueue阻塞无界堆带优先级的任务DelayQueue阻塞无界堆延迟定时任务、缓存过期SynchronousQueue阻塞容量0无缓冲直接交接LinkedTransferQueue阻塞无界链表高并发传递ConcurrentLinkedQueue非阻塞无界链表高吞吐无锁场景ConcurrentLinkedDeque非阻塞无界链表并发双端操作这张表建议存下来选型的时候扫一眼比翻文档快得多。接下来几节我会挑重点逐个拆。3. 阻塞队列的看家本领锁、条件变量与唤醒机制3.1 ArrayBlockingQueue一把锁管两头ArrayBlockingQueue是最老实的阻塞队列底层就是一个定长数组加上一把ReentrantLock和两个ConditionnotEmpty和notFull。它的工作逻辑很直白生产者放元素前先拿锁如果数组满了就在notFull条件上等待消费者取元素前也拿锁如果数组空了就在notEmpty条件上等待。放进去一个元素后唤醒在notEmpty上等待的消费者取走一个元素后唤醒在notFull上等待的生产者。这里有个设计细节值得注意它只用一把锁同时管生产和消费。这意味着生产者和消费者不能真正并行操作同一时刻只有一个线程能进临界区。好处是实现简单、内存开销小代价是高并发下锁竞争会比较激烈。所以ArrayBlockingQueue更适合并发度中等、容量固定的场景而不是那种生产者消费者都极其凶猛的极端场景。另外它支持公平锁和非公平锁构造时传fair参数。公平锁能保证线程按等待顺序获取避免饥饿但吞吐量会下降。默认是非公平的绝大多数场景用默认就行。3.2 LinkedBlockingQueue两把锁的分离设计LinkedBlockingQueue和上面那位最大的区别是它用了两把锁putLock管入队takeLock管出队各自配一个Condition。这样一来生产者和消费者可以真正并行——一个在队尾加节点一个在队头取节点互不干扰。这个设计是它吞吐量通常高于ArrayBlockingQueue的核心原因。但代价也有每个节点是一个Node对象内存开销比数组大而且因为两把锁队列的计数用了一个AtomicInteger来维护保证count的可见性和原子性。源码里有个细节我读的时候印象很深LinkedBlockingQueue在入队和出队时对count的更新和条件唤醒是分开处理的。比如入队后如果count还没到容量上限它不会去唤醒notFull上的生产者因为此时队列没满没必要唤醒。这种能少唤醒就少唤醒的优化是它在高并发下表现好的重要原因。读源码时如果只扫一遍方法签名很容易漏掉这些精巧之处。3.3 SynchronousQueue容量为零的接力棒SynchronousQueue是个很特殊的存在它的容量是0。什么意思生产者放一个元素必须等到有消费者来取这个放才算完成反过来消费者来取也必须等到有生产者放。它不存储元素只负责把元素从生产者手里直接交到消费者手里像一个接力棒。它内部有两种实现模式公平模式用队列FIFO管理等待的线程非公平模式用栈LIFO。默认非公平。这个结构在ThreadPoolExecutor里有个经典用法——当线程池的maximumPoolSize大于corePoolSize时如果用的是SynchronousQueue那么新任务来了会优先创建新线程而不是排队这正是Executors.newCachedThreadPool()的底层逻辑。用它的场景通常是直接交接语义我不希望任务在队列里堆积要么立刻被处理要么就创建更多处理者。理解这一点对理解线程池的行为非常关键。3.4 PriorityBlockingQueue与DelayQueue带排序和带时间的队列PriorityBlockingQueue是一个无界的优先级队列底层用二叉堆实现出队顺序按元素的自然顺序或传入的Comparator决定而不是FIFO。它虽然叫Blocking但因为无界生产者基本不会被阻塞除非内存耗尽阻塞主要发生在消费者这边——队列空时消费者等待。DelayQueue则是一个存放延迟元素的队列元素必须实现Delayed接口只有延迟期满的元素才能被取出。它底层也是堆按剩余延迟时间排序。典型用途是定时任务调度、缓存条目的过期清理。我做过一个本地缓存就是用DelayQueue配合一个后台线程到点自动清理过期key比定时轮询整个map高效得多。这两个队列的共性是排序逻辑决定了它们的性能特征。堆的插入和删除是O(log n)比普通链表的O(1)要慢所以只有在真的需要优先级或延迟语义时才用别拿它们当普通队列使。4. 非阻塞队列的底层功夫CAS与无锁算法4.1 ConcurrentLinkedQueue的CAS入队逻辑ConcurrentLinkedQueue是java.util.concurrent包里最早的无锁队列之一底层是单向链表靠CAS操作保证线程安全全程不加锁。它的入队逻辑大致是这样每个新节点先构造好然后通过CAS把当前尾节点的next指针从null改成新节点。如果CAS失败说明别的线程抢先改了那就重新读取尾节点再试。出队则是通过CAS把head指针往后移。听起来简单但源码里处理了很多边界情况比如尾节点不一定是真正的尾节点因为CAS可能滞后所以它用了一个hops变量来减少对tail的更新频率避免每次入队都去CAS tail导致竞争。这种优化思路很值得学习无锁结构里减少对共享热点的写操作是提升性能的关键。它的弱点是size()方法需要遍历整个链表是O(n)的而且返回的只是一个近似值遍历过程中队列可能还在变。所以千万别在循环里调size()做判断那会是个性能灾难。4.2 ConcurrentLinkedDeque的双端挑战ConcurrentLinkedDeque是双端版本两头都能进出。双端无锁队列的实现难度比单端高不少因为它要同时维护head和tail两端的并发一致性还要处理节点被删除后的自链接状态。它内部给节点定义了几种状态正常、已删除、自链接等。当一个节点被逻辑删除时会把自己的prev和next指向自己形成一个自环这样其他线程遍历时能识别出这是废弃节点并跳过。这套机制保证了在并发删除的同时遍历操作不会崩溃。实际用它的场景比如工作窃取work-stealing算法——每个工作线程有自己的双端队列自己从头部取任务别的线程从尾部偷任务。这种模式下双端操作非常频繁ConcurrentLinkedDeque就是合适的选择。不过要注意它的性能在极端高并发下不如单端队列因为双端维护的CAS操作更多。4.3 无锁不等于万能ABA问题与内存回收读无锁队列源码时绕不开两个经典问题。第一个是ABA问题。CAS操作只比较值是否相等如果一个值从A变成B又变回ACAS会误以为没变过。在队列场景里这可能导致指针操作出错。Java的AtomicStampedReference通过加版本号解决这个问题但ConcurrentLinkedQueue本身用的是另一种思路——它通过节点的不变性设计和垃圾回收机制来规避而不是靠版本号。第二个是内存回收。无锁结构里一个节点被移除后可能还有别的线程持有它的引用正在遍历所以不能立刻释放。Java靠GC自动处理这个问题这也是为什么Java的无锁队列实现比C的同类结构要简洁——GC替我们扛了最麻烦的部分。但代价是会产生一些已删除但仍可达的浮动垃圾在高频操作下对GC压力有一定影响。理解这两点你就能明白为什么无锁队列不是银弹它在特定场景下吞吐量惊人但在内存敏感或需要强一致性的场景里未必比加锁方案更优。5. 选型实战把需求翻译成具体的类5.1 按场景对号入座光看分类还不够实际选型时我习惯先问几个问题然后直接映射到类需要生产者被阻塞背压吗需要 → 阻塞队列不需要 → 非阻塞队列。需要固定容量防止OOM吗需要 →ArrayBlockingQueue或指定容量的LinkedBlockingQueue。需要优先级吗需要 →PriorityBlockingQueue。需要延迟执行吗需要 →DelayQueue。需要直接交接、不排队吗需要 →SynchronousQueue。需要双端操作或当栈用吗需要 →ConcurrentLinkedDeque或LinkedBlockingDeque。追求极致吞吐且能自己处理失败→ConcurrentLinkedQueue。这套问答走下来基本能锁定一两个候选再结合容量、公平性、内存开销微调即可。5.2 一个真实的生产消费案例拆解假设你要做一个日志异步落盘的系统业务线程产生日志后台线程批量写文件。需求是日志不能丢但也不能因为写盘慢把业务线程拖死。我的做法是用一个有界的LinkedBlockingQueue容量设成几千。业务线程调offer如果返回false队列满了说明写盘跟不上这时候要么降级丢弃低优先级日志要么短暂阻塞。后台线程用poll(timeout)批量取攒够一批或超时后一次性写盘。为什么不用ArrayBlockingQueue因为这里生产者数量多、并发高LinkedBlockingQueue的两把锁能让生产和消费更好并行。为什么不用无界因为一旦写盘卡住无界队列会无限膨胀直到OOM有界队列则能通过offer失败及时暴露问题。为什么不用ConcurrentLinkedQueue因为我们需要队列满时能感知并处理的语义非阻塞队列虽然也能通过offer返回值判断但缺少阻塞等待的便利业务线程得自己写重试。这个案例里每个选择都有明确理由选型不是拍脑袋而是把需求一条条翻译成技术约束。5.3 容量估算的一点经验有界队列的容量设多少合适这个没有标准答案但有个估算思路容量 ≈ 峰值生产速率 × 可接受的最大缓冲时间。比如你的系统峰值每秒产生1000条任务你希望即使消费者短暂卡顿5秒也不丢任务那容量至少设5000。再留点余量设8000到10000。设太小会导致频繁触发背压设太大则失去保护内存的意义。我一般会把这个值做成可配置项上线后根据实际监控调整而不是写死在代码里。6. 源码阅读时容易忽略的几个细节6.1 迭代器的弱一致性并发队列的迭代器基本都是弱一致的它不保证反映创建那一刻的完整快照也不保证后续修改一定可见但保证不会抛出ConcurrentModificationException。这意味着你可以在遍历的同时安全地修改队列但遍历结果可能包含已删除的元素也可能漏掉新加入的元素。这个特性在写代码时很重要。如果你需要遍历时看到确定的数据那并发队列的迭代器满足不了你得换思路比如先dump一份快照。但如果你只是做统计、清理这类容忍误差的操作弱一致迭代器就够用而且性能好。6.2 批量操作的原子性陷阱BlockingQueue提供了drainTo方法可以一次性把队列里的元素转移到另一个集合。这个方法很好用但要注意它不保证原子性。在drainTo执行过程中其他线程仍然可以往队列里加元素这些新元素可能被这次drainTo带走也可能留到下次。所以别指望用drainTo实现精确清空。另外addAll、containsAll这些批量方法在并发队列上语义都比较弱用之前最好读一下文档说明别想当然。6.3 中断响应的处理阻塞队列的put和take方法会抛出InterruptedException。很多人的代码里直接catch了事或者打印个日志继续跑这是有问题的。中断是一种协作机制正确的做法是要么把异常继续往上抛要么在捕获后恢复中断状态Thread.currentThread().interrupt()让上层知道这个线程被中断了。我见过因为吞掉中断异常导致线程池无法正常关闭的案例——shutdownNow发出中断信号但工作线程把异常吃了继续循环结果关闭流程卡死。这个坑不常遇到遇到一次就够记一辈子。7. 性能与踩坑那些文档不会告诉你的经验7.1 锁竞争下的性能拐点ArrayBlockingQueue和LinkedBlockingQueue的性能对比不是简单的谁快谁慢。在低并发下两者差别不大并发升高后LinkedBlockingQueue的两把锁优势开始显现但如果并发极高、队列又很短ArrayBlockingQueue因为数组的缓存友好性有时反而更稳。我的建议是别迷信理论压测说话。用你真实的负载模型跑一遍看吞吐和延迟比看任何对比文章都靠谱。我做过一个任务队列理论分析觉得LinkedBlockingQueue更好实测下来在特定负载下ArrayBlockingQueue的P99延迟反而更低最后选了后者。7.2 无界队列的OOM隐患前面提过这里再强调一次因为它太常见了。LinkedBlockingQueue不传容量、ConcurrentLinkedQueue、PriorityBlockingQueue都是无界的。在生产者速度可能超过消费者的任何场景里无界队列都是一颗定时炸弹。流量正常时看不出问题一旦消费者因为下游故障变慢队列就会像吹气球一样膨胀直到内存耗尽。防御手段有两个一是尽量用有界队列二是如果必须用无界加监控告警对队列长度设阈值超了就打日志或触发降级。别等到OOM了才发现队列已经堆了几百万个对象。7.3 公平锁的代价ArrayBlockingQueue和LinkedBlockingQueue都支持公平模式。公平模式能避免线程饥饿但吞吐量会明显下降因为每次唤醒都要维护等待队列的顺序。除非你的业务对公平性有硬性要求比如某些计费、调度场景否则用默认的非公平模式就好。我试过把一个高吞吐队列改成公平模式QPS直接掉了三成后来果断改回去了。7.4 别在队列里放大对象队列里存的元素如果是大对象会显著增加内存压力和GC负担。比如你往队列里塞一个几MB的byte[]几千个元素就是几个GB。更好的做法是存引用、存ID、存轻量描述符真正的数据放在别处比如文件、缓存消费时再按需加载。这个原则在内存敏感的队列场景里尤其重要。8. 从概述到深入接下来可以往哪读这篇把线程安全Queue和Deque的整体版图、核心机制、选型逻辑和实操经验过了一遍。如果你读到这里觉得有些地方还想再深挖我建议按这个顺序往下走先挑一个你项目里实际会用到的类把它的源码完整读一遍重点看它的锁策略、条件变量使用、CAS循环和边界处理。读的时候带着问题它为什么这么设计换成另一种写法会怎样这种带着疑问读源码的方式比从头到尾扫一遍收获大得多。然后可以关注一下这些队列和线程池的配合。ThreadPoolExecutor的构造函数里那个BlockingQueue参数直接决定了线程池的行为——用SynchronousQueue、LinkedBlockingQueue还是ArrayBlockingQueue任务调度策略完全不同。把队列和线程池放在一起理解很多之前模糊的地方会豁然开朗。最后如果你对无锁算法感兴趣可以顺着ConcurrentLinkedQueue的CAS逻辑去了解一下AtomicReference、VarHandle这些底层工具以及JMMJava内存模型里关于可见性和有序性的规则。无锁队列的每一行代码背后都是内存模型在支撑理解了那一层再看这些源码就是另一种境界了。我个人读源码的习惯是第一遍不求全懂先把主干逻辑走通第二遍带着具体问题去抠细节第三遍尝试自己复述一遍设计思路讲给别人听。能讲清楚才算真懂了。线程安全队列这套东西值得你花这个时间。