Java 中哪些核心类运用了经典设计模式

在 Java 开发中，设计模式并不是只存在于面试题或框架源码里的抽象概念。JDK 自身的很多核心类库，正是因为合理地运用了设计模式，才能够在二十多年间保持较强的兼容性、扩展性和可维护性。理解这些类背后的设计思想，不仅有助于阅读标准库源码，也能帮助开发者在业务系统中做出更合理的结构设计。

本文将以 Java 标准库中的集合容器、IO 流、并发工具和事件机制等场景为例，分析其中较为典型的几种设计模式，并说明它们解决了什么具体问题。

一、装饰者模式：在不修改原类的前提下增强能力

装饰者模式的核心思想是：在不改变原有对象接口的前提下，为对象动态附加新的职责。它通常通过包装原始对象，并在包装类中增加额外行为来实现。

Java 集合框架中有一个很典型的问题：某些场景下，调用方不希望一个 List 被后续代码修改，或者在插入元素时希望对类型进行校验。如果直接修改 ArrayList 或在每个业务位置重复编写校验逻辑，会导致代码分散且容易遗漏。此时，更合理的做法是包装原始容器。

Collections 工具类提供了多个静态方法，例如 unmodifiableList、checkedList、synchronizedList 等。它们返回的并不是全新的容器实现，而是基于原始 List 的包装对象。以 unmodifiableList 为例，它返回一个 UnmodifiableList，该包装类仍然实现 List 接口，但所有可能修改集合的方法都会抛出 UnsupportedOperationException。

这种设计对调用方完全透明。调用方仍然按照 List 接口使用容器，但容器已经被附加了“只读”约束。更复杂的情况下，还可以将多个包装器叠加，例如先包装为线程安全容器，再包装为只读容器。每增加一层包装，就增加一层能力，而不需要修改原有集合类的实现。

类似思想还广泛存在于 IO 体系中。InputStream、OutputStream、Reader、Writer 等基础类型定义了最核心的数据读取与写出能力，而 BufferedInputStream、DataInputStream、ObjectInputStream 等类则通过持有底层流对象，在原有能力之上增加缓冲、基本类型读取或对象反序列化功能。使用方可以通过组合不同装饰器来获得不同行为，而不必创建数量庞大的子类组合。

装饰者模式的优点是职责可以动态组合，但它也会增加类的数量和调试时的调用层级。因此，JDK 通常只在基础抽象足够稳定、需要频繁组合能力的场景中使用该模式。

二、适配器模式：统一新旧接口差异

适配器模式用于将一个接口转换成调用方期望的另一个接口，从而使原本因接口不匹配而无法协作的类能够一起工作。

在 Java 并发体系的发展过程中，早期版本只有 Thread 和 Runnable。Runnable 的 run 方法没有返回值，线程执行结束后无法直接向主线程返回结果。随着异步任务需求增加，JDK 后续引入了 Callable 接口。Callable 与 Runnable 都用于描述可执行任务，但前者允许返回结果并抛出受检异常。

问题随之而来：线程池需要同时支持用户提交 Runnable 和 Callable，但内部调度逻辑又希望使用统一的任务抽象。如果分别处理两种接口，就会在调度、执行、结果缓存和异常传播等环节产生重复代码。

JDK 内部采用了适配器模式，将 Runnable 和 Callable 统一抽象为 Callable。具体做法是，当线程池接收到 Runnable 时，会通过适配器将其转换为 Callable。这个适配器内部持有原始 Runnable 对象，并实现 Callable 接口。在 call 方法中，它调用 Runnable.run，然后返回预先传入的结果值，如果调用方没有指定结果值，则返回 null。

这样一来，线程池核心路径只需要面向 Callable 编程。无论用户最初提交的是哪一种任务类型，底层最终都形成一个统一的 Callable 对象。接下来，线程池可以继续将该对象封装到支持异步结果获取的结构中，例如 FutureTask。

FutureTask 本身也可以看作另一种适配与桥接的结果。它实现 RunnableFuture 接口，而该接口同时继承了 Runnable 与 Future。这意味着 FutureTask 既可以作为任务交给线程执行，又可以从外部通过 Future 接口获取执行状态和结果。这种设计让“任务执行”和“结果查询”两个关注点被清晰地分离开来。

适配器模式在这里解决的不仅是方法签名不一致的问题，更重要的是让旧接口可以在不破坏已有代码的前提下融入新体系。对于大量历史代码而言，这种渐进式演进能力非常关键。

