join()等的是目标线程run()方法执行完毕并进入TERMINATED状态；它底层调用wait()，需先start()再join()，否则无效；超时join需配合isAlive()判断，现代开发推荐Future或CompletableFuture替代。
Java中join()到底等的是什么
join()不是“等线程跑完”，而是等目标线程的run()方法执行完毕并退出——也就是线程进入TERMINATED状态。它底层调用的是wait()，但封装得非常隐蔽：当前线程会在目标线程对象上阻塞，直到目标线程自然结束或被中断。
常见错误现象：join()后主线程仍继续执行，往往是因为调用了join()的对象根本不是你启动的那个线程实例（比如误对Thread子类实例调用，但实际启动的是另一个实例）；或者在start()之前就调用了join()，此时直接返回（因为线程还没活，自然“已结束”）。
- 必须先
start()，再join()；顺序颠倒等于没等 - 不要对未启动的线程或已终止的线程反复
join()——不会报错，但无意义 - 如果目标线程被
interrupt()，当前线程会抛出InterruptedException，且目标线程状态不受影响
join(long)超时等待的陷阱
带毫秒参数的join(5000)看起来安全，实则容易误判“是否真结束了”。它只保证最多等5秒，但不保证5秒后目标线程一定结束——可能还在跑，也可能刚结束，也可能早就挂了（比如因异常提前退出）。
使用场景：适合有明确响应时限的协调逻辑，比如后台任务必须在UI线程等待3秒内完成，否则降级处理。
立即学习“Java免费学习笔记（深入）”；
- 超时返回后，务必检查
isAlive()，不能默认“没超时就成功，超时就失败” -
join(0)等价于无参join()，不是“不等待” - 注意系统时钟精度和JVM调度延迟，5ms以下的超时值基本不可靠
为什么join()不用synchronized显式写出来
因为join()内部已经对目标线程对象加锁，并在其上调用wait()。也就是说，你不需要、也不应该在外层再对同一个Thread对象做synchronized——这不仅多余，还可能引发死锁（比如两个线程互相join()又各自持锁）。
性能影响：每次join()都会触发一次对象监视器竞争，高并发下频繁调用多个线程的join()会产生明显争用。这不是瓶颈，但说明它本质是重量级协作机制。
- 避免在循环里对一堆线程逐个
join()，改用CountDownLatch或CompletableFuture.allOf() - 不要在
synchronized(threadObj)块里调用threadObj.join()——锁重入+wait()语义混乱 -
join()的锁对象永远是目标Thread实例本身，和你的业务对象无关
替代join()的现代写法更可靠
纯join()只适合最简单的父子线程模型。真实项目里，线程生命周期、异常传播、结果获取、取消支持都很难靠它搞定。比如一个子线程抛了RuntimeException，父线程用join()完全感知不到——它只关心“是否退出”，不关心“怎么退出”。
可直接替换的方案：Future.get()（配合ExecutorService）、CompletableFuture链式编排、CountDownLatch计数协调。
-
Future.get()能捕获子线程抛出的异常，join()做不到 -
CompletableFuture.supplyAsync().thenApply()天然支持异步结果传递，join()只能干等 - 所有现代方案都支持中断传播和超时组合，而
join()的中断处理需要手动重试或放弃
真正难的不是“怎么等”，而是“等的过程中怎么应对失败、超时、取消”。这些细节join()全交给你自己兜底。
