不推荐继承thread类，因其耦合任务逻辑与线程生命周期、受单继承限制、无法接入线程池调度体系、实例不可复用、职责混杂导致调试困难。
Java 中继承 Thread 类在高并发场景下不推荐使用，核心在于它与高并发工程实践存在根本性冲突：它把任务逻辑、线程生命周期、资源调度全部耦合在一个类里，既难复用、难管理，也难扩展。
单继承限制导致架构僵化
Java 只允许一个父类。一旦业务类已继承框架基类（如 Spring 的 InitializingBean、Android 的 Fragment、或自定义的领域模型基类），就无法再 extends Thread。强行调整继承链会破坏原有设计，增加维护成本。而 Runnable 或 Callable 是接口，可自由组合，不影响已有继承结构。
无法接入现代线程调度体系
高并发系统依赖线程池统一管控资源，但 ThreadPoolExecutor、ForkJoinPool、CompletableFuture 等全部只接受 Runnable 或 Callable 任务。继承 Thread 的对象无法直接提交给线程池，必须额外包装，徒增冗余代码和出错风险。更关键的是，它天然不支持超时控制、结果返回（Future）、异常统一捕获等高并发必备能力。
实例不可复用，资源浪费严重
每个 Thread 子类实例绑定一次执行，启动后进入 TERMINATED 状态，再次调用 start() 必抛 IllegalThreadStateException。高并发场景下频繁创建/销毁线程对象，不仅 GC 压力大，还绕过了线程复用机制。相比之下，同一个 Runnable 实例可被线程池反复调度，资源利用率高、响应更快。
职责混杂，调试与监控困难
继承 Thread 会让“做什么”和“谁来执行”混在一起。线程名、上下文、堆栈信息由子类决定，外部难以统一注入或修改；也无法配合 @Async、AOP 增强、分布式追踪等基础设施。当出现性能瓶颈或死锁时，定位问题的成本显著升高。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
