如果需要將內存歸還給系統，解決方案，添加參數
-XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30
這個熱點JVM是否將內存釋放回操作系統，但這是不情願的，因爲調整堆的大小是很昂貴的，並且假設如果您需要該堆一次，您將再次需要它。
你可以通過設置-XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30這將使它能夠花費更多的CPU時間來收集和限制GC循環後分配但未使用的堆內存的數量。
假設您使用的是併發收集器，您也可以設置-XX:InitiatingHeapOccupancyPercent=N使用N到一些低值使GC幾乎連續地運行併發集合，這將消耗更多的CPU週期，但會更快地縮小堆。這，這個一般這不是一個好主意，但在一些有大量空閒CPU核但內存不足的機器上，這是有意義的。
如果使用帶有默認暫停時間目標(CMS或G1)的收集器，也可以放寬該目標以減少對收集器的限制，或者可以切換Go並行收集器，以便在暫停時間內對足跡進行優先排序。
加上Java 9-XX:-ShrinkHeapInSteps選項可用於更積極地應用前兩個選項所造成的收縮。相關OpenJDK bug.
請注意，收縮能力和行爲取決於所選的垃圾收集器。例如，G1只獲得了返回堆中間未使用的塊使用jdk8u20，而zgc使用還沒支持它和epsilon收集器很可能永遠不會。
因此，如果需要堆收縮，就應該測試特定的JVM版本和GC配置。
GC測井PrintAdaptiveSizePolicy也可以提供洞察力，例如當JVM試圖爲年輕一代使用更多內存以實現某些目標時。
也有9月346，包含在OpenJDK 12中，它引入了G1GC的提示內存發佈，G1PeriodicGCInterval選項，同樣以犧牲一些額外的CPU爲代價。中還提到了類似的特性。謝南多而OpenJ9VM.