Thread.sleep(0) 是主动让出 CPU 的调度提示，平台线程触发 OS 调度，虚拟线程由 JVM 协作调度，线程池中仍属平台线程行为，均不释放锁或改变优先级。
Thread.sleep(0) 在 Java 中不是“什么也不做”，而是一个有明确语义的调度提示：它让当前线程主动退出运行态，进入就绪队列，触发操作系统重新进行一次 CPU 调度决策。它的底层唤醒行为**不取决于线程如何创建（new Thread、线程池、虚拟线程等）**，而取决于 JVM 如何将该调用映射到底层 OS 的调度机制。真正影响唤醒时机和效果的，是线程所处的执行上下文与状态模型。
普通平台线程（Platform Thread）下的唤醒机制
这是传统 Java 线程模型，每个 Thread 实例一对一绑定一个 OS 线程（kernel thread）。调用 Thread.sleep(0) 时：
- JVM 调用底层系统 API（如 Linux 的 nanosleep(0) 或 sched_yield()），向内核发出让出 CPU 的请求
- 当前线程从 RUNNING 状态转为 RUNNABLE，并被放回就绪队列（run queue）
- 内核调度器立即重评估所有就绪线程的优先级、CFS 虚拟运行时间（vruntime）等，选择下一个运行线程
- 若无更高优先级或更“饥饿”的线程，原线程可能被立刻重新选中——这不是“没生效”，而是调度结果符合策略
线程池中复用的线程（如 ThreadPoolExecutor 工作线程）
这类线程本身是长期存活的平台线程，只是任务在变。Thread.sleep(0) 的行为与上一类完全一致，但实际效果更明显：
- 避免单个 Runnable 任务长时间霸占线程（例如密集循环中未让渡）
- 使同一线程池中其他待执行任务有机会被同一线程或其它空闲工作线程拾取
- 不会导致线程销毁或重建，因此没有额外创建/销毁开销
- 注意：sleep(0) 不会释放线程池自身的资源锁（如 workQueue 的 take() 阻塞），它只作用于 CPU 时间片分配
虚拟线程（Virtual Thread，JEP 425）下的唤醒行为
虚拟线程由 JVM 调度，运行在少量平台线程（Carrier Threads）之上。Thread.sleep(0) 在此场景下表现不同：
立即学习“Java免费学习笔记（深入）”；
- 它不会直接触发 OS 调度，而是通知 JVM 调度器：当前虚拟线程愿意暂停，可挂起并切换到另一个虚拟线程
- JVM 将其状态设为 PARKED，并将其移交至虚拟线程调度器的就绪队列
- 唤醒不依赖定时器中断，而由 JVM 在 carrier thread 空闲或有更高优先级虚拟线程就绪时主动恢复
- 因此 sleep(0) 在虚拟线程中开销更低、响应更快，且几乎不引发 OS 上下文切换
关键区别总结：唤醒是否依赖 OS？
根本差异不在“怎么创建线程”，而在“谁负责调度”：
- 平台线程：唤醒由 OS 内核完成，sleep(0) 是一次轻量系统调用，效果受内核调度策略（如 CFS）直接影响
- 虚拟线程：唤醒由 JVM 用户态调度器完成，sleep(0) 是纯 JVM 层协作式让渡，无系统调用开销，也不触发 OS 级上下文切换
- 线程池线程：仍是平台线程，所以唤醒机制同第一类；区别仅在于任务粒度更细、让渡更频繁，利于公平性
不复杂但容易忽略：无论哪种机制，sleep(0) 都不会释放 synchronized 锁或 ReentrantLock，也不会改变线程优先级，它只影响 CPU 时间片的即时分配权。
