继承Thread类与线程池本质不同：前者创建独占、不可复用的单次线程，后者调度可重复执行的Runnable/Callable任务；混用会导致资源失控、生命周期错位及状态混乱。
继承 Thread 类和线程池管理本质上是两种不同层级的线程使用范式，直接混用不仅失去线程池的设计价值，还会引发资源失控、状态混乱和生命周期错位等问题。
Thread 子类无法被线程池复用
线程池（如 ThreadPoolExecutor）管理的是“可重复执行的任务”，其底层调度依赖 Runnable 或 Callable 接口。而继承 Thread 的子类本身是一个“已绑定具体线程实例”的对象，启动后即进入 JVM 线程生命周期，无法被池化回收或再次提交：
- 调用
thread.start()后，该Thread实例只能运行一次，isAlive()变为false后不可重启；线程池要求任务对象能多次提交、反复执行 - 若强行将
MyThread实例传给executor.execute(new MyThread())，实际执行的是其run()方法体，但此时它已脱离自身线程上下文——变成在池中某个工作线程里“伪同步调用”，丢失了原设计意图（如自定义线程名、优先级、异常处理器等） - 更严重的是：每个
new MyThread()都会新建一个 JVM 线程，绕过线程池管控，导致线程数失控、OOM 风险上升
状态与资源管理冲突明显
Thread 类封装了完整的线程生命周期（NEW → RUNNABLE → TERMINATED），而线程池期望任务只负责“计算逻辑”，不干预线程创建、销毁、中断等底层行为：
- 子类中若重写
start()或覆盖interrupt()，可能干扰线程池的中断策略（如shutdownNow()依赖标准中断机制） - 若在
run()中调用join()、sleep()或操作线程组（getThreadGroup()），会在池线程中产生非预期阻塞或安全限制（尤其 JDK 9+ 模块系统下） - 常见误写：在
MyThread.run()里又调用new Thread(...).start()，形成“线程套线程”，彻底脱离池管理
替代方案：解耦任务与执行载体
真正兼容线程池的做法，是把业务逻辑从 Thread 继承中剥离出来，转为纯任务单元：
立即学习“Java免费学习笔记（深入）”；
- 将原
MyThread的run()内容提取为独立Runnable或Callable实现类，或直接用 Lambda 表达式 - 需要线程级配置（如名称、优先级、上下文类加载器）时，可通过
ThreadFactory统一注入，而非在每个任务里硬编码 - 若必须保留“线程专属初始化逻辑”，可用
ThreadLocal在任务首次执行时初始化，或通过beforeExecute()/afterExecute()钩子方法统一处理 - 对需返回结果的任务，优先选用
Callable<t></t>+Future，避免自行维护线程间通信机制
何时仍可考虑继承 Thread？
仅限极少数场景：需要精确控制单个长期存活线程的整个生命周期，且不与其他任务共享资源或调度策略，例如：
- 守护型后台线程（如定时心跳、日志刷盘），明确不纳入统一调度体系
- 嵌入式或低延迟场景中，为规避线程池调度开销，手动管理极少量专用线程
- 与 native 层深度耦合的线程（如 JNI 回调线程），需严格匹配 JVM 线程模型
即便如此，也建议配合 ExecutorService 封装启动逻辑，避免裸调 start()。
