当前位置：首页 > news >正文

JDK 11核心特性解析：从GC革新到模块化实战

news 2026/8/6 15:01:15

1. 从“工具”到“艺术”：为什么JDK 11值得你重新审视

如果你还在用JDK 8，或者刚刚从8升级到11，心里可能嘀咕过：不就是个Java版本更新吗，能有多大变化？我最初也是这么想的，直到一个线上服务的内存问题把我折腾得够呛。那个服务在JDK 8上跑得好好的，一到流量高峰，GC就像个醉汉一样摇摇晃晃，停顿时间长得让人心焦。抱着试试看的心态，我把它迁移到了JDK 11，没改一行业务代码，只是调整了几个JVM参数。结果让人惊讶：不仅GC停顿时间缩短了超过60%，整体吞吐量还有了肉眼可见的提升。那一刻我才真正意识到，JDK 11远不止是增加了几个新API，它是一次从底层虚拟机到上层编程模型的系统性精进，是Java在云原生和微服务时代交出的一份深思熟虑的答卷。

很多人把JDK 11简单地看作“LTS（长期支持）版本”，这没错，但低估了它的价值。它发布于2018年9月，是Oracle调整发布模型后的第一个长期支持版。这意味着它获得了至少到2026年的官方支持，是生产环境部署的安心之选。但更重要的是，JDK 11汇集了此前多个版本（9和10）的精华，并引入了大量旨在提升开发者效率、应用性能和运维可观测性的特性。它标志着Java从一门“稳定但略显笨重”的语言，开始向“高效、敏捷、云友好”的现代平台演进。无论是全新的HTTP客户端让网络编程变得优雅，还是ZGC试图彻底解决GC停顿的顽疾，亦或是局部变量类型推断（var）带来的代码简洁性，都体现了这种“艺术化”的追求——用更少的代码，做更多的事，同时让系统运行得更快、更稳。

所以，这篇文章不是一份干巴巴的Release Notes翻译。我会结合自己这几年在微服务架构、高并发场景下的实战经验，带你深入JDK 11那些真正改变游戏规则的特性。我们会聊透它们背后的设计哲学、解决了哪些实际痛点、在落地时有哪些“坑”需要避开，以及如何让你的现有项目平滑地享受到这些红利。无论你是架构师、后端开发还是运维工程师，JDK 11都值得你花时间深度剖析。

2. 语言层面的精炼：告别冗余，拥抱简洁

JDK 11在语言特性上最大的亮点，无疑是来自JDK 10的局部变量类型推断（JEP 286），也就是我们熟悉的var关键字。这个特性争议不小，有人爱它的简洁，有人恨它降低了代码的可读性。但经过大量实践，我认为关键在于“用得其所”。

2.1 局部变量类型推断（var）的实战哲学

var不是“动态类型”，它依然是百分之百的静态类型。编译器在编译期就完全确定了变量的类型，var只是让你不用把类型名写两遍（声明一次，初始化表达式里又隐含一次）。它的核心价值在于减少样板代码，让代码的焦点集中在逻辑本身，而不是冗长的类型声明上。

哪些场景用var最合适？

初始化表达式类型显而易见时：这是最理想的场景。例如var list = new ArrayList<String>();，右边已经明确是ArrayList<String>，左边再用List<String> list声明就显得多余。
链式调用或复杂泛型时：能极大提升可读性。对比一下：
```
// 不用 var Map<String, List<Map.Entry<Integer, String>>> complexMap = getComplexMap(); // 使用 var var complexMap = getComplexMap();
```
第二行一眼就能看出complexMap是什么，而第一行光理解类型声明就要花点时间。
在for-each循环中：for (var item : collection) {...}非常干净利落。

哪些场景要慎用或不用var？

初始化表达式不能清晰表达类型时：例如var result = process();。如果process()方法返回的不是一个顾名思义的类型（比如User，Order），那么用var就会让阅读者必须去查方法签名，破坏了代码的局部可理解性。
需要依赖变量类型进行重载方法解析时：虽然罕见，但存在。编译器根据变量声明的类型，而不是初始化表达式的类型来解析重载方法。如果用了var，可能会得到意料之外的重载版本。
对可读性有极高要求的公共API或核心模块：在团队没有形成统一规范前，在公开的方法签名或核心逻辑中滥用var可能会增加协作成本。

