Thread.yield() 不可靠，因它仅提示JVM让出CPU，不保证上下文切换、不阻塞线程、不参与锁竞争，现代JVM/OS常忽略它；应改用sleep、park、wait或CAS自旋等可控阻塞方式观测调度。
Thread.yield() 不是可靠的时间片礼让手段，无法用于精确控制或稳定复现线程调度行为。它只是向 JVM 提示“当前线程愿意让出 CPU”，但是否真的让、让给谁、让多久，完全由底层调度器决定——JVM 规范甚至不要求它做任何事。
为什么 Thread.yield() 在测试调度时几乎不可靠
它不保证触发上下文切换，也不阻塞线程，更不参与锁竞争或唤醒逻辑。在大多数现代 JVM（如 HotSpot）和操作系统（Linux CFS、Windows Thread Scheduler）上，Thread.yield() 常被直接忽略，尤其在线程数 ≤ CPU 核心数、无竞争、无 I/O 等待的轻量测试中。
- OpenJDK 17+ 的
Thread.yield()实际调用的是os::yield()，而 Linux 下该函数常映射为sched_yield()—— 它只把当前线程放回就绪队列尾部，若没有其他同优先级线程就绪，该线程会立刻被重新调度 - 在 G1 或 ZGC 等垃圾收集器下，
yield()可能被 GC 线程抢占时机覆盖，导致观测结果完全失真 - IDEA/IntelliJ 调试模式下，
yield()行常被断点打断，进一步破坏调度节奏
想观察线程调度？改用可控的阻塞点代替
真正能迫使调度器介入的方式，是引入可预测的阻塞或竞争：使用 Object.wait()、LockSupport.park()、带超时的 Thread.sleep(1)，或在共享变量上制造 CAS 冲突。
-
Thread.sleep(1)比yield()更稳定：至少让出一个时间片（即使被唤醒早于 1ms，OS 也会经历一次调度决策） - 用
AtomicInteger.compareAndSet()循环自旋 + 失败后Thread.onSpinWait()（Java 9+），能模拟真实竞争场景，且onSpinWait()是 JVM 认可的提示指令（x86 上编译为pause） - 配合
System.nanoTime()打点记录各线程进入临界区的顺序和间隔，比依赖yield()的“空转”更易定位调度延迟
如果非要用 yield() 做简单对比实验，必须加约束条件
仅当满足以下全部条件时，yield() 才可能表现出轻微可观测性：
- 运行在单核 CPU 或
taskset -c 0 java ...绑定单核的环境（避免多核并行掩盖调度） - 所有线程设置相同优先级（
Thread.NORM_PRIORITY），且未启用实时调度策略（如chrt） - 关闭 JIT 编译优化（
-XX:-TieredStopAtLevel -XX:+PrintCompilation），防止热点代码内联消除 yield 点 - 用
jstack配合高频采样（如async-profiler）抓取RUNNABLE状态分布，而非依赖日志打印顺序
调度行为本质是 JVM + OS + 硬件协同的结果，Thread.yield() 连其中任意一层都未承诺语义。想验证调度策略，与其调试这个形同虚设的提示，不如直接读 /proc/sched_debug（Linux）、用 perf sched 抓 trace，或者写一段基于 pthread_cond_wait 的 C 对照组。Java 层面的“礼让”，从来就不是给开发者用的。
