Java线程创建的两种基础方式是继承Thread类和实现Runnable接口，前者受限于单继承且耦合任务与线程，后者支持任务与执行者分离、适配线程池、Lambda及现代框架设计哲学。
Java 中线程创建的两种基础方式——继承 Thread 类与实现 Runnable 接口——在框架底层设计中并非仅是语法选择，而是直接影响资源建模、扩展性边界和并发治理逻辑。主流框架（如 Spring、Netty、Tomcat）几乎全部基于 Runnable（或其衍生接口如 Callable）构建线程抽象，根本原因在于它契合现代框架对“任务”与“执行者”分离的设计哲学。
任务解耦：框架统一调度模型的基础
框架需要统一管理成百上千的任务，但不希望每个任务都绑定一个专属线程对象。实现 Runnable 使任务逻辑独立于线程生命周期：
- 一个 Runnable 实例可被多个线程反复执行（如 Tomcat 的 SocketProcessor 复用处理不同请求）；
- Spring 的 @Async 方法最终被包装为 Runnable 提交到线程池，而非生成新 Thread 子类；
- Netty 的 EventLoop 本质是单线程轮询器，它不断从任务队列取出 Runnable 执行，而非启动新线程。
避免单继承瓶颈：框架可扩展性的硬性约束
Java 不支持多继承，而框架组件往往已有明确父类（如 Spring Bean 继承自 InitializingBean，Netty 的 ChannelHandler 是抽象类）。若强制要求继承 Thread，则无法再继承其他关键基类：
- Spring 的定时任务类不能同时继承 Thread 和 ApplicationRunner；
- 用户自定义的业务处理器若需接入框架生命周期管理，就必须放弃继承 Thread；
- 所有现代框架都提供回调式扩展点（如 SmartLifecycle、ChannelInboundHandler），它们天然与 Runnable 兼容。
线程池集成：底层资源复用的必然路径
真实生产环境极少使用裸 new Thread().start()，而是通过 ExecutorService 管理线程。而线程池的 submit() 方法签名只接受 Runnable 或 Callable：
立即学习“Java免费学习笔记（深入）”；
- ThreadPoolExecutor 构造时传入的是 BlockingQueue<Runnable>，不是 Thread 队列；
- 框架内部（如 Dubbo 的 IO 线程池、RocketMQ 的消费者线程池）均以 Runnable 为最小调度单元，便于做优先级控制、拒绝策略、监控埋点；
- 继承 Thread 的方式无法直接注入线程池，必须额外包装一层，徒增间接层和内存开销。
Lambda 与函数式支持：现代框架的默认契约
JDK 8 引入 Lambda 后，Runnable 成为最轻量的函数式接口（仅一个抽象方法），天然适配函数式编程范式：
- Spring WebFlux 的异步处理链路大量使用 () -> {...} 作为 Runnable 实现；
- Vert.x 的事件循环中，所有 Handler 都是函数式接口，底层统一转为 Runnable 提交；
- 框架注解（如 @Scheduled）解析后生成的调度任务，最终也是 Runnable 实例，而非 Thread 子类。