我的经验是：在团队内制定一个简单的规范。比如，强制要求var只能用于右侧初始化表达式类型明确（通常是带有new或工厂方法）的场景，并且变量名必须具有描述性。这样既能享受简洁，又能避免混乱。

2.2 字符串API的增强：小改动，大便利

JDK 11为String类添加了几个非常实用的方法，它们看似简单，却能在日常编码中省去很多工具类调用。

String.strip()/stripLeading()/stripTrailing(): 终于有了官方的去除空白字符方法！它比旧的trim()更强大，trim()只能删除码点小于等于U+0020（空格）的字符，而strip()能识别Unicode中的所有空白字符。在处理用户输入或外部数据时，用strip()更安全。
String.isBlank(): 判断字符串是否为空或仅包含空白字符。这比str != null && !str.trim().isEmpty()这种连环判断优雅太多了。
String.repeat(int count): 字符串重复。再也不用写循环或者依赖StringUtils.repeat了。
String.lines(): 返回一个由行终止符分隔的字符串流（Stream<String>）。处理多行文本（如配置文件内容、HTTP响应体）时极其方便。

这些方法体现了JDK API设计的一个趋势：将常见的第三方库（如Apache Commons Lang）中的功能吸收进标准库，减少项目的外部依赖，让代码更纯粹。在微服务架构下，减少一个jar包依赖，有时候就意味着更小的镜像体积和更快的启动速度。

3. HTTP/2与全新HTTP客户端：现代网络编程的标配

如果说var是语法糖，那么全新的HTTP客户端（java.net.http.HttpClient）就是一把重塑网络编程的利器。它是在JDK 9中作为孵化模块引入，在JDK 11中正式成为标准库的一部分。它的目标很明确：取代陈旧的HttpURLConnection，提供对HTTP/2和WebSocket的现代支持，并且易于使用。

3.1 为什么必须告别 HttpURLConnection？

老玩家HttpURLConnection的问题太多了：API设计反人类（需要手动处理连接状态、输入输出流）、默认不支持HTTP/2、缺乏对异步调用的原生支持、难以配置超时和代理等。在需要高效网络通信的微服务环境下，它已经力不从心。

3.2 HttpClient的核心优势与实战

新的HttpClient是围绕几个核心概念构建的：

HTTP/2 优先：它默认支持HTTP/2，并能与服务器协商使用HTTP/1.1。HTTP/2的多路复用、头部压缩等特性，对于需要同时发起多个请求的微服务间调用，能显著降低延迟和连接开销。
清晰的异步/同步API：它提供了流畅的Builder模式来构建请求，并且同步（send）和异步（sendAsync）调用方式一目了然。
响应式风格：HttpResponse.BodyHandlers提供了多种处理响应体的方式，可以很容易地将响应体转换为字符串、字节数组、文件，甚至直接映射为对象流。

来看一个简单的异步GET请求示例：

import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.time.Duration; import java.util.concurrent.CompletableFuture; public class HttpClientDemo { public static void main(String[] args) { HttpClient client = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)) .followRedirects(HttpClient.Redirect.NORMAL) // 自动处理重定向 .version(HttpClient.Version.HTTP_2) // 明确指定HTTP/2 .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("https://api.example.com/data")) .timeout(Duration.ofSeconds(10)) .header("Content-Type", "application/json") .GET() .build(); // 异步发送请求 CompletableFuture<HttpResponse<String>> futureResponse = client.sendAsync(request, HttpResponse.BodyHandlers.ofString()); // 处理响应（非阻塞） futureResponse.thenApply(HttpResponse::body) .thenAccept(body -> System.out.println("Response body: " + body)) .exceptionally(e -> { System.err.println("Request failed: " + e.getMessage()); return null; }); // 主线程可以继续做其他事情 System.out.println("Request sent asynchronously..."); // 等待异步操作完成（实际生产环境中通常不会这样阻塞） futureResponse.join(); } }

实战中的坑与技巧：

连接池管理：HttpClient实例是重量级的，它内部维护着连接池。最佳实践是为整个应用（或每个目标服务）创建一个共享的HttpClient实例，而不是为每个请求都新建一个。这能最大化连接复用，提升性能。
超时配置：一定要设置合理的connectTimeout和timeout（在HttpRequest上设置）。在微服务调用链中，一个服务的超时可能引发雪崩。
异常处理：HttpClient抛出的异常类型比HttpURLConnection更丰富，例如HttpTimeoutException,SSLHandshakeException等。需要根据不同的异常类型设计重试或降级策略。
HTTP/2服务端支持：虽然客户端默认支持HTTP/2，但前提是服务端也支持。如果服务端是Nginx、Tomcat 9+、Spring Boot 2.x+等现代服务端，通常没问题。否则会自动降级到HTTP/1.1。

