为什么不用 wait/notify 直接写生产者消费者队列？
因为裸用 wait/notify 极易死锁或虚假唤醒，且无法保证线程安全的入队/出队原子性。比如没加 synchronized 块就调用 wait()，会抛 IllegalMonitorStateException；而只在 if 里判断队列空/满，不改用 while，就会漏掉唤醒后条件已失效的情况。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有共享状态（如队列、计数器）必须被同一把锁保护，推荐用
synchronized修饰方法或代码块，锁对象最好是队列本身（this或显式private final Object lock = new Object()） - 入队前必须
while (queue.size() >= capacity)循环等待，不能用if - 每次
notifyAll()而非notify()——避免唤醒错类型线程（比如只唤醒另一个生产者，消费者还在挂起） - 出队同理：用
while (queue.isEmpty())+wait()+notifyAll()
BlockingQueue 的 put()/take() 已经封装好了，为什么还要手写？
手写不是为了替代，而是为了理解阻塞语义怎么落地。比如 ArrayBlockingQueue 内部正是基于 ReentrantLock + Condition 实现的，比原始 wait/notify 更精细（可分离“非空”和“非满”两个等待队列）。但如果你只是临时需要一个无依赖、轻量、可控的内存队列（比如单元测试模拟 MQ 行为），手写反而是最省事的。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别自己造轮子去支持超时、中断、公平策略——这些交给
java.util.concurrent就行 - 若仅需 FIFO + 固定容量，用
new ArrayBlockingQueue(1024)是最稳选择；手写只适合学习或极简嵌入场景 - 注意：手写版无法像
LinkedBlockingQueue那样动态扩容，容量写死就得提前评估峰值吞吐
一个能跑通的最小内存队列示例长什么样？
下面这个类去掉日志和注释，实际不到 30 行，但覆盖了核心逻辑：线程安全、阻塞、容量控制、异常防护。
public class SimpleMemoryMQ<T> {
private final Queue<T> queue;
private final int capacity;
public SimpleMemoryMQ(int capacity) {
this.queue = new LinkedList<>();
this.capacity = capacity;
}
public void put(T item) throws InterruptedException {
synchronized (queue) {
while (queue.size() == capacity) {
queue.wait(); // 等待有空位
}
queue.offer(item);
queue.notifyAll(); // 唤醒可能等待取数据的消费者
}
}
public T take() throws InterruptedException {
synchronized (queue) {
while (queue.isEmpty()) {
queue.wait(); // 等待有数据
}
T item = queue.poll();
queue.notifyAll(); // 唤醒可能等待入队的生产者
return item;
}
}
}
注意点：
-
queue是锁对象，不是this——避免外部同步干扰内部逻辑 - 没做 null 检查，实际使用中
put(null)会导致后续take()返回 null，容易引发 NPE，建议加Objects.requireNonNull(item) - 没处理中断，真实场景应检查
Thread.interrupted()并抛InterruptedException
上线前最容易被忽略的三个细节
不是语法错，而是运行时才暴露的问题：
- 忘记在
catch (InterruptedException e)后恢复中断状态：Thread.currentThread().interrupt()——否则上层无法感知中断意图 - 用
ArrayList替代LinkedList当底层容器：虽然都实现Queue，但ArrayList.remove(0)是 O(n)，消费性能断崖下跌 - 多线程反复
put/take时没压测边界：比如容量为 1 的队列，在高并发下notifyAll()唤醒大量线程争抢锁，CPU 利用率飙升但吞吐反而下降——这时该换LockSupport或直接上Disruptor
真要长期用，别卡在 wait/notify 这一层；但第一次写清楚它怎么动起来，是绕不开的一步。
