wait/notify 必须在 synchronized 块中调用，否则抛 illegalmonitorstateexception；推荐用 while 而非 if 防虚假唤醒；condition 提供更清晰的等待队列；blockingqueue 是生产者-消费者首选；volatile 不能替代同步机制。
wait/notify 必须在 synchronized 块中调用
直接调用 wait() 或 notify() 会抛出 IllegalMonitorStateException，因为 JVM 要求当前线程必须持有对象的监视器锁。这不是可选约定，是强制语义。
- 必须用
synchronized(obj) { obj.wait(); }，不能只写obj.wait(); - 唤醒方也必须同步访问同一对象：
synchronized(obj) { obj.notify(); } - 推荐使用
while而非if检查条件，避免虚假唤醒（spurious wakeup）
public class Buffer {
private String data;
private boolean available = false;
public void put(String value) throws InterruptedException {
synchronized (this) {
while (available) { // 不用 if！
this.wait();
}
data = value;
available = true;
this.notifyAll(); // 用 notifyAll 更安全
}
}
public String take() throws InterruptedException {
synchronized (this) {
while (!available) {
this.wait();
}
available = false;
String result = data;
data = null;
this.notifyAll();
return result;
}
}
}
Condition 替代 wait/notify 实现更清晰的等待队列
ReentrantLock 配合 Condition 可以摆脱 synchronized 的单一隐式锁限制，支持多个独立等待队列，逻辑更可控，也避免了 notify() 随机唤醒的问题。
- 每个
Condition实例绑定一个特定等待条件（如“缓冲区非空”“缓冲区非满”） -
await()和signal()不再依赖对象锁的隐式语义，出错时异常信息更明确 - 必须在
lock()后调用await()，且需在finally中unlock()
public class BoundedBuffer {
private final Lock lock = new ReentrantLock();
private final Condition notFull = lock.newCondition();
private final Condition notEmpty = lock.newCondition();
private final String[] buffer = new String[10];
private int putIndex = 0, takeIndex = 0, count = 0;
public void put(String item) throws InterruptedException {
lock.lock();
try {
while (count == buffer.length) {
notFull.await();
}
buffer[putIndex] = item;
putIndex = (putIndex + 1) % buffer.length;
++count;
notEmpty.signal(); // 精准唤醒消费者
} finally {
lock.unlock();
}
}
public String take() throws InterruptedException {
lock.lock();
try {
while (count == 0) {
notEmpty.await();
}
String item = buffer[takeIndex];
takeIndex = (takeIndex + 1) % buffer.length;
--count;
notFull.signal();
return item;
} finally {
lock.unlock();
}
}
}
BlockingQueue 是生产者-消费者场景的首选封装
绝大多数线程协作问题本质是生产者-消费者模型。手写 wait/notify 或 Condition 容易出错，而 BlockingQueue 已经封装好线程安全、阻塞语义和容量控制，开箱即用。
-
ArrayBlockingQueue（有界，基于数组，性能稳定）和LinkedBlockingQueue（可选界，基于链表，吞吐略高）最常用 -
put()和take()方法自动处理阻塞与唤醒，无需手动同步 - 注意：不要在循环中反复调用
poll()+Thread.sleep()来模拟阻塞——这是反模式，浪费 CPU 且延迟不可控
BlockingQueue<String> queue = new ArrayBlockingQueue<>(10);
// 生产者线程
new Thread(() -> {
try {
for (int i = 0; i < 100; i++) {
queue.put("item-" + i); // 自动阻塞
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}).start();
// 消费者线程
new Thread(() -> {
try {
while (true) {
String item = queue.take(); // 自动阻塞
System.out.println("Consumed: " + item);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}).start();
volatile 无法替代同步机制完成线程间通信
volatile 只能保证变量读写的可见性与禁止重排序，**不提供原子性，也不构成 happens-before 关系来保障复合操作的正确性**。试图用它实现协作逻辑，几乎必然出错。
立即学习“Java免费学习笔记（深入）”；
- 比如用
volatile boolean ready = false控制线程启动顺序，再配合while(!ready) Thread.yield();—— 这不是协作，是忙等，且仍可能因指令重排导致未初始化数据被读取 -
volatile适合状态标志（如关闭信号），但绝不能用于“等待某条件成立后执行下一步”的通信逻辑 - 真正需要通信时，必须用
wait/notify、Condition、BlockingQueue、CountDownLatch或CyclicBarrier等明确建模同步语义的工具
线程协作的本质不是“让一个线程看到另一个线程改了什么”，而是“让一个线程在某个条件满足前暂停，并在条件满足时被可靠唤醒”。这个“暂停-唤醒”闭环，volatile 根本不参与。