这个新的客户端让Java进行HTTP通信的代码，第一次有了点现代语言（如Python的requests， Go的net/http）的味道——简洁、直观、功能强大。

4. 飞行记录器（JFR）开源：生产环境洞察的“黑匣子”

对于线上问题排查和性能调优，我们以前严重依赖一些“外挂”工具，比如昂贵的商业APM（应用性能管理）套件，或者配置复杂的开源方案（如SkyWalking, Pinpoint）。JDK 11做了一个石破天惊的决定：将原本属于Oracle商业特性之一的Java Flight Recorder (JFR) 彻底开源。

4.1 JFR是什么？为什么它是“神器”？

你可以把JFR想象成Java应用的“黑匣子”。它以一种极低的开销（通常低于1%），持续不断地从JVM内部和Java应用程序中收集大量的诊断和性能分析数据。这些数据包括：

JVM事件：GC活动、类加载、线程启动/停止、锁竞争、文件/网络I/O。
方法采样：周期性地抓取所有线程的栈轨迹，帮你找到CPU热点。
自定义事件：你可以在自己的代码中埋点，记录业务相关的事件（如“用户登录”、“订单创建”），并与JVM事件关联起来分析。

最关键的是，它现在是JDK的一部分，无需任何外部依赖或复杂的Agent注入。你只需要在启动应用时加上几个参数，就能开启这个强大的 profiling 能力。

4.2 如何开启并使用JFR？

启用JFR非常简单。假设你有一个Spring Boot应用，打包成了myapp.jar。

1. 启动时开启持续记录：

java -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=myrecording.jfr -jar myapp.jar

这个命令会在应用启动时开始记录，持续60秒后自动将数据保存到myrecording.jfr文件。你也可以设置duration=0来无限期记录，或者通过delay参数延迟开始。

2. 动态控制记录（更常用的方式）：应用启动后，你可以使用jcmd工具动态地开始、停止和转储记录。

# 找到你的Java进程ID jps # 假设进程ID是 12345 # 开始一个记录，持续2分钟，保存到文件 jcmd 12345 JFR.start duration=120s filename=/path/to/recording.jfr # 在记录期间，随时可以转储当前数据 jcmd 12345 JFR.dump filename=/path/to/dump.jfr # 停止一个正在进行的记录 jcmd 12345 JFR.stop

4.3 使用JDK Mission Control (JMC) 分析数据

记录生成的.jfr文件需要用工具来分析。Oracle JDK 11+ 自带了一个强大的图形化工具叫JDK Mission Control (JMC)。你可以运行jmc命令启动它。

在JMC中打开你的.jfr文件，你会看到一个信息宝库：

概览：CPU、内存、GC、线程的总体情况一览无余。
内存：精确到每一次GC的暂停时间、回收的内存大小、GC原因。这是分析GC问题的终极武器。
代码：热点方法列表，直接告诉你CPU时间花在了哪里。
线程：每个线程的状态变迁、阻塞等待锁的情况。
I/O：文件和套接字读写的耗时。

实战场景举例：有一次，我们一个服务的CPU使用率在每天固定时间会异常飙升。通过JFR录制了问题发生时段的数据，在JMC的“代码”视图中，立刻发现了一个正则表达式匹配方法是热点。进一步查看栈轨迹，发现是在处理一批特定格式的日志文件。原来是有个定时任务使用了效率极低的String.matches()方法，在数据量大时造成了CPU瓶颈。定位和修复这个过程，从录制到分析，只用了不到半小时。如果没有JFR，我们可能需要在代码里加日志、用其他Profiler工具，折腾一两天。

提示：虽然JFR开销很低，但在极端性能敏感的场景（如高频交易核心链路），仍需评估其影响。通常建议在预发环境或生产环境非核心节点上先进行采样记录。

5. 垃圾回收器的革新：ZGC与Epsilon

