Thread.yield()在多核环境下不保证跨核切换，仅提示调度器让出时间片，实际仍可能在同一核心继续执行；它不改变CPU亲和性，也不触发OS负载均衡，效果不可靠，应避免用于多核协同。
Java 中 Thread.yield() 在多处理器（或多核）架构下，**并不保证线程会切换到其他 CPU 核心执行，也不改变线程绑定的调度单元**；它仅向当前运行的线程调度器发出一个“让出当前时间片”的提示，实际效果仍由底层操作系统调度器决定，且在多核环境下表现更不可预测。
yield 不跨核迁移线程
调用 yield() 后，当前线程从“运行态”回到“就绪态”，但操作系统调度器可能立即将其重新调度到**同一个 CPU 核心**上继续执行——尤其当该核心无其他高/同优先级就绪线程时。JVM 不控制 CPU 亲和性（CPU affinity），也未要求 OS 将让出的线程迁移到其他核心。
- 多核系统中，每个核心有自己的就绪队列，
yield()只影响当前核心本地的调度决策； - 没有机制促使线程被“推”到空闲核心，迁移依赖 OS 负载均衡策略（如 Linux CFS 的 periodic rebalancing），而非 Java 层面的 yield 提示；
- 实测中常见现象：两个线程分别在 core0 和 core1 上长时间独占运行，即使频繁调用
yield()，也不会触发跨核切换。
同优先级线程竞争范围受限于调度域
yield() 的设计目标是“给同优先级线程让出机会”，但在多处理器环境中，“同优先级线程”是否能被调度，取决于它们是否处于**同一调度域（sched domain）**内：
- 若两个线程被 OS 绑定在不同 NUMA 节点或物理 CPU 包（socket）上，即使优先级相同，
yield()对另一节点上的线程几乎无影响； - Linux 默认启用负载均衡，但该过程有延迟（毫秒级），无法响应
yield()这种瞬时提示； - 在容器或虚拟化环境中，cgroup 或 vCPU 配置可能进一步限制调度可见性，导致
yield()完全失效。
与 sleep、park 的本质区别
yield() 是唯一不涉及状态变更的“让权”操作，这在多核下放大了其局限性：
立即学习“Java免费学习笔记（深入）”；
-
sleep(1)强制线程进入 TIMED_WAITING 状态，OS 必须将其移出运行队列，为其他线程腾出资源，效果明确； -
LockSupport.park()使线程阻塞并释放 CPU，调度器必然选择其他就绪线程，跨核调度概率显著提高； -
yield()仅重置线程在就绪队列中的位置（甚至不保证重排），在多核高并发场景下，常被调度器忽略——尤其当线程刚完成 cache warm-up，调度器倾向复用本地缓存。
实际建议：避免依赖 yield 实现多核协同
在多处理器系统中，yield() 不适合用于：
- 实现线程间公平轮转（应使用
ReentrantLock+ 条件等待 或Phaser）； - 缓解 CPU 密集型任务的核间争抢（应通过任务拆分 +
ForkJoinPool或显式设置线程亲和性）； - 替代同步原语（它不释放锁、不建立 happens-before 关系，也无法保证可见性）。
若需提升多核利用率，优先考虑工作窃取（work-stealing）、异步 I/O 或事件驱动模型，而非 yield() 这类弱提示。
