企业官网建设流程全解析

JDK10发布到现在已经有些年头了，但不少同学对它的印象依然停留在“只记得一个var关键字”的层面。作为经历了从JDK8直接跳到JDK11的老开发，我对JDK10的感情是很复杂的——它生命周期短、特性也不算多，但它奠定了Java后续版本快速迭代的节奏模型，也是很多重要功能（比如容器感知、并行Full GC）走向成熟的过渡版本。这篇把JDK10的干货做一个完整梳理，聊聊哪些特性现在还在影响我们的日常开发，哪些已经被后续版本超越淘汰，以及当年踩过的一些坑。

1. JDK10的定位与版本节奏改革

1.1 为什么JDK10如此特殊

很多刚入行的朋友不理解，为什么JDK10这种“小版本”值得专门写一篇文章。要知道JDK9当年可是搞出了模块化（JPMS）这种惊天动地的改动，JDK11又带来了ZGC、标准HTTP Client这些明星特性，夹在中间的JDK10看起来确实没什么存在感。

但JDK10是一个标志性的时间节点：从它开始，Java正式结束了过去那种“几年憋一个大版本”的发布模式，进入半年一个版本的快速迭代周期。之前的JDK8到JDK9隔了整整三年多，而JDK9到JDK10只隔了六个月。这种节奏变化对于企业技术选型的冲击是巨大的，很多团队本来还在评估要不要上JDK9，转眼JDK10就出来了，然后半年后又来了JDK11。

这个版本周期的转变，本质上是为了让新特性不再积压多年才能见人。Oracle把特性的粒度切小了，凡是能按半年节奏交付的活，就放进当前版本；做不完的，直接推到下一个版本。这个模型后来被证明是相当成功的，我们现在能每年稳定拿到两次更新，习惯这种节奏之后，再回去看以前那种大版本的等待周期，反而会觉得无法忍受。

1.2 JDK10核心特性全景

先给一个总览，这次版本一共包含了大概12个JEP（JDK Enhancement Proposal，JDK增强提案）。我按实际影响力分成了三档：

上面三档里，我实际工作中最有感知的是var、并行Full GC和AppCDS。接下来逐个展开聊。

2. 局部变量类型推断（var）的使用边界与实战经验

2.1 var的语法与类型推断原理

JEP 286引入了局部变量类型推断，官方称之为LVTI（Local Variable Type Inference）。简单来说就是允许你用var关键字声明局部变量，而不用显式写出类型。先看最基础的用法：

var list = new ArrayList<String>(); // 推断为 ArrayList<String> var map = new HashMap<String, List<Integer>>(); // 推断为 HashMap<String, List<Integer>> var path = Paths.get("data.txt"); // 推断为 Path

很多人刚接触var的时候，第一反应是“这不就是JavaScript里面的var吗？那Java岂不是变成了动态类型语言？”这是最大的误解。Java的var是一个编译期特性，变量的实际类型在编译时就固定下来了，运行时和普通变量没有任何区别。你可以把它理解为一种“让编译器帮你写类型”的语法糖，而不是把类型检查给丢掉了。

推断的原理其实很简单：编译器根据右边初始化表达式的静态类型来确定变量的类型。注意是静态类型，也就是说：

var x = "hello"; x = 1; // 编译错误，x已经被推断为String

这里的类型检查依然严格，只是你少写了一些代码。它是强类型、静态类型的，这一点和动态类型语言完全不同。

使用var的一条重要规则是：必须有初始化表达式，且初始化的类型不能被null字面量推断出来。下面这两种写法是直接编译报错的：

var a; // 错误：无法推断 var b = null; // 错误：无法推断

原因也很简单，没有初始值或者初始值是null，编译器就不知道这个变量应该是什么类型。这属于语法上的硬性限制，没有例外。

2.2 var解决的核心痛点

那么var到底解决了什么问题？最直观的是消除重复类型声明。以前我们用泛型写代码的时候，经常是左右两边把同样的类型写两遍：

