Thread.yield()的本质是向调度器发出“礼貌性暂停”建议，线程保持RUNNABLE状态、不释放锁、不保证切换，仅将自身放回就绪队列头部以供重新调度。
Thread.yield() 的本质，就是一次不改变状态、不释放资源、也不保证生效的“礼貌性暂停”。它既不是线程阻塞，也不是主动休眠，更不是让线程进入等待队列——它只是把当前线程从「正在运行」（Running）放回「就绪队列」头部，仍维持 RUNNABLE 状态。
yield() 不会改变线程状态
调用 yield() 后，线程不会进入 BLOCKED、WAITING 或 TIMED_WAITING 等任何阻塞态。JVM 规范明确要求：该方法不修改线程状态，线程始终处于 RUNNABLE 枚举值所涵盖的状态（即包括就绪和运行两种子情形）。你可以用 thread.getState() 验证——无论调多少次 yield()，只要没被阻塞或终止，结果永远是 RUNNABLE。
yield() 不释放锁、不打断同步块
它和 sleep()、wait() 的关键区别在于：
- 不会放弃已持有的 synchronized 锁或 ReentrantLock
- 不会触发任何中断响应（不抛 InterruptedException）
- 不会导致线程让出 monitor，其他线程无法趁机进入临界区
这意味着 yield() 只影响 CPU 时间片的调度机会，完全不影响并发控制逻辑。
yield() 的调度效果高度不确定
它只是向 JVM 发送一个建议，是否采纳取决于：
- 当前是否有其他同优先级的就绪线程（高/低优先级线程不受影响）
- JVM 实现（HotSpot 在 JIT 编译后常将 yield() 优化为 no-op）
- 操作系统线程调度策略（如 Linux CFS 调度器可能忽略该提示）
- 线程刚被放回就绪队列头部，很可能下一轮又被立即选中执行
所以它不是“礼让”，而是“试探性暂停”——你让了，但没人保证接住。
为什么并发工具类里还用 yield()？
在 AQS、ConcurrentHashMap 等底层实现中，yield() 常出现在自旋重试循环末尾，例如：
while (!tryAcquire()) {
Thread.yield(); // 避免空转耗尽时间片，给其他线程一点喘息机会
}
它的价值不在“一定让出”，而在于：降低忙等强度 + 减少上下文切换冲突概率 + 提升多线程协作的友好性，属于轻量级的协作提示，而非强制控制手段。
