阿里巴巴开源 Dragonwell JDK 最新版本 8.1.1-GA 发布 阿里巴巴jdkjavawindows
程序员文章站
2024-03-23 23:50:28
...
> **导读：**新版本主要有三大变化：同步了 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 个特别之处：
1. 分别处理 Java Heap 中新区和老区的部分。特别是不少应用为了维持可能高压力下的 GC 吞吐，会保持比较大的 young generation，例如 G1 默认的新区最大值为整堆的 60%。当 young GC 频率不高时，其实 Java 堆面临很大程度的浪费，但却没有办法快速节约这部分内存。假设当新区为整堆 60%，young GC 频率为 90 秒一次。当使用整堆 10% 作为 young generation 时，GC 频率变为 15 秒一次，同样可以满足 Java 正常运行，这样就可以节约 50% 的 Java 堆内存。而当压力变大，GC 频率变高时，会自动检测到变化并且重新 map 内存扩展新区的大小。
2. 使用了并发线程，并发且并行（concurrent and parallel）处理内存归还和重新 map 的工作。因为和 Linux kernel 交互，map/unmap 内存实际上是比较耗时的操作，特别是重新 map 内存后还会有 page fault 的开销，对于一次操作上 G 的内存，很容易消耗上百毫秒，甚至是秒级。因此，如果传统地在 GC STW中 操作内存 map/unmap，Java 应用将可能发生较大的毛刺，这是很多在线服务型应用不可接受的。通过并发线程并行处理 unmap 以及重新 map 后带来的 page fault 的开销，Java 应用线程将不受任何影响。在常规 GC STW 过程中，Java 堆的容量将会及时同步完成。
在 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 进程的物理内存。
本文作者：一绿舟
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/716777%3Futm_content%3Dg_1000081478)
本文为云栖社区原创内容，未经允许不得转载。
距离 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 个特别之处：
1. 分别处理 Java Heap 中新区和老区的部分。特别是不少应用为了维持可能高压力下的 GC 吞吐，会保持比较大的 young generation，例如 G1 默认的新区最大值为整堆的 60%。当 young GC 频率不高时，其实 Java 堆面临很大程度的浪费，但却没有办法快速节约这部分内存。假设当新区为整堆 60%，young GC 频率为 90 秒一次。当使用整堆 10% 作为 young generation 时，GC 频率变为 15 秒一次，同样可以满足 Java 正常运行，这样就可以节约 50% 的 Java 堆内存。而当压力变大，GC 频率变高时，会自动检测到变化并且重新 map 内存扩展新区的大小。
2. 使用了并发线程，并发且并行（concurrent and parallel）处理内存归还和重新 map 的工作。因为和 Linux kernel 交互，map/unmap 内存实际上是比较耗时的操作，特别是重新 map 内存后还会有 page fault 的开销，对于一次操作上 G 的内存，很容易消耗上百毫秒，甚至是秒级。因此，如果传统地在 GC STW中 操作内存 map/unmap，Java 应用将可能发生较大的毛刺，这是很多在线服务型应用不可接受的。通过并发线程并行处理 unmap 以及重新 map 后带来的 page fault 的开销，Java 应用线程将不受任何影响。在常规 GC STW 过程中，Java 堆的容量将会及时同步完成。
在 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 进程的物理内存。
本文作者：一绿舟
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/716777%3Futm_content%3Dg_1000081478)
本文为云栖社区原创内容，未经允许不得转载。