Java线程创建方式决定任务逻辑与执行机制是否解耦：继承Thread强耦合、不利于扩展；Runnable实现任务组件化；Callable+Future支持结果与异常；统一交由线程池管理可提升模块化与可维护性。
Java 中线程创建方式直接影响代码的职责分离程度和可复用性，本质上是在决定“任务逻辑”与“执行机制”是否解耦。
继承 Thread 类：逻辑与执行强耦合
当类直接继承 Thread，它就既是任务定义者，又是线程载体。这会导致：
- 一个类只能继承一个父类，无法再继承其他业务基类；
- run() 方法不能抛出受检异常，限制了 I/O 或网络等典型场景的错误处理表达；
- 线程生命周期管理（如 start、interrupt）和业务逻辑混在同一类中，不利于单元测试和替换执行策略。
适合极简原型或教学示例，但不适用于需要扩展、维护或组合的模块化系统。
实现 Runnable 接口：任务即组件
Runnable 是纯粹的任务契约——只声明“我要做什么”，不关心“谁来跑、怎么跑”。这种分离带来明显模块化优势：
立即学习“Java免费学习笔记（深入）”；
- 任务类可自由继承业务父类、实现多个接口（如 Serializable、Comparable），专注领域逻辑；
- 同一任务实例可被多个线程复用，也可提交给线程池、定时器或 CompletableFuture，执行环境可插拔；
- 便于依赖注入——比如 Spring 中将 Runnable 作为 Bean 注入，由容器统一调度，天然支持配置化和 AOP 增强。
使用 Callable + Future：支持结果与异常的模块化任务
当任务需要返回值或明确传播异常时，Callable 比 Runnable 更契合模块设计原则：
- call() 方法允许抛出 Exception，使错误语义完整，避免包装 RuntimeException 的隐式成本；
- 返回 Future 可以延迟获取结果、设置超时、取消执行，这些控制能力可封装为服务层契约（如“异步查询订单状态”）；
- 配合 CompletableFuture，能自然组合多个异步任务（如 thenCompose、exceptionally），形成声明式、可读性强的业务流程链。
统一交由线程池管理：执行策略下沉，业务逻辑上浮
无论用 Runnable 还是 Callable，最终都应交给 ExecutorService 而非手动 new Thread().start()：
- 线程创建、复用、销毁由池统一管控，业务代码无需感知资源细节；
- 不同模块可使用不同命名线程池（如 ioPool、computePool），通过线程工厂打标，便于监控和问题定位；
- 模块间可通过统一的 Executor 接口协作，例如 A 模块提交任务，B 模块提供定制化拒绝策略或装饰器，实现松耦合集成。
