应使用 join() 而非 isAlive() 等待线程结束：isAlive() 仅瞬时检测且存在竞态，join() 才能可靠阻塞等待；正确做法是先 start() 再 join()，配合超时和异常处理，或改用 Future、CountDownLatch 等高级抽象。
isAlive() 只能查“此刻是否还在跑”，不能等线程结束
isAlive() 是 Thread 类的实例方法，返回 true 表示该线程已启动且尚未自然终止（即没执行完 run()，也没被中断或异常退出）。但它不阻塞当前线程，也不保证下次调用时结果不变——两次调用之间线程可能已经结束了。
常见误用是写成轮询：
while (t.isAlive()) {
Thread.sleep(10);
}这既浪费 CPU/资源，又无法精确捕获“刚结束”那一刻；更严重的是，isAlive() 在线程刚进入 TERMINATED 状态后才返回 false，而 JVM 状态切换有微小延迟，存在极短时间窗口误判。
join() 是真等待：阻塞调用方直到目标线程结束
join() 才是判断“是否结束”的正解——它会让当前线程暂停执行，直到被调用的线程完成。底层基于 wait() 实现，是线程间协作的可靠机制。
立即学习“Java免费学习笔记（深入）”；
使用要点：
-
t.join()会无限等待，除非t结束或当前线程被中断（抛InterruptedException） -
t.join(500)最多等 500 毫秒，超时后继续执行，此时需配合t.isAlive()判断是否真结束了 - 必须在
t.start()之后调用，否则join()立即返回（因为还没启动，状态是NEW）
别用 isAlive() 做同步逻辑，join() 也别乱套在循环里
典型错误场景：
- 在 for 循环中对多个线程逐个
join()：实际是串行等待，丧失并发意义。应先start()全部，再统一join() - 用
isAlive()替代join()实现“等待+超时”，结果因竞态导致逻辑错乱 - 忽略
InterruptedException，直接吞掉异常，导致线程中断信号丢失、响应迟钝
正确做法示例：
Thread t = new Thread(() -> { /* 耗时任务 */ });
t.start();
try {
t.join(3000); // 最多等3秒
if (t.isAlive()) {
System.out.println("超时，线程可能卡住");
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
}真正要“判断是否结束”，往往意味着你需要重构设计
频繁检查线程是否结束，通常说明控制流设计偏底层。现代 Java 更推荐：
- 用
Future<?>+ExecutorService，靠future.isDone()或future.get(timeout, unit)统一管理生命周期 - 用
CountDownLatch或CyclicBarrier显式表达“等待 N 个任务完成”这类语义 - 避免直接操作
Thread对象，尤其在框架（如 Spring）或容器（如 Tomcat）中，线程由运行时管理，手动join()可能引发死锁或资源泄漏
原生 Thread 的 isAlive() 和 join() 是基础能力，但它们暴露的是线程状态细节，不是业务意图。用错一个，后续就容易补一堆轮询和 sleep 来掩盖问题。
