Java中join()方法让调用线程暂停直至目标线程结束，基于wait/notify机制实现零轮询等待；需start()后才生效，不可在目标线程内自调用，且join(0)表示无限等待。
Java 中 join() 方法实现同步等待，核心不是“控制目标线程”，而是让**调用它的当前线程暂停执行，直到目标线程自然结束**。它依赖 JVM 对线程生命周期的自动管理，配合对象监视器（monitor）和 wait()/notifyAll() 机制，做到零轮询、低开销、可中断的安全等待。
底层靠 wait/notify 实现，不是忙等
join() 是 synchronized 方法，锁的是目标线程对象本身。内部逻辑是：
- 进入同步块后，反复检查
isAlive() - 若目标线程仍在运行，就调用该线程对象的
wait()—— 这会立即释放锁，并让当前线程进入WAITING状态，不消耗 CPU - 当目标线程执行完毕（状态变为
TERMINATED），JVM 底层会自动在其对象上调用notifyAll()，唤醒所有在它上面等待的线程 - 被唤醒的线程重新竞争锁，再次检查
isAlive()，确认已结束才退出循环继续执行
超时等待不是简单 sleep，而是动态重算
使用 join(long millis) 时，JVM 不会直接调用 wait(millis) 一睡了之。实际策略是：
- 每次
wait(delay)返回后，重新计算剩余等待时间 - 如果目标线程已结束，立刻跳出循环，无需等到超时
- 如果剩余时间 ≤ 0，则停止等待，当前线程恢复执行
- 这样既保证“最多等多久”，又支持“一结束立刻响应”，兼顾确定性与响应性
必须 start() 后才能生效，否则直接返回
join() 是否等待，完全取决于目标线程是否还存活（isAlive() == true）：
立即学习“Java免费学习笔记（深入）”；
- 如果目标线程还没
start()，状态是NEW，isAlive()返回false，join()直接返回，不阻塞 - 如果目标线程已执行完（
TERMINATED），同样不等待 - 只有在
RUNNABLE或BLOCKED等活跃状态下，才会真正进入wait()
容易踩坑的关键点
几个常见误用会导致程序挂起或行为异常：
-
在目标线程内部调用自身 join：比如
Thread.currentThread().join()，会造成无法唤醒的自阻塞，即“自我死锁” -
忽略 InterruptedException：所有
join()都可能被中断，捕获后应考虑恢复中断状态（Thread.currentThread().interrupt()） -
误以为 join(0) 是“不等待”：它等价于无参
join()，表示无限等待，不是 0 毫秒 - 没 start 就 join：看似调用了，实则毫无效果，容易掩盖逻辑错误