三、模板方法模式：固定流程与延迟实现分离

模板方法模式在 JDK 中同样非常常见。它通常表现为：父类定义一个稳定的算法骨架，将其中部分步骤留给子类实现。这样可以保证整体流程一致，同时允许子类定制关键行为。

InputStream 和 OutputStream 的多个抽象与具体方法之间就体现了这种思想。例如 InputStream 中定义了 read() 与 read(byte[], int, int)。其中批量读取方法内部可以基于单字节读取构建，而具体子类往往只需要实现单字节读取逻辑。父类已经规定了批处理、读取长度校验和循环控制等通用流程，子类只需关注最核心的数据来源。

在集合框架中，AbstractList、AbstractSet、AbstractMap 等抽象类也是模板方法模式的典型体现。例如 AbstractList 为 List 接口提供了大量默认实现，包括迭代器遍历、索引访问、子列表视图等通用逻辑，而子类通常只需要实现 get、size 等少数核心方法。这样开发者在实现自定义集合时，不必从零开始实现全部接口方法。

在多线程同步工具中，AbstractQueuedSynchronizer 是模板方法模式的高级应用。它内部维护等待队列、节点唤醒、状态传播等复杂逻辑，而子类只需要重写少量方法来表示对同步状态的获取与释放规则。父类负责“如何排队、如何唤醒、如何检查中断”等通用机制，子类负责“什么条件下可以获得资源、什么情况下释放资源”等具体策略。

模板方法模式最大的价值在于降低扩展成本。它将可变部分与不可变部分分离，使框架作者可以控制整体执行流程，同时保留足够的定制空间。

四、观察者模式：事件驱动的基础结构

观察者模式用于定义对象之间的一对多依赖关系。当一个对象状态发生变化时，所有依赖它的对象都会被自动通知。JDK 早期直接在标准库中提供了 Observer 接口与 Observable 类，用于支持这种模式。虽然在现代 Java 版本中，这套 API 的重要性已经下降，但它所代表的事件通知思想被大量 GUI 事件处理、异步回调与消息驱动设计中沿用。

事件监听机制本质上也是观察者模式的一种演化形式。组件或服务作为被观察者，在发生特定行为时向已注册的监听器广播事件。监听器接口通常由框架定义，调用方根据业务需要实现并注册。这种设计使得事件生产者不必关心具体有哪些消费者，也不会因为后续新增消费者而频繁修改自身代码。

观察者模式提升了模块之间的解耦程度，但也带来了一些需要注意的问题，例如事件回调链路过长、通知顺序不稳定、监听器造成对象无法及时回收等。因此，JDK 在早期提供基础实现之后，实际业务框架往往会结合弱引用、事件总线或响应式流等方式进一步优化。

五、策略模式：行为与使用方解耦

策略模式允许在运行时选择算法或行为，而不需要在使用方代码中写入大量条件分支。JDK 中比较典型的是 Comparator 与 Comparable。

Comparable 将比较逻辑内聚在对象自身，适用于对象具有天然默认排序规则的情况。Comparator 则把比较策略外部化，允许调用方根据不同维度动态选择排序规则。例如同一个对象既可以按照创建时间排序，也可以按照名称字典序排序。排序方法只需要依赖 Comparator 接口，而不需要关心具体比较规则。

这种设计非常适合参数化行为。现代 Java 中大量使用函数式接口，本质上也延续了策略模式的思想。将策略封装为接口或 lambda，可以显著减少重复条件判断和子类数量。

六、如何在实际开发中应用这些思路

理解 JDK 中的设计模式，并不意味着要在业务中刻意套用模式。更实用的方式是，当遇到以下问题时，回想标准库的解决思路：

当需要在避免修改既有类的前提下增加能力时，可以考虑包装对象，而不是直接扩展继承体系。

当存在两个或多个功能相似但接口不同的组件时，可以通过适配层统一处理，而不是在不同分支中重复编写兼容代码。

当多个实现遵循相同流程，仅部分步骤不同时，可以提取模板类，把公共流程上移。

当业务状态变化需要通知多个模块时，可以设计轻量级事件监听机制，避免直接调用造成强耦合。

当同一行为存在多种规则时，可以将规则抽象为接口，通过组合实现灵活替换。

Java 标准库之所以能够长期演进，很大程度上得益于这些设计模式带来的低耦合与高扩展性。理解这些核心类背后的结构选择，不仅有助于更好地使用标准 API，也能在业务开发中减少过度设计，同时在合适的场景做出恰当的抽象。