thread.yield()的作用是提示当前运行线程让出cpu，回到就绪状态，不释放锁、不改变线程优先级、不保证切换成功；其行为与线程创建方式无关，仅取决于当前执行线程及jvm/os调度器。
Thread.yield() 的行为与线程的创建方式（继承 Thread 类 或 实现 Runnable/Callable）**完全无关**。它只取决于当前正在执行的线程对象本身，以及 JVM 线程调度器和底层操作系统的配合。
yield 方法不区分线程创建方式
无论你用哪种方式创建线程——
- 继承 Thread 并重写 run()
- 实现 Runnable 传给 Thread 构造器
- 使用 lambda 表达式 创建 Runnable
- 通过 ExecutorService 提交任务（Runnable/Callable）
只要在某个线程的执行路径中调用了 Thread.yield()，效果都是一样的：让**当前正在 CPU 上运行的那个线程**从 RUNNABLE（运行中）状态回到 RUNNABLE（就绪）状态，重新参与 CPU 时间片竞争。
关键点在于“当前线程”而非“怎么建的”
yield 是静态方法，它作用的对象永远是调用它的那个线程实例，而不是某个特定类或接口的实现。例如：
- 在
new Thread(() -> { Thread.yield(); }).start();中，yield 让的是这个新线程自己让出 CPU - 在
ExecutorService.submit(() -> { Thread.yield(); });中，yield 让的是线程池中实际执行该任务的工作线程 - 在主线程里直接写
Thread.yield();，让的就是 main 线程自己
创建方式影响的是线程的生命周期管理或任务组织形式，但 yield 的语义和调度效果始终一致。
不同场景下表现看似不同，实则原因相同
你可能观察到“在 ExecutorService 中 yield 像没用”或“在两个裸 Thread 中交替明显”，这不是因为创建方式改变了 yield，而是因为：
- 线程数量与竞争强度：两个裸线程竞争时，yield 更容易被调度器感知；而在线程池中，可能有 10 个空闲工作线程，yield 后大概率还是轮到自己
- 是否有其他就绪线程：yield 只对同优先级或更高优先级的就绪线程“有效提示”。若没有其他线程在等 CPU，yield 几乎无感
- JVM 和 OS 调度策略：Linux 的 CFS、Windows 的时间片轮转等，对 yield 的响应程度不同，与创建方式无关
注意：yield 在 ForkJoinPool 或虚拟线程中也适用，但意义减弱
在现代 Java（如 Loom 项目引入的虚拟线程）中，大量轻量级线程共存，CPU 调度已脱离传统内核线程一对一模型。此时 yield 对调度器的“提示价值”进一步降低——因为虚拟线程挂起/恢复成本极低，调度更激进。但它仍合法、可调用，行为定义未变：当前虚拟线程主动让出当前调度单元的执行权。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
