JDK 26 模式匹配支持原始类型，1 个 JEP，3 大特性，N 个 bug 消失！

公告：“业余草”微信公众号提供免费CSDN下载服务(只下Java资源)，关注业余草微信公众号，添加作者微信：xttblog2，发送下载链接帮助你免费下载！
本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序

腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云

再过两周，JDK 26 就要正式发布了，这是一个非 LTS 版本的 JDK，目前已有不少开源框架进行了版本迭代并支持了 JDK 26。早前，我已经写过 JDK 26 的所有新特性了，当时是一个总览的形式给大家介绍的。现在随着发布日期的越来越近，我再来解读一下这其中的 JEP 530 特性，模式、instanceof和switch中的原始类型（Primitive Types in Patterns, instanceof, and switch）。这个特性被社区归类为 Java 语言规范层面的特性。

这个 JEP 530 特性，可以说是让 Java 的模式匹配终于“完整”了。instanceof、switch 和记录模式现在都能直接使用 int、long、float、double、boolean 等原始类型，既能捕获值又能保证类型安全，告别繁琐的范围检查和手动转型！

这也可以说是 Java 模式匹配的最后一块拼图，让 Java 再次伟大的一个基石之一。

为什么我们需要这个特性？

在 Java 25 以及之前的版本中，模式匹配（Pattern Matching）已经逐步支持了引用类型、记录类型，但唯独原始类型（primitive types）一直被“特殊对待”。

这导致了很多“割裂感”，看下面 3 个简单案例。

// 想用模式匹配捕获 int 值？不行！
switch (status) {
    case 0 -> "OK";
    case 1 -> "WARN";
    case int i -> "Unknown: " + i;  // 编译错误！
    default -> "Error";
}

// 想用 instanceof 安全转型为 byte？得手写范围检查
if (value >= -128 && value <= 127) {
    // 繁琐且易错
    byte b = (byte) value;  
    // ...
}

// 解析 JSON 数字时，double 转 int 得手动强转（还可能丢精度）
if (json instanceof JsonNumber(double d)) {
    // 静默精度丢失风险
    int age = (int) d;  
}

这些“历史包袱”让模式匹配的体验不够统一，也增加了出错概率。现在，JEP 530 的目标，就是消除这些摩擦，让原始类型也能优雅地参与模式匹配。

JEP 530 带来了什么？

简单来说，switch 支持所有原始类型 + 模式捕获。就连 instanceof 也支持原始类型了，成了安全转型的“守门员”。同时，Record 模式也支持原始类型嵌套和安全窄化。

switch 原始类型 + 模式捕获

现在，switch 不仅能处理 byte/short/char/int，还能直接处理 long、float、double、boolean，并且可以用类型模式捕获值。

看下面 4 个小案例。

// 捕获未知状态值，日志更清晰
switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning"; 
    case 2 -> "error";
    case int i -> "unknown status: " + i;  // i 就是匹配到的值！
}

// 配合 guard 实现复杂分支逻辑
switch (user.getYearlyFlights()) {
    case 0 -> "新用户";
    case 1, 2 -> issueDiscount();
    case int f when f >= 100 -> issueGoldCard();  // 守卫条件
    case int f -> "普通用户: " + f + " 次飞行";
}

// boolean switch：比三元表达式更易扩展
switch (user.isLoggedIn()) {
    case true  -> user.id();
    case false -> { log("未登录用户"); yield -1; }  // 支持语句块 + logging
}

// long switch：大整数常量直接写，不用 if-else
switch (orderId) {
    case 1L              -> processNormal();
    case 10_000_000_000L -> processBigOrder();  // 100 亿订单
    case long id         -> fallback(id);       // 捕获其他值
}

instanceof 原始类型 + 安全转型

这个功能也是 JEP 530 最实用的特性之一，用instanceof检查原始类型转换是否安全，避免静默精度丢失。

看下面的两个场景之前的新旧写法案例代码。

// 场景：人口数据可能是 int，但系统用 float 存储
int population = getPopulation();

// 旧写法：自动转型，但可能丢精度（无警告！）
float pop = population;  // 如果 population > 2^24，精度就丢了

// 新写法：只有能无损转换时才匹配
if (population instanceof float pop) {
    // 能进来说明转换是 exact 的，放心用 pop
    processPopulation(pop);
} else {
    // 转换会丢精度，走降级方案
    logWarning("人口数据过大，使用高精度处理");
    processWithBigDecimal(population);
}

// 场景：int 转 byte，再也不用手写范围检查！
int value = 1000;
if (value instanceof byte b) {
    // 只有 value ∈ [-128, 127] 时才会匹配
    sendByte(b);  // b 已经是 byte 类型，直接用
} else {
    // 超出 byte 范围，走其他逻辑
    sendInt(value);
}

这里的核心原理是，instanceof会检查转换是否是“精确转换”（exact conversion）。即运行时不会丢失任何信息。如果是int转float但值超过 2 的 24 次方，或者int转byte但值超出范围，匹配就会失败。

Record 原始类型嵌套 + 安全窄化

我们解析结构化数据时，这个特性就特别有用了。

// 假设 JSON 数字统一用 double 表示
sealed interface JsonValue {
    record JsonNumber(double value) implements JsonValue {}
    // ... 其他类型
}

