thread.join()的作用是让当前线程阻塞等待目标子线程执行结束，它通过检查isalive()并调用wait()等同步原语实现被动等待，不中断子线程，仅在子线程自然终止后恢复父线程执行。
Thread.join() 的作用很明确：让当前线程（通常是主线程或父线程）阻塞，直到目标子线程执行结束。它不是“通知”子线程做什么，而是“等待”子线程自然终止。
为什么调用 join() 后父线程才继续？
因为 join() 底层会检查目标线程的 isAlive() 状态，并在内部调用 wait()（Java）或类似同步原语（如 Python 的 _thread.wait()），使当前线程进入 WAITING 状态，直到子线程调用 exit() 或自然 return。注意：它不中断、不强制终止子线程，只被动等待。
常见误判场景：
- 子线程抛异常后未处理，导致
run()提前退出，但父线程仍正常收到join()返回 —— 这不算失败，只是子线程逻辑有缺陷 - 忘记在启动子线程后立即
join()，而是先做其他耗时操作再join()，结果等待时间变长，误以为join()失效 - 多个子线程共用同一个
Thread实例并重复start()，抛出IllegalThreadStateException，根本走不到join()
Java 中正确使用 join() 的三个关键点
Java 的 Thread.join() 有三种重载：join()、join(long)、join(long, int)。实际使用中要注意：
- 必须在
thread.start()之后调用join()，否则join()会立刻返回（因为线程还没开始运行，isAlive()为false） - 若传入超时参数（如
join(5000)），超时后父线程会恢复执行，但子线程仍在后台运行 —— 此时需额外判断thread.isAlive()来决定是否容错或中断 - 如果子线程处于无限
sleep()或wait()，且未被interrupt()，join()也会无限等下去；建议配合interrupt()和InterruptedException处理
示例片段：
Thread t = new Thread(() -> {
try { Thread.sleep(2000); } catch (InterruptedException e) { return; }
System.out.println("done");
});
t.start();
t.join(); // 主线程在此阻塞约 2 秒
System.out.println("after join"); // 这行一定最后输出
Python 中 threading.Thread.join() 的差异点
Python 的行为更“温和”，但有几个容易忽略的细节：
- 不能对已
join()过的线程再次调用join()（会立即返回），但可以安全地重复调用 —— 不报错，也不阻塞 - 没有“毫秒+纳秒”的双参数重载，只有
join(timeout=None)；传None表示无限等待，传浮点数（如2.5）表示最多等 2.5 秒 - 若子线程是守护线程（
daemon=True），主线程退出时该线程会被强制终止，此时join()可能永远等不到结束 —— 所以守护线程一般不配join()
典型写法：
t = threading.Thread(target=lambda: time.sleep(2))
t.start()
t.join() # 阻塞直到完成
print("done")
容易被忽略的并发陷阱
真正难的不是调用 join()，而是它掩盖了更深层的问题：
- 多个子线程都
join()，但顺序写成串行（一个接一个join()），实际性能不如用list存所有线程，统一start()后再统一join() - 在 GUI 或 Android 主线程里盲目
join()，会导致界面卡死 —— 这类场景应该用回调、Handler、ExecutorService或协程替代 -
join()只保证线程结束，不保证共享变量可见性；若子线程修改了某全局变量，父线程读取前仍需加锁或用volatile（Java）/threading.local（Python）等机制
线程结束 ≠ 数据就绪。别把同步逻辑和线程生命周期混为一谈。
