thread.yield() 不会让线程真正让出 cpu，仅向调度器发出可忽略的让权提示；它不改变线程状态、不触发上下文切换，在多数场景下无效，仅极少数协作式轮询中谨慎使用。
Thread.yield() 真的会让线程“让出 CPU”吗？
不会。它只是向操作系统调度器发出一个弱提示：当前线程愿意暂停执行，但不保证任何效果；多数情况下，Thread.yield() 调用后线程立刻又被选中继续运行。
这是因为 yield 不改变线程状态（仍是 RUNNABLE），也不触发上下文切换强制条件（比如阻塞、时间片耗尽或更高优先级就绪）。现代 JVM（尤其是 HotSpot）在 Linux/Windows 上通常将 Thread.yield() 编译为 sched_yield() 或 SwitchToThread()，而这些系统调用本身语义就是“建议让权”，调度器完全可以忽略。
- 在单核 CPU 或线程数 ≤ 核心数时，yield 基本无效 —— 没有其他可运行线程竞争，自然“让了也白让”
- 在高负载多线程场景下，yield 可能略微增加其他同优先级线程被调度的概率，但无法控制具体让给谁、让多久
- JVM 参数如
-XX:+UseThreadPriorities会影响 yield 效果，但默认开启且优先级对 Linux 的 CFS 调度器实际影响极小
什么时候用 Thread.yield() 才不算瞎写？
极少。真实可用的场景非常窄，仅限于调试或特定协作式轮询逻辑中，且必须配合明确的等待条件和退避策略。
典型例子是自旋等待某个共享标志位变化，又不想用 LockSupport.park() 或 wait() 引入锁开销，同时希望降低 CPU 占用：
立即学习“Java免费学习笔记（深入）”；
while (!ready) {
Thread.yield(); // 避免纯忙等，但不能替代 sleep(1)
}
- 绝对不要用在“防止线程抢资源”的朴素想法里 —— yield 不提供同步语义，也不释放锁
- 不要用于“让主线程等子线程完成”：它不是
join()，也不保证可见性，volatile + 循环检查才靠谱 - 若目标是降 CPU，
Thread.sleep(1)比 yield 更可靠（至少触发一次调度器检查）
yield 和 sleep(0)、park() 的关键区别在哪？
三者表面都“暂停”，但语义和底层行为完全不同。
-
Thread.yield()：不进入阻塞态，不释放监视器锁，不参与等待队列，无超时机制，纯提示调度器 -
Thread.sleep(0)：进入TIMED_WAITING态，触发调度器重调度，但立即到期，效果接近 yield（某些 JDK 版本甚至内联为 yield），但更重 -
LockSupport.park()：进入WAITING态，需显式 unpark 唤醒，支持阻塞点中断，是构建锁和并发工具的基础原语
错误地把 yield() 当作轻量 sleep() 用，常导致本地测试看似正常、压测时 CPU 狂飙 —— 因为在高并发下，yield 几乎不缓解竞争，反而掩盖了真正需要同步或限流的问题。
为什么 JMH 基准测试里要禁用 yield？
因为 Thread.yield() 在微基准测试中会严重污染测量结果：它引入不可控的调度抖动，使单次操作耗时方差极大，且不同机器、内核版本响应差异明显。
- JMH 默认启用
-jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:SuppressErrorAt=..."类参数时，部分 JDK 会直接忽略 yield 调用 - 即使没忽略，yield 导致的线程状态停留时间无法建模，会使吞吐量（ops/s）和平均延迟（ns/op）失去可比性
- 真实业务代码若依赖 yield 控制节奏，JMH 测出来的性能数字根本不能反映生产行为
真正需要调控执行节奏的地方，应该用明确的限流（如 RateLimiter）、背压（如 Flow.Subscriber）或异步编排（如 CompletableFuture.delayedExecutor），而不是靠调度器猜你的心思。
