Java并发队列全解析：从BlockingQueue到线程池选型实战

聊到Java里的Queue，很多人第一反应是“这不就是个队列嘛，LinkedList也能用”。但真正到了并发场景，或者面试被问到“线程池的阻塞队列怎么选”时，才发现这里面水很深。我见过不少生产事故，明明线程池参数看着没问题，结果任务全堆在队列里，内存直接被打爆；也见过有人把SynchronousQueue当成普通队列用，线程池直接废掉一半。其实队列选型这件事，本质上是在回答三个问题：数据怎么进、怎么出、进不来出不去的路上该谁等谁。搞懂了这三个问题，无论是JDK自带的Queue，还是Dubbo、Netty里那些高性能队列，你都能一眼看穿它的设计意图。

这篇文章我想把JDK里的Queue家族从头到尾梳理一遍，重点放在并发场景和阻塞队列上。内容包括每个队列的底层结构、适用场景、常见坑点，以及线程池里队列怎么配、爬虫并发任务怎么分、延迟任务怎么做这类实战问题。不管你是刚学Java基础，还是在准备面试八股文，或者是线上出了队列相关问题正在排查，这篇都值得你收藏慢慢看。

1. 先摸清家底：JDK里的Queue到底分了哪几路

1.1 非阻塞队列：LinkedList、ArrayDeque、PriorityQueue怎么用才不踩坑

先聊最简单的。JDK里有一类队列，它只实现了Collection和Queue接口，没有实现BlockingQueue，也就是说它本身不具备线程阻塞的语义。这类队列包括 LinkedList、ArrayDeque、PriorityQueue，以及它们的并发安全版本 ConcurrentLinkedQueue。

LinkedList是最常被拿来当队列用的，add往尾部加，poll从头部取，看起来没什么问题。但你要知道，LinkedList的底层是双向链表，节点是离散分配的，CPU缓存命中率不高。在单线程高频入队出队的场景下，LinkedList往往不如ArrayDeque快，因为ArrayDeque底层是循环数组，内存是连续的，扩容也是整体搬迁，局部性更好。我自己测过，在百万级入队出队的基准测试里，ArrayDeque比LinkedList能快出不少，虽然单次操作差距很小，但积少成多之后差异就明显了。

ArrayDeque还有一个特点，它不允许存null，这一点和LinkedList不同。为什么不允许null？因为null在队列里经常被当作特殊返回值，比如poll()在队列为空时返回null，如果允许入队null，那取出来的null到底是元素还是空队列的标志？语义就乱了。所以JDK的设计者干脆禁止了null入队。这个细节面试偶尔会考，实际使用中也要注意。

PriorityQueue则完全不同，它虽然名字里有Queue，但出队顺序不遵循FIFO，而是按元素的自然顺序或者你传入的Comparator来排序。每次poll()返回的是当前优先级最高的元素。它的底层是二叉堆，具体来说是数组实现的小顶堆。这里有两个坑：第一，PriorityQueue不是线程安全的，多线程并发修改会出问题；第二，它的迭代器不保证顺序，如果你用for-each遍历元素，拿到的顺序和每次poll()的顺序没有任何关系。想按优先级处理任务时，优先考虑它，但记得加锁或者用下面的PriorityBlockingQueue。

再说说ConcurrentLinkedQueue。它是真正线程安全的非阻塞队列，底层是CAS实现的Michael-Scott无锁队列。它的特点是不锁整个队列，每次入队出队都通过CAS操作完成，所以在高并发读多写少、且对实时性要求高的场景下表现很好。但注意，它的size()方法是一个O(n)遍历操作，在并发环境下返回的也只是个近似值，不要拿它来做精确统计。我见过有人用ConcurrentLinkedQueue.size() == 0做判断，结果高并发下偶尔判断失误，就是因为这个原因。如果你想判断队列是否为空，优先使用isEmpty()。

