Thread.sleep(0)会主动让出CPU时间片，触发调度器重评估线程优先级并可能上下文切换，本质是协作式yield；它不进入TIMED_WAITING状态，不抛InterruptedException，绕过定时器直接调用底层yield原语。
在 JVM 中，Thread.sleep(0) 并非“什么都不做”，而是具有明确的底层语义：它主动让出当前 CPU 时间片，触发线程调度器重新评估线程优先级并可能进行上下文切换——即使休眠时间为 0。这本质上是向操作系统（或 JVM 线程实现层）发出一个“我愿意让出 CPU”的协作式提示。
sleep(0) 的 JVM 层行为：不是空操作，而是 yield + 调度点
JVM 规范未强制规定 sleep(0) 必须让出 CPU，但所有主流实现（HotSpot、OpenJ9）都将其实现为：清空本地调度延迟、刷新线程状态，并立即进入阻塞/可运行队列重排流程。它不进入 TIMED_WAITING 状态（区别于 sleep(1)），而是快速走完 ObjectMonitor 或 OS 线程调度路径中的“yield 分支”。
关键点：
-
sleep(0)不会抛出InterruptedException（除非当前线程已被中断且中断状态未被清除） - 它绕过纳秒级定时器逻辑，直接调用底层线程让出原语（如 Linux 上的
sched_yield()或 pthread_yield()） - HotSpot 源码中，
os::sleep()对millis == 0的分支会调用os::yield_all()或等效的平台特定让出函数
用原生代码验证：通过 JNI 调用底层 yield 并对比行为
纯 Java 无法直接观测 CPU 轮转，但可通过 JNI 在 C 层插入可观测的调度行为，并与 sleep(0) 对比执行顺序和时间戳变化：
示例（Linux + HotSpot）：
// Java 层public class SleepZeroTest {
static {
System.loadLibrary("sleepzero");
}
private static native void nativeYield(); // 调用 sched_yield()
private static native long nanoTimeBeforeYield();
<pre class="brush:php;toolbar:false;">public static void main(String[] args) throws Exception {
Thread t = new Thread(() -> {
for (int i = 0; i <p>}</p>// C 层（sleepzero.c）#include <time.h>
#include <sched.h>
#include <jni.h><p>JNIEXPORT void JNICALL Java_SleepZeroTest_nativeYield(JNIEnv *env, jclass cls) {
sched_yield(); // 明确触发内核调度器重选
}</p>
<p>JNIEXPORT jlong JNICALL Java_SleepZeroTest_nanoTimeBeforeYield(JNIEnv <em>env, jclass cls) {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return (jlong)ts.tv_sec </em> 1000000000L + ts.tv_nsec;
}</p></jni.h></sched.h></time.h>运行结果通常显示：
-
sleep(0)耗时多为几十至几百纳秒（含 JVM 入口开销），但明显大于普通指令（如空循环），说明它进入了调度路径 -
sched_yield()耗时更短（常 - 若在单核 CPU 或高负载下观察线程调度日志（如
perf sched record -g），可见sleep(0)后紧随一次context-switch事件，而连续空循环则无
反证法：对比 sleep(0) 与空循环 / Thread.yield()
以下三者行为不同：
-
while(true);：死占 CPU，不触发调度，其他线程可能饿死（尤其低优先级） -
Thread.yield();：语义是“建议让出”，但现代 JVM（尤其 Linux 上）常被忽略（因 CFS 调度器认为 yield 价值低），实际效果不稳定 -
Thread.sleep(0);：强制进入 JVM 线程状态机的「阻塞→就绪」流转，必然触发调度器重评估，效果强于 yield
实测可写一个双线程竞争场景：
sleep(0)
