应使用BlockingQueue而非手动加锁实现生产者消费者，因其封装了线程安全、阻塞逻辑与唤醒机制，避免漏唤醒、虚假唤醒和死锁；常用实现为ArrayBlockingQueue（有界、公平可选）和LinkedBlockingQueue（默认无界、高吞吐）。
为什么用 BlockingQueue 而不是自己加锁实现
自己用 synchronized + wait/notify 实现生产者消费者，容易漏唤醒、虚假唤醒或死锁；BlockingQueue 把这些细节全封装好了，线程安全、语义清晰、还能自动阻塞。它不是“能用”，而是“该用”——尤其当你要避免重复造轮子和调试竞态条件时。
关键点：BlockingQueue 是接口，实际得选一个具体实现，最常用的是 ArrayBlockingQueue（有界、基于数组、公平可选）和 LinkedBlockingQueue（默认无界、基于链表、吞吐高）。别直接 new 接口。
put() 和 take() 怎么配合实现真正的阻塞
这两个方法是核心：生产者调 put(e)，队列满时线程挂起；消费者调 take()，队列空时线程挂起。它们内部已处理了锁、条件变量和唤醒逻辑，你不需要手动同步。
-
put()是阻塞式插入，不返回布尔值，也不抛异常（除非中断），适合“必须塞进去”的场景 -
take()同理，阻塞取，取不到就等，适合“必须拿到一个”的消费逻辑 - 如果想带超时控制，改用
offer(e, timeout, unit)和poll(timeout, unit)，它们返回false或null表示失败，不会无限等
错误写法示例（常见坑）：if (!queue.offer(item)) { Thread.sleep(10); } —— 这不是阻塞队列的用法，是自造 busy-wait，浪费 CPU，还可能丢数据。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
如何避免生产者把消费者“撑爆”或“饿死”
本质是容量设计与线程协作节奏问题。比如用 LinkedBlockingQueue 且没传构造参数，默认容量是 Integer.MAX_VALUE，等于变相取消背压，生产者狂发，内存迟早 OOM；而 ArrayBlockingQueue 必须指定容量，天然强制限流。
- 有明确吞吐预期时，优先选
ArrayBlockingQueue，设合理容量（比如 1024），让生产者在满时自然等待，保护系统稳定性 - 若消费者处理极慢，且不能丢数据，不要靠增大队列撑着，应考虑降级策略（如拒绝新任务、记录告警、异步落盘）
- 注意：
size()在并发下只是快照值，不能用来做“if (q.size()
真实代码里怎么组织生产者和消费者线程
别用 Thread 原生裸写，用 ExecutorService 管理更稳妥。生产者和消费者都 submit Runnable，队列作为共享变量传入即可。
BlockingQueue<String> queue = new ArrayBlockingQueue<>(100);
ExecutorService pool = Executors.newFixedThreadPool(4);
// 生产者
pool.submit(() -> {
for (int i = 0; i < 1000; i++) {
try {
queue.put("msg-" + i); // 自动阻塞
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return;
}
}
});
// 消费者
pool.submit(() -> {
while (!Thread.currentThread().isInterrupted()) {
try {
String msg = queue.take(); // 自动阻塞
System.out.println("Consumed: " + msg);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
});
重点：所有对 BlockingQueue 的操作都必须响应 InterruptedException，否则中断信号会被吞掉，线程无法被优雅关闭。这点极易被忽略，尤其在日志打印或简单 demo 里。
