LinkedBlockingQueue 应设为有界队列以避免OOM和GC压力，配合固定大小线程池提升吞吐，优先使用带超时的poll()/offer()而非永久阻塞的take()/put()，并理解其双锁机制而非无锁假象。
LinkedBlockingQueue 是 Java 并发包中一个线程安全的、基于链表实现的阻塞队列，它在生产者-消费者模型中能显著提升吞吐量——关键不在于“用不用”，而在于“怎么用对”。合理利用其容量控制、无锁入队/出队（部分场景）、以及与线程池协同机制，才能真正释放性能。
用有界队列避免内存失控，同时保持高响应
默认构造的 LinkedBlockingQueue 是无界（Integer.MAX_VALUE），看似“永不阻塞”，实则埋下 OOM 隐患，且 GC 压力陡增，反而拖慢整体吞吐。应显式指定合理容量：
- 根据业务峰值 QPS、单任务平均处理时长、可接受的最大排队延迟，反推队列大小（例如：1000 QPS × 200ms = 约 200 个待处理任务）
- 设为有界后，当队列满时，生产者会阻塞或快速失败（用 offer(e, timeout, unit)），这迫使系统暴露瓶颈，而非掩盖问题
- 相比无界队列，有界设置让线程调度更可预测，减少因过度堆积导致的上下文切换和缓存失效
配合固定大小线程池，消除动态扩容开销
LinkedBlockingQueue 常作为 ThreadPoolExecutor 的工作队列。若搭配 newCachedThreadPool（无界队列 + 无限线程），线程频繁创建销毁会严重损耗 CPU。推荐组合：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 核心线程数 = CPU 核心数（CPU 密集型）或 2×CPU 核心数（I/O 密集型）
- 最大线程数 = 核心线程数（即不扩容），所有任务都进队列等待
- 使用 LinkedBlockingQueue 作为 workQueue，容量设为适度有界值（如 1024 或 2048）
- 这样线程数稳定，避免线程生命周期开销；队列承担缓冲职责，吞吐由消费端稳定消化能力决定
优先使用 poll() / offer() 而非 take() / put()，减少不必要的阻塞
take() 和 put() 是无超时的永久阻塞操作，在高负载或异常场景下易导致线程长时间挂起，降低资源利用率。实际业务中更推荐：
立即学习“Java免费学习笔记（深入）”；
- 消费者用 poll(10, TimeUnit.MILLISECONDS)，带短超时轮询，便于做空闲检测、优雅关闭或负载感知
- 生产者用 offer(e, 50, TimeUnit.MILLISECONDS)，避免因队列满而卡死，可降级（如写入本地缓冲、返回失败提示）
- 若必须强一致性，再考虑 take()/put()，但需配套监控队列水位和线程阻塞时间
注意锁粒度：头尾分离锁带来并发优势，但别误用“无锁”假象
LinkedBlockingQueue 内部用两个独立 ReentrantLock（takeLock 和 putLock），分别保护出队和入队操作，实现“读写分离式并发”。这意味着：
- 多个生产者可并发调用 offer()，互不阻塞（只要队列未满）
- 多个消费者可并发调用 poll()，互不阻塞（只要队列非空）
- 但同一时刻只有一个线程能执行 take()，也只有一个能执行 put() —— 它不是无锁队列，只是双锁优化
- 不要把它当成 ConcurrentLinkedQueue 使用：后者是真正的无锁、无界、弱一致性，适合低延迟场景；而 LinkedBlockingQueue 更适合可控吞吐+背压的场景
