慎用 LinkedBlockingQueue 作为线程池工作队列，因其默认无界（容量为 Integer.MAX_VALUE）易导致内存耗尽而非队列溢出；必须显式设限并配合适当拒绝策略；链表结构带来额外内存与缓存开销；双锁仅在纯生产和消费场景受益，中间操作反而更慢；size() 不可靠，应依赖拒绝次数等真实指标。
慎用 LinkedBlockingQueue 作为线程池工作队列，核心原因不是它“不能用”，而是它默认行为容易掩盖真实瓶颈，把问题从队列溢出悄悄转移到内存耗尽。
默认无界 → 实际是内存泄漏温床
它无参构造时容量为 Integer.MAX_VALUE（约 21 亿），表面“无限”，实则把背压完全交给堆内存。一旦生产者快于消费者（比如下游服务响应变慢、DB 负载升高），任务持续堆积，JVM 堆会缓慢但坚定地涨到 90%+，触发频繁 Full GC，最终 OOM。这不是理论风险——线上已有因未设限导致服务雪崩的案例。
- 必须显式指定容量，例如
new LinkedBlockingQueue(1000) - 容量值要结合 QPS、平均处理时长估算：比如每秒 200 个任务、单个耗时 50ms，理论缓冲需求约 10 个，设为 50～200 是常见安全余量
- 设了容量后，配合拒绝策略（如
AbortPolicy或自定义日志记录）才能暴露真实瓶颈
链表结构 → 内存与缓存双重开销
每个任务都包装成一个 Node 对象，含 item + next 引用。存 1 万个字符串，比 ArrayBlockingQueue 多占 2–3MB；存百万级任务时，额外对象开销显著，GC 压力陡增。
- Android 或容器等内存受限环境，这点差异足以影响稳定性
- 链表节点内存不连续，CPU 缓存预取失效，高并发遍历或监控调用
size()时性能反不如数组队列
双锁优势有前提 → 不是所有场景都受益
虽用 putLock 和 takeLock 分离，提升纯提交/执行吞吐，但一旦涉及中间操作，反而更慢：
立即学习“Java免费学习笔记（深入）”；
-
remove()、contains()、size()需同时获取两把锁，高并发下易成瓶颈 - 若业务代码中有任务取消、优先级调整、实时队列长度判断等逻辑，
ArrayBlockingQueue的单锁模型反而更可控、更可预测
监控不可靠 → 容易误判系统状态
size() 返回值在高并发下仅反映某一瞬时快照，且内部计数基于 AtomicInteger，不保证强一致性。用它做“队列是否过载”判断极易出错。
- 别写
if (queue.size() > threshold) {...}这类逻辑 - 真正可靠的指标是拒绝策略触发次数、线程池活跃线程数、任务平均等待时长（需埋点）