GC停顿时间（Stop-The-World, STW）一直是Java在大内存、低延迟应用场景下的阿喀琉斯之踵。JDK 11在GC领域带来了两个激动人心的新成员：面向低延迟的ZGC和“无操作”的Epsilon GC。

5.1 ZGC：将停顿时间控制在10ms以内的梦想

ZGC（Z Garbage Collector）是一个可扩展的低延迟垃圾回收器。它的设计目标是：无论堆内存有多大（从几百MB到几个TB），GC停顿时间都不超过10毫秒。这对于响应时间要求极高的金融服务、实时游戏、大数据处理等场景是革命性的。

ZGC是如何做到的？它的核心技术是“染色指针”和“读屏障”。

染色指针：ZGC在64位指针上“偷”了几位来存储对象的元数据（如标记、重定位状态）。这意味着对象的状态信息不存储在对象头里，而是跟着指针走。这为并发处理（如并发标记、并发转移）打下了基础。
读屏障：这是ZGC实现并发的关键。当应用程序线程从堆中读取一个对象引用时，JVM会插入一小段代码（读屏障），这段代码会检查指针上的元数据。如果发现对象正在被GC移动，读屏障会“拦截”这次访问，确保应用程序总是拿到正确的新地址。这样，GC就可以在应用程序线程运行的同时，安全地移动存活对象（压缩堆），从而消除了因移动对象而产生长停顿的需要。

启用ZGC：非常简单，在启动参数中加入：

java -XX:+UseZGC -Xmx4g -jar myapp.jar

注意，ZGC目前仅支持Linux/x64和macOS/x64平台。从JDK 15开始，它成为了正式特性并支持了更多平台。

ZGC的适用场景与局限：

适用：大堆内存（>32GB）、对延迟极其敏感（P99延迟要求亚秒级甚至毫秒级）的应用。例如支付核心、实时风控、在线广告竞价等。
注意：ZGC通过牺牲一部分吞吐量来换取低延迟。如果你的应用对吞吐量要求极高，而对延迟不敏感（比如一些离线批处理任务），那么G1或Parallel GC可能仍然是更好的选择。此外，ZGC的并发处理会占用额外的CPU资源。

5.2 Epsilon GC：没有GC的GC

Epsilon GC（JEP 318）是一个“无操作”的垃圾回收器。它只负责分配内存，但从不回收内存。当堆内存耗尽时，JVM就会直接关闭。

这有什么用？难道不是自寻死路？恰恰相反，它在特定场景下非常有用：

性能测试基准：当你需要测试应用程序本身的理论最大性能，而不想受到GC活动带来的任何干扰和性能波动影响时，可以用Epsilon GC。它能给出一个“纯净”的性能基线。
超短生命周期应用：对于一些运行时间极短（几秒或几分钟），任务完成即退出的应用（如AWS Lambda函数、某些CI/CD构建任务），可能根本不需要GC。使用Epsilon GC可以完全避免GC开销。
内存压力测试：用于测试应用程序在内存耗尽时的行为，或者验证你的内存泄漏检测工具。

启用Epsilon GC：

java -XX:+UseEpsilonGC -Xmx1g -jar short-lived-app.jar

使用它需要你对应用的内存使用模式有非常精确的把握，知道它绝不会超出预设的堆大小。

6. 模块化与依赖管理：从JAR地狱到清晰边界

虽然Java模块系统（JPMS， Project Jigsaw）在JDK 9就引入了，但直到JDK 11这个LTS版本，它才开始被更多严肃的项目所考虑。模块化的核心思想是“强封装”和“显式依赖”，旨在解决经典的“JAR地狱”问题——类路径上充斥着大量未知的、可能冲突的依赖。

6.1 模块描述符：module-info.java

模块化的基础是module-info.java文件，它位于模块的根目录。这个文件声明了模块的三要素：

模块名：唯一标识符。
导出包：这个模块向其他模块公开哪些包（exports）。
依赖模块：这个模块需要哪些其他模块（requires）。

例如，一个简单的服务模块声明：

// 在 `com.example.service` 模块的 `src/main/java/module-info.java` module com.example.service { // 依赖其他模块 requires java.logging; // 平台模块 requires com.example.dao; // 自己的另一个模块 requires transitive com.fasterxml.jackson.databind; // 传递性依赖 // 导出包给其他模块使用 exports com.example.service.api; exports com.example.service.impl to com.example.web; // 限定导出 // 开放反射权限（给Spring等框架用） opens com.example.service.internal to spring.core; }

