大厂开发规范推荐Runnable/Callable而非继承Thread，因其避免单继承限制、支持线程池调度、实现任务与执行解耦，并符合Java并发演进方向。

大厂开发规范不反对继承 thread 类本身，但明确限制其使用场景——核心原因是它会破坏类的继承结构、削弱扩展性，并违背面向对象设计原则。真正被推荐和强制要求的是基于 runnable 或 callable 的线程任务建模方式。

单继承机制带来硬性约束

Java 只允许一个类继承一个父类。如果业务类已经 extends 了某个框架类（比如 Spring 的 ApplicationRunner、Android 的 Activity、或自定义的领域基类），就无法再继承 Thread。

• 编译器会直接报错：“Cannot inherit from final Thread”（实际是 “already has a superclass”）
• 强行重构继承链会导致代码耦合加深、可测试性下降
• 而 implements Runnable 不占用继承名额，一个类可同时实现多个接口

任务逻辑与线程控制必须分离

继承 Thread 把“做什么”（run()）和“谁来执行”（线程生命周期管理）混在一起，造成职责不清。

• 每个 Thread 子类实例都绑定一个专属线程，无法复用；而 Runnable 实例可被多个 Thread 或线程池反复提交
• 线程池（ThreadPoolExecutor）只接受 Runnable / Callable，无法直接调度继承 Thread 的对象
• 调试和监控时，线程名、上下文、堆栈更难统一管理——因为线程身份由 Thread 子类决定，而非外部可控

不符合现代并发编程演进方向

从 Java 5 开始，官方推荐的并发模型就是“任务抽象 + 执行器解耦”。大厂规范正是基于这一演进做出的约束。

• ExecutorService、ForkJoinPool、CompletableFuture 全部围绕函数式任务接口设计
• 继承 Thread 无法天然支持超时控制、结果返回（Future）、异常传播等能力，需额外封装
• 在响应式编程（如 Project Reactor）或协程（Loom）背景下，继承线程类更显过时且难以迁移

实际编码中更容易踩坑

表面看只是写法差异，但继承 Thread 带来隐性成本远高于预期。

• 误调用 start() 多次导致 IllegalThreadStateException
• 混淆 run() 和 start()，直接调用 run() 导致同步串行执行
• 子类重写 run() 时忘记调用 super.run()（虽无实际作用，但易引发理解偏差）
• 无法使用注解（如 @Async）、AOP 增强等 Spring 并发基础设施