第一章JDK 25 都发了为什么大家还在 Java 8JDK 25 发布那天我特意去看了一眼发布说明。内容不复杂新特性不少语气一如既往地克制像是在告诉你 “你可以升级了但我们不催。”这种感觉我在 Java 世界里已经很熟了。同一天Python 社区的画风完全不一样。Python 3.13 的兼容性讨论、弃用警告、生态适配进度被反复拿出来说。很多库会直接写在 README 里“Python 3.8 即将停止支持请尽快升级。”Java 这边没有这种集体施压。JDK 25 发布了但JDK 8 依然能跑、能用、能上线。我翻了下手头几个线上系统的运行环境结果并不意外老核心系统Java 8偏边缘的新服务Java 11真正用到 17 的只有少数新项目至于 21、25基本只存在于 PPT 和技术分享里这不是个别现象。招聘网站、云厂商镜像、监控 SDK 默认支持版本几乎都在默默告诉你一件事Java 8 依然是“安全版本”你发任你发我用java8。这和 Python 的升级节奏形成了非常明显的反差。Python 2 → 3是一次不升级就活不下去的断代。Java 8 → 25更像是一次你可以一直不动的演进。从技术角度看Java 明明一直在进化语言层面var、record、sealed classJVM 层面GC、JIT、内存模型工程层面模块化、工具链但这些变化没有哪一项是“非升不可”。我见过不少 Java 服务代码风格停在 2016 年但稳定运行到今天。也见过 Python 项目因为一个依赖不再支持旧版本被迫整体升级。这两种生态的差异很早就写在设计选择里了。Java 的向后兼容是它的优势。但到了 JDK 25 这个时间点这个优势开始变得有点微妙。因为问题已经不是JDK 8 能不能用而变成了如果一直停在 JDK 8到底是在保守还是在逃避某些成本这个问题在技术会议上很少被正面讨论。更多时候它会被一句话带过“先别动风险太大。”可风险到底在哪为什么 Python 升级时大家骂归骂还是会跟着走而 Java 这边哪怕官方已经跑到 25企业却依然集体停在 8我后来发现真正卡住升级的从来不是新特性本身。而是升级这件事一旦开始就很难只停在“换个 JDK”上。但这件事只有在你真的尝试过一次升级之后才会意识到。你也就会抱怨为何JDK会把普及新特性的成本强加在每个java开发者身上第二章升级 JDK看起来向下兼容实际上并不“平滑”很多人对 Java 升级的第一判断来自一个几乎写进 DNA 的认知Java 是强向下兼容的语言。这句话本身没错也是大多数人从jdk7到jdk8无缝升级的真实感受。但问题在于大多数人只把它理解成了语法层面。你用 Java 8 写的代码放到 JDK 17、21、25 上大概率还能编译。for、try-catch、Stream、lambda一个都不会少。这也是为什么很多升级评估一开始都显得非常乐观。真正的问题是 Java 的“向下兼容”从来不等于 JVM 的平滑迁移。第一次认真推进 JDK 升级时我们的目标设得非常保守不引入新语法、不改业务逻辑、不升级框架只把运行时从 Java 8 换成 17。理论依据也很充分代码是向下兼容的JVM 只要能跑就行。结果第一个暴露问题的不是业务代码而是 JVM 本身。从 JDK 9 开始Java 做了一次非常激进、但长期看又必须要做的事情模块化JPMS。这一步本质上是在重塑 JVM 的边界。在 Java 8 之前JDK 更像是一个“开放的整体”。JDK 自己的内部实现和应用代码之间并没有严格的隔离。于是很多框架、工具、甚至业务代码都默认了一件事JVM 内部的类我是可以摸得到的。比如反射。Field field String.class.getDeclaredField(value); field.setAccessible(true);在 Java 8这是一个非常常见、甚至被大量框架依赖的操作。但在模块化之后这种行为被明确标记为非法访问Illegal Reflective Access。升级后日志里开始出现大量这样的提示Illegal reflective access by xxx这类 warning 很容易被误判成“噪音”。因为程序还能跑接口也没挂。但实际上这不是 JVM 在提醒你“写得不优雅”而是在明确告诉你你现在还能用是 JVM 在帮你兜底。于是有人会加启动参数--add-opens java.base/java.langALL-UNNAMED问题是从这一刻开始所谓的“向下兼容”已经被你亲手打破了。你不再是被 JVM 兼容而是用参数强行绕过 JVM 的设计边界。这也是 Java 升级过程中一个非常隐蔽的转折点代码层面看起来没变启动参数开始越来越复杂JVM 行为开始依赖“约定俗成的补丁”而这一步一旦走出去基本就退不回去了。更麻烦的是这种不平滑迁移并不是“偶发问题”而是 Java 设计演进的必然结果。模块化不是可选项它是为了限制 JVM 内部 API 滥用提升安全性为长期演进留空间但代价是大量在 Java 8 时代“合理存在”的用法在新 JVM 下被系统性否定了。这也是为什么很多团队会有一种强烈的错觉代码明明没变怎么升级 JDK 反而问题一堆因为你真正升级的不只是一个版本号而是 JVM 对“什么是合法行为”的判断标准。而这类问题偏偏又很难在测试环境一次性暴露完。有的库只在特定路径触发反射有的异常只在高并发下出现有的 warning 今天是 warning下一版就变成 error......这也是 Java 升级和 Python 最大的不同。Python 的升级是显式断代你升级就必须改代码。Java 的升级是隐式收紧你不改代码但 JVM 会慢慢不再纵容你。这种“看起来兼容实际上在变”的特性让 Java 在企业环境里变得越来越尾大不掉。不是升不了而是你永远无法确定下一步是不是会踩到一个你完全没预期过的 JVM 行为变化也正因为这样很多公司最终选择了一个看似稳妥、但风险被推迟的方案停在 Java 8。第三章真正让升级失败的不是编译错误而是线上行为变了如果只是编译报错JDK 升级反而简单。编不过改代码启动不了补参数问题是可定位的也是可回滚的。真正让团队对升级产生恐惧的往往发生在上线之后。升级前所有检查都过了单元测试全绿接口回归没问题压测 QPS、RT 都在预期范围内代码一行没改JDK 从 8 换成 17。上线当天没有事故。第二天开始监控里出现了一些非常微妙的变化。不是报错也不是性能雪崩。而是一些“看起来不该变的行为变了”。最早被发现的是 GC 行为。Java 8 默认用的是 Parallel GC而 JDK 17 的默认已经变成了 G1。当时的判断很简单G1 是“更先进的 GC”不应该比旧的差。但线上数据并不这么配合。Full GC 次数少了Minor GC 次数变多单次停顿更短但更频繁这对 JVM 来说是“健康变化”但对业务来说结果是某些接口的 P99 响应时间开始抖动。不是慢而是不稳定。问题在于这类变化不会在压测里明显暴露。压测关注的是吞吐和平均值而不是长尾。你只能在真实流量下才会看到这些边缘效应。紧接着出现的是更难定位的问题类加载行为的变化。JDK 9 之后类加载和模块边界被重新梳理过。很多“以前恰好能工作”的加载顺序在新 JVM 下变了。最典型的是 SPI 机制。ServiceLoader.load(SomeService.class)体验AI代码助手代码解读复制代码ServiceLoader.load(SomeService.class)在 Java 8 下这段代码的加载顺序是稳定的。在新 JDK 下如果存在多个实现顺序可能发生变化。大多数时候这没什么影响。但如果你的代码里隐式依赖了加载顺序问题就来了比如默认实现被换了没有异常没有日志只是业务行为“和以前不太一样”。这类问题几乎不可能靠自动化测试完全覆盖。因为测试本身也是在“旧认知”下设计的。还有一类更隐蔽的变化来自于 JIT。JVM 在新版本里持续优化编译策略。某些代码路径在 Java 8 下是“冷路径”在新 JDK 下被识别成“热点”。结果是以前不明显的锁竞争被放大原本可以忽略的对象创建开始影响 GC代码没变但 JVM 对代码的“理解方式”变了。这也是为什么很多线上问题在排查时会陷入一种诡异的状态SQL 没变代码没变配置没变只有 JDK 变了而你又很难证明问题真的就是 JDK 引起的。到这一步升级已经不再是技术选型问题了。它变成了一个心理问题。团队开始本能地回避这种“不可解释风险”。即便你知道这些问题不是 JDK 的 bug而是历史代码对 JVM 行为的过度依赖但现实是线上系统不接受“技术上合理”的解释。这也是很多公司在第一次升级尝试之后迅速得出结论的原因不是升不了 而是不值得再为这种不确定性买单。于是升级计划被无限期搁置。Java 8 继续稳定运行问题被推迟而不是被解决。第四章真正的风险不在 JDK而在你不敢动的那一部分代码当升级卡在第三章那些“行为变化”上时团队往往会得出一个结论问题太散了风险不可控。但后来复盘发现真正不可控的从来不是 JDK而是我们不敢去验证的那一块代码。几乎每个中大型 Java 项目里都有这样一层东西没人愿意动但所有人都在用出问题只能回滚它可能是十年前写的公共组件也可能是一次紧急需求里硬塞进去的工具类。在 Java 8 时代这类代码有一个共同特征它们和 JVM 的关系非常近。比如自定义 ClassLoader。public class CustomClassLoader extends ClassLoader { Override protected Class? findClass(String name) { // 从非标准路径加载字节码 } }在 Java 8 下这种实现非常常见。升级之后问题不一定立刻出现。但一旦涉及模块、服务加载或反射行为就开始变得不可预测。再比如字节码增强。无论是早期的 cglib还是基于 ASM 的工具很多实现都默认了某些 JDK 内部类是存在的某些方法签名是稳定的这些假设在新 JDK 下不再成立。更现实的问题是这些代码往往没有完整测试。因为它们本来就不是“业务逻辑”。它们被视为基础设施 被默认是“不会出问题的”。升级 JDK 时测试覆盖率看起来还不错。但真正和 JVM 行为强相关的部分几乎没有被验证过。于是升级就进入了一个死循环不敢上线是因为没验证不验证是因为不敢动不动就永远无法升级这也是 Java 升级和其他语言很不一样的地方。Python 项目里底层行为大多由解释器和库兜住。Java 项目里很多“工程能力”是直接构建在 JVM 之上的。而这些能力恰恰是最难平滑迁移的。还有一个被严重低估的因素是运维和排障成本。Java 8 的排障手段大家已经非常熟悉jmapjstack老一套 GC 日志新 JDK 不是不能用这些工具而是行为、参数、输出都在变化。同一条 GC 日志在不同版本下含义已经不完全一致。这会直接导致一个现实问题出问题时团队是否有信心“看懂”新 JDK 的行为如果答案是否定的那升级本身就是一种冒险。于是你会看到一种很典型的现象开发知道 Java 17 更好架构知道 Java 21 是趋势但一到生产所有人都默认还是 Java 8 吧不是因为它完美而是因为它足够“熟”。升级 JDK本质上不是技术债的清理而是一次对未知的正面接触。而大多数系统并没有为这种接触做好准备。也正因为这样很多公司并不是“卡在 Java 8”而是被 Java 8保护了很多年。第五章真正逼你升级的从来不是技术本身在很多公司里JDK 升级从来不是一个“主动议题”。它通常出现在某个非常具体、而且很现实的场景里。比如云厂商的一封邮件。内容往往写得很克制大概意思是某某 JDK 版本即将停止安全更新 请尽快规划升级方案这类邮件第一次看到时大多数人并不会紧张。因为“即将”往往意味着还有一段缓冲期。真正产生压力的是第二封、第三封。当你发现云厂商的默认镜像开始发生变化新建实例已经不再提供 Java 8升级这件事就从“技术选择”变成了外部约束。还有安全审计。Java 8 的漏洞并不比新版本多。但问题在于很多漏洞在 Java 8 上不再修了。这意味着同样一个问题在新 JDK 上是一个补丁在 Java 8 上是一个长期风险安全团队不会和你讨论 JVM 设计演进。他们只看结果有没有官方支持有没有风险背书。接着是第三方生态。越来越多的中间件、SDK、监控工具开始把“最低支持 JDK”往上抬。不是突然抛弃 Java 8而是新功能不再考虑它。你会慢慢发现想用新版本框架 → 需要新 JDK想接入新工具 → 官方不再测试 Java 8想拿到性能优化 → 只在新 JVM 生效这时候继续停在 Java 8 的成本开始显性化。不是系统跑不动而是你被锁在一个越来越狭窄的选择空间里。更现实的是人员问题。新来的工程师默认使用的已经是 Java 17 甚至更高版本。他们熟悉的是新工具链、新调试方式。当他们面对一套 Java 8 的系统时不是学不会而是很多问题的解决路径已经不在他们的经验范围内了。这会让“稳定”变成另一种风险。因为稳定的前提是有人能长期维护它。到这一步升级已经不再是“要不要”的问题。 而是变成了现在升级还是被动升级很多团队选择继续拖延希望把升级成本压到最低。但现实往往是拖得越久升级的边界越难控制。当升级真的不可避免时你已经不再有“慢慢试”的空间。而这才是 Java 8 最危险的地方。它让你误以为时间是站在你这边的。第六章一次相对靠谱的 JDK 升级应该从哪里开始真正开始升级之前有一件事必须先想清楚你这次升级是为了“到达某个版本”还是为了“验证系统能否继续演进”。这两个目标看起来很像路径完全不同。很多失败的升级问题就出在一开始选错了目标。如果你只是想“把 Java 8 换成 17”那你会天然倾向于尽量不改代码尽量不动依赖尽量让系统看起来“没变”但这种升级方式本质上是在赌赌 JVM 的变化不会触发你没覆盖到的路径。相对靠谱的升级第一步反而是承认一件事有些问题不是升级带来的 而是升级帮你提前暴露出来的。所以真正的起点往往不是生产环境而是一个可以被随时推翻的验证环境。不是单元测试也不是本地跑一下。而是把完整应用用新 JDK 跑起来。不接真实流量但一定要接真实配置、真实依赖、真实启动参数。很多团队在这里就已经踩到了第一个坑启动参数。Java 8 下积累了大量 JVM 参数其中不少早已被废弃甚至在新版本里直接失效。你会看到类似这样的警告Ignoring option PermSize; support was removed in 8.0在 Java 8 你还能“假装没看到”在新 JDK 下它会直接提醒你这些参数已经没有意义了。清理这些参数本身就是一次风险排查。不是“能不能启动” 而是启动之后哪些地方开始行为变化。这里有一个非常实际的做法在同一套代码下同时跑两个版本的 JVM。一套用 Java 8一套用目标 JDK对外提供同样的接口跑同样的请求。不需要全量对比结果但要盯几个关键指标P99 延迟GC 行为异常日志类型是否变化很多问题不是“新版本一定有 bug”而是你第一次看到了原来就存在的极端情况。还有一个经常被忽略的点日志和监控工具本身是否适配新 JDK。有些 agent 在 Java 8 下工作得很好但在模块化之后注入行为发生变化。结果不是监控失效而是监控数据“看起来正常其实已经不完整”。如果你在升级过程中突然发现某些指标消失了那不是系统变健康了而是你少看了一部分。这也是为什么靠谱的升级节奏通常很慢。不是因为技术上推进不了而是你需要时间去重新建立“我对这个系统行为的信心。”到这里升级才算真正开始。不是宣布成功而是你终于知道哪些问题是 JDK 带来的哪些问题是历史债务哪些地方必须在升级过程中一起解决而这一步几乎不可能一蹴而就。也正因为这样很多公司在真正启动升级后才意识到一件事升级 JDK其实是在逼自己重新理解系统。而这件事本身就是一次不小的工程。第七章如果一直不升会发生什么在很多团队内部其实都默认了一种状态不升级不代表现在就有问题。这句话在相当长的一段时间里都是成立的。Java 8 足够稳定线上系统运行多年没有明显的性能瓶颈也没有无法解决的故障。于是“暂时不升”逐渐变成了“长期不升”。真正的问题是这种状态并不是静止的。最先发生变化的往往不是系统本身而是它所处的环境。云厂商开始调整基础镜像CI/CD 环境里的默认 JDK 版本往前走安全扫描工具对旧版本的容忍度越来越低你会发现原来“理所当然”的前提一个一个消失了。接着是依赖生态。一开始只是新功能不支持 Java 8后来变成新版本直接不再测试再后来是明确标注不兼容。这时候你还能苟住靠锁版本、靠私服、靠内部维护。但代价在慢慢累积。每一次新需求评估都会多一个隐含条件这个东西能不能在 Java 8 上跑这个问题一旦出现得足够频繁系统就已经被版本反向塑形了。更危险的是问题开始延迟出现。很多在新 JDK 下会被立刻暴露的行为问题在 Java 8 下被默默吞掉。你看不到 warning也感受不到约束。直到某一天你必须升级。那时候你面对的已经不是一次版本迁移而是一堆被时间放大的设计问题。而升级窗口反而更小了。因为这次升级不是你主动选的。可能是安全合规要求外部依赖强制云平台策略调整你已经没有“慢慢试”的空间。于是很多团队会在这个阶段做出一个看似合理的选择那就继续顶着吧能跑一天是一天。问题在于这条路并不是线性的。系统越老理解成本越高可控范围越小。最终你会发现你并不是在“稳定运行一个老系统”而是在维护一个越来越没人敢动的黑盒。这时候Java 8 不再是你的缓冲垫而是你的时间锁。而你已经很难判断现在不升级到底是在规避风险 还是在把风险推给未来一个更糟糕的时刻这一点很多团队只有在真正被逼到墙角时才会意识到。结语也许问题不只在我们写到这里再回头看“为什么还卡在 Java 8”很多原因已经很清楚了生态复杂历史债重升级风险真实存在但如果只停在这里其实有点不公平。因为有一个问题很少被正面拿出来讨论Java 真的做到“向下兼容”了吗从语法层面看是的。Java 8 写的代码放到 JDK 25大多数还能编译。但从工程和运行时层面看答案并没有这么确定。JDK 9 之后JVM 的内部结构、边界、约束被系统性地重构过。模块化不是补丁是一次方向性的调整。这个调整本身没有错。甚至可以说是 Java 走向长期可维护性的必经之路。问题在于JDK8之后演进的成本几乎全部落在了使用者身上。旧代码还能跑但开始被警告旧用法还能用但需要加参数旧依赖还能凑合但不再被官方支持从结果上看JDK 并没有为“平滑迁移”提供一条真正低成本的路径。它选择的是保证不立刻崩 但也不保证你能轻松往前走。这是一种非常 Java 的工程取舍。向后兼容被理解成“不破坏既有运行”而不是“帮助你完成迁移”。于是一个微妙的局面就出现了JDK 在持续演进企业系统被留在原地升级的代价被默认为“业务方应该承担的成本”当升级困难时我们习惯反思自己的架构、代码、历史债。但很少有人问一句如果一个平台的演进让大多数成熟用户都不敢升级 那这个演进路径是否真的对“工程用户”友好也许这并没有标准答案。Java 选择了稳定、选择了克制、选择了长期演进。而代价是把升级这件事变成了一次高认知门槛的工程决策。所以今天还停在 Java 8 的团队未必是保守也未必是技术债失控。有时候只是因为他们不想为一次并不完全由自己造成的不连续演进 付出过高的试错成本。当然这并不意味着一直停留就是对的。只是到了 JDK 25 这个节点也许我们该承认一件事Java 的升级之所以难 并不只是因为系统老 也因为这条升级路本身就不够平坦。而要不要踏上这条路现在依然没有一个放之四海而皆准的答案。原文链接https://juejin.cn/post/7599551824548397082