继承线程基类：最直观的起点与耦合的代价

Java线程编程的最初范式，是让自定义类直接继承语言标准库中提供的线程基类。这种方式在概念上最为直观：一个线程就是一个具有独立执行路径的对象，通过创建该对象的实例并启动其执行，即实现并发。从实现角度看，开发者需要重写基类中定义的一个无参数返回的关键方法，该方法的方法体将成为新线程独立执行的代码逻辑。启动线程时，调用从基类继承而来的启动方法，虚拟机底层会创建一个真正的操作系统线程，并安排其执行被重写的那个方法。

这种方法的设计初衷是提供一种简单、直接的线程建模。它将“线程”这一执行实体本身作为了继承与扩展的对象，符合面向对象中“是一个”的思维。在早期或教学示例中，它清晰演示了线程的诞生与执行。然而，其核心缺陷在于严重的继承耦合。由于Java是单继承语言，一旦自定义类继承了线程基类，便无法再继承其他任何业务相关的父类，这极大地限制了类的设计灵活性。更本质的问题是，它混淆了“任务”与“执行机制”的边界。任务是指需要异步执行的具体工作逻辑，而执行机制是指如何调度、运行这个任务（如通过线程、线程池或其它异步框架）。继承线程基类的方式将任务定义牢牢绑定在了特定的线程执行模型上，使得任务逻辑难以被其他执行机制（如线程池）复用，违反了关注点分离原则。

因此，在当今的工程实践中，直接继承线程基类的方式已很少被推荐用于实现业务逻辑。它通常仅出现在一些需要深度定制线程行为本身（如重写某些线程生命周期管理方法）的极特殊场景。其历史价值在于定义了线程操作的基本接口，但其设计上的局限性促使了更优方案的诞生。理解这种方法，有助于我们认识到并发编程中一个关键的优化方向：将异步执行的任务单元，从具体的执行载体中解耦出来。

实现可运行接口：解耦任务与执行的经典范式

为了克服继承方式带来的耦合问题，Java引入了“可运行接口”。这是一种标志性接口，其核心在于定义了一个无参数、无返回值的执行方法。任何实现了此接口的类，都必须提供该方法的具体实现，而这个实现体就代表了需要异步执行的任务内容。创建线程时，需要将一个实现了此接口的对象实例，作为构造参数传递给线程基类的构造函数。随后，启动这个新建的线程对象，线程便会执行传入的那个可运行对象中定义的方法。

这种方式的革命性进步在于实现了“任务”与“执行线程”的分离。任务被封装在一个独立的、实现了特定接口的对象中，这个任务对象本身并不具备线程的能力，它仅仅是一个包含了执行逻辑的普通对象。线程则作为一个通用的、来自标准库的“执行器”，负责承载并运行这个任务对象。这种解耦带来了巨大的灵活性：同一个任务对象可以被传递给不同的线程实例执行，也可以被提交给线程池、定时任务执行器等更高级的执行框架。它使得任务逻辑成为了可复用的组件，不再依赖于某一种特定的创建线程的方式。

实现可运行接口成为了业界公认的、创建线程任务的首选标准做法。其优势显而易见：它避免了单继承的限制，使任务类可以自由地继承其他业务类；它符合面向接口编程的原则，提高了代码的抽象层次和可测试性（因为任务逻辑可以独立于线程被测试）。然而，它并非完美。其定义的方法签名决定了任务无法直接返回计算结果，也无法抛出被调用方检查的异常。任务的执行结果或异常通常需要通过共享变量、回调函数等额外机制传递给主线程，这增加了程序设计的复杂度。此外，对任务执行状态（如取消、进度）的控制也缺乏内置支持。尽管存在这些限制，由于其出色的解耦特性，实现可运行接口至今仍是构建大多数异步任务的基石，也是理解后续更高级并发组件的基础。

利用可调用接口与未来结果：获取结果的异步计算

