Java 26 发布了，我人麻了。。

钱都都 發表於 2026-3-23 19:16:00

大家好，我是R哥。
Java 25 刚发布半年之久（Java 25 正式发布），很多人可能还没听说过，现在 Java 26 又来了，我真的人麻了啊。。。
<img src="https://www.javastack.cn/images/img3/20260322201137461.png">
需要注意的是，Java 26 并不是 LTS（长期支持版本），千万不要用在生产环境里，因为它许多特性还在预览阶段，可能会有不兼容的变动。
废话不多说了，下面我们来看看 Java 26 都有哪些新特性。。
<h2 id="如何下载">如何下载</h2>
Java 26 的下载入口：
<blockquote>
https://www.oracle.com/java/technologies/downloads/
</blockquote>
<img src="https://www.javastack.cn/images/img7/20260322201710098.png">
如果你只是想本地装个环境体验一下，直接下就行，但千万别打算拿去跑生产。。
<h2 id="版本定位">版本定位</h2>
这次得说明下，Java 26 并是一个长期支持的大版本，上一个长期支持的版本是 Java 25，如下表所示：
<table>
<thead>
<tr>
<th style="text-align: left">版本</th>
<th style="text-align: left">发布日期</th>
<th style="text-align: left">优先支持期限</th>
<th style="text-align: left">延长支持期限</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left">8 (LTS)</td>
<td style="text-align: left">03/2014</td>
<td style="text-align: left">03/2022</td>
<td style="text-align: left">12/2030</td>
</tr>
<tr>
<td style="text-align: left">9 - 10 (non-LTS)</td>
<td style="text-align: left">09/2017</td>
<td style="text-align: left">09/2018</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">11 (LTS)</td>
<td style="text-align: left">09/2018</td>
<td style="text-align: left">09/2023</td>
<td style="text-align: left">01/2032</td>
</tr>
<tr>
<td style="text-align: left">12 - 16 (non-LTS)</td>
<td style="text-align: left">03/2019</td>
<td style="text-align: left">09/2021</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">17 (LTS)</td>
<td style="text-align: left">09/2021</td>
<td style="text-align: left">09/2026</td>
<td style="text-align: left">09/2029</td>
</tr>
<tr>
<td style="text-align: left">18 - 20 (non-LTS)</td>
<td style="text-align: left">03/2022</td>
<td style="text-align: left">09/2023</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">21 (LTS)</td>
<td style="text-align: left">09/2023</td>
<td style="text-align: left">09/2028</td>
<td style="text-align: left">09/2031</td>
</tr>
<tr>
<td style="text-align: left">22 (non-LTS)</td>
<td style="text-align: left">03/2024</td>
<td style="text-align: left">09/2024</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">23 (non-LTS)</td>
<td style="text-align: left">09/2024</td>
<td style="text-align: left">03/2025</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">24 (non-LTS)</td>
<td style="text-align: left">03/2025</td>
<td style="text-align: left">09/2025</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">25 (LTS)</td>
<td style="text-align: left">09/2025</td>
<td style="text-align: left">09/2030</td>
<td style="text-align: left">09/2033</td>
</tr>
<tr>
<td style="text-align: left">26 (non-LTS)</td>
<td style="text-align: left">03/2026</td>
<td style="text-align: left">09/2026</td>
<td style="text-align: left">不支持</td>
</tr>
<tr>
<td style="text-align: left">27 (non-LTS)</td>
<td style="text-align: left">09/2026</td>
<td style="text-align: left">03/2027</td>
<td style="text-align: left">不支持</td>
</tr>
</tbody>
</table>
Java 版本分为 LTS（Long-Term Support，长期支持版） 和 Non-LTS（非长期支持版），它们的主要区别如下：
<table>
<thead>
<tr>
<th>对比项</th>
<th>LTS 版本（长期支持）</th>
<th>Non-LTS 版本（非长期支持）</th>
</tr>
</thead>
<tbody>
<tr>
<td>发布周期</td>
<td>每 2 年 一次</td>
<td>每 6 个月 发布一次</td>
</tr>
<tr>
<td>支持时长</td>
<td>官方长期支持（8 年+）</td>
<td>仅支持 6 个月</td>
</tr>
<tr>
<td>适用场景</td>
<td>生产环境、企业级项目、长期维护的系统</td>
<td>个人学习、实验性项目、尝鲜新特性</td>
</tr>
<tr>
<td>稳定性</td>
<td>更稳定，企业级可用</td>
<td>新特性多，但可能不稳定</td>
</tr>
<tr>
<td>安全性</td>
<td>持续提供安全更新和 bug 修复</td>
<td>仅在生命周期内提供短期修复</td>
</tr>
<tr>
<td>新特性</td>
<td>主要以稳定性和性能优化为主</td>
<td>包含最新特性，但可能在下个版本修改或移除</td>
</tr>
</tbody>
</table>
所以，用不用 Java 26 分场景来看：
<ul>
<li>生产环境追求稳的团队，还是优先用 Java 21 和 Java 25。</li>
<li>想跟上 Java 演进方向的人，Java 26 很值得看，因为里面不少东西明显是在给下一个大版本试水。</li>
</ul>
这也是 Java 半年发版最有价值的地方，它不一定每次都让你全面升级，但它一直在替未来铺路。
<h2 id="java-26-新特性">Java 26 新特性</h2>
JDK 26 带来了 10 个重大升级：
<table>
<thead>
<tr>
<th>编号</th>
<th>特性名称</th>
<th>中文解释</th>
<th>备注</th>
</tr>
</thead>
<tbody>
<tr>
<td>500</td>
<td>Prepare to Make Final Mean Final</td>
<td>准备让 <code>final</code> 真正变成 <code>final</code></td>
<td></td>
</tr>
<tr>
<td>504</td>
<td>Remove the Applet API</td>
<td>移除 Applet API</td>
<td></td>
</tr>
<tr>
<td>516</td>
<td>Ahead-of-Time Object Caching with Any GC</td>
<td>任意 GC 的 AOT 对象缓存</td>
<td></td>
</tr>
<tr>
<td>517</td>
<td>HTTP/3 for the HTTP Client API</td>
<td>HTTP Client 支持 HTTP/3</td>
<td></td>
</tr>
<tr>
<td>522</td>
<td>G1 GC: Improve Throughput by Reducing Synchronization</td>
<td>G1 通过减少同步提升吞吐量</td>
<td></td>
</tr>
<tr>
<td>524</td>
<td>PEM Encodings of Cryptographic Objects</td>
<td>加密对象的 PEM 编码</td>
<td>第 2 次预览</td>
</tr>
<tr>
<td>525</td>
<td>Structured Concurrency</td>
<td>结构化并发</td>
<td>第 6 次预览</td>
</tr>
<tr>
<td>526</td>
<td>Lazy Constants</td>
<td>懒加载常量</td>
<td>第 2 次预览</td>
</tr>
<tr>
<td>529</td>
<td>Vector API</td>
<td>向量 API</td>
<td>第 11 次孵化</td>
</tr>
<tr>
<td>530</td>
<td>Primitive Types in Patterns, instanceof, and switch</td>
<td>模式匹配支持更多原始类型</td>
<td>第 4 次预览</td>
</tr>
</tbody>
</table>
其中包括 4 个预览特性、1 个孵化特性，看着数量不算多，但这 10 个里面，既有语法继续推进，也有运行时性能提升，还有标准库和安全边界的持续加强。
这些新特性涵盖了 Java 语言的创新、安全性增强、性能和运行时的改进、库的优化，以及对 JDK 的维护和清理工作，整体来说都是相当给力的升级。
<blockquote>
完整特性说明可以参考：
<ul>
<li>https://openjdk.org/projects/jdk/26/</li>
<li>https://jdk.java.net/26/release-notes</li>
</ul>
</blockquote>
<h3 id="1语言层特性">1、语言层特性</h3>
<h4 id="530---primitive-types-in-patterns-instanceof-and-switch">530 - Primitive Types in Patterns, instanceof, and switch</h4>
<blockquote>
模式匹配支持更多原始类型，第四次预览。
</blockquote>
Java 这几年一直在补模式匹配这条线，<code>instanceof</code>、<code>switch</code> 等，一路都在往更统一的方向走。
但之前这套东西更多还是围着引用类型打转，碰到 <code>long</code>、<code>float</code>、<code>double</code>、<code>boolean</code> 这些原始类型，多少还是有点别扭。
Java 26 这次继续把这个坑填平，<code>switch</code> 现在能更自然地处理这些原始类型了。
来看一个示例：
<pre><code class="language-java">float score = 86.5f;

