wait和sleep调度逻辑不同：wait进入对象等待队列并释放锁，需notify或超时后重新争锁；sleep进入系统定时队列且不释锁，超时即恢复执行。
两者在 CPU 调度上不涉及“优先级”差异，而是处于**不同线程状态、进入不同等待队列、受不同唤醒机制约束**。所谓“谁更容易被调度”或“谁优先醒来”，本质上是误解——它们的调度逻辑根本不在同一维度。
wait(long) 进入的是对象监视器的等待队列，状态为 WAITING 或 TIMED_WAITING
调用 Object.wait(long) 时，当前线程：
- 必须已持有该对象的 monitor 锁（即在 synchronized 块内）
- 立即释放锁，并被挂起，加入该对象的 等待队列（WaitSet）
- 状态变为 WAITING（无参）或 TIMED_WAITING（带超时）
- 唤醒条件有两个：被同对象上的 notify()/notifyAll() 显式唤醒，或超时自动唤醒
- 即使超时，也需重新竞争该对象锁才能继续执行（可能被其他线程抢先获取锁而阻塞在锁队列）
sleep(long) 进入的是操作系统线程调度器的就绪队列，状态为 TIMED_WAITING
调用 Thread.sleep(long) 时，当前线程：
- 无需任何锁，可出现在任意代码位置（包括 synchronized 块内）
- 不释放任何锁，只是让出 CPU 执行权
- 被放入操作系统的 定时休眠队列，到期后自动回到就绪队列等待 CPU 分配
- 状态始终为 TIMED_WAITING，不受其他线程 notify 影响
- 时间一到即可参与下一轮 CPU 调度，无需额外同步条件
关键区别不在“优先级”，而在“是否依赖协作与锁重入”
表面上都“等一段时间”，但行为本质不同：
- sleep 是单向暂停：只控制自身节奏，不影响他人，也不依赖他人唤醒
- wait 是协作式等待：必须配套 synchronized + notify，本质是线程间通信机制
- 若在 synchronized(lock) 中 sleep(1000)，其他线程整个 1 秒都拿不到 lock；而 wait(1000) 立刻释放 lock，别人马上能进
- 超时后，sleep 线程直接恢复运行；wait 线程还需再次抢锁，可能被阻塞在锁队列中，实际恢复时间不确定
别用“谁更优先”去理解，要看“谁在等什么”
调度器对 TIMED_WAITING 状态的线程统一按时间片和优先级策略处理，不会因为你是 sleep 还是 wait 就区别对待。真正影响响应及时性的，是：
- wait 后是否有人 notify —— 没有则只能等超时
- wait 超时后能否立刻抢到锁 —— 若锁被占用，会先进入 BLOCKED 状态
- sleep 时间固定、可预测，适合节奏控制；wait 适合条件满足才继续，适合资源协调
