Java多线程通信应使用wait()/notify()或Lock+Condition配合共享状态，而非while(true)+sleep；因后者浪费CPU、响应延迟高、易错过唤醒，且无法精准定向通知。
Java 多线程中实现线程通信，核心不是靠“手动轮询”或“sleep 等待”，而是用 wait() / notify() 或更可靠的 Lock + Condition，配合共享状态（如队列）来协调生产与消费节奏。
为什么不能直接用 while(true) + sleep 模拟等待？
这种做法浪费 CPU、响应延迟高、无法精准唤醒——比如消费者刚睡着，生产者就塞进新数据，只能等下一轮醒来才发现，还可能错过唤醒信号。
真正有效的通信必须满足：等待时释放锁、被唤醒时重新竞争锁、唤醒动作能定向通知（而非广播惊群）。
-
wait()必须在synchronized块内调用，且会释放当前对象锁 -
notify()只唤醒一个等待线程，但不保证是消费者；notifyAll()更稳妥（尤其多个生产/消费者时） - 每次
wait()返回后，必须重新检查条件（用while而非if），防止虚假唤醒
用 synchronized + wait/notify 实现基础版
适用于简单场景，共享一个 ArrayList 或计数器，通过同一把锁（如 this 或队列对象）协调。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
public class SimplePC {
private final List<String> buffer = new ArrayList<>();
private final int capacity = 5;
public void produce(String item) throws InterruptedException {
synchronized (this) {
while (buffer.size() == capacity) {
this.wait(); // 满了就等
}
buffer.add(item);
System.out.println("Produced: " + item);
this.notifyAll(); // 通知所有等待者（包括可能的消费者）
}
}
public String consume() throws InterruptedException {
synchronized (this) {
while (buffer.isEmpty()) {
this.wait(); // 空了就等
}
String item = buffer.remove(0);
System.out.println("Consumed: " + item);
this.notifyAll(); // 通知生产者可以继续
return item;
}
}
}
⚠️ 注意：notifyAll() 是必须的；如果只用 notify()，在多消费者场景下可能唤醒另一个消费者，导致生产者永远没人通知。
用 ReentrantLock + Condition 实现更灵活控制
当需要区分“生产等待队列”和“消费等待队列”时（比如避免 notifyAll 唤醒错角色），Condition 是唯一选择。
- 一个
Lock可绑定多个Condition，例如notFull和notEmpty -
await()对应wait()，signal()对应notify()，signalAll()对应notifyAll() - 必须显式
lock().unlock()，推荐用try-finally保证释放
public class LockBasedPC {
private final Lock lock = new ReentrantLock();
private final Condition notEmpty = lock.newCondition();
private final Condition notFull = lock.newCondition();
private final List<String> buffer = new ArrayList<>();
private final int capacity = 5;
public void produce(String item) throws InterruptedException {
lock.lock();
try {
while (buffer.size() == capacity) {
notFull.await(); // 等待“不满”条件
}
buffer.add(item);
notEmpty.signal(); // 唤醒一个消费者
} finally {
lock.unlock();
}
}
public String consume() throws InterruptedException {
lock.lock();
try {
while (buffer.isEmpty()) {
notEmpty.await(); // 等待“非空”条件
}
String item = buffer.remove(0);
notFull.signal(); // 唤醒一个生产者
return item;
} finally {
lock.unlock();
}
}
}
实际项目中更推荐用 BlockingQueue
自己手写 wait/notify 容易出错（漏 notify、条件判断错、锁范围不对），JDK 提供的 ArrayBlockingQueue、LinkedBlockingQueue 已经封装好线程安全与阻塞逻辑。
-
queue.put(item)：满时自动阻塞，直到有空间 -
queue.take()：空时自动阻塞，直到有元素 - 内部使用
ReentrantLock+Condition，性能和可靠性都经过验证
绝大多数生产者-消费者场景，直接组合 ExecutorService + BlockingQueue 即可，无需手动管理 wait/notify。
真正容易被忽略的是：无论用哪种方式，**共享变量的可见性必须由同步机制保障**——没有锁或 volatile 修饰的 flag，另一线程永远看不到变化。这不是“逻辑问题”，是 JVM 内存模型决定的硬约束。