1.2 阻塞队列：真正的并发利器

非阻塞队列不解决“等待”的问题。生产者往里塞数据，如果容器满了，直接失败或者自己忙等；消费者来取数据，如果容器空了，也是直接返回null或抛异常。这在大多数生产消费模型里是不够用的。你总不能让生产者一直死循环重试吧？这时候就需要阻塞队列登场。

BlockingQueue接口在Queue的基础上增加了阻塞语义，核心就是put()和take()两个方法。put()在队列满时会一直等待，直到队列有空间；take()在队列空时会一直等待，直到有新元素进来。这个“等待”不是空转，而是通过Lock和Condition实现的线程挂起与唤醒，既不浪费CPU，又能做到精确的通知。

JDK里BlockingQueue的实现类一共有7个：ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue、PriorityBlockingQueue、DelayQueue、LinkedTransferQueue、LinkedBlockingDeque。我先把它们放在一张表里对比，后面再一个个展开讲。

这些队列的设计思路差异很大。ArrayBlockingQueue用一把锁管所有操作，入队出队互相排斥；LinkedBlockingQueue用两把锁分别管入队和出队，所以生产者消费者可以同时操作队列两端。SynchronousQueue干脆不存数据，生产者put时直接阻塞等待消费者take。每一种设计的背后，都是对特定场景的取舍。

2. API和原理：阻塞等待背后到底做了什么

2.1 add/offer/put/remove/poll/take这一组方法，千万别用混

很多初学者学Queue时，被这一堆方法搞晕了。其实它们的区别只有一个核心，那就是操作失败时的行为不同。我直接列一张表，把这几个方法按“失败处理方式”分组，你对比着看就清楚了。

为什么JDK要提供这么多语义？因为不同场景对“失败”的容忍度不一样。比如你写一个异步日志系统，日志任务满了，你希望直接丢弃还是阻塞等待？如果选择丢弃，用offer(e)加返回值判断最合适；如果希望背压，让生产者慢下来，就得用put()，让它阻塞在队列满的位置上。用错API最常见的后果是：用offer(e)做队列满了就丢弃，结果日志静默丢失，排查半天才发现；或者用put()却期待它不要阻塞，结果线程全部卡死。

我自己的使用习惯是：能用带超时的offer(e, timeout, unit)就不用裸的put()。因为put()一旦阻塞就是无限期等待，如果没有消费者或者消费者挂了，生产者会永久挂起。带超时版本可以设置一个合理的等待时间，超时后走降级逻辑，比如打印告警、写入本地文件、丢弃并计数，这样系统至少还有自愈的可能。并发编程里有一条铁律：无限期阻塞的依赖链条越长，系统越容易在极端情况下瘫痪。

还有一个容易忽略的点：peek()只查看队首元素但不移除，在队列为空时返回null。而element()同样只查看，但为空时抛NoSuchElementException，日常开发中用得很少。我建议统一用peek()，并且做null判断，因为element()的异常语义在实际代码里几乎没有正面价值。

2.2 底层阻塞原理：Condition和Lock是怎么配合的

搞懂阻塞队列的原理，最直接的方法是看ArrayBlockingQueue的源码。它的内部有几个关键字段：一个Object[]数组当存储容器，一个ReentrantLock，还有两个从锁上派生出来的Condition：notEmpty和notFull。

put(e)的流程大致是：

public void put(E e) throws InterruptedException { final ReentrantLock lock = this.lock; lock.lockInterruptibly(); try { while (count == items.length) notFull.await(); enqueue(e); } finally { lock.unlock(); } }

注意这个while循环，而不是if判断。为什么？因为线程被唤醒后，队列可能又被其他生产者塞满了，也就是说发生了“伪唤醒”或者竞争。所以必须用while重新检查条件，这也是Condition使用的标准姿势。take()的流程是对称的，队列为空时在notEmpty上等待，有元素被enqueue时通过notEmpty.signal()唤醒等待的消费者。

