使用G1GC时回收JVM已提交内存以实现系统缩容

一、调整G1GC核心参数促进内存释放 #

针对G1GC主动避免Full GC的特性，通过以下参数配置让JVM更积极收缩堆、释放已提交内存：

• 启用并发Full GC触发：添加-XX:+ExplicitGCInvokesConcurrent和-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses，让System.gc()或外部触发的GC调用G1的低停顿并发Full GC，同时卸载无用类，为堆收缩创造条件。
• 优化堆空闲比例阈值：设置-XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=20，当Full GC后堆空闲内存占比超过40%时，JVM会主动收缩堆空间，将多余已提交内存释放给系统。
• 降低堆浪费容忍度：调整-XX:G1HeapWastePercent=2（默认5），让G1更积极回收空闲内存区域，减少堆内存的闲置预留。
• 立即回收大对象内存：启用-XX:+G1EnableEagerReclaimHumongousObjects，当大对象（Humongous Objects）被回收后，立即释放对应内存块，无需等待下一次Full GC。

二、自动触发GC的策略 #

无需手动干预，通过以下方式在低负载时触发GC以释放内存：

• 利用Dropwizard自带管理端点：Dropwizard默认提供/admin/gc端点，可通过定时任务（如CloudWatch Events触发Lambda）在系统空闲期调用该端点，触发GC操作。
• 基于指标触发外部GC：通过CloudWatch监控ECS任务的CPU负载（空闲时CPU使用率极低），结合JVM堆已提交内存指标，当满足“低负载+高已提交内存”条件时，执行jcmd <pid> GC.run命令触发并发Full GC。
• 调整软引用回收策略：设置-XX:SoftRefLRUPolicyMSPerMB=1000，缩短软引用对象的存活时间，让JVM在内存空闲时更快回收这类对象，减少堆内存占用。

三、应用与ECS层面的配套优化 #

• 排查内存泄漏：检查应用中的静态集合、无过期时间的缓存、未关闭的资源等，确保无内存泄漏问题——内存泄漏会导致Full GC无法回收内存，堆收缩也就无从谈起。
• 合理设置JVM堆大小：将-Xmx设置为ECS任务内存限制的80%-90%，既避免JVM因内存不足触发OOM，也给系统预留足够空间。
• 改用堆已使用内存作为扩缩容指标：通过JMX暴露JVM堆已使用内存的指标，用CloudWatch收集后作为ECS自动扩缩容的依据，替代系统级的已提交内存指标，从根源上规避JVM内存预留带来的扩缩容误判。

内容的提问来源于stack exchange，提问作者Gautam