BlockingQueue选型需先明确线程安全需求，再权衡吞吐与响应：ArrayBlockingQueue适合固定容量场景，LinkedBlockingQueue默认无界需警惕OOM，SynchronousQueue适用于零缓冲直连，PriorityBlockingQueue支持优先级但非严格FIFO。
BlockingQueue 选型关键：先看线程安全需求，再比吞吐和响应
Java 里 BlockingQueue 不是“拿来就能用”的通用容器，它本质是为**多线程协作场景**设计的——比如生产者往里塞数据、消费者从里取数据，中间需要自动阻塞、唤醒、容量控制。如果你只是单线程用、或者自己加锁管理队列，用 ArrayList 或 LinkedList 更轻量。
选错实现类，轻则吞吐上不去，重则死锁或丢数据。核心差异不在“能不能放”，而在“怎么等”“怎么醒”“怎么控”。
-
ArrayBlockingQueue：固定大小、基于数组、公平锁可选；适合对内存占用敏感、容量明确的场景（比如日志缓冲区上限 1024 条） -
LinkedBlockingQueue：默认无界（实际是Integer.MAX_VALUE），但构造时传capacity就变有界；链表结构，入队出队开销略高，但扩容无压力 -
PriorityBlockingQueue：无界、支持优先级排序；注意它不保证完全 FIFO，且take()仍会阻塞，但取出来的是堆顶元素 -
SynchronousQueue：没有内部容量，每个put()必须配一个take()才能返回；适合纯中转、零缓冲的直连场景（如线程池的直接交接）
put() 和 offer() 的区别，直接决定你的线程会不会卡死
这是最常踩的坑：put() 是阻塞式，队列满时线程挂起直到有空间；offer() 是非阻塞式，满了立刻返回 false，不等。
如果在定时任务或响应敏感的接口里用了 put()，而下游消费慢，上游线程就会被卡住，可能拖垮整个线程池。
立即学习“Java免费学习笔记（深入）”；
- 用
put()：确定能接受等待，且下游稳定（如后台批处理） - 用
offer(E e, long timeout, TimeUnit unit)：想设超时，避免无限等待（比如最多等 100ms，超时就丢弃或告警） - 别用无参
offer()就以为“不会失败”——它失败时静默返回false，不抛异常，容易漏判
poll() 返回 null？不是空队列，很可能是你没处理好中断
poll() 在队列为空时返回 null，这没错；但如果你在 while (!Thread.interrupted()) 循环里调它，又没检查中断状态，就可能陷入忙等或忽略 shutdown 信号。
更危险的是 take()：它会阻塞，但如果当前线程被 interrupt()，会立即抛出 InterruptedException 并清中断状态——很多代码只 catch 了却不重设中断标志，导致后续逻辑收不到退出信号。
- 用
poll()时，必须判断返回值是否为null，不能假设“有就处理、没就跳过” - 用
take()时，catchInterruptedException后建议立刻Thread.currentThread().interrupt() -
drainTo(Collection)虽快，但只移出当前所有元素，不阻塞；若需“取一批或等”，得自己封装逻辑
和线程池搭配时，SynchronousQueue 和 LinkedBlockingQueue 的隐含成本
很多人以为 Executors.newFixedThreadPool(n) 用的是 LinkedBlockingQueue 就很稳，其实它的默认构造是无界的——意味着只要任务提交够快，内存会持续增长，OOM 风险真实存在。
而 Executors.newCachedThreadPool() 用的是 SynchronousQueue，看似高效，实则每次提交任务都依赖有空闲线程来“接招”，否则就新建线程；大量突发任务下，线程数可能飙到上千，GC 压力陡增。
- 固定线程池 + 有界队列：显式指定
new ArrayBlockingQueue(100)，配合拒绝策略（如AbortPolicy或自定义） - 缓存线程池：慎用，尤其 IO 密集型任务；不如用
new ThreadPoolExecutor(…)自控核心/最大线程数和队列类型 - 别依赖
Executors工具类默认配置——它们为“快速上手”设计，不是为生产稳定性
真正难的不是选哪个类，而是想清楚：你到底要容忍多少延迟、允许多少内存占用、能否接受任务丢失、以及下游消费者是不是真的能跟上节奏。这些没理清，换十个队列也白搭。
