推荐实现runnable接口而非继承thread类，因后者违反单一职责、不支持多重继承、无法复用任务逻辑、易引发线程安全问题，而runnable解耦执行逻辑与环境，支持线程池、lambda及多接口实现。
Java 中继承 Thread 类会让线程控制逻辑和业务逻辑强行绑在一起，本质上是把“谁来执行”和“执行什么”混为一谈，导致对象职责不清、复用困难、扩展受限。
线程与任务无法分离
继承 Thread 的类既是线程载体，又是任务容器。每次 new MyThread() 都创建一个全新线程实例，哪怕业务逻辑完全相同，也无法共享任务代码。而 Runnable 方式下，同一个 task 对象可被多个 Thread 复用，任务逻辑独立存在、清晰可测。
- Thread 子类一旦启动，就进入生命周期管理（NEW → RUNNABLE → TERMINATED），无法再次 start
- 若需重复执行相同逻辑，必须反复 new 新对象，浪费资源且状态难统一
- run() 方法里若含初始化或共享变量操作，多个实例会各自维护一份副本，造成数据不一致
破坏类的继承体系
Java 是单继承语言，继承 Thread 意味着放弃继承其他父类的机会。比如一个业务服务类本该继承 BaseService 或 Entity，却因要开线程被迫改成继承 Thread，结果只能把服务逻辑硬塞进 run()，或者用组合绕过——反而增加复杂度。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 无法同时继承框架基类（如 Spring 的 InitializingBean）和 Thread
- 后续想添加 AOP、事务、依赖注入等功能时，因继承链已固定，改造成本高
- 测试时难以 mock 线程行为，因为线程生命周期与业务逻辑耦合在同一个类中
隐含线程安全陷阱
很多人误以为“写个 static 实例 + 继承 Thread”就能实现单例线程，但实际每次 new 都产生新对象，static 字段若未同步初始化，可能被多个线程并发赋值；run() 中的懒加载逻辑也容易被多次触发。
- Thread 子类本身不是“可共享资源”，而是“执行体”，天然不具备线程安全语义
- 若在构造器里启动线程（new MyThread().start()），对象可能尚未初始化完成就被执行
- 共享字段未加锁或未用 volatile，多实例并发读写会导致不可预测结果
替代方案更轻量可控
用 Runnable 或 Callable 接口定义任务，再交由 Thread、ExecutorService 或 CompletableFuture 执行，能自然解耦。任务对象可序列化、可缓存、可单元测试，线程调度由专门组件负责。
- Runnable 实现类可同时继承任意父类，也可实现多个接口（如 Serializable + Validatable）
- ExecutorService 复用线程池，避免频繁创建销毁线程，支持定时、周期、批量提交
- Callable + Future 支持带返回值和异常传播，比纯 Thread 更适合真实业务场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
