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