继承Thread类存在三大局限：单继承阻断业务类扩展、任务与执行体耦合违背职责分离、线程生命周期干扰业务逻辑；应优先使用Runnable/Callable配合线程池实现轻量级并发。
Java 中继承 Thread 类在实现轻量级线程时，表面看简单直接，实则存在几处关键局限，不是“写起来麻烦”的问题，而是架构层面的硬性约束和工程隐患。
单继承导致扩展能力归零
Java 只允许一个类继承一个父类。一旦你写 class Worker extends Thread，这个类就彻底失去了继承业务基类的机会——比如无法再继承 ServiceBase、Entity 或框架要求的 Activity / InitializingBean。这不是线程本身的限制，而是语言规则对整个类设计的刚性约束。
- 已有业务类已带父类？无法复用，只能复制逻辑或强行拆解
- 要用 Lombok 的
@Data或 JPA 的@Entity？这些注解通常依赖特定父类或接口契约，继承 Thread 后往往失效 - 团队统一使用线程池？
ExecutorService.submit()接收的是Runnable，不接受Thread子类实例
任务与执行体耦合，违背职责分离
继承 Thread，等于把“做什么”（业务逻辑）和“谁来跑、怎么跑”（线程生命周期管理）绑死在一个类里。这带来三个实际问题：
- 无法共享任务状态：每个
new MyThread()都是全新对象，想让多个线程操作同一份数据（如票池、计数器），只能靠静态变量，易出错且难测试 - 无法被 Spring 管理：Thread 子类通常无参构造、无法注入依赖，不能作为
@Component使用 - 与现代并发模型脱节：CompletableFuture、ForkJoinPool、Virtual Threads 全部围绕函数式接口或 Runnable/Callable 设计，不兼容继承式线程
线程生命周期干扰业务逻辑
Thread 的 start()、join()、interrupt() 等方法暴露了底层调度细节。当你在业务类中重写 run()，却还要手动处理中断响应、异常传播、资源释放，就会让核心逻辑被并发基础设施代码淹没。
立即学习“Java免费学习笔记（深入）”；
- 比如想在流程中暂停/恢复？Thread 没有状态机支持，只能靠自定义标志位 +
wait()/notify()，极易出错 - 异常未捕获会静默终止线程，而 Runnable 在线程池中可被统一异常处理器兜底
- 无法统一监控：每个 Thread 实例独立存活，没有统一入口做日志、指标、超时控制
轻量 ≠ 简单，更不等于继承 Thread
所谓“轻量级线程”，本质是减少资源开销、提升调度效率，而不是少写几行代码。真正轻量的做法是：
- 用
Runnable或Callable封装纯任务逻辑，无继承负担 - 交给
ThreadPoolExecutor或ForkJoinPool统一调度，复用线程资源 - 结合
CompletableFuture实现异步编排，避免阻塞和手动线程管理
继承 Thread 适合教学演示或极简脚本，但在任何需要维护、协作、集成的项目中，它都会成为第一个需要重构的瓶颈。
