JDK 8 升级到 JDK 11 存在显著兼容性风险：模块系统变更导致 NoClassDefFoundError；Java EE/CORBA 模块被移除需手动引入替代依赖；正则语义变化引发逻辑失效；构建工具、JVM 参数及 GC 策略需同步更新；模块化访问限制要求显式开放内部 API。
直接说结论：JDK 8 升级到 JDK 11 不是“改个版本号就能跑”，核心风险集中在模块系统变更、API 移除、正则语义变化和第三方库兼容性上。很多项目卡在启动阶段就报 NoClassDefFoundError 或 ClassNotFoundException，不是代码写错了，而是 JDK 11 默认不加载某些曾经内置的模块。
Java EE 和 CORBA 模块被彻底移除
JDK 11 删除了 java.xml.ws、java.xml.bind、java.xml.soap、java.corba 等模块，这些在 JDK 8 中是默认可用的。如果你的项目或依赖（比如老版 Spring Boot 1.x、Axis2、JAXB 注解序列化）直接用了 javax.xml.bind.JAXBContext 或 javax.xml.ws.Service，运行时会立即抛出 NoClassDefFoundError。
解决方式不是降级，而是显式引入替代依赖：
-
javax.xml.bind:jaxb-api:2.3.1+org.glassfish.jaxb:jaxb-runtime:2.3.1 javax.xml.soap:javax.xml.soap-api:1.4.0-
com.sun.xml.ws:jaxws-ri:2.3.3（注意用 pom 类型）
别用 com.sun.xml.bind:jaxb-impl 单独引入——它不带 API，必须配对 jaxb-api 才能编译通过。
正则表达式中 [^] 和交集运算符行为变更
JDK 9 起，正则引擎对字符类取反的解析顺序变了：[^a-d&&e-f] 在 JDK 8 中先执行 ^a-d 再与 e-f 取交；JDK 11 中先算 a-d&&e-f（结果为空），再取反（即匹配所有字符）。这种差异会导致权限校验、输入过滤等逻辑静默失效。
检查你代码里所有含 ^ 和 && 的正则，尤其是用于白名单/黑名单的场景。临时兼容方案是加 -Djdk.lang.ProcessHandleImpl.disableSystemExit=true 没用——得改正则本身。稳妥写法是拆开写：[^a-d][^e-f] 或用 Pattern.compile("(?![a-d])(?![e-f]).") 显式表达意图。
构建工具和 JVM 参数要同步更新
Maven 必须 ≥ 3.5.0，否则 maven-compiler-plugin 无法识别 11 作为 source/target 值；IDEA 需 ≥ 2018.2，且项目 SDK 和 Project bytecode version 要分别设为 JDK 11；Lombok 需 ≥ 1.18.10，否则注解处理器在模块路径下失效。
JVM 参数方面：-XX:+PrintGCDetails 和 -XX:+PrintGC 已废弃，要用 -Xlog:gc* 替代；-XX:MaxPermSize 完全无效（元空间已取代永久代），删掉即可；如果用了 -XX:+UseConcMarkSweepGC，必须换成 -XX:+UseG1GC——CMS 在 JDK 11 中已被移除。
GC 策略不能照搬 JDK 8 的经验
G1 在 JDK 11 中默认启用且性能提升明显（压测显示平均快 16.1%），但它的行为更激进：比如默认启用 -XX:+UseStringDeduplication，对堆外内存敏感的服务可能引发 OutOfMemoryError: Direct buffer memory。如果你的应用大量使用 Netty 或 NIO，务必升级 netty-all ≥ 4.1.33.Final，否则堆外内存泄漏风险陡增。
小内存机器（≤ 4G）别盲目跟风 G1，Parallel GC 吞吐量更稳；大内存（≥ 8G）且延迟敏感的场景，G1 配 -XX:MaxGCPauseMillis=200 效果通常比调优 CMS 更省心。CMS 彻底别碰——它在 JDK 11 中不存在。
最常被忽略的一点：JDK 11 的模块系统（--add-modules、--add-exports）不是可选项。当你用反射访问 sun.misc.Unsafe 或修改 java.base 内部类时，必须显式开放，否则 IllegalAccessError 会在运行时才暴露，CI 流水线可能一路绿灯，上线后秒挂。
