happens-before 规则仅保证线程终结后写操作对 join 的线程可见，不涉及任何资源回收；对象回收由 gc 根据可达性判断，threadlocal 需手动 remove，系统资源须显式关闭。
Java 中没有“线程终结规则 happens-before 怎么回收”这种说法——happens-before 是内存可见性规则，不是资源回收机制；线程终结本身不触发对象自动回收。它只保证：当线程 A 正常终止（如 run() 方法执行结束），那么该线程所有写操作对后续通过 threadA.join() 成功返回的线程 B 来说是可见的。
线程终结与 happens-before 的关系
Java 内存模型（JMM）定义了一条明确的 happens-before 规则：
- 如果线程 A 调用
threadB.join()并成功返回，则线程 B 的所有操作 happens-before 于 A 中 join() 返回后的任何操作。 - 这隐含了：线程 B 的终止动作（即 run() 执行完毕）建立了一个同步点，确保其写入的变量对 A 可见。
- 注意：该规则不涉及“回收”——它不释放堆内存、不关闭文件、不清理 ThreadLocal，也不调用 finalize() 或触发 GC。
真正负责“回收”的是哪些机制？
线程生命周期结束 ≠ 对象被回收。资源清理需显式或按约定处理：
- 堆对象回收：由垃圾收集器（GC）负责，条件是对象不可达。线程结束时，其栈帧销毁，局部变量引用消失；若这些变量曾持有堆对象引用，且无其他强引用，对应对象才可能被 GC 回收。
-
ThreadLocal 清理：线程退出时不会自动清除 ThreadLocalMap 中的 Entry。必须手动调用
remove()，否则可能导致内存泄漏（尤其在线程池中）。 - 系统资源释放：如打开的文件、Socket、数据库连接等，需在 finally 块或 try-with-resources 中显式关闭，不能依赖线程终结。
常见误区与正确做法
开发者容易误以为“线程死了，它用的东西就安全了”，这是危险的：
- ❌ 错误：在线程 run() 结尾不清理 ThreadLocal，指望“线程结束自动清空”。
- ✅ 正确：在 run() 末尾或使用 try-finally 调用
threadLocal.remove()。 - ❌ 错误：把大对象塞进局部变量，认为线程一结束 GC 就立刻回收。
- ✅ 正确：减少长生命周期引用；必要时置为 null（仅在极端引用延长场景下有微弱作用，通常非必需）。
- ❌ 错误：用
System.gc()强制回收——无效且有害。
总结一句话
happens-before 解决的是多线程间**读写可见性顺序问题**，和内存回收完全无关；线程终结只是让其栈空间释放、状态变为 TERMINATED，而对象是否被回收、资源是否被释放，取决于 GC 策略、引用可达性以及你是否写了正确的清理代码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