// 传统写法 Map<String, List<Order>> orderMap = new HashMap<>(); // 用var之后的写法 var orderMap = new HashMap<String, List<Order>>();

但这种形式只是最表面的好处。其实var更大的价值在于让代码更关注变量名本身代表的意义，而不是它的类型。举个例子，处理流式操作中大量中间变量的时候，var能显著减少模板代码：

var orders = customer.getOrders(); var filtered = orders.stream() .filter(o -> o.getStatus() == Status.PAID) .collect(Collectors.toList()); var totalAmount = filtered.stream() .mapToDouble(Order::getAmount) .sum();

这里每个变量的名字已经足够说明含义，类型反而成为干扰信息。用var之后，代码的“噪音”减少了，逻辑更突出。尤其在进行链式调用、流式运算的时候，var的体验是质的提升。

还有一类场景是匿名内部类和方法返回的复杂泛型。比如下面的代码，传统写法要写出一长串类型名，但实际上你根本不会直接去引用那些类型名：

var session = ConnectionManager.openSession();

实际返回类型可能是DefaultSessionManagerProxy<OrderSession>这种超长的泛型类型，用var可以省掉这堆没意义的重复。

2.3 需要谨慎使用的场景

var虽然好用，但有几个场景必须克制。最大的坑是可读性下降。如果变量名取得不够清晰，或者初始化表达式过长，读者就要费力去推断类型。看这个例子：

var result = service.execute(complexRequest);

result到底是什么类型？是Response对象，还是String，还是boolean？不翻service的代码根本不知道。这种盲区一旦出现，代码的可读性和可维护性就会变差。

还有一类必须避免的情况是接口编程时的类型替换问题。以前我们习惯写：

List<String> list = new ArrayList<>();

用var之后如果写成：

var list = new ArrayList<String>();

那么list的推断类型是ArrayList<String>而不是List<String>。如果你后续想改成LinkedList，var的写法就多改一行（类名），而List<String>的写法只需要改右边的实例类型。所以当变量类型需要作为抽象接口使用时，尽量避免用var，保持面向接口编程的写法。

简单总结一下我的使用习惯：

• 能用var：局部变量、循环中的临时变量、流式操作的中间结果、类型名特别长的泛型变量。
• 不要用var：方法返回值需要给调用方明确类型时、变量类型容易被推断错时（比如var a = b.get(0);这种）、需要面向接口编程时。
• JDK11升级之后，lambda表达式的参数也可以使用var了，结合注解使用时比较有用，但JDK10阶段还不支持这个。

2.4 var与代码质量的实际联调体验

我实际在一个订单处理模块里大规模引入var之后，代码量缩减了大约15%到20%。这个省出来的不是“打字量”，更多是阅读时的信息噪音。原来一屏能看到8个方法调用，用var之后一屏能看到12个，这个信息密度的提升对分析复杂业务逻辑是有帮助的。

但后来代码审查的过程中，我发现一个隐患：当变量名取得太随意时，var反而增加了阅读成本。比如有人写了var s = user.getAddress();，但s到底是String还是Street对象？完全不清楚。我们后来专门在团队规范里加了一条：用var时，变量名必须能自解释类型或至少能强烈暗示类型，比如var streetAddress = user.getAddress();，这样读者即使看不到类型也能猜个大概。

还有一个值得注意的点：var和重载方法结合时要小心。假设类里有getUser(int id)和getUser(String name)两个重载方法，初始化表达式是var u = obj.getUser(10086);，推断为方法1的返回类型没问题。但如果初始化表达式本身有重载歧义，某些Java版本会编译出错，这在当时确实遇到过几回。虽然现在版本的编译器改善了不少，但还是建议如果重载方法的参数类型相近且返回类型不同，就不要用var让这个歧义放大。

3. 容器环境感知与JVM内存治理

3.1 容器感知能力的前世今生

