BLOG
拾闻对谈 第十六期｜Java 27 发布：AI 写代码的年代，这个老语言在忙什么？
开场：一封安静的邮件，和一个快三十岁的语言照例交上的半年作业
9 月 15 日，OpenJDK 首席工程师 Mark Reinhold 在 announce 邮件列表发出一封短信：JDK 27 正式 GA，build 35。从 8 月 20 日 RC2 到正式版，没有再出现任何一个 P1 级 bug。GPLv2 授权的 OpenJDK 构建，当天就能在 jdk.java.net/27 下载。在 AI 编程工具几乎周更的 2026 年，这个快三十岁的语言照例每半年交一次作业——这一次只有 9 个 JEP，没有轰动性的新语法，安静得像一次例行维护。
但细节值得咂摸。9 个 JEP 里，对用户钱包影响最直接的两件事恰好都不是语法：G1 垃圾回收器成为所有环境的默认（JEP 523），紧凑对象头默认启用（JEP 534），全是省内存的。与此同时，后量子混合密钥交换进了 TLS 1.3（JEP 527），一个明显为十年后准备的改动。而另一边厢，原始类型模式匹配第 5 次预览、结构化并发第 7 次预览、Vector API 干到了第 12 个孵化器版本——有人管这叫严谨，也有人管这叫拖沓。
拾闻：AI 写代码写得飞起的年代，Java 发了这样一版，你的第一反应是什么？
永亮：不是「Java 还行不行」，是「这两件事终于被设成默认了」。省内存的改动比新语法更能打动我——我在天津一家医院集团管技术，手里几百个 JVM 服务，堆小一分，账单就瘦一分。至于 preview 磨了几轮，咱们慢慢聊。
拾闻：那咱们就聊透：AI 编程时代还写 Java 是不是守旧、预览马拉松是严谨还是拖沓、为什么这版最重要的是两个默认项、后量子布局 AI 公司为什么不谈、以及给留在 Java 生态的人三条实在建议。
Q1：AI 编程时代，还写 Java 是不是在守旧？
永亮：不是守旧，是分工。AI 写得越快，跑这些代码的机器越累，而 Java 三十年攒下的恰恰是「让代码不出事」的那套底盘。
AI 工具把写代码这个环节的速度抬了一个量级，我团队里用 AI 写代码的人早就超过一半，这没什么可回避的。但有个事实常被忽略：AI 写得越多，跑这些代码的机器越累。生成的代码不会自己运行，它要占内存、要回收、要在凌晨两点扛住定时任务。我所在的是天津一家医院集团，挂号、缴费、检验这些系统大部分跑在 JVM 上，其中不少活过的时间比大多数 AI 公司的岁数还长。Java 的价值从来不在语法新不新——平心而论，它的语法一直是「够用但不好看」那一类——而在三十年攒下的运行底子：成熟的垃圾回收器、可以逐行分析的观测工具、出问题一搜就有答案的社区。所以「AI 编程时代还写 Java 是不是守旧」这个问题本身问错了方向。真实的分工是：AI 负责把代码写出来，JVM 负责让代码不出事。写代码的门槛在降，让系统不出事的门槛从来没降过。对一个要跑十五年的系统来说，「守旧」有时候就是「靠谱」的别名。
Q2：一个特性预览五遍、一个并发磨七轮、一个 API 孵了十二版——这是严谨还是拖沓？
永亮：这是 Java 和 AI 行业在赌两件不同的事。AI 赌「先上线再改」，Java 赌「改错了的代价远大于晚一点」。两种赌法都对，前提是你输不输得起。
先说两边的赌注。AI 行业赌的是「先上线再改」：对话类产品出错的代价是一次糟糕的回答，关掉重开就翻篇了，所以周更、甚至日更都合理。Java 赌的是另一个方向：语言规范一旦定稿就是永久的，泛型的类型擦除提了二十多年也没改回来，受检异常的争论从 JDK 5 吵到今天还在吵。一个收不回去的决定，多磨几年是理性，不是拖延。而且「预览」这个机制本身就是在对抗拖沓——它让数以百万计的生产环境用户在特性没定稿前就能真刀真枪地试，反馈直接改规范。结构化并发从第 1 版磨到第 7 版，改掉的正是真实用户踩出来的坑。当然，代价是真实的：你今年就想要的原始类型模式匹配，还得再等几个版本才能转正。我的态度很直白：你要是创业公司，这个节奏会憋死你，别硬融；你要是维护一个要活十五年的系统，你会感谢有人替你慢——特性晚到三年，比错误跟一辈子划算。
Q3：为什么这一版最重要的不是新语法，而是两个「省内存」的默认项？
永亮：因为企业真实的疼处在账单上，不在语法上。9 个 JEP 里对钱包影响最直接的两个，恰好都是省内存的——这绝不是巧合，是这门语言的用户画像决定的。
先看版本结构。Java 25 是去年 9 月的 LTS 版本，27 是非 LTS，下一个 LTS 预计是 JDK 29。对企业来说，真正大规模升级只发生在 LTS 上，所以 27 里的新特性，多数生产环境要到 29 才真正用上。那为什么说 27 重要？因为它把两件省内存的事变成了默认行为。第一，G1 成为所有环境的默认垃圾回收器——以前选 GC 是个需要论证的技术决策，现在不用选了，大堆服务开箱即用的就是这个按停顿目标优化的回收器。第二，紧凑对象头默认启用，显著降低了每个 Java 对象的头部内存占用。这两个特性都不性感，但它们直接改的是账单：一个医院集团跑着几百个 JVM 服务，堆占用缩小一成（这是我个人的估算，不是官方数字），省下的就是真金白银的内存采购和云费用。语法糖让开发者开心，小堆让财务开心。在企业里待久了你会明白：能被写进采购申请的理由，比能被写进发布会的理由值钱得多。
Q4：后量子密钥交换进了 TLS 1.3——老牌语言在替十年后布局，AI 公司为什么很少谈这个？
永亮：因为两者的客户对「十年后」的定价完全不同。医院数据要存几十年，「先存下来、以后再解密」的威胁今天就在发生；而大部分 AI 产品的数据生命周期不到两年，锁还没生锈，产品就先下线了。
JEP 527 做的事，是在 TLS 1.3 的握手里同时用传统算法和抗量子算法各算一份密钥，任何一边被攻破都不致命。为什么要现在做？因为「先存储、等量子计算机成熟了再解密」这种攻击，今天就在发生：攻击者截取你现在的加密流量存着，十年后再拆锁。医疗数据的保存期限以几十年计，今天挂号系统里的一次握手，密文可能到 2040 年代还有法律意义——所以对医院来说，这是现在就要付账的风险，不是十年后的故事。而大部分 AI 创业公司的数据生命周期不到两年，训练集几个月一换，产品的锁还没生锈就先下线了，自然没人急着谈换锁。这不是谁高谁低，是时间尺度不同：老牌语言的用户在替 2040 年做预算，AI 行业的客户在赌六个月后自己还在不在——各自理性，互相不必嘲笑。
Q5：给还留在 Java 生态的人三条实在建议
永亮：三条，按顺序来：生产只升 LTS、把省内存当正经指标、让 AI 写代码但别让 AI 替你拿架构决定。
第一条，生产环境只升 LTS，别追新。Java 25 是现行 LTS，27 可以用来试、用来读、用来当团队的技术雷达，但别上生产；下一个 LTS 预计是 JDK 29，到那时候再把 27 和 29 里成熟的东西一起收。新版本焦虑症在这个生态里是个假问题，真正的风险是追新追出来的兼容事故。第二条，把省内存当成正经指标来管。紧凑对象头默认启用之后，花一周把核心服务的堆占用对比量一遍（这是估算级的工作，但方向不会错），把省下来的内存换算成钱写进季度总结——让老板看见 JVM 调优的回报，比你写十篇技术文章都有用。第三条，让 AI 写代码，别让 AI 拿架构决定。AI 生成的代码越来越多，但依赖选谁、服务怎么拆、数据怎么流，这些决定的影响以年计，必须人来扛。结构化并发磨到第 7 次预览还没定稿，恰恰说明并发模型这种决定有多难——难到需要七轮公开打磨才敢定稿。我干了十七年软件、带过七十人的团队，踩过最贵的坑全是「当时觉得可以先这样」的架构决定，没有一个是语法用错的。
尾声
拾闻：最后，用一句话总结这期？
永亮：AI 决定代码写得多快，JVM 决定系统跑得多稳——写得越快的年代，稳本身就是一种竞争力。
拾闻：这句话，送给大家。下期见。
【技术纵深】对象头里那笔你没写过的开销，G1 和紧凑对象头是怎么联手省下来的
这期的主线是「省内存比新语法更接近企业真实痛点」。给想再深一步的读者拆一层：为什么两个不起眼的默认项，值得占掉 JDK 27 最重要的两个位置。
第一层：对象头存什么。 Java 里每个对象除了你写的字段，还带着一个头部：mark word 记录哈希码、锁状态、GC 标记，再加一个指向类元数据的指针。这些信息你没写过一行代码，但每个对象都背着。
第二层：为什么这笔开销可观。 64 位机器默认开启压缩指针后，一个对象头通常占 12 个字节——对象越小，头部占比越狠。一个只装两个整数的对象，数据 8 字节，头部 12 字节，一多半内存花在「行李」上。应用里有几百万个小对象的服务（缓存、会话、消息队列都是重灾区），堆的大头不是数据，是行李。
第三层：两个 JEP 怎么联手省。 紧凑对象头（JEP 534，这一版默认启用）把头部信息重新编码，显著压缩这部分占用；G1（JEP 523，成为所有环境默认）把堆切成一块块 Region，按停顿目标回收，大堆服务不用再为选回收器纠结。一个让每个对象更瘦，一个让整堆管理更顺。
回到本期主线：新语法解决的是「写代码爽不爽」，对象头和回收器解决的是「账单疼不疼」。对企业来说，疼的地方从来不在键盘上。
本期信息来源
- OpenJDK announce 邮件列表 2026-09-15：Mark Reinhold《JDK 27 General Availability》（build 35，附 9 个 JEP 清单）
- jdk.java.net/27（GPLv2 授权 OpenJDK 构建下载）
- OpenJDK 半年发布节奏与 LTS 命名惯例（2026-09-16 时点口径，下一个 LTS 预计为 JDK 29）