在 Java 程序中，我们经常需要根据对象的实际类型执行不同逻辑：先通过 instanceof 检查类型，再强制转型，最后使用转型后的变量。这种“检查-转型-使用”的惯用代码不仅冗长，还容易出错——类型名重复出现三次，一旦某个分支忘记转型或转型错误，编译器无法察觉。更麻烦的是，当需要处理多种类型时，一连串的 if-else 不仅可读性差，还可能因遗漏分支而导致运行时错误。
Java 16 引入的 instanceof 模式匹配（JEP 394）初步解决了这一问题，而 Java 21 最终确定的 switch 模式匹配（JEP 441）则进一步将这种能力扩展到多分支选择结构，并与密封类（sealed classes）结合，实现了编译期可检查的穷举性（exhaustiveness）。这些特性共同推动了 Java 中“数据导向编程”（Data-Oriented Programming）的风格，让代码更安全、更清晰。
本文将以一个订单处理服务为贯穿场景：系统接收到不同类型的订单对象（如普通订单、促销订单、退款订单），需要根据订单类型提取不同字段并执行相应业务逻辑。我们将从传统写法出发，逐步引入模式匹配，展示其如何消除样板代码、增强类型安全，并探讨工程实践中的权衡与边界。
传统写法的痛点：强制转型与 if-else 链
假设订单类型定义如下（使用密封接口）：
public sealed interface Order permits RegularOrder, PromoOrder, RefundOrder {
String orderId();
}
public record RegularOrder(String orderId, BigDecimal amount) implements Order {}
public record PromoOrder(String orderId, BigDecimal amount, String promoCode) implements Order {}
public record RefundOrder(String orderId, BigDecimal amount, String reason) implements Order {}在 Java 16 之前，处理这些订单的典型写法是：
public String processOrder(Order order) {
if (order instanceof RegularOrder) {
RegularOrder ro = (RegularOrder) order;
return "Regular: " + ro.amount();
} else if (order instanceof PromoOrder) {
PromoOrder po = (PromoOrder) order;
return "Promo: " + po.promoCode() + " amount " + po.amount();
} else if (order instanceof RefundOrder) {
RefundOrder ro = (RefundOrder) order;
return "Refund: " + ro.reason();
} else {
throw new IllegalStateException("Unknown order type");
}
}这段代码存在几个问题：
- 重复的类型名：每个分支中，类型名
RegularOrder、PromoOrder、RefundOrder都出现了三次（instanceof检查、变量声明、强制转型）。 - 强制转型容易出错：如果
instanceof检查的类型与转型的类型不一致，编译器不会报错，但运行时会抛出ClassCastException。例如，误将PromoOrder转型为RegularOrder。 - 缺乏穷举性检查：如果后续新增了
GiftOrder类型，但忘记在if-else链中添加分支，代码仍能编译通过，但会在运行时落入else分支抛出异常。编译器无法帮助我们保证所有子类型都被处理。 - 性能可能不佳：
if-else链的时间复杂度为 O(n)，虽然在实际业务中分支数通常不多，但编译器无法将其优化为更高效的表跳转。
这些问题的根源在于：类型检查和类型转换是分离的，且控制流结构（if-else）不感知类型的封闭性。Java 的模式匹配正是为了解决这些痛点而设计。
instanceof 模式匹配：简化类型检查与转型
Java 16 通过 JEP 394 将模式匹配引入 instanceof 操作符。所谓模式（pattern），包含一个谓词（测试目标是否匹配）和一组模式变量（匹配成功后从目标中提取的变量）。类型模式 String s 就是一个最简单的模式：谓词是“目标是否为 String 的实例”，模式变量是 s。
使用类型模式，上面的订单处理可以改写为：
public String processOrder(Order order) {
if (order instanceof RegularOrder ro) {
return "Regular: " + ro.amount();
} else if (order instanceof PromoOrder po) {
return "Promo: " + po.promoCode() + " amount " + po.amount();
} else if (order instanceof RefundOrder ro) {
return "Refund: " + ro.reason();
} else {
throw new IllegalStateException("Unknown order type");
}
}现在，类型检查、转型和变量声明合为一体。模式变量 ro 或 po 仅在 instanceof 表达式为 true 时才被赋值，并且其作用域由流作用域（flow scoping）决定：编译器通过流分析确定模式变量在哪些代码区域中一定已被赋值。例如，在 if (order instanceof RegularOrder ro) 的条件为真时，ro 在 if 块内可用；在 && 连接的条件下，ro 在右侧表达式和 if 块内可用，因为右侧表达式仅在模式匹配成功后才被求值。
这种写法消除了强制转型，减少了类型名的重复，但 if-else 链依然存在，且穷举性问题未解决。如果新增 GiftOrder，else 分支仍会悄悄吞掉未处理的情况。
switch 模式匹配：多分支选择与穷举性
Java 21 最终确定的 JEP 441 将模式匹配扩展到 switch 语句和表达式。现在，switch 的选择器表达式可以是任何类型，case 标签可以包含模式，而不仅仅是常量。上面的代码可以进一步改写为：
public String processOrder(Order order) {
return switch (order) {
case RegularOrder ro -> "Regular: " + ro.amount();
case PromoOrder po -> "Promo: " + po.promoCode() + " amount " + po.amount();
case RefundOrder ro -> "Refund: " + ro.reason();
};
}这里没有 default 分支，因为 Order 是一个密封接口，编译器知道它只有三个许可的子类型。当 switch 覆盖了所有可能的类型时，它就是穷举的（exhaustive），不需要 default。如果后续有人新增了 GiftOrder 并加入到 permits 子句中，编译器会立即报错，要求 switch 必须处理新类型。这就将运行时错误转变为了编译期错误，大大增强了安全性。
switch 模式匹配还解决了 null 处理问题。传统 switch 在选择器为 null 时会抛出 NullPointerException，因此通常需要在外部先判空。现在，我们可以直接在 switch 中使用 case null 标签：
public String processOrder(Order order) {
return switch (order) {
case null -> "No order";
case RegularOrder ro -> "Regular: " + ro.amount();
case PromoOrder po -> "Promo: " + po.promoCode() + " amount " + po.amount();
case RefundOrder ro -> "Refund: " + ro.reason();
};
}如果 switch 没有 case null 且选择器为 null，则仍然抛出 NullPointerException，保持了向后兼容性。
密封类型与穷举性：编译期安全的基石
穷举性检查是 switch 模式匹配的核心优势之一，但它依赖于密封类型（sealed classes/interfaces）。密封类型通过 permits 子句显式列出所有允许的子类型，编译器因此能够确定一个类型的所有可能形态。
在我们的订单示例中，Order 接口被声明为 sealed，并许可 RegularOrder、PromoOrder、RefundOrder 三个记录类。当 switch 覆盖了这三个类型时，编译器认可其穷举性。如果缺少任何一个，编译器会报错：the switch statement does not cover all possible input values。
密封类型不仅用于模式匹配，它还是一种设计工具，强制模块化地控制类型层次。在数据导向编程中，我们通常将数据建模为不可变的记录（record），并用密封接口将相关类型组合成一个封闭的代数数据类型（Algebraic Data Type）。这样，处理数据的代码就可以利用模式匹配进行穷举解构。
不过，密封类型要求所有许可的子类型必须与密封类型在同一个模块或包内（如果密封类型在具名模块中，则子类型必须在同一模块；如果在无名模块中，则必须在同一包）。这意味着类型层次是集中管理的，不适合需要跨模块扩展的场景。如果类型层次需要开放扩展，则无法使用密封类型，也就无法获得编译期穷举性检查，此时仍需要 default 分支或显式抛出异常。
数据导向编程：模式匹配的设计哲学
模式匹配、记录和密封类共同构成了 Java 数据导向编程（Data-Oriented Programming）的基础。数据导向编程鼓励将数据建模为透明、不可变的数据载体（如记录），而将业务逻辑放在单独的函数中，通过模式匹配来解构数据并执行操作。这与传统的面向对象编程（OOP）将数据和行为封装在对象内部的做法形成对比。
在 OOP 中，我们可能会为每种订单类型定义一个处理方法，通过多态来分发行为。这种风格适合实体具有丰富行为且类型层次稳定的场景。但在许多服务中，数据只是在不同系统间传递的载体，行为相对简单且容易变化。此时，使用数据导向风格，将数据定义与操作分离，可以更灵活地添加新的操作而不必修改数据类，同时利用模式匹配确保所有情况被处理。
以下表格对比了两种风格在订单处理场景下的差异：
| 维度 | 面向对象风格 | 数据导向风格 |
|---|---|---|
| 数据建模 | 类封装状态，可能包含行为方法 | 记录（record）作为透明数据载体 |
| 行为分发 | 多态：每个子类实现自己的处理方法 | 模式匹配：外部函数根据类型解构数据 |
| 扩展新类型 | 需添加新子类，并实现所有相关方法 | 需修改密封接口 permits 子句，并更新所有 switch |
| 扩展新操作 | 需在所有子类中添加新方法，侵入性强 | 只需添加新函数，使用模式匹配处理所有类型 |
| 穷举性检查 | 编译器无法保证所有子类都实现了某个方法（除非抽象方法） | 编译器强制 switch 覆盖所有类型 |
| 适用场景 | 类型稳定、行为与数据紧密耦合的领域实体 | 类型易变、操作多变的轻量级数据服务 |
选择哪种风格取决于具体需求。在订单处理服务中，订单类型相对固定，但操作可能多种多样（格式化、验证、计算折扣等），因此数据导向风格更合适。
贯穿场景：订单处理服务的完整实现
让我们回到订单处理服务，展示如何利用模式匹配构建一个健壮的处理流程。假设我们需要实现一个方法，根据订单类型计算最终价格：普通订单不打折，促销订单根据促销码打折，退款订单金额为负。
public BigDecimal calculateFinalAmount(Order order) {
return switch (order) {
case RegularOrder ro -> ro.amount();
case PromoOrder po -> {
BigDecimal discount = promoService.getDiscount(po.promoCode());
yield po.amount().multiply(BigDecimal.ONE.subtract(discount));
}
case RefundOrder ro -> ro.amount().negate();
};
}这里使用了 switch 表达式，每个 case 通过 -> 直接返回值，或使用 yield 语句在块中返回值。编译器确保所有订单类型都被处理，无需 default。
如果业务逻辑更复杂，需要从订单中提取多个字段进行判断，模式匹配还可以嵌套记录模式（JEP 440，在 Java 21 中与 switch 模式匹配共同最终确定）。例如，我们可能只关心促销订单中特定促销码的情况：
public String handleSpecialPromo(Order order) {
return switch (order) {
case PromoOrder(var id, var amount, "BLACK_FRIDAY") -> "Black Friday order: " + id;
case PromoOrder po -> "Regular promo: " + po.promoCode();
default -> "Not a promo order";
};
}记录模式 PromoOrder(var id, var amount, "BLACK_FRIDAY") 不仅检查类型，还解构记录组件并匹配特定值。这进一步减少了样板代码。
下图展示了订单处理服务中模式匹配的决策流程：
flowchart TD
A[接收 Order 对象] --> B{switch 匹配}
B -->|RegularOrder ro| C[提取 amount]
B -->|PromoOrder po| D[提取 amount 和 promoCode]
B -->|RefundOrder ro| E[提取 amount 和 reason]
C --> F[计算普通订单价格]
D --> G[根据促销码计算折扣]
E --> H[生成退款金额]
F --> I[返回结果]
G --> I
H --> I
流程从接收 Order 对象开始，switch 根据实际类型将控制流转到对应分支，每个分支解构所需数据并执行特定逻辑，最终返回结果。编译器在编译时验证所有路径都被覆盖。
工程实践中的常见失败模式与诊断
尽管模式匹配带来了诸多好处，但在实际使用中仍需注意以下问题：
1. 密封类型层次修改导致的编译错误
当在密封接口的 permits 子句中添加新类型时，所有使用该类型进行穷举性 switch 的代码都会编译失败。这虽然安全，但在大型项目中可能造成大量编译错误，需要逐一修改。一种缓解策略是使用 IDE 的批量重构功能，或者暂时将 switch 改为带有 default 分支的非穷举形式，再逐步迁移。
2. 模式匹配与 null 处理的混淆
如果 switch 没有 case null，且选择器为 null，则会抛出 NullPointerException。这与传统 switch 行为一致，但开发者可能误以为模式匹配会自动处理 null。建议在需要处理 null 的场景显式添加 case null，或确保选择器不会为 null。
3. 记录模式与组件名称的依赖
记录模式通过位置而非名称来匹配组件，因此如果记录类的组件顺序发生变化，模式匹配代码可能静默地匹配到错误的组件，导致逻辑错误。例如，如果 PromoOrder 的组件顺序从 (String orderId, BigDecimal amount, String promoCode) 变为 (String orderId, String promoCode, BigDecimal amount)，原有的记录模式 PromoOrder(var id, var amount, var code) 仍然编译通过，但 amount 和 code 的值会错位。因此，修改记录定义时需谨慎，并依赖充分的测试。
4. 性能考量
switch 模式匹配的编译策略会根据分支数量和类型分布选择不同的实现方式（如 tableswitch、lookupswitch 或逐条 if-else）。对于密封类型，编译器可能生成更高效的跳转表。但在分支数量很少时，性能差异可忽略。如果分支极多且性能敏感，建议通过 JMH 基准测试验证。
5. 兼容性与预览特性
模式匹配在 Java 16 和 Java 21 中已最终确定，但记录模式在 Java 21 中才最终确定。如果使用更早版本，部分特性可能仍处于预览阶段，需要在编译时启用 --enable-preview。在生产环境中，应尽量使用 LTS 版本（如 Java 21）以确保稳定性。
适用边界与替代方案
模式匹配并非银弹。以下场景可能不适合或需要权衡：
- 类型层次开放扩展：如果类型层次需要由不同团队或模块自由扩展，则无法使用密封类型，穷举性
switch也就无法使用。此时，if-else链或访问者模式可能更合适。 - 复杂行为与数据紧密耦合：当数据对象自身需要封装复杂行为，且行为随类型变化时，传统的多态可能更自然。模式匹配将行为外置，可能导致数据和行为分离过远，增加理解成本。
- 遗留代码迁移：在大量使用
instanceof和强制转型的遗留代码中，可以逐步引入模式匹配，但需注意流作用域可能改变变量作用域，导致现有代码编译失败。例如，在if-else链中，模式变量在else块中不可见，而传统写法中转型后的变量可能在外层作用域。
替代方案包括：
- 多态：在类型内部定义抽象方法，由子类实现。适合类型稳定、操作固定的场景。
- 访问者模式：将操作封装为访问者，由类型接受访问。适合类型稳定但操作多变的场景，但代码较为冗长。
- if-else 链：简单直接，但缺乏编译期安全检查，适合分支少且类型不封闭的场景。
在订单处理服务中，订单类型由本团队控制且数量有限，操作多变，因此模式匹配是理想选择。
模式匹配的引入标志着 Java 在数据导向编程方面迈出了重要一步。它通过 instanceof 简化了类型检查与转型，通过 switch 提供了穷举性多分支选择，并与密封类型和记录协同，使代码更安全、更清晰。然而，开发者需要理解其适用边界，合理选择设计风格，并注意记录模式中的组件顺序、null 处理等细节，才能充分发挥其价值。