6.2 迁移到模块化的现实挑战与策略

对于庞大的现有项目，一步到位迁移到模块化是痛苦且危险的。JDK 11提供了灵活的过渡路径：

未命名模块：所有放在传统类路径（-cp）下的JAR包，都会被自动归入一个巨大的“未命名模块”。这个模块可以读取所有其他模块（相当于有requires所有模块的权限），但其他模块无法requires它。这是兼容旧世界的基石。
自动模块：将一个普通的、非模块化的JAR包放到模块路径（--module-path或-p）下，它就会变成一个“自动模块”。自动模块的模块名通常从JAR文件名推导而来（如jackson-databind-2.13.0.jar变成jackson.databind），它会自动requires所有其他模块，并exports其所有的包。这是迁移第三方库的便捷方式。
分步迁移策略：
- 第一步：在类路径下运行。确保你的应用在JDK 11的类路径下能正常工作。这是基础。
- 第二步：创建初始的模块描述符。从最底层、依赖最少的模块开始（比如你的领域模型模块），为其创建module-info.java，只exports必要的包。
- 第三步：将第三方库转为自动模块。将项目依赖的第三方JAR包移到模块路径上，让它们成为自动模块。此时你的模块就可以requires它们了（使用推导出的模块名）。
- 第四步：自底向上，逐步模块化。沿着依赖链，逐步为更多的内部模块创建module-info.java。
- 第五步：处理反射和资源访问。大量框架（Spring, Hibernate）严重依赖反射来访问私有成员。你需要使用opens语句向特定模块开放反射权限，或者使用命令行参数--add-opens在运行时开放。

我的经验是：对于大多数大型企业应用，除非有强烈的安全隔离或镜像瘦身需求，否则不必强求完整的模块化。可以先将JDK 11作为运行时环境，利用其性能和新特性，代码和构建仍然保持传统的类路径方式。等到主要依赖的第三方库都提供了正式的模块描述符后，再考虑迁移。模块化更像是一个长期的架构优化方向，而不是JDK 11升级的必选项。

7. 其他不容忽视的实用特性

除了上述重磅特性，JDK 11还包含了许多能切实提升开发体验和运维效率的改进。

7.1 单文件源代码启动

对于编写小工具、快速原型或教学演示来说，这是一个极其实用的功能。现在，你可以直接运行一个.java文件，而无需先手动编译它。

# 假设有一个 Hello.java 文件 echo 'public class Hello { public static void main(String[] args) { System.out.println("Hello, JDK 11!"); } }' > Hello.java # 直接运行！ java Hello.java

JVM会隐式地在内存中编译并执行这个文件。这对于写一些简单的脚本或测试代码非常方便，降低了入门门槛。

7.2 TLS 1.3 默认启用

安全无小事。JDK 11将传输层安全协议默认升级到了TLS 1.3。TLS 1.3相比1.2，握手速度更快（通常只需1-RTT甚至0-RTT），并且移除了一些不安全的加密算法，安全性更高。这意味着你的Java应用在进行HTTPS通信时，默认就获得了更好的性能和更强的安全保证。大多数现代服务端（如Nginx, Apache）都已支持TLS 1.3，所以通常无需额外配置。

7.3 动态类文件常量

这是JVM字节码层面的一项增强（JEP 309），对于普通应用开发者来说感知不强，但它为语言和工具开发者提供了更大的灵活性。它扩展了Java类文件格式，允许更高效地表达新的常量形式，为未来诸如“模式匹配”等更复杂的语言特性铺平了道路。

7.4 移除和废弃的模块

JDK 11也是一个“瘦身”和“清理”的版本。它移除了Java EE和CORBA模块（如java.xml.ws,java.xml.bind,java.corba），这些模块在JDK 9/10中已被标记为废弃。如果你的项目还在使用这些技术，升级时需要手动添加对应的依赖（例如，使用Maven引入javax.xml.bind:jaxb-api）。同时，JavaFX也被从JDK中分离出来，需要单独下载。

8. 升级到JDK 11：行动指南与避坑实录

理论说得再多，不如一次成功的升级。下面是我在多个项目中从JDK 8升级到JDK 11的实战经验总结。

8.1 升级前的准备工作

