线程执行完run()方法后不会立刻消失，而是先由jvm将状态设为terminated、清理threadlocal等资源并解绑native句柄，再通过系统调用（如pthread_exit）通知操作系统释放内核线程及物理资源，全过程分java层、jvm层、os层三级协同完成。
线程执行完 run() 方法后，并不会立刻“消失”，而是进入一个由 JVM 和操作系统协同完成的资源清理与注销流程。这个过程涉及 Java 层面的线程状态变迁、JVM 线程管理模块的回收动作，以及最终向内核发起系统调用释放内核线程（kernel thread）和相关资源。关键在于：JVM 不直接销毁内核线程，而是通知操作系统“该线程已终止”，由内核完成最终回收。
Java 层：run() 返回 → 状态切换 → 等待 JVM 清理
当 run() 方法正常返回（或抛出未捕获异常并结束），JVM 会立即将该线程对象的状态从 RUNNABLE 更新为 TERMINATED。此时 Java 线程对象仍存在于堆中，可被引用；但其关联的底层执行体（即 OS 线程）已停止调度。JVM 的线程管理器（如 HotSpot 中的 JavaThread）会标记该线程为“待回收”，但不会立即释放其 native 资源——因为内核线程的销毁必须通过系统调用，且需确保无残留上下文。
JVM 层：线程退出钩子触发 + native 资源解绑
在 run() 结束后，JVM 会执行线程退出逻辑：
- 调用
java.lang.Thread.exit()，清理线程局部变量（ThreadLocal）、释放锁持有记录、清空中断状态； - 通知 JVM 线程注册表（
Threads::remove()）移除该线程的 native 句柄（如pthread_t或 WindowsHANDLE）； - 调用
os::free_thread()（HotSpot）释放线程私有的栈内存（C++ heap 分配的线程栈）、TLS（Thread Local Storage）结构等 native 内存； - 但此时内核线程（kernel thread）尚未被销毁——它仍存在于内核的 task_struct 链表中，处于
EXIT_ZOMBIE或等待waitpid()-style 回收的状态（Linux 下类似进程退出机制）。
操作系统层：内核线程注销与资源回收
JVM 在线程退出最后阶段会主动触发系统调用，通知内核终结对应线程：
- 在 Linux 上，HotSpot 使用
pthread_exit()（而非pthread_cancel()）结束线程；该函数内部会调用exit()系统调用的变体，使内核将该任务的task_struct标记为EXIT_DEAD，并释放其内核栈、打开文件表项、信号处理结构、CPU 时间统计等； - 线程的用户态栈（JVM 分配的 Java stack）已在 JVM 层释放；内核栈（通常 8MB）由内核在
do_exit()流程中释放； - 若该线程创建过子线程或使用了
clone()特性，内核还会清理其线程组（thread group）关系； - 整个过程是异步的：JVM 发起退出后，内核在下一个调度周期或延迟清理链路中完成物理资源释放，不阻塞 JVM 主线程。
特别注意：守护线程与非守护线程在此过程中的差异
两者在退出链路上完全一致，区别仅在于 JVM 进程级生命周期判断：
- 非守护线程（user thread）的存在会阻止 JVM 退出；一旦所有非守护线程终止，JVM 才启动全局 shutdown hook 并最终调用
exit(0)； - 守护线程（daemon thread）不影响 JVM 存活，但其
run()结束后的资源回收流程与非守护线程完全相同——该线程的内核资源仍会被完整注销； - 不存在“守护线程不释放内核资源”的情况；任何线程退出，只要正确执行了
pthread_exit()或等效路径，内核都会回收其资源。
理解这条链路的关键，是分清三层职责：Java 层管逻辑生命周期，JVM 层管 native 资源解绑与线程元信息注销，操作系统层管底层执行实体与物理资源释放。三者通过明确定义的接口协作，缺一不可。