为了克服可运行接口无法返回结果的短板，并在并发编程中引入更强大的管理能力，Java在后续版本中引入了“可调用接口”与“未来结果”这一组合范式。可调用接口也是一个函数式接口，但其定义的方法可以返回一个泛型结果，并且可以抛出受检异常。这使得封装的任务不仅能够执行计算，还能明确地告知外部一个计算结果，或者声明执行过程中可能发生的故障。

然而，可调用接口对象并不能像可运行对象那样直接传递给一个线程基类来运行。它需要与一个“执行器服务”框架协同工作。开发者将一个可调用任务提交给执行器服务，执行器服务会异步地调度执行这个任务，并立即返回一个“未来结果”对象。这个未来结果对象充当了异步计算的句柄：主线程可以继续执行其他工作，在未来的某个时刻，当需要任务的结果时，可以调用未来结果的获取方法。如果此时任务已完成，则立即得到结果；如果尚未完成，调用线程可以选择阻塞等待，也可以设置超时，或者先检查是否完成。未来结果还提供了取消任务执行、查询任务是否完成或已取消等方法，实现了对异步任务生命周期的管理。

这种范式的核心价值在于将异步计算“对象化”和“可管理化”。它将一次异步操作封装为一个具有明确输入、输出和状态的对象，并通过未来结果提供了获取输出、感知状态、施加控制的统一接口。这极大地简化了需要处理并发计算结果的编程模型，避免了手动使用共享变量和等待通知机制带来的复杂性与错误。它自然地集成了异常处理机制，任务中抛出的异常会被捕获并包装在未来结果中，当主线程获取结果时，异常会被重新抛出，从而保持了同步编程中的异常传播逻辑。

可调用与未来结果的组合，代表了更高阶的并发抽象。它不再仅仅关注如何启动一个线程，而是关注如何描述一个异步计算单元，并如何与之进行安全、可控的交互。它是构建复杂并发工作流、实现异步响应式编程的重要基础。当然，其使用通常需要依赖线程池等执行器服务，引入了比前两种方式更复杂的框架概念，但对于绝大多数需要处理返回结果或异常的现代并发场景，这已被证明是最佳实践。

综合对比与演进视野

从继承线程、实现可运行接口到使用可调用与未来结果，这三种方法清晰地勾勒出Java并发编程抽象层次的演进路径：从与执行机制紧耦合，到任务与执行解耦，再到对异步计算本身进行建模与管理。

在设计哲学上，三者迥异。继承线程是“线程即任务”，注重对执行实体本身的扩展。实现可运行接口是“任务交付给线程”，注重任务的独立性与可复用性。可调用与未来结果则是“计算作为服务”，注重对异步操作生命周期的全面控制与结果的契约化交付。在能力维度上，可调用接口弥补了可运行接口无法返回结果和抛出受检异常的缺陷，而未来结果则增加了状态查询、取消、超时等待等管理能力。在复杂度与灵活性上，继承线程最简单但最不灵活；实现可运行接口在灵活性与复杂度上取得良好平衡，是通用之选；可调用与未来结果功能最强大，但需要理解更广泛的执行框架，复杂度最高。

从历史演进的视角看，实现可运行接口是对继承线程方式的扬弃，确立了任务解耦的核心范式。可调用与未来结果则是在此范式上的深化和增强，服务于更复杂的异步编程需求。在现代Java开发中，直接继承线程基类创建业务线程已被视为反模式；实现可运行接口是定义无返回结果异步任务的标准方式；而需要处理计算结果、异常或需要任务控制时，可调用接口与未来结果（或其增强版本）是毋庸置疑的选择。随着并行流、响应式编程等更高层抽象的发展，底层线程的创建越来越被框架所隐藏，但对这三种基础模式的理解，仍然是有效使用这些高级抽象、诊断深层并发问题的基石。它们共同构成了Java开发者应对并发挑战的、层次分明的工具箱。