JEP 317和JEP 307这一组改动，本质上都是围绕“JVM在现代部署环境下如何自适应的”来做的。先说容器感知。

在JDK8以及更早的版本中，JVM读取内存和CPU信息时依赖的是操作系统的/proc/meminfo和/proc/cpuinfo这类系统级视图。这意味着当你把Java应用放进容器，并且容器设置了内存上限（比如-m 2g）时，JVM不会感知到这个上限，它依然按照宿主机的总内存来计算默认堆大小。这个问题的后果是典型的“容器内内存溢出”：宿主机有64G，JVM默认堆可能开出32G，但容器只允许2G，应用一启动就面临内存超限被OOMKilled。

JDK10的一个关键改动是JEP 317在JDK10中不是直接实现全部特性，而是为后续版本做了铺垫。真正让容器感知能力落地的是JDK8u191和JDK10的后续更新。不过JDK10的发布说明里明确了容器环境的内存和CPU检测逻辑改进方向，后续的UseContainerSupport参数（默认开启）就是在这条线上完善起来的。

具体来说，在支持容器感知的版本中，JVM会读取cgroups的配置，从而正确获得容器设置的内存上限、CPU配额等参数。这些信息直接影响：

• 默认最大堆大小（-Xmx）
• 默认初始堆大小（-Xms）
• GC线程数量的选择
• JIT编译线程数量

有了这个能力之后，假设你在K8s里给Pod分配了2G内存并且没显式设置-Xmx，JVM会把最大堆控制在合理范围内（大概是容器内存的1/4到1/2，具体取决于实际算法），而不是按照宿主机物理内存去计算。这个特性对微服务架构普及的意义非常大，可以说没有它，Java在容器里跑起来始终是有阴影的。

3.2 G1并行Full GC的机制解读

再来聊JEP 307。这可能是JDK10里对生产环境影响最大的一个内部改进。

先简单铺垫一下G1的基础知识：G1把堆划分成很多大小相等的Region，通过维护一个优先级列表来回收垃圾最多的Region，以此来控制停顿时间。在绝大多数情况下，G1都可以通过并发标记清理（并发模式）来回收垃圾。但总有一些特殊场景（比如并发清理失败、大对象分配失败、晋升失败），G1不得不走Full GC这条兜底路径。

在JDK9以及更早版本中，G1的Full GC是单线程的。这就很致命了——堆如果开到了几十个G，单线程做一次Full GC可能要几十秒甚至几分钟。这种“世界停顿”在生产环境几乎是不可接受的。

JDK10的JEP 307把G1的Full GC从单线程改成了并行回收。具体做法是在Full GC阶段使用多个GC线程并行处理对象标记、复制和清理工作。GC线程数量默认由JVM根据CPU核心数来定，也可以通过-XX:ParallelGCThreads来调整。

这样说可能还不够形象。打个比方：单线程Full GC就像一个人打扫整个体育场，并行GC则是叫来一支保洁团队分工合作，把座椅区、走道区、看台区分别承包给不同的人同时打扫。理论上，并行GC可以把Full GC的耗时为原来的约1/N（N为并行线程数）。当然这只是理想化估算，实际受限于内存带宽、锁竞争等因素，但效果依然是非常明显的。

在当时的实测中，一个堆大小为12G的应用在GC日志中显示Full GC从之前的3.2秒降到了0.8秒左右，停顿时间减少了大约75%。对于还没有升级到ZGC或Shenandoah的应用来说，这个改进可以说是雪中送炭。

3.3 堆内存分配在备用内存设备上

JDK10里的JEP 316引入了对NVDIMM（非易失性内存）这类备用内存设备的堆分配支持。它允许JVM使用-XX:AllocateHeapAt参数指定堆文件路径，本质上是让JVM把堆的底层存储放在一个指定的文件或设备上。

