java8默认内存收集器

转载地址：java8默认内存收集器_使用正确的垃圾收集器将Java内存使用量降至最低_dnc8371的博客-CSDN博客

java8默认内存收集器

大小对于软件至关重要。 很明显，与大的整体方法相比，在微服务体系结构中使用小片段具有更多优势。 最新的Java版本的Jigsaw有助于分解旧应用程序或从头开始构建新的云原生应用程序。

这种方法减少了磁盘空间，构建时间和启动时间。 但是，它对RAM使用管理没有足够的帮助。 众所周知，Java在许多情况下会消耗大量内存。 同时，许多人还没有注意到Java在内存使用方面已经变得更加灵活，并且提供了满足微服务需求的功能。 在本文中，我们将分享我们的经验，如何在Java进程中调整RAM的使用以使其更具弹性，并获得更快的扩展和更低的总体拥有成本（TCO）的好处。

缩放有三个选项：垂直，水平和两者的组合。 为了最大化结果，首先您需要以最佳方式设置垂直缩放。 然后，当您的项目水平增长时，单个容器内的预配置资源消耗将被复制到每个实例，并且效率将成比例地增长。

如果配置正确，则垂直缩放可完美地适用于微服务和整体组件，并根据容器内的当前负载优化内存和CPU使用率。 选定的垃圾收集器是主要的基础砖之一，其设置会影响整个项目。

OpenJDK有五种广泛使用的垃圾收集器解决方案：

• G1
• 平行
• ConcMarkSweep（CMS）
• 序列号
• 雪兰多

让我们看看它们在缩放方面的表现以及可以应用哪些设置来改善结果。

为了进行测试，我们将使用一个示例Java应用程序来帮助跟踪JVM垂直缩放结果： https : //github.com/jelastic/java-vertical-scaling-test

将为每个GC测试启动以下JVM启动选项：

java -XX:+Use[gc_name]GC -Xmx2g -Xms32m -jar app.jar [sleep]

哪里：

• [gc_name]将替换为特定的垃圾收集器类型
• Xms是扩展步骤（本例中为32 MB）
• Xmx是最大缩放限制（本例中为2 GB）
• [sleep]是内存加载周期之间的间隔（以毫秒为单位），默认值为10

目前，为了完全释放未使用的资源，需要调用Full GC。 可以使用各种选项轻松启动它：

• jcmd <pid> GC.run –执行外部调用
• System.gc() – 源代码内
• jvisualvm –通过出色的VisualVM故障排除工具手动进行
• -javaagent:agent.jar –可插入的常用方法。 Github repo Java Memory Agent上提供了开源自动化附件。

可以在输出日志中跟踪内存使用情况，或使用VisualVM进行更深入的查看。

G1垃圾收集器

对于Java生态系统来说，好消息是，从JDK 9开始，默认情况下启用了现代收缩的G1垃圾收集器。 如果使用较低版本的JDK，则可以使用-XX:+UseG1GC参数启用G1。

G1的主要优点之一是能够压缩可用的内存空间，而无需花费较长的暂停时间和不提交未使用的堆的能力。 我们发现，对于在OpenJDK或HotSpot JDK上运行的Java应用程序进行垂直扩展，该GC是最佳选择。

为了更好地了解JVM在不同内存压力级别下的行为，我们将运行以下三种情况：1）快速，2）中速和3）内存使用量增长缓慢。 通过这种方式，我们可以检查G1人机工程学的智能程度以及GC如何处理不同的内存使用动态。

内存使用量快速增长

java -XX:+UseG1GC -Xmx2g -Xms32m -jar app.jar 0

内存在25秒内从32 MiB增长到1 GiB。

G1内存使用量快速增长

如果内存使用量的增长非常快，则根据其内部自适应优化算法，JVM人机工程学将忽略Xms扩展步骤，并更快地保留RAM。 结果，相对于实际使用量的快速增长（蓝色），我们看到了JVM（橙色）的RAM分配要快得多。 因此，即使出现负载峰值，使用G1还是安全的。

中等内存使用量增长

java -XX:+UseG1GC -Xmx2g -Xms32m -jar app.jar 10

在4个周期内，内存在90秒内从32 MiB增长到1 GiB。

有时，为了使JVM符合人体工程学，需要几个周期才能找到最佳的RAM分配算法。

G1中型内存使用量增长

如我们所见，JVM在第4 个周期中对人体工程学进行了调整，以使垂直扩展在可重复的周期中非常有效

内存使用量增长缓慢

java -XX:+UseG1GC -Xmx2g -Xms32m -jar app.jar 100

内存从32 MiB增长到1 GiB，增量时间增长了大约300秒。 非常灵活，高效的资源扩展符合我们的期望-令人印象深刻。

G1内存使用量增长缓慢

如您所见，橙色区域（保留的RAM）随着蓝色区域（实际使用）的增长而缓慢增加。 因此，没有过量使用或不必要保留的内存。

重要提示：激进堆或垂直缩放

用于提高Java应用程序性能的流行JVM配置通常会阻碍有效地垂直扩展的能力。 因此，您需要在优先级之间选择对您的应用程序最重要的属性。

广泛使用的设置之一是激活积极堆，以最大程度地利用堆的物理内存。 让我们分析一下使用此配置时发生的情况。

java -XX:+UseG1GC -Xmx2g -Xms2g

要么

java -XX:+UseG1GC -Xmx2g -XX:+AggressiveHeap

G1激进堆