String level = switch (score) {
case 0f -> "zero";
case float s when s < 60f -> "fail";
case float s when s < 85f -> "pass";
case float s -> "excellent";
};
</code></pre>
现在编译器对 <code>switch</code> 的检查也更严格了，这些修改使编译器能够识别出更多类型的编码错误，不过此前合法的少数 switch 结构现在将被拒绝。
<h4 id="500---prepare-to-make-final-mean-final">500 - Prepare to Make Final Mean Final</h4>
<blockquote>
准备让 <code>final</code> 真正变成 <code>final</code>。
</blockquote>
这个名字非常直接，意思也很明确。
按正常理解，<code>final</code> 字段应该就是不可变的。但现实情况是，Java 里长期存在通过深度反射去修改 <code>final</code> 字段的玩法。
这就会带来两个问题：
<ul>
<li>代码语义没那么可信；</li>
<li>JVM 也没法完全放心做相关优化。</li>
</ul>
Java 26 这次还没有一步到位封死，而是先对这类修改行为发出 warning 警告，提前给框架、序列化库、各种底层工具一个适配期。
未来的 Java 版本会默认限制 final 字段的修改，从而提升程序的安全性和运行效率。
对于应用开发者来说，如果确实有必要修改 final 字段，可以有选择地开启相关能力，这样既能避开当前的警告，也能应对将来的限制。
<h4 id="517---http3-for-the-http-client-api">517 - HTTP/3 for the HTTP Client API</h4>
<blockquote>
HTTP Client 支持 HTTP/3。
</blockquote>
这个特性我觉得很多人会喜欢，因为它真的很实用。
Java 标准库自带的 <code>HttpClient</code> 这几年已经越来越顺手了，但在协议支持上一直差一口气，现在 HTTP/3 终于补上了。
而且这个支持方式挺舒服，不需要你换掉整套 API，只要显式指定协议版本就行：
<pre><code class="language-java">var client = HttpClient.newBuilder()
 .version(HttpClient.Version.HTTP_3)
 .build();