我在实际应用场景中很少用到它，因为普通服务器没有NVDIMM这样的硬件。它的目标用户是那些对内存容量要求极高、希望扩展内存但预算又不够上大内存条的团队，这种场景下确实可以绕一下。值得留意的限制是，它只在Linux系统上工作，而且堆文件路径对应的存储设备必须支持mmap。听起来很美好，但传统企业生产环境要专门采购这种内存设备，门槛还是比较高的。

3.4 内存治理实战注意事项

在容器环境下跑Java，即使JDK10及以上版本默认开启了容器感知，我仍然建议显式设置关键内存参数。下面是几组常用的配置：

java -XX:MaxRAMPercentage=75.0 \ -XX:InitialRAMPercentage=75.0 \ -XX:MinRAMPercentage=50.0 \ -jar app.jar

用百分比的方式设置堆大小，比固定-Xmx更灵活，尤其在K8s环境中根据Pod限额自动适配。需要强调一点：MaxRAMPercentage是基于容器的内存上限来计算的，如果容器上限设了2G，75%就是1.5G堆。剩下的0.5G留给JVM自身的元空间、线程栈、直接内存等。经验值上，堆占容器内存的50%到75%都是合理的区间，具体看应用的类型。高并发IO型应用需要留更多堆外内存，可以适当调低堆占比；计算密集型应用堆占比可以高一些。

还有一个比较容易踩的坑：如果不设置-XX:MaxDirectMemorySize，那么直接内存的默认上限等于堆大小。这在容器空间本来就很紧张的情况下，可能导致超限。尤其是Netty等框架重度使用堆外内存，这里建议显式设置-XX:MaxDirectMemorySize，给堆外内存留出明确的空间。

4. 应用类数据共享（AppCDS）优化启动速度

4.1 类数据共享的原理

应用类数据共享，简称AppCDS，是JDK10中最能直接感受到“提速”的特性之一。它的核心思路是：把类加载过程中的元数据（类定义、方法字节码、常量池等）预先处理并保存到一个归档文件中，下次启动的时候直接映射读取，跳过类解析和验证的阶段，从而降低启动时间、减少内存占用。

要理解这个机制，得先回顾一下CDS（Class Data Sharing）在JDK5的时代就已经存在的雏形。很久之前的CDS只支持引导类加载器（也就是JDK自身的类），而AppCDS扩展了能力，让应用类也能参与归档。默认的CDS归档文件是classes.jsa，位于JDK安装目录下，保存的是核心类库的类数据。

4.2 从创建归档到实际使用

实施AppCDS的步骤并不复杂，主要包括：用-XX:ArchiveClassesAtExit方式创建归档，或者用-XX:SharedArchiveFile指定归档来进行启动测试。我日常操作主要用前者。

先演示标准的流程。假设应用主类叫com.example.Main，下面是一个比较典型的操作序列：

# 第一步：导出归档文件 java -XX:ArchiveClassesAtExit=app.jsa \ -cp app.jar \ com.example.Main # 第二步：启动时使用归档文件 java -XX:SharedArchiveFile=app.jsa \ -cp app.jar \ com.example.Main

第一次执行不带归档的启动，应用正常跑一次；第二次带上归档，JVM从归档中映射类数据，不再重复做类加载全过程。实测中，对于Spring Boot这样的框架，启动时间普遍可以降低15%到30%。如果应用本身类路径复杂、启动类多，收益可能会更大。

还有一种进阶方式是配合-Xshare:on参数使用，它会强制要求共享归档可用，如果归档不可用，JVM会直接启动失败，而不是回退到非共享模式。生产环境建议用这种方式来确保每次启动都确实享受到了CDS的加速效果。

app.jsa这个归档文件本质上是一个静态快照，它记录了“当时那个类路径下所有类的元数据”。如果你的应用每次启动用的类路径一样，归档就能精确命中；如果类路径变了，JVM会尝试去匹配类路径，不匹配的部分就会回退到正常加载，但也不会崩。要注意的是，归档文件跟JDK版本强绑定，升级JDK之后必须重新生成，否则会直接失效。

4.3 动态归档与后续演进

