wait()和notify()必须在synchronized块中调用，且需用while循环而非if检查条件以应对虚假唤醒；多线程场景优先用notifyAll()；推荐使用Lock+Condition替代原生机制。

wait() 和 notify() 必须在 synchronized 块里调用

直接调用 wait() 或 notify() 会抛出 IllegalMonitorStateException，因为这两个方法依赖对象的内置锁（monitor）。JVM 要求当前线程必须已持有该对象的锁，才能操作其等待队列。

• 错误写法：obj.wait();（没加 synchronized）
• 正确写法：

  synchronized (obj) {
      obj.wait();
  }

• 注意：用哪个对象调用 wait()，就要对哪个对象加锁；notify() 同理
• 如果锁的是 this，但调用的是 otherObj.wait()，依然报错

为什么必须用 while 而不是 if 检查条件

虚假唤醒（spurious wakeup）是真实存在的——即使没人调用 notify()，wait() 也可能提前返回。只用 if 判断会导致线程在条件不满足时继续执行，引发逻辑错误。

• 典型场景：生产者-消费者中，消费者发现 queue.isEmpty() 为 true 后进入 wait；被唤醒后必须重新检查是否真有元素可取
• 正确模式：

  synchronized (lock) {
      while (!conditionMet()) {
          lock.wait();
      }
      // 安全执行后续操作
  }

• Java 文档明确建议使用 while 循环，而非 if

notify() 和 notifyAll() 的选择直接影响线程安全性

单个等待线程时，notify() 足够；但多数实际场景（如多个消费者等待同一队列）中，用 notify() 极易导致死锁或饥饿。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• notify() 只唤醒一个随机等待线程，若它发现条件仍不满足又回到 wait，其他线程可能永远等不到通知
• notifyAll() 唤醒所有等待线程，让它们重新竞争锁并各自判断条件——这是更安全、更可预测的做法
• 性能差异在现代 JVM 中已不明显，除非高并发且严格压测，否则优先选 notifyAll()
• 不要为了“省一点唤醒开销”而冒险用 notify() 替代 notifyAll()

推荐用 Lock + Condition 替代原生 wait/notify

原生机制难调试、易出错，java.util.concurrent.locks.Condition 提供了语义更清晰、功能更可控的替代方案。

立即学习“Java免费学习笔记（深入）”；

• 一个 Lock 可绑定多个 Condition，比如 notFull 和 notEmpty，避免不同等待逻辑互相干扰
• 方法名更直观：await() / signal() / signalAll()
• 支持带超时的等待：await(5, TimeUnit.SECONDS)，避免无限阻塞
• 示例：

  Lock lock = new ReentrantLock();
  Condition notEmpty = lock.newCondition();
  
  lock.lock();
  try {
      while (queue.isEmpty()) {
          notEmpty.await();
      }
      return queue.poll();
  } finally {
      lock.unlock();
  }

实际编码中，最常被忽略的是「条件检查必须在同步块内完成」和「虚假唤醒必须用 while 循环防御」——这两点一旦漏掉，问题往往在线上偶发，极难复现和定位。