应优先选择实现 runnable 接口而非继承 thread 类；因为 runnable 更符合任务解耦、可复用、可组合、单一职责原则，且规避 java 单继承限制，而继承 thread 仅适用于需定制线程生命周期行为的极少数场景。
Java 中继承 Thread 类和实现 Runnable 接口，本质区别不在“能不能跑”，而在“设计意图”和“扩展能力”。绝大多数场景下，应优先选择 Runnable；只有极少数明确需要重写线程生命周期行为时，才考虑继承 Thread。
Runnable 更适合任务逻辑解耦
当你关注的是“做什么”，而不是“怎么启动线程”，Runnable 是更自然的选择。它把任务（run 方法）和执行环境（线程、线程池、调度器）彻底分离。
- 可复用：同一个
Runnable实例能被多个线程或线程池重复执行 - 可组合：容易配合
ExecutorService、ForkJoinPool或异步框架（如 CompletableFuture）使用 - 符合单一职责：类只表达业务行为，不承担线程管理责任
- 避免单继承限制：Java 不支持多继承，若类已继承其他父类，就无法再继承
Thread
继承 Thread 仅在需定制线程自身行为时适用
继承 Thread 意味着你正在定义一种“特殊类型的线程”，而不仅是“一个要执行的任务”。这种需求极少，典型包括：
- 重写
start()实现自定义启动前检查（例如资源预分配、上下文初始化） - 重写
run()但需访问Thread的受保护字段（如threadLocals），且封装在子类中更合理 - 为调试/监控目的，覆盖
interrupt()或join()行为（注意：通常应避免）
注意：即使重写 run()，也建议优先通过组合方式（持有一个 Runnable）来实现，而非直接覆盖逻辑。
实际编码中的明显信号
遇到以下情况，基本可以判定该用 Runnable：
- 类名以
Task、Job、Worker结尾（如DataProcessorTask） - 构造器接收参数（数据库连接、配置对象等），说明它是有状态的业务单元
- 需要在测试中直接调用
run()而不启动新线程（Runnable支持，Thread子类调用run()易误触发start()逻辑） - 未来可能接入 Spring 的
@Async或 Quarkus 的@Blocking等声明式并发机制
现代 Java 已弱化 Thread 继承的必要性
从 Java 5 开始，Executor 框架成为标准；Java 8 引入 lambda 后，Runnable 可简写为 () -> { ... }；Loom 项目（虚拟线程）进一步让任务与线程解耦成为默认范式。继承 Thread 既无性能优势，也不利于可观测性和资源治理。
除非你在维护一段 2005 年前的遗留代码，否则几乎不需要写 class MyThread extends Thread。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