LinkBlockingQueue和ArrayBlockingQueue在这方面有个重要差异：ArrayBlockingQueue只有一把锁，所有操作串行化；LinkedBlockingQueue有两把锁，takeLock和putLock互相独立，所以一个生产者入队的同时，另一个消费者可以出队。这也是为什么很多场景下LinkedBlockingQueue的吞吐量要好于ArrayBlockingQueue，但代价是它默认是无界的，容易OOM。

这和数据库里的读写锁设计是一个思路。锁的粒度越细，并发度越高，但实现的复杂度也越高。LinkedBlockingQueue通过两把锁把“队头操作”和“队尾操作”解耦，前提是链表结构天然支持头尾分离。ArrayBlockingQueue的循环数组，入队出队都要维护同一个count变量，用一把锁反而更简单可靠。理解了这层设计，你就不难明白为什么JDK里会有这么多“看起来功能重复”的队列了。

2.3 有界无界怎么选，容量设置多少才合理

无界队列最大的风险是内存溢出。LinkedBlockingQueue默认构造时，容量是Integer.MAX_VALUE，等于没设上限。你用Executors.newFixedThreadPool()时，它内部就是这么干的。如果生产速度长期大于消费速度，任务会在队列里无限堆积，最终堆内存被打爆，JVM直接OOM。这个问题太经典了，几乎每个面试官都会问。

那有界队列的容量怎么定？我给你一个可以落地参考的公式思路：平均每秒任务量 乘以 单个任务平均处理耗时（秒），得到稳态下的积压量；再乘以你愿意承受的缓冲倍数，就是容量。举例来说，系统每秒产生1000个任务，每个任务平均处理100毫秒，那么稳态下处理中的任务大约是100个。如果你希望即使在短暂流量尖峰下也能容忍3倍积压，那容量设在300到500比较合理。如果容量太大，流控形同虚设；太小，则可能频繁触发拒绝策略，导致任务大量失败。

另外一个容易被忽略的点是，有界队列不仅要设容量，还要配合合理的拒绝策略。如果队列满了，任务怎么办？四种策略各有各的坑。AbortPolicy直接抛RejectedExecutionException，适合对失败敏感的业务；CallerRunsPolicy让提交任务的线程自己执行，实际上是反向背压，适合不想丢任务的场景；DiscardPolicy和DiscardOldestPolicy都是静默丢弃，适合能容忍少量数据丢失的日志、埋点类任务。我在生产环境最常用的是CallerRunsPolicy，因为线上重要任务不能随便丢，让调用方线程去执行反而是最稳妥的兜底。

3. 线程池里的阻塞队列怎么配：最常被问也最容易出事的点

3.1 为什么newFixedThreadPool会堆积到OOM

你先看一段常见的反面教材：

ExecutorService executor = Executors.newFixedThreadPool(10);

这行代码看着人畜无害，但它内部创建的ThreadPoolExecutor，队列用的是无界LinkedBlockingQueue，容量是Integer.MAX_VALUE。这意味着无论核心线程是否空闲，新任务都会先塞进队列，只有当队列满了之后才会创建非核心线程。而队列永远不可能满，所以线程池里的线程数永远只有10个。如果这10个线程处理不过来，任务就无限排队，最终内存耗尽。

网上很多文章把它归因于“Executors不靠谱”，其实更准确地说，是默认的无界队列设计放大了风险。你把队列换成有界的，问题就解决了一大半。Executors里几个工厂方法的默认队列配置，我列出来你感受一下：

CachedThreadPool的问题和固定线程池正好相反。它用SynchronousQueue，不缓存任何任务，每个任务都必须立刻有一个空闲线程来接走。一旦没有空闲线程，就创建新线程。如果任务提交速率持续很高，线程数会一直涨，直到把内存和文件描述符耗尽。面试八股文里常说的“Executors四大坑”，基本都离不开队列和线程数的匹配问题。

