arrayblockingqueue强制指定固定容量，put满即阻塞，提供确定性背压；linkedblockingqueue默认无界（integer.max_value），易致oom，需显式设界并配拒绝策略，且双锁机制并发性能更优。
ArrayBlockingQueue 和 LinkedBlockingQueue 在处理变量（任务或数据）积压时，核心差异不在“有界 vs 无界”本身，而在于**容量是否可控、阻塞时机是否明确、以及失控风险是否可防**。默认无界 ≠ 真正无界，关键看你怎么用。
容量边界决定积压是否可控
ArrayBlockingQueue 必须指定固定容量，一旦满，put 操作立刻阻塞生产者，强制上游减速或降级。这是天然的背压机制，能防止内存持续膨胀。
- 适合场景：任务耗时稳定、下游处理能力可预估（如订单入库、日志缓冲）
- 风险点：容量设太小 → 频繁阻塞，吞吐受限；设太大 → 延迟升高，但至少不会 OOM
LinkedBlockingQueue 的“无界”是危险的默认值
不传容量时，默认使用 Integer.MAX_VALUE（≈21亿），表面看不会满，实际等于放弃容量管控。只要生产速度 > 消费速度，队列就不断增长，最终耗尽堆内存。
- 常见误用：new LinkedBlockingQueue() 直接用于线程池，没配拒绝策略 → GC 频繁、Full GC、OOM
- 正确做法：显式传入合理容量，例如 new LinkedBlockingQueue(1024)，让它变成有界队列
积压行为差异不止在容量，还在响应方式
两者都支持 put/take 阻塞，但面对积压时的线程行为不同：
- ArrayBlockingQueue：单锁机制，生产者和消费者竞争同一把锁 → 积压严重时，锁争用加剧，吞吐下降更明显
- LinkedBlockingQueue：双锁分离（putLock + takeLock）→ 即使队列已满，消费者仍可并发取数；即使为空，生产者也能并发准备入队 → 更平稳扛住短时脉冲积压
选型建议：按积压风险等级来定
如果系统对延迟敏感、资源有限、或无法承受突发流量冲击，优先选 ArrayBlockingQueue —— 它用确定性阻塞换稳定性。如果需要更高并发吞吐，且能严格控制容量（绝不裸用无参构造）、配合拒绝策略（如 CallerRunsPolicy），再考虑带界的 LinkedBlockingQueue。