var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
 .version(HttpClient.Version.HTTP_3)
 .GET()
 .build();
</code></pre>
还有个很实在的点，如果目标服务不支持 <code>HTTP/3</code>，它默认还能自动降级到 <code>HTTP/2</code> 或 <code>HTTP/1.1</code>，完全透明的，不至于一上来就不可用。
所以，对于网关、微服务客户端、API 调用层，或者网络环境比较复杂的场景，这个特性是有实际价值的。
<h4 id="524---pem-encodings-of-cryptographic-objects">524 - PEM Encodings of Cryptographic Objects</h4>
<blockquote>
加密对象的 PEM 编码，第二次预览。
</blockquote>
做过证书、密钥、TLS 配置的人，对 <code>PEM</code> 肯定不陌生。
平时我们看到的这种内容就是 PEM 格式：
<pre><code class="language-text">-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEi/kRGOL7wCPTN4KJ2ppeSt5UYB6u
cPjjuKDtFTXbguOIFDdZ65O/8HTUqS/sVzRF+dg7H3/tkQ/36KdtuADbwQ==
-----END PUBLIC KEY-----
</code></pre>
Java 26 继续预览这套 API，目标也很明确，就是把密钥、证书、证书吊销列表这些对象和 PEM 文本之间的转换，尽量做成标准能力，不再总让大家靠第三方库、自己手搓。
这类特性对企业开发真的是减负，尤其是安全接入、证书管理、合规场景。
<h4 id="525---structured-concurrency">525 - Structured Concurrency</h4>
<blockquote>
结构化并发，第六次预览。
</blockquote>
结构化并发已经预览很多次了，说明 OpenJDK 对它非常认真。
它解决的问题也很实际，以前你写多线程，不难，但一组有关系的并发任务，错误怎么传、取消怎么做、结果怎么收，写到后面经常乱。
结构化并发就是把一组相关任务当成一个整体来处理，简化了错误处理和取消操作，提升了程序的可靠性，也让监控变得更方便。
来看示例：
<pre><code class="language-java">Response handle() throws InterruptedException {
try (var scope = StructuredTaskScope.open()) {
 Subtask<String> user = scope.fork(() -> findUser());
 Subtask<Integer> order = scope.fork(() -> fetchOrder());

 scope.join();
 return new Response(user.get(), order.get());
}
}
</code></pre>
这种写法比一堆 <code>Future</code>、<code>CompletableFuture</code> 拼来拼去顺手太多了。尤其是和虚拟线程搭配起来以后，Java 并发这块真的是越来越像现代语言了。。。
结构化并发是把在不同线程中运行的相关任务当作一个整体来处理，而 <code>Future</code> 大多是在把多个任务作为单独任务对待时派上用场的。一个 scope 通常只会阻塞一次，等待它的子任务结果，然后集中处理异常。
你可能在会纳闷，为什么这些 <code>fork</code> 方法没有返回更强大的 <code>CompletableFuture</code> 对象，毕竟，这些方法返回的 <code>Future</code> 只有在确认它们完成后才能用。所以，使用 <code>CompletableFuture</code> 其实也没啥用，因为它主要是为未完成的 futures 异步编程模式设计的，而 <code>StructuredTaskScope</code> 则更偏向于阻塞式的操作。
所以，对于 <code>Future</code> 和 <code>CompletableFuture</code> 来说，它们虽然提供了一些并发自由度，但在结构化并发中反而起到了反作用。
<h4 id="526---lazy-constants">526 - Lazy Constants</h4>
<blockquote>
懒加载常量，第二次预览。
</blockquote>
这个特性是 Java 25 里 <code>StableValue</code> 的继续演进版，在 Java 26 里名字直接改成了 LazyConstant，意思也更好懂。
懒加载常量存放的是不可变数据的对象，在 JVM 眼中就像真正的常量一样，能够享受到和声明字段 <code>final</code> 时相同的性能优化。不过，相比于 <code>final</code> 字段，懒加载常量在初始化时机上更具灵活性。
比如下面的示例：
<pre><code class="language-java">class OrderController {

private final LazyConstant<Logger> logger =
 LazyConstant.of(() -> Logger.create(OrderController.class));

void submitOrder() {
 logger.get().info("order submitted");
}
}
</code></pre>
这样写的好处是，只有真正用到 <code>logger</code> 的时候才初始化，但 JVM 又能把它按常量去优化。
<h4 id="529---vector-api">529 - Vector API</h4>
<blockquote>
向量 API，第十一次孵化。
</blockquote>
这个 API 真的挺能熬，已经到 第十一次孵化 了。
它的目标还是老样子，让 Java 可以表达向量计算，并在支持的 CPU 架构上，运行时编译成更优的向量指令，从而拿到比标量计算更好的性能。
这东西对普通 CRUD 业务同学感知不大，但对数据处理、科学计算、图像处理、AI 推理这类场景，在现如今 AI 技术发展的今天意义很大。
而且它一直还没正式转正，也说明这块能力依然在等更成熟的底层配合，比如 Valhalla 那条线。
<h3 id="2性能和运行时特性">2、性能和运行时特性</h3>
<h4 id="516---ahead-of-time-object-caching-with-any-gc">516 - Ahead-of-Time Object Caching with Any GC</h4>
<blockquote>
任意 GC 的 AOT 对象缓存。
</blockquote>
这个特性是 Project Leyden 方向上的继续推进。
简单说，就是 AOT 对象缓存不再只适配某一种 GC 了，现在可以使用任意 GC，连 <code>ZGC</code> 这种低延迟回收器也能兼容这套机制。。
它可以将预先初始化好的 Java 对象以 GC 无关的格式，顺序加载到内存中。还优化了提前缓存（ahead-of-time cache），让 HotSpot 虚拟机在启动和热身阶段表现得更快，同时支持任何 GC，包括低延迟的 ZGC。
所以，这一改进提升了资源利用率，也加快了 Java 应用的启动速度。
OpenJDK 在 JEP 516 里提到，像 Spring PetClinic 这样的应用，在已有的 AOT 类加载和链接方案下，生产启动速度可以提升 41%。
所以，这类能力对云原生、弹性扩容、冷启动场景都挺香的。
<h4 id="522---g1-gc-improve-throughput-by-reducing-synchronization">522 - G1 GC: Improve Throughput by Reducing Synchronization</h4>
<blockquote>
G1 通过减少同步来提升吞吐。
</blockquote>
通过提升内存效率，帮助开发者在更短的时间内完成更多工作。
Java 26 在 G1 上做的事情，就是减少了应用程序线程和垃圾回收线程之间的同步，提高了使用 G1 垃圾回收器时的吞吐量。
运行速度更快，就能支持更多用户而无需额外硬件，Java 大大提升了效率，降低了基础设施成本，还带来更流畅的用户体验。
官方给的数据也不算虚：
<ul>
<li>在频繁修改对象引用字段的应用里，吞吐提升大概有 5% - 15%；</li>
<li>就算不是这类重场景，也观察到了 最高 5% 的收益；</li>
<li>在 <code>x64</code> 平台上，G1 写屏障的指令数大概从 50 条 压到了 12 条。</li>
</ul>
这种特性很有价值，尤其是对于那些对 GC 敏感的应用来说。
<h3 id="3其他特性">3、其他特性</h3>
<h4 id="504---remove-the-applet-api">504 - Remove the Applet API</h4>
<blockquote>
移除 Applet API。
</blockquote>
这玩意终于要被彻底送走了。。
Applet API 在 <code>JDK 9</code> 就已经开始废弃，<code>JDK 17</code> 进入准备移除状态，到 Java 26 终于正式删除。
原因也很简单，现代浏览器早就不支持 Applet 了，所以，Applet 留在 JDK 里已经没什么意义。
移除 Applet API 后，可以缩减安装包和源代码的体积，同时提升应用的性能、稳定性和安全性。
如果你项目里现在还有 <code>java.applet.Applet</code>、<code>javax.swing.JApplet</code> 这类东西，那是你的代码真的该考古了。。。
<h2 id="还有两件事">还有两件事</h2>
除了 10 个 JEP，这次 Oracle 官方博客里还有两件偏企业侧的消息，也挺值得看。
第一件是 JavaFX 商业支持回来了，真是活久见了。
Oracle 这次明确说了，会重新提供 JavaFX 的商业支持，JDK 8 的 JavaFX 商业支持还延到了 2028 年 3 月。这个消息对大多数后端同学没那么刺激，但对桌面端、可视化、教学场景、老项目维护来说，其实挺现实。
第二件是 Oracle 推了一个新的 Oracle Java Verified Portfolio，把 JavaFX、Helidon、VS Code 的 Java 扩展这些能力弄进了一个企业级组合支持包里。
这类消息你要说跟日常写业务代码有多大关系，也未必。
但它至少说明一件事，Oracle 现在不是只想发 JDK，它还想把 Java 周边生态的企业支持也一块打包得更完整。
<h2 id="总结">总结</h2>
Java 26 这次给我的感觉，不是王炸级大版本，而是一个处处都在憋着大招的过渡版本。
HttpClient 终于把 HTTP/3 补上了，结构化并发还在持续打磨，模式匹配继续往原始类型推进，G1 在默认 GC 的位置上继续狠狠压榨性能，AOT cache 开始跟更多 GC 体系打通，final 这玩意也终于要 final 了。
现在再看，Java 还是稳，还是强，但它的变化节奏已经不是那种一夜之间颠覆式的了，而是每 6 个月往前拱一点，版本号也越拉越大。
这恰恰就是 Java 最可怕的地方，为了升级而升级，一年 2 个版本，有必要吗？对于很多还在用 Java 8 的公司来说，这谁跟得上啊？
但升级到 Java 17、Java 21、Java 25 这些长期支持版本，还是很有必要的，毕竟它们带来的性能、安全、语言特性提升都是实打实的，而且主流框架都放弃 Java 8 了要求 Java 17+ 了。
比如：
<ul>
<li>Spring Boot 正式弃用 Java 8，要求 17+！！</li>
<li>Kafka 4.0 发布，Java 8 和 Zookeeper 彻底被抛弃了！！</li>
</ul>
所以，别停留在 Java 8 了，赶紧升级吧，Java 26 不用急着上，但 Java 17 还是很值得的。
<blockquote>
⚠️ 版权声明：
本文系公众号 "Java技术宅" 原创，转载、引用本文内容请注明出处，抄袭、洗稿一律投诉侵权，后果自负，并保留追究其法律责任的权利。
</blockquote>

</div>
<div id="MySignature" role="contentinfo">

<div style="clear: both"></div> 
来源：https://www.cnblogs.com/javastack/p/19759594

頁: [1]

琼殿技术论坛's Archiver

Java 26 发布了， 我人麻了。。

Java 26 发布了，我人麻了。。