所以生产环境我强烈建议直接使用ThreadPoolExecutor，手动指定核心线程数、最大线程数、工作队列、拒绝策略和线程工厂。这样每个参数都是自己深思熟虑过的，不会因为框架默认值踩坑。

3.2 生产环境线程池队列的几种配置参考

线程池的队列怎么选，前提是想清楚你的任务特性是什么。

先说IO密集型任务，比如网络请求、文件读写、数据库操作。这类任务大部分时间在等待IO，CPU利用率不高，所以可以适度调大线程数，避免线程太少导致队列积压。队列我一般选有界LinkedBlockingQueue，容量在几百到几千之间，具体按前面的公式估算。线程数公式很多人背过：IO密集型线程数 = CPU核数 * 2，或者用CPU核数 / (1 - 阻塞系数)，实际操作时还会加上压测调整的空间。参考配置：

ThreadPoolExecutor pool = new ThreadPoolExecutor( 16, 32, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000), new ThreadFactoryBuilder().setNameFormat("io-worker-%d").get(), new ThreadPoolExecutor.CallerRunsPolicy() );

这段代码里我把核心线程设为16，最大线程32，队列容量1000。当任务量超过“16个线程处理不过来”时，新任务先进入队列排队，队列填满1000个后再扩容到最多32个线程。如果32个线程加1000个排队的任务都扛不住，就触发CallerRunsPolicy让提交线程自己执行，实现自然的背压。这个思路保证系统在极端流量下不会被击穿，最多是提交任务的线程卡顿一些。

再有一种场景是CPU密集型任务，比如图片处理、加解密、数值计算。这类任务几乎不等待，线程数超过CPU核数反而会因为线程切换增大开销。线程数我一般设在CPU核数加1左右，队列也用小容量，比如100到200，让任务尽快进入执行而不是排队。因为排队对CPU密集型任务没有意义，反而增加了调度延迟。

SynchronousQueue在什么场景下用？如果你希望任务提交后立刻交给一个工作线程执行，不允许排队，那么SynchronousQueue是唯一选择。它不存储元素，put()必须等take()，take()必须等put()，两边同时准备好才能完成交接，中间不存在缓冲。CachedThreadPool就是基于这个设计来的，但你需要自己控制最大线程数，避免无限创建线程。参考配置：

ThreadPoolExecutor pool = new ThreadPoolExecutor( 0, 200, 60L, TimeUnit.SECONDS, new SynchronousQueue<>(), new ThreadPoolExecutor.AbortPolicy() );

这里的思路是，核心线程为0，意味着任务到来时优先创建新线程并尝试放入SynchronousQueue。一旦有空闲线程，它会在队列上等待并立刻接走任务；没有空闲线程，就新建线程直到达到200上限。注意配合AbortPolicy，因为SynchronousQueue永远“满”，如果线程数也到上限，再提交任务必然会触发拒绝策略，你需要在catch里做好兜底。

3.3 线程池任务提交顺序：核心线程、队列、最大线程

很多人以为线程池处理任务的顺序是“先核心线程，满了就扩容到最大，再满了走拒绝策略”，这个理解是错误的。ThreadPoolExecutor真正执行execute()时的逻辑是这样的：先判断当前工作线程数是否小于核心线程数，小于则创建新线程执行任务；否则尝试把任务放入队列；如果队列也满了，才判断当前线程数是否小于最大线程数，小于则创建新线程执行任务；否则走拒绝策略。

注意这个顺序：先试着进队列，队列满了才创建非核心线程。这就是为什么无界队列会让最大线程数形同虚设。很多人调优时把最大线程数设得很大，但队列是无界的，结果非核心线程一个都没创建过，等于白设。理解了执行顺序，你就能明白为什么核心线程数、最大线程数、队列容量三者必须联动设计，单独调某一个参数往往没有效果。

