Java 17 发布已经有段时间了但直到现在我在很多技术群里看到的第一个问题依然是“Java 17 到底新增了哪些新特性升级值不值”说明大部分人其实都在观望手里还牢牢握着 Java 8 或者 Java 11。作为一个从 Java 8 时代一路维护老系统、后来又接连把几个服务迁到 Java 17 的实践者我可以负责任地说Java 17 不是那种“宣传很猛、实际没感觉”的版本它的每一项改动都直接影响你的编译参数、运行时报错和安全策略。这篇文章我不想写成官方 JEP 的翻译稿而是尽量用踩过坑的口吻把 Java 17 的新特性拆开揉碎讲清楚它解决了什么问题、在什么场景下用、迁移时会遇到什么坑。同时考虑到很多朋友搜到这篇文章其实是想先解决“怎么装”的问题我还会把 Linux 和 macOS 上安装 Java 17 的完整流程、环境变量配置、以及从 JDK 8/11 升级的实操建议一起放进来。无论你是刚入门的新人还是在维护老项目的资深开发这篇文章都能帮你少走不少弯路。1. 为什么要关注 Java 171.1 LTS 版本的含义与版本节奏Java 从 2017 年开始改成半年一个功能版本Oracle 每六年发布一个 LTS长期支持版本。Java 8 是 2014 年发布的 LTSJava 11 是 2018 年发布的 LTSJava 17 则是 2021 年 9 月发布的 LTS。很多人不理解为什么那么多团队一直在 Java 8 上不动其实不是因为 Java 8 够用而是因为非 LTS 版本的生命周期太短企业不敢把生产环境跑到一个半年后就停止免费维护的版本上。Java 17 作为 LTS享受的是至少五年的 Oracle 高级支持后续还有延长的维护期。对于大多数公司来说从 Java 8 或 Java 11 升级最安全的下一个着陆点就是它。更重要的是Java 17 在语言、运行库、平台支持和内部封装方面都做了大量收口工作很多从 Java 9 以来一直“预览”“孵化”的特性到 17 已经正式落地这意味着你今天学的东西未来几年都不会被推翻。1.2 从 Java 8 直接跳到 Java 17相差到底有多大如果你还在 Java 8那我直接告诉你中间差的不只是一个版本号而是一整套开发范式的变化。Java 9 带来了模块系统JPMSJava 11 移除了 Java EE 和 CORBA 模块Java 14 带来了 switch 表达式正式版Java 15 带来了 Text Blocks 正式版Java 16 带来了 Record 正式版和 instanceof 模式匹配正式版。而 Java 17 在这些基础上又增加了密封类正式版、强封装 JDK 内部、增强的伪随机数生成器等。也就是说从 Java 8 跳到 Java 17你会第一次感受到“编译器能帮你检查更多东西”。过去写switch忘记break导致穿透错误过去写 DTO 要手动生成一堆getter/setter/equals/hashCode过去想限制继承关系只能靠文档约定这些问题在 Java 17 里都有了语言层面的原生解法。如果你的项目已经用上了 Spring Boot 3.x 或较新的版本那底层早就是基于 Java 17 编译的了继续停留在 Java 8 反而会成为上游框架升级的阻碍。1.3 Java 17 全部 JEP 速览在进入细节之前先把 Java 17 包含的 JEP 清单摆出来。JEP 是 JDK Enhancement Proposal 的缩写每个 JEP 代表一个经过评审的增强提案看这一张表就能理解 Java 17 的改动范围JEP 编号标题类型一句话概括JEP 306Restore Always-Strict Floating-Point Semantics运行时默认恢复严格浮点语义结果更可预测JEP 356Enhanced Pseudo-Random Number GeneratorsAPI新增统一随机数接口和多种算法实现JEP 382New macOS Rendering Pipeline平台macOS 上 Swing/AWT 渲染走新管道JEP 391Port to macOS/AArch64平台原生支持 Apple SiliconJEP 398Deprecate the Applet API for Removal清理Applet API 进入弃用流程JEP 403Strongly Encapsulate the JDK Internals运行时默认拒绝反射访问 JDK 内部 APIJEP 406Pattern Matching for switch (Preview)语言switch 支持模式匹配预览状态JEP 407Remove RMI Activation清理彻底移除 RMI ActivationJEP 409Sealed Classes语言密封类正式转正JEP 410Remove the Experimental AOT and JIT Compiler清理移除实验性 AOT/JIT 编译器JEP 411Deprecate the Security Manager for Removal运行时弃用 SecurityManagerJEP 412Foreign Function Memory API (Incubator)API外部函数与内存 API 进入孵化JEP 414Vector API (Second Incubator)API向量 API 进入第二孵化器JEP 415Context-Specific Deserialization Filters安全上下文特定反序列化过滤器看完这张表你就会发现Java 17 的新特性并不是“拍脑袋加功能”而是“该收的收、该放的放”。语言层面的密封类和 switch 模式匹配负责让代码更安全、更表达意图运行时层面的强封装负责让 JDK 内部不再裸奔平台层面的 AArch64 和 macOS 渲染支持则让 Java 在现代硬件上继续工作。下面我按这几个层面逐个展开。2. 语言层面密封类与 switch 模式匹配2.1 密封类正式落地限制继承从此有语法保证JEP 409 把密封类Sealed Classes带到了 Java 17 的正式版本。什么是密封类通俗地说你可以用sealed修饰一个类或接口然后通过permits显式列出哪些类可以继承或实现它。这样做的目的是打破“继承体系不受控”的局面过去你定义了一个Shape接口谁都能实现它导致下游代码永远无法穷举所有可能现在你可以告诉编译器这个接口只允许这三个类实现。看一段最简单的代码public sealed interface Shape permits Circle, Rectangle, Triangle { double area(); } public final class Circle implements Shape { private final double radius; public Circle(double radius) { this.radius radius; } Override public double area() { return Math.PI * radius * radius; } } public non-sealed class Rectangle implements Shape { private final double width; private final double height; public Rectangle(double width, double height) { this.width width; this.height height; } Override public double area() { return width * height; } }这里有一个特别容易踩的坑被permits列出的子类必须显式声明为final、sealed或non-sealed三者之一。很多人第一次写的时候直接写public class Circle implements Shape编译立刻报错提示缺少修饰符。这个设计很容易理解如果子类既不封闭也不终态那“密封”就名存实亡了因为别人还能在那个子类之后继续无限派生。final表示这条路到此为止sealed表示子类还可以再列自己的允许列表non-sealed等于主动放弃密封约束、回归普通类。这三种选择正好对应了三种真实的设计意图。密封类最大的价值在于配合模式匹配做穷举判断。当你有一个Shape变量并且确定了它的所有子类后编译器就能帮你检查switch里的分支是否覆盖完整不需要再写尴尬的default兜底分支。这也是 Java 团队为什么要同时推动 switch 模式匹配的原因。2.2 switch 模式匹配进入预览模式匹配时代开启JEP 406 把模式匹配扩展到了switch语句和表达式上在 Java 17 中处于预览状态。预览的意思是功能已经实现但 API 和语法仍可能调整必须显式开启--enable-preview才能使用。你可以在 switch 里直接判断对象的类型并绑定变量public static String handle(Object o) { return switch (o) { case Integer i - Integer: i; case Long l - Long: l; case String s - String: s; case int[] arr - Array, length arr.length; default - Unknown: o.getClass().getName(); }; }注意这里单个case里能直接声明变量并使用不用再写instanceof加显式强转。如果分支是带代码块的需要用yield返回值否则会报编译错误。我在 IDEA 里测试时遇到最多的问题是写完case String s - ...之后忘了在块里使用s然后 IDEA 就提示变量 s 未使用或不可达。其实这是好事说明编译器在强迫你写出更清晰的逻辑。一旦你习惯了这种写法再回头看旧的if (obj instanceof Integer) { Integer i (Integer) obj; }就会觉得非常啰嗦。虽然 switch 模式匹配在 Java 17 还是预览但 Java 21 已经把它转正并继续扩展了现在提前学完全值得。2.3 Record 和 Text Blocks 已成为新代码的默认风格严格来说 Record 是 Java 16 正式发布的Text Blocks 是 Java 15 正式发布的。但很多直接看待 Java 17 的开发者实际接触到它们就是在 17 上。Record 用一行代码定义不可变数据载体public record User(Long id, String name, String email) {}这段代码会自动生成构造函数、accessor方法、equals、hashCode和toString。不用再手写十几行样板代码更重要的是Record 的字段默认是final的天然不可变这在线程安全和缓存场景里太有用了。Text Blocks 则解决了多行字符串的转义地狱。以前写 SQL 或 HTML 片段时你要在每行末加\n还要转义双引号错误率极高现在三个双引号就能搞定String sql SELECT id, name, email FROM users WHERE status ACTIVE ORDER BY id DESC ;实际迁移的时候我的感受是新特性里最“润物细无声”的就是这两个。它们不像密封类那样有强烈的存在感但它们让日常写代码的速度和可读性提升了一个档次。如果你从 Java 8 直接切到 Java 17建议先在项目里把 DTO 改成 Record把长 SQL 改成 Text Blocks马上就能感受到差别。3. 运行时与平台增强浮点语义、随机数与平台支持3.1 恢复严格浮点语义结果稳定压倒一切JEP 306 的标题是“Restore Always-Strict Floating-Point Semantics”翻译过来就是“恢复始终严格的浮点语义”。很多人觉得这个特性跟自己无关其实它关系到任何依赖浮点运算结果一致性的程序。Java 在早期版本里浮点运算默认是严格按照 IEEE 754 标准进行的但后来为了利用某些 CPU 的扩展精度寄存器引入了“非严格”模式。也就是说同样的表达式在不同平台、不同 JVM 版本上结果可能有一点点差别只有显式加了strictfp关键字才能保证每次都严格按标准计算。Java 17 直接取消了这种差异所有浮点运算默认就是严格模式strictfp关键字虽然还保留但已经没有什么实际作用了。对开发者的影响主要有两点一是涉及科学计算、数据比对的系统在升级到 17 后测试数据的基线可能要重新校准二是性能上可能会有细微差别因为 JVM 不能再走某些不严格的快速优化路径。我在做数值指标归因时曾经因为一个浮点数尾差导致校验任务失败查到最后就是升级带来的行为变化。所以遇到这类问题别急着怀疑 Java 17 有bug先检查浮点运算的前后一致性。3.2 增强伪随机数生成器终于不用啥都靠第三方JEP 356 给 JDK 的随机数体系做了一次完整升级。以前我们生成随机数常用的java.util.Random、ThreadLocalRandom、SecureRandom虽然各自能用但并没有统一的抽象而且算法选择非常有限。Java 17 引入了新的顶级接口RandomGenerator以及一系列子接口还内置了大量的新算法实现。可以通过RandomGenerator.of(算法名)直接获取一个生成器RandomGenerator generator RandomGenerator.of(L128X256MixRandom); generator.nextInt(100);也可以用RandomGeneratorFactory.all()列出当前 JVM 支持的全部算法。Java 17 内置的算法分为几大系列表格整理一下算法类型代表实现典型用途传统 Linear CongruentialL32X64MixRandom轻量级通用随机Xoroshiro/Xoshiro 系列Xoshiro256PlusPlus高性能、非加密场景LXM 系列L64X128L128X256 等L128X256MixRandom高周期、并行流友好加密强随机SecureRandom密码学安全新增接口还细分了能力类型SplitableGenerator负责拆分成多条独立流适合并行计算JumpableGenerator和LeapableGenerator支持跳跃式前进适合蒙特卡洛模拟中生成互不重叠的随机流。如果你正在做 A/B 测试分桶、分布式仿真或游戏抽奖系统这套 API 能帮你省下不少自研算法的时间和 bug。唯一要注意的是SecureRandom并没有被替代涉及加密场景还是得走专门的强随机方案。3.3 macOS 渲染管道与 Apple Silicon 支持JEP 382 和 JEP 391 是纯平台层面的改动但对一部分开发者影响非常直接。JEP 382 说的是 macOS 上 Swing/AWT 渲染会采用新的渲染管道用来适配现代 macOS 的图形栈JEP 391 则是把 JDK 官方移植到了 macOS/AArch64 平台也就是 Apple Silicon 芯片。如果你是 Mac 用户此前在 M1/M2 上跑 Java 应用一般要靠 Rosetta 转译 x86 版本启动慢、内存占用也偏高。Java 17 提供了原生 AArch64 版本实测在内存分配和启动速度上都有明显改善。如果你做桌面客户端涉及 Swing 界面渲染升级到 17 后可能还会发现 UI 交互更跟手了。这两项特性对于只做后端服务的人可以忽略但它们决定了 Java 生态在现代 Mac 上能不能继续顺畅地作为主力开发环境。4. 内部机制收紧与清理强封装 JDK 内部与其他移除4.1 强封装 JDK 内部升级后最让人头疼的一刀JEP 403 把 JDK 内部 API 的“强封装”规则正式落实到默认状态。什么意思以前在 Java 8 或 Java 11 中虽然 JDK 内部类不推荐直接使用但通过反射往往还是能访问到比如sun.misc.Unsafe、jdk.internal.*等从 Java 17 开始默认情况下直接反射调用这些内部 API 会被拒绝抛InaccessibleObjectException或IllegalAccessError。我在迁移老项目时就遇到过这样一个问题一个用来做对象序列化的第三方工具为了绕过类型检查反射扫描了java.util下的某些内部字段Java 11 还跑得好好的换到 Java 17 之后应用启动直接失败。排查下来根因是内部 API 被封装第三方库版本太旧。解决办法有两个优先顺序首选把第三方库升级到兼容 Java 17 的版本这是最干净的做法临时兜底在启动命令里显式放开某个模块包的访问权限java --add-opens java.base/java.utilALL-UNNAMED -jar app.jar类似的参数还有--add-exports用于导出内部包。但这类参数只应该在迁移过渡期使用别把它当成长期方案。它等于把 JDK 内部重新暴露出来破坏了强封装带来的好处也让团队对内部 API 的依赖永远清理不掉。很多老项目抱怨 Java 17 启动就崩其实绝大多数都是这个原因。好消息是整个 Java 生态在 17 发布前后已经大范围适配大部分流行框架和中间件的新版本都对 Java 17 有良好支持。你会遇到的坑通常集中在那些长期没有人维护的冷门依赖上。4.2 移除实验性 AOT/JIT 编译器JEP 410 移除了 Java 9 引入的实验性 AOT 和 JIT 编译器也就是jaotc工具和与之相关的编译路径。当年设计 AOT 编译是为了让 Java 应用直接编译成原生代码降低启动时间但由于适用场景有限、维护成本高最终在 Java 17 被正式移除。如果你没有用过jaotc这条对你没有影响如果构建脚本里还写着jaotc --output libapp.so App.class之类的命令升级后这些命令会直接不存在。更准确地说Java 17 移除的是“实验性的提前编译整体方案”而不是禁止 JIT。现代 JVM 默认的 C1/C2 层级编译依然在工作只是不再提供官方 AOT 途径。想显著降低启动时间的话反而是推荐叠加 CDSClass Data Sharing或 AppCDS这些在 Java 17 上更成熟也更实用。4.3 弃用 SecurityManager 和 Applet APIJEP 411 宣布弃用SecurityManager为将来移除做准备。SecurityManager是 Java 1.0 时代的沙箱机制原本用来限制不可信代码的权限但今天 Java 应用的形态早就变了大量代码来自可信的依赖库应用运行在自己的容器或虚拟机上传统沙箱反而成为维护负担和攻击面。Java 17 里调用System.setSecurityManager会输出弃用警告API 上标记了Deprecated(forRemovaltrue)。我的建议是不要再在新项目里使用它老项目如果用了也要尽早规划替代方案。JEP 398 则是弃用 Applet API。Applet 是浏览器时代 Java 在网页里跑小程序的技术随着浏览器插件时代结束它已经没有任何实际使用场景。这条和普通后端开发基本无关但它代表 Java 团队清理历史包袱的决心。遇到这类弃用 API 时最简单的应对策略就是无视它们——只要不在新代码里引用升级到 Java 17 不会产生任何编译问题。4.4 RMI Activation 被彻底移除JEP 407 移除了 RMI Activation 机制也就是java.rmi.activation包。RMI Activation 原本用于让远端 Java 对象在网络中延迟激活常用于老式分布式系统和工作流引擎。由于设计复杂、安全性问题突出这个机制很早就进入了弱维护状态Java 17 直接把它删掉。如果你的项目在用Activatable或ActivationGroup相关的类升级前一定要扫描代码和依赖。可以使用jdeps工具对构建产出进行依赖分析或者直接用 grep 搜索java.rmi.activation确认没有引用再升级。大多数现代项目都不会碰到这个包但遗留系统迁移时需要格外留个心眼。5. 面向未来的孵化特性外部函数、向量计算与反序列化安全5.1 外部函数和内存 API跟 JNI 说再见的前奏JEP 412 把外部函数和内存 APIForeign Function Memory API以孵化器模块jdk.incubator.foreign的形式带到了 Java 17。这个 API 的目标是最终替代 JNI 调用 C 库和用sun.misc.Unsafe访问堆外内存的旧方案。JNI 的痛苦想必大家都有耳闻写本地方法声明、生成头文件、用 C 编译动态链接库稍有跨平台需求就要维护多套产物。Unsafe虽然能直接读写堆外内存但绕过了 Java 的类型安全检查官方一直在收缩它的可用范围。Java 17 孵化版提供了一种更安全的描述方式你可以用MethodHandle描述一个 C 函数的签名然后用MemorySegment表示一段堆外内存空间并在MemorySession的管理下自动释放。try (MemorySession session MemorySession.openConfined()) { MemorySegment segment session.allocate(100); segment.asSlice(0, 4).set(ValueLayout.JAVA_INT, 42); }这段代码在 Java 17 的孵化 API 里完全合法。虽然孵化阶段的 API 随时可能调整我个人强烈建议所有玩过 JNI 或对底层操作有兴趣的人提前体验。未来 Java 应用在调用原生库、处理高并发内存操作时会有一条远比今天干净得多的路径可以走。5.2 Vector API把 SIMD 指令带进 Java 代码JEP 414 是 Vector API 的第二个孵化器版本它的目标很简单让 Java 开发者不用写内联汇编或 JNI就能直接使用 CPU 的 SIMD 向量运算指令。图像处理、音频编码、推荐系统里的特征向量点积这些场景的瓶颈往往不在内存而在计算指令的并行度Vector API 恰好就是补这块短板的。用法上它引入了VectorSpecies和一系列专用向量类。比如用FloatVector对两个float[]做逐元素乘法并收集到新数组var species FloatVector.SPECIES_256; var vectorA FloatVector.fromArray(species, a, 0); var vectorB FloatVector.fromArray(species, b, 0); vectorA.mul(vectorB).intoArray(result, 0);这里的SPECIES_256代表一次处理 256 位数据也就是 8 个float。如果你的 CPU 支持 AVX2 或 NEON运行效率会明显好于普通 for 循环。需要提醒的是Vector API 同样还在孵化模块API 兼容性不稳定生产项目直接用风险太大但做技术预研和性能摸底是非常合适的。5.3 上下文特定反序列化过滤器安全加固的务实之选JEP 415 是 Java 17 中相对低调但非常重要的一项安全增强它让反序列化过滤器能够根据调用上下文动态生效。过去ObjectInputFilter要么是全局配置要么得在每个ObjectInputStream上手动设置控制粒度很粗。JEP 415 引入了更灵活的规则可以基于当前线程或调用栈的上下文来设定过滤器。对实际项目来说最直接的价值是你可以在网关层或 RPC 入口统一配置反序列化过滤规则限制反序列化对象的类型、数组长度、对象图深度从而掐断恶意反序列化攻击的入口。常用的配置方式有两种一种是在 JVM 启动参数里加-Djdk.serialFiltermaxdepth100;maxrefs100;maxarray100000;另一种是在代码里设置全局过滤器ObjectInputFilter filter ObjectInputFilter.Config.createFilter( java.base/*;com.example.**;maxdepth100;maxrefs1000 ); ObjectInputFilter.Config.setSerialFilter(filter);我从安全角度给所有做服务端开发的读者一个建议升级 Java 17 之后别只盯着语言特性把反序列化过滤器顺手配上这是投入产出比极高的一次安全加固。尤其是暴露了 HTTP/JSON、RPC 或者消息队列接口的系统反序列化攻击仍然是 JVM 生态里最危险的漏洞类型之一过滤器能帮你限制攻击面。6. 安装与升级实操从下载到迁移6.1 Linux 上安装 OpenJDK 17 的完整流程很多文章标题写“Java17 下载安装教程详细”但最省心的其实是命令行安装。如果你在 Linux比如 CentOS 或 Ubuntu上手动作业可以按下面步骤走# 建议先把旧版本路径清理干净避免多版本混淆 sudo rm -rf /opt/jdk/jdk-17* # 创建目录并下载 OpenJDK 17 的官方构建 sudo mkdir -p /opt/jdk cd /tmp wget https://download.java.net/java/GA/jdk17.0.2/dfd4a8d099574f18bedb7c4f2a4e6e83/8/GPL/openjdk-17.0.2_linux-x64_bin.tar.gz # 校验哈希官方网站会提供对应 SHA256 sha256sum openjdk-17.0.2_linux-x64_bin.tar.gz # 解压到安装目录 sudo tar -zxvf openjdk-17.0.2_linux-x64_bin.tar.gz -C /opt/jdk然后配置环境变量在/etc/profile.d/java.sh里写入export JAVA_HOME/opt/jdk/jdk-17.0.2 export PATH$JAVA_HOME/bin:$PATH执行source /etc/profile.d/java.sh后运行java -version如果显示openjdk version 17.0.2就说明安装成功。我特别想提一句不要忘记sha256sum这一步官方下载页给出的哈希值就是用来防止下载包被篡改或传输损坏的省这一步容易在后面编译时遇到各种莫名其妙的错误再回来排查反而更费时间。6.2 macOS 和 Windows 安装方式的对比macOS 上最推荐用 Homebrew一条命令搞定brew install openjdk17安装完成之后Homebrew 会提示你设置JAVA_HOME我一般习惯把这几行加到~/.zshrcexport JAVA_HOME$(/usr/libexec/java_home -v 17) export PATH$JAVA_HOME/bin:$PATHjava_home这个工具会按版本号自动找到对应 JDK 的路径比自己写死路径要可靠得多。Windows 上则是下载 Oracle 或 OpenJDK 的.msi安装包一路下一步然后把JAVA_HOME指到安装目录再把%JAVA_HOME%\bin加入Path。注意 Windows 上如果还装有旧版本 JDK多版本切换容易把Path搞乱建议只保留一个JAVA_HOME入口不要同时塞多个 Java 路径。如果你需要在开发机上频繁切换 Java 8、11、17强烈推荐SDKMAN。因为 wget 下载、解压、软链、改环境变量这些操作SDKMAN 都替你做了sdk install java 17.0.2-tem sdk use java 17.0.2-tem我个人常年同时维护多个项目有的还锁在 Java 8用 SDKMAN 切换版本真的能把“切环境”的时间从十分钟压缩到几秒谁用谁知道。6.3 升级前的依赖健康检查清单从 JDK 8 或 11 升级到 17建议先做一轮完整的体检别急着改代码。我用得比较顺手的三个命令是jdeps --ignore-missing-deps -s target/classes分析这个 jar 或目录的模块依赖能看到第三方库依赖了哪些 JDK 模块jdeprscan --release 17 target/classes检查代码里是否使用了已弃用的 APIjava -XX:PrintFlagsFinal -version确认当前 JDK 实际可用的 JVM 参数提前发现写死的老参数。依赖检查的重点是那些基于字节码增强或反射的库比如过旧的 Mockito、CGLIB、ByteBuddy、Fastjson 之类。它们最容易踩“强封装 JDK 内部”的雷。只要把第三方库版本一列逐个到官网或 GitHub 查一下是不是兼容 Java 17基本就能预判出大部分问题。6.4 迁移过程中的典型参数与兜底策略迁移期最常见的启动报错就是InaccessibleObjectException。遇到它先不要慌更不要随手把一串--add-opens全堆上去。更合理的排查路径是用-verbose:class或堆栈日志确定具体是哪个内部包被访问再针对性加参数。比如访问了java.util内部java --add-opens java.base/java.utilALL-UNNAMED -jar app.jar如果访问了java.lang内部java --add-opens java.base/java.langALL-UNNAMED -jar app.jar这类参数列表长了之后很难维护我建议统一放在启动脚本或容器环境变量里加上注释说明是给哪个依赖兜底的。等第三方依赖升级完成后再逐条删除这些参数直到最终做到零--add-opens。这也是 Java 17 团队希望所有人做到的最终状态依赖符合规范不再触碰 JDK 内部。7. 常见问题与排查技巧7.1 密封类编译报错子类必须声明为 final、sealed 或 non-sealed这个问题我在前面提到过但因为它出现的频率实在太高值得单列。第一次写密封类的人几乎都会把子类写成普通类。记住permits里列出的类必须“接住”密封规则否则编译器会直接拒绝。解决方式是回到设计本身你是想让这个子类彻底封闭就加final想让它的后代继续可控就加sealed并写自己的permits想让它的后代完全放开就加non-sealed。没有第三种写法也没有“省略修饰符”这个选项。7.2 启动报InaccessibleObjectException或NoClassDefFoundError这类报错在升级到 Java 17 的过渡期很常见。NoClassDefFoundError有时并不代表类不存在而是指该类所在的包不允许被当前模块访问本质上是封装问题而不是缺包问题。排查顺序应该是先看堆栈里是哪个包再查是哪一段反射代码最后决定是升级依赖还是加--add-opens。千万不要一上来就加一堆兼容参数那只会把问题藏起来后面某个环境随时会爆出来。7.3 反序列化过滤器配置了却没生效如果你在代码里用了ObjectInputFilter.Config.setSerialFilter但发现某些场景仍然能反序列化恶意对象先检查两点一是这个静态设置是否在所有反序列化操作发生之前执行二是过滤器配置的语法是否写对。Java 17 的过滤规则支持包名、通配符、深度和引用数量限制如果配置字符串里有个拼写错误JVM 可能在启动时没有任何提示直到真正使用过滤器时才暴露。我的做法是在启动参数里加-Djava.security.debugserial做验证能看到系统加载了哪些过滤规则判断是否真的生效。7.4 GC 与启动参数变化带来的性能波动Java 17 的默认垃圾回收器还是 G1如果你之前用的是 Java 8 的默认配置升级后 GC 行为会有变化。如果发现某个服务的延迟指标变差建议先用 JFR 或-Xlog:gc记录一段 GC 日志对比 GC 暂停频率和暂停时间再决定要不要调-XX:MaxGCPauseMillis或换用 ZGC。另外Java 11 之前很多常见的参数比如-XX:UseConcMarkSweepGC已经被移除了启动时如果写得有JVM 会直接退出。最好的办法是升级后用java -XX:PrintFlagsFinal -version验证全部参数都在当前版本支持范围内再进入下一轮压测。7.5 下载安装时版本冲突和校验问题Linux 上如果之前用 yum 或 apt 装过 OpenJDK你手动解压的 JDK 很可能没被正确全局生效。原因多半是PATH里存在旧路径。运行which java看一下当前java指向哪里再运行echo $JAVA_HOME确认环境变量就能定位问题。还有如果下载后解压失败建议优先校验 SHA256——国内网络环境下下载大文件偶尔会不完整一个校验能帮你省一晚上的排查时间。网络正常的情况下也可以直接用包管理工具安装发行版提供的 OpenJDK 17 包省去手动下载的步骤。7.6 CDS 和应用打包的坑最后补充一个容易被忽略的细节Java 17 是 LTS很多团队为了追求启动速度会启用 AppCDSApplication Class Data Sharing。用 CDS 时一定要确认 JDK 版本一致跨版本或不同发行商的 JDK 使用同一份 CDS 存档可能触发校验失败。实测下来最好的做法是把 CDS 的生成和启动脚本打包在一起不要在构建机上生成一次存档就到处复用。这个坑虽然不直接属于“新特性”但在 17 上用得多了自然会遇到提前知道能少折腾很久。这些就是我在迁移和日常开发中反复踩过的典型问题。Java 17 作为 LTS 版本生态成熟度已经很高新特性的稳定性和工具链支持也基本到位。对老项目来说最大的成本从来不是“理解密封类”而是把历史依赖和内部 API 的账清干净对新项目来说Java 17 值得你直接从第一天就在全链路中使用尤其结合 Spring Boot 3.x整体体验远优于停留在 Java 8 上的任何方案。升级不必等到“项目空闲”时才做挑个业务低峰跑一遍依赖扫描、修复几个兼容点、再观察一两周 GC 和延迟指标你就能把 Java 17 稳稳接住。