yield() 不降低 CPU 占用率反而可能推高，因其不释放 CPU 仅转为就绪态，易导致原地循环、调度抖动及内核负担增加，无法替代 sleep() 或条件等待机制。
频繁调用 yield() 不但不能降低 CPU 占用率，反而可能推高它。
它不释放 CPU，只是“假装让出”
yield() 不会让线程进入阻塞或等待状态，它只把当前线程从“运行中”转为“就绪”，仍留在调度队列里。如果此时没有其他同优先级或更高优先级的就绪线程，调度器大概率立刻把它重新选中——线程看似让出了时间片，实则原地循环、持续占用 CPU。
- 在单线程或低并发场景下，
yield()几乎无效，CPU 依然满载运转 - 在忙等待（busy-wait）循环中滥用，例如
while (!flag) Thread.yield();，等同于空转耗电 - 每次调用都触发一次轻量级调度决策，虽无完整上下文切换开销，但累积起来仍增加内核调度负担
它可能加剧上下文切换抖动
当多个线程频繁 yield()，又都很快被重新调度，系统会陷入“让出→重获→再让出”的高频震荡。尤其在线程数超过 CPU 核心数时：
- 调度器反复切换线程，寄存器和缓存状态不断刷新
- TLB（地址转换后备缓冲区）命中率下降，内存访问变慢
- CPU 时间越来越多花在调度本身，而非实际业务逻辑
它无法替代真正的等待机制
开发者常误以为 yield() 是“轻量 sleep”，但二者语义完全不同：
立即学习“Java免费学习笔记（深入）”；
-
sleep(1)：线程进入 TIMED_WAITING 状态，明确放弃 CPU 至少 1 毫秒，期间必然不参与调度 -
yield()：线程停留在 RUNNABLE 状态，随时可能被立即执行，CPU 周期照常消耗 - 真正该用条件变量、
LockSupport.park()或Object.wait()的地方，yield()只是掩盖问题
真实影响取决于运行环境
同一段代码，在不同系统上表现差异显著：
- Linux 上对应
sched_yield()，调度器常忽略该调用，尤其在 CFS（完全公平调度器）下更倾向保持缓存局部性 - Windows 上映射为
Sleep(0)，仅当存在同优先级就绪线程时才可能切换 - JVM 实现（如 HotSpot）也可能对连续
yield()做静默优化或限流，行为不可预测
想控制 CPU 占用，应优先使用阻塞式等待；若必须自旋，也建议搭配微秒级 sleep() 或硬件指令（如 Thread.onSpinWait()），而不是依赖 yield()。
