大小對于軟件至關重要。 很明顯，與大型整體方法相比，在微服務體系結構中使用小型組件具有更多優勢。 最新的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 ） 。

并行垃圾收集器

并行是高吞吐量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周期

雪蘭多亞垃圾收集器

雪蘭多厄非常靈活，只分配必要的資源。 它還壓縮了用過的RAM（藍色），并即時將未消耗的保留RAM（橙色）釋放回操作系統，而無需進行昂貴的Full GC調用。 請注意，此GC是實驗性的，因此您對穩定性的反饋將對其創建者有所幫助。

結論

Java會不斷完善和適應不斷變化的需求。 因此，目前，對于微服務和傳統應用程序的云托管而言，RAM的需求不再是問題，因為已經有了正確地對其進行擴展，清理垃圾并釋放所需過程資源的正確工具和方法。 通過智能配置，Java對于所有項目范圍（從云原生啟動到傳統企業應用程序）都可以具有成本效益。

翻譯自: https://www.javacodegeeks.com/2017/11/minimize-java-memory-usage-right-garbage-collector.html

總結

以上是生活随笔為你收集整理的使用正确的垃圾收集器将Java内存使用量降至最低的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。