yield() 方法仅是向调度器建议当前线程让出 cpu，不保证切换、不释放锁、不阻塞，效果依赖 jvm 和 os 实现，现代环境中常被忽略；慎用于自旋退让、公平性提示或调试，生产环境应优先选用 wait/sleep/locksupport 等可控机制。
Java 中的 yield() 方法并不能真正“让出执行权”，它只是向调度器建议当前线程愿意暂停运行，但不保证其他线程立即获得 CPU —— 实际效果高度依赖 JVM 实现和操作系统调度策略。
yield() 的本质是提示而非强制
调用 Thread.yield() 时，JVM 会把当前线程从“运行中（Running）”状态转为“就绪（Runnable）”状态，并重新参与 CPU 竞争。但它不会释放锁、不会阻塞、不会进入等待队列，也不会改变线程优先级。是否切换、切给谁、何时切，完全由调度器决定。在多数现代 JVM（如 HotSpot）和主流 OS（Linux/Windows）上，yield() 常常被忽略或效果微弱，尤其在单核或负载较低时几乎无感。
慎用 yield() 的典型场景
-
自旋等待的轻量退让：比如在无锁算法中，线程短暂忙等某个条件成立，可插入 yield() 减少 CPU 空转消耗（但更推荐使用
LockSupport.parkNanos(1)或短时 sleep） - 同优先级线程的公平性微调：当多个同优先级线程协作且希望避免某一线程长期独占 CPU 时（仅作尽力而为的提示，不可依赖）
- 调试与教学用途：人为制造线程调度可见性，便于观察并发行为（生产环境应避免）
比 yield() 更可靠的选择
若目标是“让出执行权并等待特定条件”，应优先使用语义明确、行为可控的机制：
- Object.wait() / Condition.await()：配合 synchronized 或 Lock，真正释放锁并进入等待队列，直到被 notify 或 signal 唤醒
- Thread.sleep(1)：至少让出当前时间片，强制触发调度，比 yield() 更具可预测性（注意捕获 InterruptedException）
- LockSupport.park()/unpark()：底层支持，无条件阻塞/唤醒，适用于高级并发工具（如 AQS）
- CompletableFuture 或 Reactive 流：面向异步编程，用非阻塞方式交出控制权，避免线程空等
实际编码中的提醒
不要在循环中盲目写 while (condition) Thread.yield(); —— 这既不能保证响应及时，又可能因调度器忽略而持续空转。若 condition 检查开销小且预期等待极短，可保留；否则务必引入超时、计数限制或改用 wait/sleep。另外，yield() 对线程优先级无影响，也不解决竞态或死锁问题，它不是同步原语，不能替代 proper synchronization。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
