new LinkedBlockingQueue() 线程安全因其内部使用 ReentrantLock 和两个 Condition（notEmpty、notFull）对所有关键操作加锁，无需额外同步；但迭代器弱一致，遍历时修改会抛 ConcurrentModificationException。
为什么直接 new LinkedBlockingQueue() 就线程安全？
LinkedBlockingQueue 内部使用了 ReentrantLock 和配套的 Condition 实现生产/消费端的互斥与等待唤醒，所有关键操作（put()、take()、offer()、poll()）都加锁保护。它不是靠 synchronized 方法块，而是显式锁 + 双条件变量（notEmpty 和 notFull），因此比 ArrayBlockingQueue 在高并发吞吐场景下通常更轻量。
不需要额外包装或同步——只要不暴露内部迭代器或调用 toArray() 后手动修改数组，就天然线程安全。
阻塞 vs 非阻塞方法怎么选？
根据下游处理逻辑是否允许“等”或“丢弃”来决定：
-
put(E e)：阻塞直到队列有空位，适合强一致性场景（如任务必须入队）；但若生产者远快于消费者且容量有限，可能长期挂起 -
take()：阻塞直到有元素，适合消费者不能空转的场景（如后台工作线程持续拉取任务） -
offer(E e)和poll()：立即返回true/false或元素/null，适合需快速失败、降级或带超时控制的逻辑 -
offer(E e, long timeout, TimeUnit unit)和poll(long timeout, TimeUnit unit)：折中方案，避免无限等待又不轻易丢弃
注意：offer(null) 会抛 NullPointerException，这是明确设计行为，不是 bug。
立即学习“Java免费学习笔记（深入）”；
容量设为 Integer.MAX_VALUE 有什么隐患？
默认构造函数 new LinkedBlockingQueue() 实际等价于 new LinkedBlockingQueue(Integer.MAX_VALUE)，看似“无界”，但仍是**有界链表**——节点对象本身占用堆内存，且 GC 压力随队列长度线性上升。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
常见问题：
- OOM 风险：生产者持续涌入、消费者卡顿 → 链表无限增长 →
java.lang.OutOfMemoryError: Java heap space - 虚假“无界”错觉：和真正的无界队列（如
ConcurrentLinkedQueue）不同，它仍受锁竞争影响，高并发下性能不如后者 - 监控困难：JVM 无法区分“正常积压”和“异常堆积”，需额外埋点统计
size()并告警
建议：显式指定合理容量（如 new LinkedBlockingQueue(1024)），配合拒绝策略（如自定义 RejectedExecutionHandler）控制背压。
和 ConcurrentLinkedQueue 的核心区别在哪？
两者都线程安全，但设计目标完全不同：
-
LinkedBlockingQueue：面向**阻塞协作**，提供put/take等阻塞语义，适合生产者-消费者模型中需要等待的场景（如线程池任务队列） -
ConcurrentLinkedQueue：纯非阻塞、无锁（CAS 实现），只提供offer/poll，不支持等待；适合高性能、低延迟、能容忍“立刻失败”的场景（如事件总线缓冲） - 性能差异：在无竞争或轻竞争下，
ConcurrentLinkedQueue吞吐更高；但一旦出现大量失败重试（如反复poll()返回null），实际吞吐可能反低于阻塞队列
别因为“Concurrent”前缀就默认它更适合所有并发场景——如果业务逻辑依赖阻塞等待，硬换 ConcurrentLinkedQueue 会导致忙等或逻辑重构成本陡增。
public class QueueUsageExample {
private final LinkedBlockingQueue<String> queue = new LinkedBlockingQueue<>(128);
public void produce(String item) throws InterruptedException {
// 拒绝策略：满时丢弃并记录
if (!queue.offer(item)) {
System.err.println("Dropped item: " + item);
}
}
public String consume() throws InterruptedException {
return queue.take(); // 保证一定能拿到，除非被中断
}
}
真正容易被忽略的是：即使用了 LinkedBlockingQueue，如果多个线程共用同一个 Iterator（比如调用 iterator() 后遍历），依然会抛 ConcurrentModificationException —— 它的迭代器是弱一致性的，不支持边遍历边修改，这点和文档里写的 “weakly consistent” 直接相关。
