thread.yield()的底层语义是向操作系统调度器发送可被忽略的弱提示，不改变线程状态、不触发上下文切换、不释放锁，仅通过jni调用如sched_yield()等系统函数，效果完全不可控且高度依赖运行时环境。
Thread.yield() 的底层语义不是“交出 CPU”，而是向操作系统调度器发送一个**可被完全忽略的弱提示**：当前线程此刻不排斥让权，但依然保持就绪、随时待命。
它不触发任何状态变更或强制调度
调用后，线程仍处于 RUNNABLE 状态，既不阻塞、也不休眠、更不释放锁；JVM 不会发起上下文切换，也不会更新线程的等待时间或优先级。它只是通过 JNI 调用底层系统函数（如 Linux 的 sched_yield() 或 Windows 的 SwitchToThread()），把控制权短暂交还给内核调度器——而内核收到这个请求后，可能直接跳过，也可能重新扫描就绪队列，但结果完全不可控。
效果高度依赖运行时环境
- 在单核 CPU 或线程数 ≤ CPU 核心数时，若没有其他同优先级就绪线程，yield 几乎无感——“让了也没人接”
- 在 Linux CFS 调度器下，线程优先级默认几乎不起作用，yield 对高/低优先级线程的调度权重影响微乎其微
- HotSpot JVM 在启用 JIT 后常将 yield() 编译为空操作（no-op），尤其在服务端模式下
- 即使 yield 生效，原线程大概率被插回就绪队列头部，下一轮仍可能立即被选中
它和真正让权机制有本质区别
yield ≠ sleep(0) ≠ park() ≠ wait()：
— sleep(0) 会让线程进入 TIMED_WAITING 状态，至少触发一次调度器重评估；
— park() 进入 WAITING 状态，需显式 unpark 唤醒，是并发工具的基础；
— wait() 必须配合 synchronized，释放对象监视器，进入条件队列；
— yield 做不到其中任何一项，它连“暂停”都算不上，只是轻点一下调度器的门铃。
唯一合理的使用逻辑是“降噪”而非“控流”
它只在极少数明确需要避免纯忙等、又不愿引入锁或 park 开销的场景下，作为降低 CPU 占用的辅助手段，例如：
- 轮询一个 volatile 标志位时插入 yield()，比空循环稍友好
- 多线程压力测试中，人为制造轻微调度扰动，辅助复现竞态窗口
- 教学演示中展示“同优先级线程调度非确定性”，帮助理解协作式让权的局限性
把它当作同步手段、时序控制工具或性能优化开关，都会带来反效果。