这里还藏着一个参数坑：allowCoreThreadTimeOut。默认情况下核心线程即使空闲，也会一直活着不被回收。如果你希望线程池在空闲一段时间后收缩到0个线程，可以设置allowCoreThreadTimeOut(true)，搭配keepAliveTime使用。这对按需创建、用完回收的CachedThreadPool风格线程池很重要，否则即使没有任务，核心线程也会占用系统资源。

4. 不同业务场景下的队列实战选择

4.1 生产者-消费者：日志异步写、请求削峰怎么做

生产消费者模型是阻塞队列最经典的落地场景。我给你拆一个日志异步写的例子。假设你的业务系统每秒钟产生大量操作日志，如果每条都同步写数据库或文件，主流程会被IO拖慢。常规做法是引入一个阻塞队列，业务线程只负责把日志对象offer到队列里，后台一个或几个消费者线程take出来批量写入。

我用ArrayBlockingQueue还是LinkedBlockingQueue？这是个好问题。如果日志写入频率比较均衡，队列长度固定，ArrayBlockingQueue足够了，因为它的内存占用更小，数组是预分配的，没有链表节点的离散开销。而且ArrayBlockingQueue支持公平锁模式，构造时传入true，能避免某些生产者线程长期等待。缺点是单锁设计，并发入队出队会互相竞争。

LinkedBlockingQueue在“同时入队+同时出队”的场景下吞吐量略高一筹，因为两把锁分离。如果你的消费者有多个，且队列经常同时有生产者和消费者操作，LinkedBlockingQueue体验更好。但它默认无界，一定要记得在构造时传入容量，比如new LinkedBlockingQueue<>(5000)，否则就是给自己埋雷。

请求削峰的逻辑也类似。网关层接收到突发请求，先把请求封装成任务对象塞进有界队列，后端worker按自己的处理能力消费。队列在这里充当了缓冲池的角色，消费者按恒定速率消费，相当于把突刺流量“熨平”了。这类场景我特别建议用带超时的offer()，不要用put()。原因很简单：队列满时，put()会让请求线程无限期阻塞，此时如果后端已经过载，阻塞只会让故障传导到更多线程。而offer(e, 1, TimeUnit.SECONDS)超时返回false后，可以直接返回“系统繁忙，请稍后重试”，把压力挡在入口，起到熔断的效果。

4.2 爬虫并发设计：任务队列怎么选才既高效又不被反爬

很多人做爬虫，上来就开几十个线程去抓页面，结果要么被封IP，要么内存暴涨。热搜里“爬虫并发设计到底哪个好”这个问题，本质上就是线程池和队列的选型问题。我的建议是：用有界阻塞队列做任务池，用固定线程池消费，队列容量按目标网站的抓取频率限制来设定。

举一个实际例子。假设你要抓取一个商品列表页，每页返回100条数据，详情页需要单独请求。你可以设计一个两级队列：第一级队列存放待抓取的商品ID列表，第二级队列存放待解析的HTML源码或JSON数据。因为详情页请求比较耗时，第一级队列的消费速率决定了整体抓取效率；而第二级队列的消费速率决定了解析入库的效率。它们之间的缓冲容量，起到解耦作用，某个环节慢了不至于直接拖垮另一个环节。

队列容量怎么设？关键看目标网站允许的请求频率。如果网站要求每秒最多10个请求，那么你开10个线程，每个请求耗时1秒，队列容量设为50到100就够了。为什么不能设太大？因为一旦其中一个页面异常导致消费者卡住（比如网络连接超时设置过长），队列里的任务会迅速堆积，占用的内存可能非常可观。爬虫任务里每个URL或HTML都可能达到几百KB，几千个任务堆积就是上百MB内存。