环境清单：列出所有需要升级的应用、构建服务器、CI/CD流水线。
依赖审计：使用mvn dependency:tree或gradle dependencies命令彻底分析项目依赖。重点关注：
- 已移除的模块：检查是否依赖了javax.xml.bind,javax.activation,javax.annotation,javax.xml.ws等。如有，需添加Maven/Gradle依赖。
- 第三方库兼容性：访问主要依赖库（Spring Framework, Hibernate, MyBatis, 日志框架，连接池等）的官方文档，确认其支持JDK 11的最低版本。例如，Spring Boot 2.1+ 对JDK 11有良好支持。
- 内部工具JAR：检查公司内部开发的工具包或SDK是否兼容JDK 11。
构建工具更新：确保Maven（至少3.5.0）或Gradle（至少5.0）版本支持JDK 11。更新相关的编译器插件（如maven-compiler-plugin到3.8.0+）。

8.2 逐步升级与验证

不要直接在生产环境升级。建议遵循以下流程：

本地开发环境：首先在本地用JDK 11运行和测试。使用IDE（IntelliJ IDEA/Eclipse）可以很方便地切换项目SDK。
CI/CD流水线：在CI服务器上安装JDK 11，修改构建脚本，让CI用JDK 11进行构建和运行单元测试。这是第一个重要的质量关卡。
集成测试环境：部署到集成测试环境，进行全面的功能测试、API测试和简单的性能测试。
预发/性能测试环境：进行长时间的压力测试、稳定性测试和性能基准测试。对比JDK 8下的性能指标（吞吐量、延迟、内存占用）。特别关注GC日志，使用新的-Xlog:gc*参数输出更详细的GC信息，或者直接使用JFR录制分析。
生产环境灰度：选择非核心的、流量较小的服务进行第一批生产环境灰度发布，密切监控所有指标。

8.3 常见问题与解决方案

问题一：java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

原因：JDK 11移除了Java EE模块。

解决：在Maven项目中添加依赖：

<dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-impl</artifactId> <version>2.3.1</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-runtime</artifactId> <version>2.3.1</version> <scope>runtime</scope> </dependency>

根据你的实际情况选择一组即可。Spring Boot 2.x 通常已经帮你处理了这些依赖。

问题二：使用反射的库（如Lombok、某些JSON序列化工具）报错
- 原因：模块化加强了封装，默认禁止非法反射访问。
- 解决：在启动命令中添加JVM参数来开放权限。这是最常见的“坑”。
```
# 开放整个模块的反射权限（较粗粒度） --add-opens java.base/java.lang=ALL-UNNAMED # 更精确地，只为特定模块开放特定包的反射权限 --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED
```
  通常，第三方库的文档会说明需要添加哪些--add-opens参数。Spring Boot在spring-boot-starter-parent中预置了许多常用的参数。
问题三：sun.misc.BASE64Encoder等内部API找不到
- 原因：JDK 强烈不建议使用以sun.*开头的内部API，它们在JDK 11中可能被移除或无法访问。
- 解决：使用标准库的替代品。例如，用java.util.Base64替代sun.misc.BASE64Encoder。
问题四：启动变慢
- 原因：JDK 9+ 引入了模块系统和应用类数据共享（AppCDS）等，初始启动时可能会有一些额外开销。
- 排查：使用-Xlog:class+load查看类加载情况。对于容器化部署，可以考虑使用JDK提供的“提前编译”（AOT）特性（通过GraalVM）或优化Spring Boot的启动流程（如Spring Boot 2.3+的懒初始化）。

8.4 性能调优参数调整

升级后，原有的GC参数可能不再是最优的。特别是如果你从Parallel GC或CMS迁移到G1（JDK 9+的默认GC），或者想尝试ZGC，需要重新审视GC配置。

G1 GC：如果使用G1，可以关注-XX:MaxGCPauseMillis（默认200ms），根据你的延迟目标调整。-XX:G1HeapRegionSize可以影响大对象的分配。
ZGC：除了-XX:+UseZGC，还可以设置-Xmx,-Xms。ZGC对堆大小的设置比较敏感，建议-Xmx和-Xms设置为相同值，避免堆伸缩。可以启用日志观察：-Xlog:gc*。
通用建议：无论使用哪种GC，升级后务必在预发环境进行压测，根据新的GC日志（使用-Xlog:gc*:file=gc.log输出到文件）来调整参数。JFR是分析GC行为和停顿时间的绝佳工具。