今天就跟大家聊聊有關如何解決JVM空閑堆內存不釋放回OS的問題，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)于2013年成立，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目網(wǎng)站設計、成都做網(wǎng)站網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元紫金做網(wǎng)站,已為上家服務,為紫金各地企業(yè)和個人服務,聯(lián)系電話:13518219792

JDK 8及更早版本

在這些版本中，沒有用于立即回收的顯式選項，但是您可以通過進行設置來使GC一般更具侵略性，該設置-XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30將使其在GC后花費更多的CPU時間來收集和限制已分配但未使用的堆內存的數(shù)量。循環(huán)。

如果使用并發(fā)收集器，還可以將-XX:InitiatingHeapOccupancyPercent=NN設置為一個較低的值，以使GC幾乎連續(xù)運行并發(fā)收集，這將消耗更多的CPU周期，但會更快地縮小堆。通常這不是一個好主意，但是在某些類型的具有大量備用CPU內核但內存不足的計算機上，這是有道理的。

如果您使用的是G1GC，請注意，它僅使用jdk8u20獲得了在堆中間退還未使用的塊的功能，而早期版本只能在堆末尾返回塊，這對可裝載的塊數(shù)量有很大的限制。收回。

如果您使用的收集器具有默認的暫停時間目標（例如CMS或G1），則您也可以放寬該目標，以對收集器施加更少的約束，或者您可以切換并行收集器，以在暫停時間上優(yōu)先考慮占用空間。

為了驗證是否發(fā)生收縮或診斷GC決定不收縮的原因，您可以使用GC Logging-XX:+PrintAdaptiveSizePolicy來提供見解，例如，當JVM嘗試為年輕一代使用更多內存以滿足某些目標時。

JDK 9

添加了-XX:-ShrinkHeapInSteps可用于更積極地應用由上一節(jié)中提到的選項引起的縮小的選項。相關的OpenJDK錯誤。

對于日志記錄-XX:+PrintAdaptiveSizePolicy已被替換為-Xlog:gc+ergo

JDK 12

引入了通過G1PeriodicGCInterval（JEP 346）為G1GC啟用即時內存釋放的選項，但又以一些額外的CPU為代價。JEP還提到了Shenandoah和OpenJ9 VM中的類似功能。

如果您使用G1收集器并偶爾調用System.gc（）（我每分鐘執(zhí)行一次），則Java將可靠地收縮堆并將內存返還給OS。

從Java 12開始，如果應用程序處于空閑狀態(tài)，則G1會自動執(zhí)行此操作。

我建議將這些選項與以上建議結合使用，以實現(xiàn)非常緊湊的駐留進程大小：

-XX:+UseG1GC -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=10

JDK 13

ZGC在13 Java中發(fā)布，它可以將未使用的堆內存返回給操作系統(tǒng)，請參閱鏈接

看完上述內容，你們對如何解決JVM空閑堆內存不釋放回OS的問題有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。