ArrayBlockingQueue基于固定数组、有界且内存紧凑，LinkedBlockingQueue基于链表、可选有界、双锁并发吞吐高但GC压力大；选择依容量控制、吞吐需求及内存敏感度而定。
ArrayBlockingQueue 是基于数组的有界阻塞队列，LinkedBlockingQueue 是基于链表的可选有界（默认无界）阻塞队列。核心区别在于底层结构、容量约束、性能特征和内存使用方式。
底层数据结构与容量限制
ArrayBlockingQueue 内部用固定大小的 Object 数组存储元素，创建时必须指定容量，且不可更改。它始终是有界的。
- 初始化必须传入正整数 capacity，如
new ArrayBlockingQueue(10) - 插入满时调用
put()会阻塞，offer()返回 false - LinkedBlockingQueue 默认构造器创建的是 无界队列（最大容量为
Integer.MAX_VALUE），也可显式指定容量变为有界 - 有界模式下，它仍用 Node 链表实现，节点动态分配，不预占连续内存
线程安全与锁机制
两者都线程安全，但锁策略不同：
- ArrayBlockingQueu
e 使用单个
ReentrantLock（可选公平/非公平）保护整个队列，take 和 put 共享同一把锁 - LinkedBlockingQueue 使用两个独立的锁：
takeLock用于出队，putLock用于入队，读写操作可并发执行，吞吐量通常更高
内存占用与 GC 压力
ArrayBlockingQueue 在创建时就分配好全部数组空间，内存占用确定、紧凑；LinkedBlockingQueue 每次入队新建 Node 对象，元素多时对象数量多，GC 压力略大。
- 适合元素数量稳定、内存敏感场景：选 ArrayBlockingQueue
- 适合生产消费速率差异大、需高吞吐或不确定长度的场景：选 LinkedBlockingQueue（尤其有界时）
- 无界 LinkedBlockingQueue 在持续高速写入且消费滞后时，可能引发 OOM
常用场景建议
实际开发中可根据需求倾向选择：
- 需要强容量控制、避免内存无限增长（如任务调度池限流）→ ArrayBlockingQueue
- 追求更高并发吞吐，且能接受链表开销或可控容量 → LinkedBlockingQueue（推荐显式设 capacity）
- 日志收集、异步通知等对长度不敏感、希望写入不阻塞 → 可用无界 LinkedBlockingQueue，但务必配监控
不复杂但容易忽略：有界性不是“是否能扩容”，而是“是否在构造时锁定容量上限”；LinkedBlockingQueue 的“无界”只是逻辑上不限，实际仍受堆内存约束。