如我们所见，保留堆（橙色）是恒定的，并且不会随时间变化，因此容器中没有JVM的垂直缩放。 即使您的应用程序仅使用可用RAM的一小部分（蓝色），其余部分也不能与其他进程或其他容器共享，因为它已完全分配给JVM。

因此，如果要垂直扩展应用程序，请确保未启用主动堆（参数应为-XX:-AggressiveHeap ），也不-XX:-AggressiveHeap -Xms定义为与-Xmx一样高（例如，不要声明-Xmx2g -Xms2g ） 。

[JDK-8204089] JEP 346: Promptly Return Unused Committed Memory from G1 - Java Bug Systemhttps://bugs.openjdk.org/browse/JDK-8204089另外G1没有做full GC，导致堆内存没有被回收。这是jdk8的G1内存的一个bug，在jdk12修复：[JDK-8204089] JEP 346: Promptly Return Unused Committed Memory from G1 - Java Bug System

并行垃圾收集器

并行是高吞吐量GC，默认情况下在JDK8中使用。 同时，它不适合进行内存缩减，因此不适合进行灵活的垂直缩放。 为了确认这一点，让我们对示例应用程序进行测试：

java -XX:+UseParallelGC -Xmx2g -Xms32m -jar app.jar 10

平行垃圾收集器

如我们所见，未使用的RAM不会释放回OS。 带有并行GC的JVM可以永久保留它，甚至不考虑显式的Full GC调用。

因此，如果您希望根据应用程序负载从垂直缩放中受益，请将Parallel更改为JDK中可用的收缩GC。 它将所有活动对象打包在一起，删除垃圾对象，然后取消提交未使用的内存并将其释放回操作系统。

串行和ConcMarkSweep垃圾收集器

Serial和ConcMarkSweep也在缩小垃圾回收器，并且可以垂直扩展JVM中的内存使用量。 但是与G1相比，它们需要4个完整的GC周期才能释放所有未使用的资源。

让我们看看这两个垃圾收集器的测试结果：

java -XX:+UseSerialGC -Xmx2g -Xms32m -jar app.jar 10

串行垃圾收集器

java -XX:+UseConcMarkSweepGC -Xmx2g -Xms32m -jar app.jar 10

ConcMarkSweep垃圾收集器

从JDK9开始，可以使用新的JVM选项-XX：-ShrinkHeapInSteps加快内存释放速度，该选项在第一个完整GC周期后立即减少已提交的RAM。

雪兰多亚垃圾收集器

Shenandoah是垃圾收集器中的一颗冉冉升起的新星，该垃圾收集器已经被视为即将推出的针对JVM垂直扩展的最佳解决方案。

与其他版本相比，主要的不同是能够异步收缩（取消提交未使用的RAM并将其释放给OS），而无需调用Full GC。 Shenandoah可以在检测到可用内存后立即压缩活动对象，清理垃圾并将RAM释放回OS。 省略Full GC的可能性可以消除相关的性能下降。

让我们看看它在实践中如何工作：

java -XX:+UseShenandoahGC -Xmx2g -Xms32m -XX:+UnlockExperimentalVMOptions -XX:ShenandoahUncommitDelay=1000 -XX:ShenandoahGuaranteedGCInterval=10000 -jar app.jar 10

在这里，我们添加了雪南多厄可用的一些额外参数：

• -XX:+UnlockExperimentalVMOptions –启用下面列出的uncommit选项所需
• -XX:ShenandoahUncommitDelay=1000 –垃圾收集器将开始取消提交超过此时间（以毫秒为单位）的未使用内存。 请注意，当应用程序想要取回内存时，将延迟设置得太低可能会导致分配停顿。 在实际部署中，建议使延迟大于1秒
• -XX:ShenandoahGuaranteedGCInterval=10000 -这样可以保证在指定的时间间隔（以毫秒为单位）内的GC周期

雪兰多亚垃圾收集器

雪兰多（Shenandoah）非常灵活，只分配必要的资源。 它还压缩了用过的RAM（蓝色），并即时将未消耗的保留RAM（橙色）释放回操作系统，而无需进行昂贵的Full GC调用。 请注意，此GC是试验性的，因此您对稳定性的反馈将对其创建者有所帮助。

Shenandoah官方介绍：https://wiki.openjdk.java.net/display/shenandoah/Main

结论

Java会不断完善和适应不断变化的需求。 因此，目前，对于微服务和传统应用程序的云托管而言，RAM的需求不再是问题，因为已经有了适当的工具和方法来适当地对其进行扩展，清理垃圾并释放所需进程的资源。 通过智能配置，Java对于所有项目范围（从云原生启动到传统企业应用程序）都具有成本效益。

服务启动参数改为：-XX:NativeMemoryTracking=summary -Dtracer_append_pid_to_log_path=true -XX:+UseContainerSupport -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=75.0 -XX:MaxMetaspaceSize=512M -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahUncommitDelay=2000 -XX:ShenandoahGuaranteedGCInterval=10000 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:./${APP_NAME}-gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=14 -XX:GCLogFileSize=20M -XX:+PrintGCCause -XX:+PrintGCApplicationStoppedTime

jenkins配置：APP_OPTS        = " -XX:NativeMemoryTracking=summary -Dtracer_append_pid_to_log_path=true -XX:+UseContainerSupport -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=75.0 -XX:MaxMetaspaceSize=512M -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahUncommitDelay=2000 -XX:ShenandoahGuaranteedGCInterval=10000 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:./${APP_NAME}-gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=14 -XX:GCLogFileSize=20M -XX:+PrintGCCause -XX:+PrintGCApplicationStoppedTime "

翻译自: Minimize Java Memory Usage with the Right Garbage Collector