JDK10的AppCDS还需要手动指定类列表和导出步骤，用起来有一些繁琐。到了JDK12，又推出了“动态CDS归档”（Dynamic CDS Archive），JVM可以自动收集启动过程中加载的类并自动生成归档，这就省去了手动指定类列表的麻烦。

在当时的项目里，我们为了让用户交互类的启动体验更好，专门为服务写了一个“预热脚本”，在构建流水线中运行一个代表真实启动过程的命令，生成归档后和可执行jar包一起打进镜像中。这个优化带来的启动时间下降是很直观的，即使后续升级了JDK11，这个方案也完全延续了下来。如果你的应用是那种冷启动频繁的Serverless函数式部署，AppCDS就更值得研究了。

4.4 与AppCDS相关的踩坑记录

说两个实际遇到的问题。

第一个是Spring Boot应用启动时如果扫描的包很多，归档文件的体积会非常大。我们当时生成过一个200多MB的app.jsa，这不仅浪费空间，还让镜像的拉取时间变长了。后来我们精简了类路径，并配合使用-XX:SharedClassListFile指定类列表来缩小归档范围，才把体积降下来。

第二个是使用JShell或者热部署工具（大量动态生成类的场景）时，AppCDS的收益会明显下降，因为动态生成的类不会在归档里，还是要走一遍完整加载流程。如果业务大量使用CGLIB这类字节码代理技术，需要评估一下收益是否值得折腾。

5. 其他值得关注的小特性与清理项

5.1 统一的垃圾回收接口

JEP 304把垃圾回收器的实现代码从原本散落在JVM各处、重复度很高的逻辑中抽离出来，统一成了一套接口。这个改动的直接意义在于：后续要新加入一个GC（比如JDK11的ZGC、JDK12的Shenandoah）时，JVM的改动成本大幅降低。

对于应用开发人员，这个特性本身没有可感知的影响，但它是整个GC演进过程的必要基础设施。相当于给JVM内部修了一条标准化的“高速公路”，以后各种GC都能更方便地在同一套机制下运行。从架构角度理解这个特性会更容易：没有这个基础设施，每加一个新GC都要把整个JVM的GC调用点全部改一遍，成本高且容易出错。

5.2 基于时间的版本号方案

JEP 322定义了新的版本号格式：$FEATURE.$INTERIM.$UPDATE.$PATCH。

举个例子，10.0.2表示FEATURE版本是10，INTERIM是0，UPDATE是2，PATCH是0。而像10.0.1这种，UPDATE部分是1，安全更新就在这个数字上递增。这个方案的好处是，你看到版本号就能知道这个版本对应的功能和更新节奏，不用去查发布日期。

这个改动表面上只是版本命名规范，实际上它配合了半年发布周期的策略，让用户对啥时候应该升级、当前用的是什么版本一目了然。后来的JDK11、JDK17甚至LTS版本也都延续了这个编号体系。

5.3 根证书认证

JDK10还做了一个让很多HTTPS排查经历眼泪掉下来的改动：在JDK中内置了一套根证书（CA Certificates）。在JDK9及以前，Java默认没有自己的根证书库，你在访问HTTPS站点时经常遇到PKIX path building failed这类证书校验错误。解决办法一般是在cacerts文件里手动导入整套根证书。

JDK10把常见的公共根证书直接内置进cacerts里面，平时面向公网的HTTPS调用，大多可以开箱即用，不需要再手动导入那些证书链。这个改动平时感知不强，但真遇到的时候会觉得特别贴心。

5.4 移除javah与线程局部握手

JEP 313删掉了javah这个C语言头文件生成工具。之前用JNI开发本地方法时，需要通过javah生成C/C++头文件，JDK10里这个工具被标记为移除，功能并入到javac -h命令里面。如果你维护过JNI代码，应该对这个移除有切肤之痛：稍不注意用旧命令就会报错。实际上javac -h从JDK8就开始提供了，JDK10只是正式把旧工具清掉。

