Java中join()是Thread类实例方法，用于让当前线程阻塞等待目标线程终止；必须先start()再join()，否则立即返回；无参join()存在死锁风险，推荐使用带毫秒超时的重载，并检查isAlive()。
Java 中 join() 的基本用法和阻塞逻辑
join() 是 Thread 类的实例方法，调用它会让当前线程暂停执行，直到目标线程终止（进入 TERMINATED 状态）。这不是“主动通知”，而是“被动等待”——它不唤醒、不协作、不传递数据，只做一件事：阻塞调用方。
常见错误是误以为 join() 会启动线程，其实它和 start() 完全无关。没调用 start() 就直接 join()，当前线程会立刻返回（因为目标线程根本没运行过，状态是 NEW）。
- 必须先调用
thread.start()，再调用thread.join() -
join()调用后，当前线程进入WAITING状态，JVM 底层通过Object.wait()实现 - 如果目标线程已结束，
join()立即返回，不阻塞
带超时的 join(long millis) 怎么避免无限等待
生产环境里，绝不能依赖无参 join()——万一目标线程卡死、死锁或陷入无限循环，调用方就永远挂起。带超时的重载才是安全选择。
注意：join(5000) 表示“最多等 5 秒”，不是“固定等 5 秒”。如果目标线程 2 秒就结束了，它立刻返回；如果 5 秒后还没结束，它也返回，但此时目标线程仍在运行。
- 超时后需手动检查线程状态：
thread.isAlive()，判断是否真结束了 - 超时单位是毫秒，传负数会抛
IllegalArgumentException - 超时期间若被中断，会抛
InterruptedException，且会清除当前线程的中断状态
多个线程依次 join() 还是并行 join()？
顺序调用 t1.join(); t2.join(); t3.join(); 是串行等待：t1 结束后才开始等 t2，t2 结束后才等 t3。实际耗时 ≈ t1 + t2 + t3。
如果想“同时等全部结束”，应该先 start() 所有线程，再统一 join()：
t1.start(); t2.start(); t3.start(); t1.join(); // 此时 t2/t3 可能还在跑 t2.join(); t3.join();
这样总耗时 ≈ max(t1, t2, t3)，更接近并发语义。漏掉某个 join() 就意味着放弃等待它，后续逻辑可能读到未完成的数据。
为什么在 ExecutorService 场景下很少用 join()
一旦用了线程池，你就不再直接持有 Thread 实例，submit() 返回的是 Future，不是 Thread。这时候 join() 失效，必须用 future.get() 等待结果。
强行从 Future 反查线程（比如通过 Thread.getAllStackTraces().keySet()）不可靠，且违反抽象层级。更隐蔽的问题是：线程池复用线程，一个 Thread 对象可能执行多个任务，join() 等的是线程对象生命周期，不是某次任务执行周期。
- 用
ExecutorService就别碰join()，改用Future.get()或CompletableFuture - 如果非要混合使用（比如池中任务内部又新建了子线程），子线程的
join()只影响该任务线程本身，不影响池线程调度
真正容易被忽略的是：所有 join() 调用都隐含了内存可见性保证——当 join() 返回时，目标线程写入的变量对当前线程是可见的。但这不等于线程安全，只是 happens-before 关系成立。如果目标线程修改的是共享可变对象，仍需同步机制保护。
