yield()只是向调度器发出可被忽略的礼貌性提示，不保证切换、不释放锁、不改变线程状态，实际行为由JVM和操作系统共同决定。
Java 中的 yield() 方法不会真正“让出 CPU 执行权”给特定线程，它只是向线程调度器发出一个礼貌性提示：当前线程愿意暂停执行，让其他同优先级的线程有机会运行。 它不保证切换、不释放锁、也不进入阻塞状态，实际是否让出、让给谁，完全由 JVM 和底层操作系统调度器决定。
yield() 的本质是“建议”，不是“指令”
调用 Thread.yield() 后：
- 当前线程仍处于
RUNNABLE状态（不是WAITING或BLOCKED）； - JVM 会把该线程重新放回就绪队列，与其他同优先级线程一起参与下一轮调度；
- 如果此时没有其他同优先级线程在等待，或者调度器直接再次选中它，线程可能立刻继续执行——你几乎看不出效果；
- 它不释放已持有的任何 monitor 锁（synchronized 块或方法中的锁不受影响）。
和 sleep()、wait() 的关键区别
避免混淆这几个常被拿来对比的方法：
-
sleep(1)：强制线程暂停至少指定毫秒数，进入TIMED_WAITING状态，期间不参与调度，但不释放锁； -
wait()：必须在 synchronized 块内调用，释放锁并进入WAITING状态，直到被notify()唤醒； -
yield()：不设时长、不释放锁、不改变线程状态，仅尝试“谦让”——行为最弱、效果最不确定。
什么时候可以考虑用 yield()？
现实中极少需要主动调用 yield()。仅在极少数场景下作为轻量级协作手段，例如：
立即学习“Java免费学习笔记（深入）”；
- 自旋等待逻辑中，避免空转消耗过多 CPU（比如轮询某个标志位时，在每次循环末尾加
yield()）； - 测试或调试多线程调度行为（如验证线程优先级的影响），但生产环境不推荐依赖它做逻辑控制；
- 某些无锁算法中，作为退让策略的一部分（但通常已有更成熟的方案如
LockSupport.parkNanos()）。
实际效果往往不如预期，别依赖它
由于现代 JVM 的线程调度高度优化（尤其在 HotSpot 上），yield() 在多数情况下会被忽略。不同 JDK 版本、不同操作系统（Linux vs Windows）、甚至不同 CPU 核心数都可能导致行为差异。写代码时若靠 yield() 来保证顺序、避免竞争或实现协作，大概率会出问题。
真正需要线程协作，请使用 wait/notify、Condition、CountDownLatch、Phaser 等明确语义的同步工具。