还有一个细节：爬虫任务里最好不要用无界队列，也不要让队列过深。因为爬虫任务的失败率比普通业务高很多，如果消费者线程因反爬被限制而停止消费，无界队列会在很短时间内把内存吃满。我用爬虫线程池时，队列通常设成100到200，拒绝策略用CallerRunsPolicy，这样当队列满时，提交任务的主线程会自己执行抓取，天然放慢了整体抓取速度，等价于一种简单的限流。实测下来，这比直接丢弃任务或者抛异常要优雅得多。

4.3 延迟任务与优先级任务：DelayQueue和PriorityBlockingQueue

说到DelayQueue，我第一个想到的是订单超时自动关闭。一个订单创建后，如果30分钟内未支付，系统要自动将其置为关闭状态。用户可能创建大量订单，总不能每分钟全表扫一遍。DelayQueue就是为此设计的，它内部封装了一个PriorityQueue，元素按照“剩余延迟时间”排序，只有当一个元素的delay时间到了之后，take()才能取到它。

这里有一点必须注意：DelayQueue里存放的元素必须实现Delayed接口，这个接口有两个方法，getDelay(TimeUnit unit)返回剩余延迟时间，compareTo(Delayed o)定义排序规则。我写一个简单示例，你就明白用法了。

public class OrderDelayTask implements Delayed { private final String orderId; private final long triggerTime; // 毫秒时间戳 public OrderDelayTask(String orderId, long delayMs) { this.orderId = orderId; this.triggerTime = System.currentTimeMillis() + delayMs; } @Override public long getDelay(TimeUnit unit) { return unit.convert(triggerTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS); } @Override public int compareTo(Delayed o) { return Long.compare(this.triggerTime, ((OrderDelayTask) o).triggerTime); } public String getOrderId() { return orderId; } }

使用方式很简单：一个后台单线程不断执行taskQueue.take()，取到就处理，取不到就阻塞在那里。每来一个新订单，就offer一个延迟30分钟的OrderDelayTask进去。这样你就用很少的代码实现了一个可靠的延迟任务调度器，不需要引入额外的中间件。

但要注意两点：第一，DelayQueue是无界的，如果任务大量堆积，同样有OOM风险，使用时要限制任务总量或者配合定时清理；第二，如果服务重启，内存里的延迟任务会全部丢失，所以它只适合做单机轻量级延迟任务，真正需要持久化和分布式能力时，还是得靠RocketMQ延迟消息或者Redis ZSet这类方案。

PriorityBlockingQueue则是PriorityQueue的线程安全版本。它内部的堆是按优先级排序的，每次take()都会取出优先级最高的元素。注意它的比较器是构造时传入的，如果不传，就要求元素实现Comparable接口。它有个特点是无界队列，虽然不会因为“满了”而阻塞生产者，但同样可能因持续入队导致OOM。另外它的遍历顺序和出队顺序也不一致，从队列里poll()出来的是有序的，但直接迭代队列看到的是乱序的。这属于二叉堆的数据结构特性，不算bug，但面试时经常被拿出来当陷阱题。

5. 常见问题与排查技巧实录

5.1 队列任务堆积不消费，先看这四件事

线上如果发现消息积压或者线程池任务排队越来越多，按照这个顺序排查，通常能快速定位问题。

第一，确认消费者线程是否都活着。用jstack抓一下线程栈，看看消费者线程是处于WAITING状态（正常阻塞等待任务），还是BLOCKED状态（死锁或锁竞争），又或者是RUNNABLE状态但卡在某个IO调用上。如果是第三种，大概率是下游接口响应变慢，导致消费者吞吐量暴跌。

第二，确认队列是有界还是无界。如果是无界，检查当前堆内存使用率以及队列深度的监控指标。很多框架都暴露了队列大小的JMX指标，比如ThreadPoolExecutor可以通过getQueue().size()拿到实时值。队列持续增长，说明生产速度长期大于消费速度，要么扩容消费者，要么限流生产者。

第三，确认拒绝策略是否生效。有界队列打满后，拒绝策略如果设置不当，任务会在你完全没有感知的情况下被丢弃。我建议生产环境至少把拒绝次数做成一个监控指标，比如在拒绝策略里加一个AtomicLong计数器或者日志埋点，方便在告警平台上看到丢弃量。

第四，确认单个任务是否存在异常死循环或者无限重试。有一种隐蔽的情况：某个任务处理时抛出异常，而你在catch里没有正确结束任务，导致它被重新提交到队列头部，形成一个永不结束的循环，其他任务永远没有机会执行。这种问题通常不会让线程池挂掉，但会让系统“假死”。排查办法是看日志里同一个任务ID是否反复出现，或者在任务里加执行次数的最大限制。

5.2 我踩过的坑和面试高频题速查

先说坑。第一个坑是SynchronousQueue配错线程数导致死等。我有一次写生产者消费者程序，生产者用put()往SynchronousQueue里放数据，消费者只有一个线程，但生产速率远远大于消费速率，结果生产者线程全部阻塞在put()上，UI卡死。后来才意识到SynchronousQueue没有任何缓冲能力，生产者必须和消费者“手递手”交接，线程数不匹配时，要么生产者等，要么消费者等。用它之前，一定要想清楚你的生产消费速率是否匹配。

第二个坑是poll()空转导致CPU飙高。有人想让消费者不阻塞，就用while(true) + poll()去拿任务，队列为空时poll()立刻返回null，于是循环就变成了一次高性能空转，一个线程就能占满一个CPU核心。用阻塞队列的意义就在于让线程在无任务时挂起，而不是空转。如果你真的需要非阻塞轮询，至少要在拿不到任务时Thread.sleep一小段时间，或者直接用take()。

第三个坑是DelayQueue内存泄漏。延迟任务如果长期不触发，会一直留在堆里。比如你放了一万个30分钟后执行的延迟任务，但服务在10分钟后重启，这些任务全部丢失，重启后不会有任何补偿机制。就算不重启，大量长期延迟的任务也会占据内存。因此延迟任务一定要有总量上限和持久化补偿方案，不能用完就忘。

至于面试高频题，整理几个我常被问到的，顺便把回答要点给你：

• ArrayBlockingQueue和LinkedBlockingQueue的区别？一个是数组有界单锁，一个是链表默认无界双锁。LinkedBlockingQueue并发度更高，但要注意默认无界的隐患。
• SynchronousQueue有什么特点？没有容量，put和take必须同时准备好才能完成交接，一般配CachedThreadPool或需要直接转交的场景。
• 阻塞队列哪些方法会阻塞？put和take会无限期阻塞，offer(e, timeout, unit)和poll(timeout, unit)会超时返回，add和offer(e)不会阻塞只会立刻失败。
• DelayQueue怎么实现的？内部用PriorityQueue按延迟时间排序，take时通过Condition等待队首元素到期，所以注意元素需要实现Delayed接口的getDelay和compareTo。
• ConcurrentLinkedQueue和LinkedBlockingQueue怎么选？前者是无锁非阻塞的，适合对实时性要求高、任务量可控的场景；后者有阻塞语义，适合做生产者消费者缓冲队列。前者没有阻塞等待的能力，后者可以挂起线程节省CPU。

这些题目看起来是八股文，但如果你能把每个队列的底层结构和设计意图讲清楚，面试官基本不会再深挖。真正拉开差距的，是你是否能结合项目里的实际场景说清楚“我为什么选这个队列”。

我在实际项目中的习惯是：先画出生产者和消费者的速率模型，再决定用有界还是无界，用单锁还是双锁，最后把拒绝策略和监控指标一起加上。队列选型没有银弹，真正重要的不是你用了哪个队列，而是你有没有想清楚每一个关键参数背后的代价。把LinkedBlockingQueue默认无界这件事刻在脑子里，把put()有可能永久阻塞这件事刻在脑子里，线上会少很多事故。