(编辑:jimmy 日期: 2024/12/22 浏览:2)
导读:新版本主要有三大变化:同步了 OpenJDK 上游社区 jdk8u222-ga 的最新更新;带来了正式的 feature:G1ElasticHeap;发布了用户期待的 Windows 实验版本 Experimental Windows version。
距离 Dragonwell JDK 第一个正式版本 8.0.0-GA 发布已经过去 3 个月了,项目在 Github 上的 stars 继续攀升达到了 1900。今天我们带来了最新版本 8.1.1-GA 的发布,包含了全新的特性和更新。详情见下文。
龙井 8.1.1-GA 的新变化
新版本里我们同步了 OpenJDK 上游社区 jdk8u222-ga 的最新更新,带来了上游稳定版本的最新安全更新和补丁。
在 8.0.0-GA 发布的时候,我们介绍了 Dragonwell 第三个新特性 ElasticHeap 的一些情况,很多用户已经跃跃欲试了,这次发布我们带来了正式的 feature:G1ElasticHeap。能够在不影响 Java 业务运行的前提下,动态节约 Java 进程物理内存。
另外,我们还发布了用户期待的 Windows 实验版本 Experimental Windows version,使用 Windows 开发的小伙伴们可以更加方便的使用 Dragonwell JDK 进行相应的开发工作。
G1ElasticHeap
从 feature 的名字上我们可以看到 ElasticHeap 是基于 G1 GC 开发的,所以想要使用这个功能的小伙伴,需要开启 G1 GC(-XX:+UseG1GC)。在 8.0.0-GA 正式版介绍时,我们介绍了部分技术背景,由于 Java 自动管理内存的特性,整个 Java Heap 的地址空间和物理内存将被 Java 进程占用,即使使用率不高,回收后也并不会归还给操作系统,导致 Java 进程会有较高的常驻内存。
OpenJDK8 的几个常规 GC 算法仅能支持在 Full GC 时,按照一定规则有限缩减 Java 堆,然而 Java 开发的小伙伴们非常清楚,频繁的 Full GC 的 STW(stop-the-world)对 Java 应用意味着什么,长暂停会导致很多不可预期的应用异常和无法响应。
ElasticHeap 可以根据整体 GC 的压力,敏捷地将 Java 堆的物理内存归还给操作系统,没有额外的 STW 对 Java 应用带来的超时异常风险,核心设计有 2 个特别之处:
在 OpenJDK 新的 12 版本中,也引入了周期性触发 G1 concurrent mark 来触发内存的节约机制,但是并没有解决在 STW中map/unmap 的开销问题,也不能快速在 young GC 周期中来发现和处理 young generation 的内存浪费。目前除了在 Dragonwell 8.1.1 中发布,我们同时把 G1ElasticHeap 的 patch 提交给 OpenJDK 社区 review 和讨论,希望将这些创造性的变化加入到最新的 OpenJDK G1 GC 中。
云栖大会上孤尽的演讲,清晰地描述了 ElasticHeap 的使用场景。在双 11 流量剧增的情况下,核心应用 tradeplatform3 迅速的回涨 Java heap 和内存,以保持高流量压力下的稳定。高峰过后,内存逐渐缩减。从集群维度来说,在线 Java 应用占据大量内存,即使在线流量低,cpu 利用率很低,由于内存的占据,集群机器的 cpu 资源依然无法复用。而 ElasticHeap 可以有效降低低压力的在线 Java 应用的内存占用,把内存资源出让一部分运行离线任务,从而突破在线应用集群的资源利用率的内存瓶颈。在本例中,节约了 22.8% 的 Java 进程的物理内存。
想要立刻使用最新特性的小伙伴们,可以通过下面的地址下载最新版本的 Dragonwell JDK 的二进制包。
https://github.com/alibaba/dragonwell8/releases
这里提供了用户指南和发布说明。用户指南的末尾还有支持的钉钉群和邮件。
https://github.com/alibaba/dragonwell8/wiki
如果有小伙伴觉得这个特性符合自身的场景需求好用的话,不妨也向 OpenJDK 社区邮件列表支持我们,让 OpenJDK 听到更多中国 Java 使用者和开发者的声音。
总结
以上所述是小编给大家介绍的阿里巴巴开源 Dragonwell JDK 最新版本 8.1.1-GA 发布,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对网站的支持!
如果你觉得本文对你有帮助,欢迎转载,烦请注明出处,谢谢!