sleep是Thread类静态方法，作用于当前线程且不释放锁；wait是Object类实例方法，必须在synchronized块内调用，会释放指定对象锁并依赖notify协作。
sleep 是 Thread 类的静态方法，wait 是 Object 类的实例方法
这是最根本的区别，直接决定调用方式和作用对象。sleep 操作的是当前线程本身，不依赖任何对象锁；wait 必须在已获得某个对象锁的前提下调用，且只能由该对象上调用。
常见错误现象：IllegalMonitorStateException —— 直接在没加锁的代码里写 obj.wait() 就会抛这个异常。
-
Thread.sleep(1000)可以在任意地方调用，哪怕没 synchronized 块 -
obj.wait()必须出现在synchronized(obj) { ... }内部 -
wait会释放当前持有的obj锁，而sleep不释放任何锁 - 两者都让线程进入 阻塞态（Blocked/Waiting），但 JVM 状态不同：
sleep进入TIMED_WAITING，wait进入WAITING（或TIMED_WAITING如果带超时）
wait 必须配合 notify/notifyAll 使用，sleep 不需要
wait 的设计意图是线程协作：一个线程等某个条件成立，另一个线程负责“通知”。没有 notify，wait 可能永远卡住；sleep 则只看时间，到期自动恢复。
使用场景差异明显：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 生产者-消费者模型中，消费者调用
queue.wait()等待非空，生产者插入后调用queue.notify() -
sleep更适合“延迟执行”“轮询间隔”这类单线程节奏控制，比如模拟心跳、重试退避 - 误用
wait而忘记notify是典型死锁诱因；误用sleep通常只是逻辑延时不准
中断行为不同：sleep 响应 interrupt，wait 也响应但需重新检查条件
两者都会被 Thread.interrupt() 打断，但处理方式有关键区别：
-
sleep被中断时抛出InterruptedException，并清除中断状态（Thread.interrupted()返回 true 后变为 false） -
wait被中断同样抛InterruptedException，但**不保证条件已满足**，必须放在 while 循环里重检
while (queue.isEmpty()) {
try {
queue.wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
return; // 或重新 throw
}
}
漏掉 while 循环、用 if 替代，是 wait 最常见的误用——虚假唤醒（spurious wakeup）会导致线程在条件仍不满足时继续执行。
参数和超时机制表面相似，语义完全不同
sleep(long) 和 wait(long) 都支持毫秒级超时，但含义不同：
-
Thread.sleep(5000)：最多睡 5 秒，到期必醒（除非被 interrupt） -
obj.wait(5000)：最多等 5 秒，但可能提前被notify唤醒，也可能因虚假唤醒醒来 -
wait的超时是协作协议的一部分，sleep的超时是硬性时间约束 - 性能影响上：
wait/notify涉及锁竞争和 JVM 线程调度器介入，开销略高于sleep；但sleep在高频率轮询中会浪费 CPU
真正难的不是记住语法，而是判断该用哪个——看到“等别人告诉我可以继续”，选 wait；看到“我自己数三秒再干活”，选 sleep。混淆这两者，往往意味着对线程协作模型的理解还没落地到具体锁对象上。