JEP 312（线程局部握手）属于JVM内部的机制改进。它允许JVM在不停止所有线程的情况下，只对特定线程执行操作。这个能力在后来的JFR安全事件采样、偏向锁撤销等场景中发挥了作用。对应用层开发没有直接影响，但它的存在让JVM的暂停更加精细化了。

6. 迁移到JDK10时的注意事项与兼容性排查

6.1 从JDK8或JDK9升级的场景差异

先说从JDK8升级到JDK10的情况。这类升级跨度较大，JDK9引入的模块化系统会带来很多类路径和模块描述符上的问题。最典型的例子是原本使用rt.jar或tools.jar中类的项目，在升级后立刻找不到类。因为这些内部JAR在JDK9之后被移除了，替换成了java.base等模块系统。

如果你只是直接替换JRE，没有为JDK9的模块系统做适配，那JDK9本身就已经暴露出问题了。很多团队的策略是绕过JDK9直接跳到11，因为JDK11是之后第一个LTS版本，升级代价一次到位。但JDK10作为过渡版本，兼容性上和JDK9是同一套模块模型，从JDK9升级到JDK10的改动很小；从JDK8直接升级到JDK10则需要重点排查模块相关的报错和第三方库的兼容性。

再说从JDK10往后的迁移。JDK11删除了Java EE模块（比如java.xml.ws中的JAX-WS等），如果项目中还在用Java EE相关API，直接升JDK11会报java.lang.NoClassDefFoundError。所以在JDK10阶段就该提前排查这些API的使用情况。JDK10里这些模块还是存在的，但已标记为废弃，升到11的时候就会移除。

6.2 第三方框架与字节码库兼容性

升级JDK版本时，除了业务代码，还要排查所有引入的字节码操作库和框架。比如当时比较常见的问题有：

• 某些版本的CGLIB无法在JDK10上正常工作，因为CGLIB内部实现的字节码生成逻辑和模块系统冲突。
• 某些老版本的ASM库不支持Java 10的class文件版本（54.0），导致运行时报IllegalArgumentException: Unsupported class file major version 54。
• Spring Boot旧版本对JDK10的支持不完整，尤其反射操作较多时可能出现InaccessibleObjectException。

排查思路很固定：把项目依赖里的ASM、CGLIB、ByteBuddy这类库列出来，逐一确认它们的版本是否支持class文件版本54。如果某个不确定，就先去对应框架的Release Notes里找兼容性说明。

当时我们有一个内部工具链，依赖ASM做代码增强，升级JDK10第一天就炸了。排查日志发现是ASM版本太老，不支持class文件54。最后升级了ASM、同时把CGLIB替换成了ByteBuddy方案，问题才解决。所以如果你要升级JDK10，建议升级前先看一遍框架的官方兼容矩阵。

6.3 构建工具与IDE支持

Java 10发布时，构建工具和IDE的适配情况参差不齐。先说Maven，需要升级到Maven 3.5.0以上版本，并且配合maven-compiler-plugin3.7.0及以上版本，才能正确处理--release 10参数。如果插件版本过老，会默认按JDK1.8编译，导致无法使用var等新语法。Gradle当时适配得比较慢，Gradle 4.6才开始支持Java 10，之前版本直接会报“无法识别Java 10”的错误。

IDE方面，IntelliJ IDEA在2018.1版本开始完全支持Java 10，Eclipse则需要Photon版本。如果你用老版本IDE打开JDK10项目，代码会报很多奇怪的语法错误，比如var被标红，即使Maven命令行编译没问题。这不是代码问题，纯粹是IDE的语法解析器没有跟上。

6.4 升级操作清单参考

下面是一份比较完整的升级检查清单，适合直接用来落地执行：