JsonValue json = new JsonNumber(30);  // 传入 int，自动 widen 为 double

// 旧写法：必须按声明类型 double 匹配，再手动窄化
if (json instanceof JsonNumber(double d)) {
    if (d >= Integer.MIN_VALUE && d <= Integer.MAX_VALUE) {
        int age = (int) d;  // 还得自己检查范围
        processAge(age);
    }
}

// 新写法：直接用 int 模式匹配，匹配失败自动走 else
if (json instanceof JsonNumber(int age)) {
    // 能进来说明 double 值能无损转为 int
    processAge(age);  // age 直接就是 int！
} else {
    // 值太大或带小数，走高精度处理
    handleLargeNumber(json);
}

可以看出，有了 JEP 530 之后，不管是 switch、instanceof，还是 Record，都变得非常丝滑好用了。

精确转换的安全机制

JEP 530 的核心是引入了exact conversion精确转换的概念。看下面这个转换表格。

再举 3 个小案例，看下面的代码。

// 编译期就能确定的“无条件精确”转换
byte b = 42;
boolean r1 = b instanceof int;     // true，永远匹配

// 需要运行时检查的转换
int i = 1000;
boolean r2 = i instanceof byte;    // false，1000 超出 byte 范围

// float 精度陷阱：2^24+1 无法精确表示为 float
int big = 16_777_217;  // 2^24 + 1
boolean r3 = big instanceof float; // false！精度丢失，匹配失败

这种设计让instanceof不仅检查“类型”，还检查了“值”，从根本上避免了传统强制转型的静默 bug。

注意事项以及兼容性

这是一个 Preview 特性，在 JDK 26 中，它是第四次预览。

JEP 530 目前处于Fourth Preview阶段，目标在 JDK 26 正式发布。使用前需要启用预览。

# 编译 + 运行
javac --release 26 --enable-preview Main.java
java --enable-preview Main

# 或用源码启动
java --enable-preview Main.java

# JShell
jshell --enable-preview

JEP 530 增强了switch的支配性检查，一些以前能编译的代码现在会报错。比如下面这段代码，就有了更严格的支配性检查（Dominance）。

int x = ...;
switch (x) {
    case int _    -> {}  // 无条件匹配所有 int
    case float _  -> {}  // 编译错误！被上面的 case 支配，永远 unreachable
}

这是官方有意为之的设计，帮助开发者提前发现逻辑冗余，避免维护时的困惑。

还有就是，在switch中使用 float/double 时，case 常量必须表示等价。也就是说，现在有浮点数 case 标签的精度要求了。

float v = ...;
switch (v) {
    case 1.0f -> ...;
    case 0.999999999f -> ...  // 编译错误！该字面量会被舍入为 1.0f，重复 case
}

实用场景推荐

下面我们看几个我推荐的实用场景吧。

日志/监控中的状态码处理

// 用模式捕获未知状态，避免 default 里重复调用 getter
switch (metric.getStatusCode()) {
    case 200 -> "Success";
    case 404 -> "Not Found";
    case 500 -> "Server Error";
    case int code -> logUnknown("HTTP " + code);  // code 直接可用
}

配置解析中的安全类型转换

// 用户输入的配置值，安全转为 byte 发送给嵌入式设备
Object configValue = getConfig("device_param");
if (configValue instanceof byte param) {
    device.send(param);  // 安全，已验证范围
} else if (configValue instanceof Integer i) {
    log.warn("配置值 {} 超出 byte 范围，使用默认值", i);
    device.send(DEFAULT_PARAM);
}

领域模型中的灵活匹配

// 订单金额可能是 int（分）或 BigDecimal（高精度）
switch (order.getAmount()) {
    case int cents when cents < 100 -> "小额订单";
    case int cents -> processNormalOrder(cents);
    case BigDecimal amt -> processHighPrecisionOrder(amt);  // 未来扩展
}

社区声音

这个特性在 OpenJDK 社区讨论热烈。

支持者认为：

终于不用在 instanceof 和 switch 里区别对待原始类型了，语言一致性 +1

安全转型检查是刚需，尤其是金融、嵌入式等对精度敏感的场景

而谨慎派则提醒道：

预览特性 API 可能微调，生产环境建议观望 JDK 26 GA

switch (boolean) 虽然语法可行，但简单场景用三元表达式可能更直观

如文章开头所说，除了 Spring 这类主流框架外，工具链的进展也开始跟上来了。IntelliJ IDEA、Eclipse JDT 等主流 IDE 已陆续开始支持 JEP 530 的语法高亮和检查了。

总结

JEP 530 应该说是需要我们关注的一个新特性之一，毕竟它是语言规范层面的一个新特性。后面，万一哪天 AI 或你的同事，写出了“新语法”一样的代码，你看不懂就糟了。

下面这个表格，整理了痛点、解法与收益之间的平衡，供大家参考。

总的来说，JEP 530 不是“炫技”的新语法，而是 Java 向更安全、更一致、更表达力迈进的务实一步。它让模式匹配真正成为处理数据的“瑞士军刀”，无论数据是 String、Record 还是 int。

最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！

本文原文出处：业余草： » JDK 26 模式匹配支持原始类型，1 个 JEP，3 大特性，N 个 bug 消失！