yield仅是提示调度器让出cpu，不保证效果；join则强制等待目标线程结束，支持超时和中断处理，适用于完成依赖场景。
Java 中的 yield 和 join 都能影响线程执行时机，但作用机制、适用场景和可靠性完全不同。想靠它们“精确控制顺序”，必须分清谁管提示、谁管等待。
yield 是礼貌让位，不是强制交班
Thread.yield() 只是向调度器发出一个建议：当前线程愿意暂时放弃 CPU，给同优先级或更高优先级的其他就绪线程一次机会。它不阻塞、不挂起、不释放锁，也不保证效果。
- 调用后，当前线程立刻回到就绪队列，但可能下一毫秒又被选中继续运行
- 对低优先级线程无效；若没有其他同优先级线程在等待，yield 基本无感
- 不能用于同步逻辑——比如“等 A 跑完再跑 B”，yield 完全做不到
- 典型用途是微调吞吐或缓解忙等待，例如在自旋重试前 yield 一下，减少 CPU 空转
join 是明确等待，能实现“完成依赖”
thread.join() 的作用很实在：当前线程暂停执行，直到目标线程终止。它底层基于 wait()，会释放锁（如果在 synchronized 块中调用），且支持超时控制。
- 主线程启动多个子线程后，逐个调用
t1.join()、t2.join()，就能确保全部执行完毕再汇总结果 - 有三种形式：
join()（无限等待）、join(long millis)（最多等若干毫秒）、join(long millis, int nanos)（精度更高，但极少需要） - 若目标线程已结束，join 立即返回；若被中断，抛出
InterruptedException，务必捕获处理 - 注意：join 不等于“插队”或“抢占”，而是“守规矩地等”，不影响其他未 join 的线程运行
别混淆用途：顺序控制不能只靠 yield
很多初学者尝试用反复调用 yield() 实现 A→B→C 的串行执行，这在 JVM 规范里没有任何保障。不同 JDK 版本、操作系统甚至单次运行结果都可能不同。
- 真正需要确定性协作时，应选用
CountDownLatch（一个线程等多个）、CyclicBarrier（多线程互相等）、Semaphore（控制并发数）等显式同步工具 - 共享状态修改必须加锁或使用原子类，否则即使顺序看似正确，数据也可能因竞态而损坏
- join 适合“等待完成”，yield 仅适合“轻量提示”，二者不可互换，也不该叠加滥用
实际写法要注意安全细节
用 join 时，异常和资源管理不能马虎：
- 始终包裹在 try-catch 中，响应
InterruptedException，避免中断信号被吞掉 - 若需在 finally 块中清理资源，注意 join 可能被中断，要判断线程是否还存活
- 避免在持有锁期间长时间 join，否则可能造成其他线程饥饿
- yield 不抛异常，也无需 try-catch，但也不该放在关键路径上做逻辑依赖
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