• 检查JDK版本：确认当前所有运行环境统一为JDK10。
• 更新构建工具：Maven最低3.5.0、Gradle最低4.6、Maven编译器插件3.7.0+。
• 检查class文件版本：使用javap -verbose 类名查看major version，确认为54。
• 排查字节码库和框架：确认ASM、CGLIB、ByteBuddy、Spring等适配情况。
• 扫描Java EE API依赖：检查是否使用了后续会被移除的模块。
• 验证容器参数：确认容器内存限制下JVM堆设置符合预期。
• 生成AppCDS归档并验证启动速度收益。
• 全量跑回归测试，重点关注反射和模块访问类错误。

这些操作做完之后，JDK10的升级基本就能顺利落地了。

7. 常见问题排查实录

记录几个实际项目中遇到的高频问题，以及对应的排查路径。

问题一：报错java.lang.IllegalArgumentException: Unsupported class file major version 54

这说明某个库的字节码处理工具版本过旧，不支持Java 10的class文件版本。处理方法：升级ASM到7.0及以上、CGLIB到3.2.9及以上、ByteBuddy到1.8.0及以上。如果依赖传递链比较复杂，用dependency:tree把相关依赖找出来，再逐个排除升级。

问题二：默认堆大小异常，容器的内存限制没有生效

先确认JDK版本是不是真的满足容器感知的要求。如果用的是JDK10的早期版本，或者启动命令中存在-XX:UseContainerSupport=false这类参数，容器感知会被关闭。还有一种可能是容器没设置内存上限，JVM认为可以使用宿主机全部内存。排查步骤：先看启动日志里有没有打印Container memory limit相关字样，再用java -XX:+PrintFlagsFinal -version | grep MaxHeapSize查看实际生效的堆大小。

问题三：启动时Unable to map shared file之类的AppCDS报错

通常是归档文件和应用类路径不匹配导致的。处理办法是重新生成一次归档，确保生成归档时的类路径和实际运行的类路径完全一致。也可以加上-Xshare:auto让JVM在归档不匹配时自动回退，但这样就享受不到加速了。

问题四：升级JDK10后，Spring Boot应用启动时出现InaccessibleObjectException

这是模块系统和反射的经典冲突。在JDK9之前，反射可以随意访问任意类；模块化之后，如果目标包没有向反射机制开放，就会报这个错。处理方法有三种：给JVM加--add-opens参数，把相关的包显式打开；升级Spring Boot版本；改动代码减少深反射的使用。经验上，最省事的是先把java.base模块中对应的包加上--add-opens，撑过升级窗口再慢慢改造。

问题五：IDE报错但命令行编译正常

绝大多数情况是IDE的JDK版本配置错误。检查项目SDK设置是否选择了JDK10，以及IDE的语言级别是否设置为10。IntelliJ IDEA里Language Level在2018.1版本后才默认支持Java 10，如果还停留在旧版本，建议升级IDE。

问题六：老项目启动时Could not find or load main class

有些老项目习惯用java -cp手写类路径，升级后可能因为模块系统的路径分隔符和处理方式不同导致类路径解析异常。确认一下java.class.path属性的实际内容，看是否有包含空字符串或相对路径的写法。

8. 写在最后的个人体会

JDK10是我个人认为“从JDK8到现代Java中间最舒服的过渡站”。它没有上来就砍掉老功能，也把很多新能力（var、G1并行GC、容器感知、AppCDS）引入到生产可用的状态。如果你还在JDK8上挣扎，我建议跳跃升级时先花一两天在JDK10上做一个预检和适配验证，看看第三方的字节码工具库、反射使用、模块化兼容这些关键点，再决定直接上JDK11还是先进入10试水。这样后续升级会顺畅很多。

最后分享一个小技巧：升级后别急着删掉旧的JDK8，把两套JDK的bin目录同时放到PATH里，用JAVA_HOME切换版本。在项目里用Maven的Toolchain机制绑定不同JDK版本，这样同一个机器上编译不同版本的项目都不会冲突。我当年用这个方案，顺手就把一堆老项目的“能不能升”问题全部摸底清楚了，效率特别高。