sleep是Thread静态方法，wait是Object实例方法；sleep不释放锁且可任意调用，wait必须在synchronized块内调用并释放锁，需配合notify/notifyAll唤醒，并用while循环防虚假唤醒。
sleep 是 Thread 的静态方法，wait 是 Object 的实例方法
这是最根本的差异，直接决定你能不能调用、在哪调用、要不要加锁。Thread.sleep() 属于线程自身行为，不依赖任何对象；而 obj.wait() 必须作用在某个具体对象上，且该对象必须是当前线程已持有的锁目标。
常见错误现象：wait() 被写在非 synchronized 块里，运行时抛出 IllegalMonitorStateException —— 不是语法错，是 JVM 在运行时检查到“你没拿锁就敢释放锁”，直接拒绝执行。
-
Thread.sleep(1000)可以出现在任意位置（但需处理InterruptedException） -
lock.wait()必须写在synchronized(lock) { ... }内部 - 想唤醒等待中的线程？只能用
lock.notify()或lock.notifyAll()，且同样必须在synchronized(lock)块中
sleep 不释放锁，wait 会释放锁
这个区别直接影响并发逻辑是否死锁或卡住。比如你在同步块里做耗时操作，又想让其他线程能进来干活，用 sleep 就白搭——锁还攥着，别人干瞪眼；而 wait 一调，锁立刻松手，别人就能进来了。
实操建议：别靠“休眠几秒”来模拟等待条件，那是反模式。例如生产者-消费者场景中，用 queue.wait() 等待队列非空，比 Thread.sleep(100) 轮询更高效、更安全。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 持有锁期间调用
Thread.sleep(5000)→ 其他线程阻塞等待该锁，5 秒内无法进入临界区 - 持有锁期间调用
queue.wait(5000)→ 锁立即释放，其他线程可操作queue；5 秒后若未被notify，自动重新竞争锁 - 注意：
wait(long timeout)不等于“超时后自动继续”，它只是避免永久挂起，仍需重新抢锁才能往下走
唤醒机制完全不同：sleep 靠时间，wait 靠 notify
sleep 是单向计时器，时间一到就醒；wait 是协作式等待，必须有另一个线程显式调用 notify 或 notifyAll 才能结束等待状态（除非设了超时）。
容易踩的坑：notify() 只随机唤醒一个等待线程，如果多个线程在等同一把锁，可能唤醒错人，导致部分线程永远等下去。生产环境更推荐 notifyAll()，再配合 while 循环检查条件（即“虚假唤醒”防护）。
-
Thread.sleep(2000)→ 2 秒后自动恢复运行（前提是没被interrupt()） -
resource.wait()→ 永远不会自己醒，必须有人调resource.notify() - 正确写法应是：
synchronized (resource) { while (!conditionMet()) { resource.wait(); } // 处理逻辑 }
异常处理和中断响应都得接住 InterruptedException
两者都会响应线程中断（thread.interrupt()），并抛出 InterruptedException。但很多人只记得 catch，却忘了关键一点：**该异常发生时，线程的中断状态会被清除**。
这意味着如果你在 catch 块里啥也不做，上层逻辑就再也感知不到这次中断了——相当于“悄悄吞掉中断信号”。尤其在框架或线程池中，这可能导致任务无法被优雅终止。
- 必须在 catch 中恢复中断状态：
Thread.currentThread().interrupt(); - 不要用空 catch 或只打日志就完事
- 不是所有场景都要立即退出，但中断意图要向上传递
while + wait 循环、选对 notify 还是 notifyAll、以及中断处理不丢信号——这些细节才决定多线程代码到底稳不稳定。 
