实现Runnable接口更优，因其避免单继承限制、解耦任务与线程、支持依赖注入和线程池，便于测试、扩展及迁移至虚拟线程。
线程创建方式直接影响类的设计自由度、职责划分清晰度和系统扩展能力。选错方式，轻则导致后续无法继承关键父类，重则让业务逻辑与线程调度强耦合，增加维护成本。
继承 Thread 类会锁死类的继承路径
Java 是单继承语言，一旦让业务类 extends Thread，它就再也不能继承其他有意义的基类（比如 Spring 的 ApplicationRunner、框架提供的模板类或领域模型父类）。例如：
- 你写了一个订单处理类
OrderProcessor extends Thread，后期想让它也具备 Spring Boot 启动时自动执行的能力，就得放弃继承或改用组合，徒增重构负担； - 所有线程逻辑都挤在
run()方法里，无法复用已有工具类或注入依赖，测试时只能启动真实线程，难以 mock 和隔离验证。
实现 Runnable 或 Callable 才真正解耦职责
把任务逻辑封装进 Runnable 或 Callable，意味着“做什么”和“由谁执行”彻底分离：
- 一个
PaymentTask implements Runnable可以被丢进线程池、被单元测试直接调用、被 CompletableFuture 异步包装，甚至未来迁移到虚拟线程也不需改动； - 类本身可以自由继承任意父类、实现多个接口，还能通过构造器或 setter 注入服务、配置、监控组件，符合依赖倒置原则；
- 配合 Lambda 使用时，一行代码就能定义轻量任务，避免为简单逻辑新建类文件，架构更轻盈。
用 Executor 框架才能支撑可演进的并发治理
直接 new Thread().start() 看似简单，但会让线程生命周期脱离管控：
立即学习“Java免费学习笔记（深入）”；
- 无法限制并发数，突发流量可能瞬间创建上千线程，耗尽栈内存或触发 OOM；
- 没有统一的拒绝策略、队列监控、活跃线程统计，出问题时定位困难；
- 当业务从单机走向分布式、从同步走向响应式，Executor 抽象层能平滑对接
CompletableFuture、VirtualThread或自定义调度器，而裸 Thread 几乎无法升级。
虚拟线程进一步放大设计选择的重要性
Java 21 虚拟线程虽降低创建成本，但不改变底层契约：
-
Thread.ofVirtual().start(runnable)仍要求传入Runnable，说明官方仍在强化“任务即对象”的范式； - 若原有代码大量使用继承 Thread，迁移到虚拟线程时仍需重写任务结构，无法直接受益；
- 真正发挥虚拟线程高吞吐优势的，是那些已将 IO 密集型任务拆成小颗粒
Runnable并交由ExecutorService统一调度的系统。
