在本文中，我們希望分享Java內(nèi)存管理的細(xì)節(jié)和容器內(nèi)部的彈性，這些細(xì)節(jié)乍一看并不明顯。

在下面，您將找到要注意的問(wèn)題列表以及即將發(fā)布的JDK版本中的重要更新，以及針對(duì)核心痛點(diǎn)的現(xiàn)有解決方法。 我們收集了5個(gè)最有趣，最有用的技巧，以提高Java應(yīng)用程序的資源使用效率。

Docker中的Java堆內(nèi)存限制

當(dāng)前，社區(qū)正在討論有關(guān)在Docker容器中運(yùn)行Java應(yīng)用程序時(shí)錯(cuò)誤地確定內(nèi)存限制的問(wèn)題。

問(wèn)題是，如果未明確定義Xmx選項(xiàng)，則由于默認(rèn)的內(nèi)部垃圾回收（GC）人機(jī)工程學(xué)算法，JVM使用了可用于主機(jī)OS的所有內(nèi)存的1/4。 如果JVM內(nèi)存使用量超過(guò)為Docker容器定義的cgroups限制，則可能導(dǎo)致內(nèi)核殺死Java進(jìn)程。

為了解決此問(wèn)題，OpenJDK 9最近實(shí)現(xiàn)了一項(xiàng)改進(jìn)：

OpenJDK 9已添加了第一個(gè)實(shí)驗(yàn)性更改，因此JVM可以了解它正在容器中運(yùn)行并相應(yīng)地調(diào)整內(nèi)存限制。” 如果使用Docker運(yùn)行Java 9發(fā)行版將調(diào)整內(nèi)存限制

新的JVM選項(xiàng)（ -XX：+ UseCGroupMemoryLimitForHeap ）根據(jù)cgroup中定義的內(nèi)存限制自動(dòng)為Java進(jìn)程設(shè)置Xmx。

作為解決公共Java 9發(fā)行前問(wèn)題的一個(gè)不錯(cuò)的解決方法，可以在JVM的啟動(dòng)選項(xiàng)中顯式指定Xmx限制。 OpenJDK官方倉(cāng)庫(kù)中有一個(gè)公開(kāi)拉取請(qǐng)求，要求“根據(jù)docker內(nèi)存限制設(shè)置一個(gè)更好的默認(rèn)Xmx值的腳本”。

Jelastic設(shè)法通過(guò)結(jié)合使用增強(qiáng)的系統(tǒng)容器虛擬化層和Docker映像來(lái)省略錯(cuò)誤的內(nèi)存限制確定。 在前面的文章“容器中的Java和內(nèi)存限制：LXC，Docker和OpenVZ”中，我們解釋了它的工作原理。

跟蹤本機(jī)非堆內(nèi)存使用情況

在云中運(yùn)行Java應(yīng)用程序時(shí)，還必須注意Java進(jìn)程對(duì)本機(jī)內(nèi)存的使用，即所謂的堆外內(nèi)存。 它可以用于不同目的：

• 垃圾收集器和JIT優(yōu)化正在跟蹤對(duì)象圖的數(shù)據(jù)并將其存儲(chǔ)在本機(jī)內(nèi)存中。 此外，自JDK8起，類的名稱和字段，方法的字節(jié)碼，常量池等現(xiàn)在位于Metaspace中，該空間也存儲(chǔ)在JVM堆之外。

• 另外，為了獲得高性能，許多Java應(yīng)用程序在本機(jī)區(qū)域分配內(nèi)存。 使用java.nio.ByteBuffer或第三方JNI庫(kù)，這些應(yīng)用程序存儲(chǔ)大型的，長(zhǎng)壽命的緩沖區(qū)，這些緩沖區(qū)由基礎(chǔ)系統(tǒng)的本機(jī)I / O操作管理。

默認(rèn)情況下，元空間分配僅受可用本機(jī)OS內(nèi)存量的限制。 再加上Docker容器中錯(cuò)誤的內(nèi)存限制確定，這增加了應(yīng)用程序不穩(wěn)定的風(fēng)險(xiǎn)。 限制元數(shù)據(jù)的大小很重要，尤其是在遇到OOM問(wèn)題時(shí)。 使用特殊選項(xiàng)-XX：MetaspaceSize來(lái)執(zhí)行此操作 。

由于所有對(duì)象都存儲(chǔ)在正常的垃圾回收堆內(nèi)存之外，因此，它們對(duì)Java應(yīng)用程序的內(nèi)存占用量有什么影響并不明顯。 有一篇很好的文章詳細(xì)解釋了該問(wèn)題，并提供了一些有關(guān)如何分析本機(jī)內(nèi)存使用情況的準(zhǔn)則：

“幾周前，我在嘗試分析在Docker下運(yùn)行的Java應(yīng)用程序（Spring Boot + Infinispan）中的內(nèi)存消耗時(shí)遇到了一個(gè)有趣的問(wèn)題。 Xmx參數(shù)設(shè)置為256m，但是Docker監(jiān)視工具顯示的已用內(nèi)存幾乎增加了兩倍。” – 分析Docker容器中的Java內(nèi)存使用情況 。

作者的有趣結(jié)論：

“我可以說(shuō)一個(gè)結(jié)論嗎？ 好吧……永遠(yuǎn)不要在我開(kāi)玩笑的同一句話中使用“ java”和“ micro”這兩個(gè)詞–請(qǐng)記住，在使用Java，Linux和Docker的情況下處理內(nèi)存比起初看起來(lái)要棘手得多。”

為了跟蹤本機(jī)內(nèi)存分配，可以使用特定的JVM選項(xiàng)（ -XX：NativeMemoryTracking = summary ）。 請(qǐng)注意，如果啟用此選項(xiàng)，您將獲得5-10％的效果。

在運(yùn)行時(shí)調(diào)整JVM內(nèi)存使用量

減少Java應(yīng)用程序內(nèi)存消耗的另一個(gè)有用的解決方案是在Java進(jìn)程運(yùn)行時(shí)動(dòng)態(tài)調(diào)整JVM可管理選項(xiàng)。 由于JDK7u60和JDK8u20，選項(xiàng)MinHeapFreeRatio和MaxHeapFreeRatio成為可管理的，這意味著我們可以改變?cè)谶\(yùn)行時(shí)它們的值，而無(wú)需重新啟動(dòng)Java進(jìn)程。

在“ 運(yùn)行時(shí)承諾的堆大小調(diào)整”一文中，作者描述了如何通過(guò)調(diào)整以下可管理選項(xiàng)來(lái)減少內(nèi)存使用：

“…調(diào)整大小又花了一個(gè)時(shí)間，并且堆容量從159MB增加到444MB。 我們描述了至少85％的堆容量應(yīng)該是可用的，并且這表明JVM調(diào)整了堆的大小以獲取最多15％的使用率。”

這種方法可以為可變工作負(fù)載帶來(lái)顯著的資源使用優(yōu)化。 改善JVM內(nèi)存大小的下一步是可以在運(yùn)行時(shí)模式下更改Xmx，而無(wú)需重新啟動(dòng)Java進(jìn)程。

改善內(nèi)存壓縮

在許多情況下，客戶希望最大程度地減少Java應(yīng)用程序中使用的內(nèi)存量，從而導(dǎo)致產(chǎn)生更頻繁的GC。 例如，它可以通過(guò)在開(kāi)發(fā)，測(cè)試和構(gòu)建環(huán)境以及負(fù)載高峰后的生產(chǎn)中更有效地利用資源來(lái)幫助節(jié)省資金。 但是，根據(jù)官方的增強(qiáng)票證 ，當(dāng)前的GC算法需要多個(gè)完整的垃圾回收周期才能釋放所有可用的未使用內(nèi)存。

結(jié)果，引入了新的JVM選項(xiàng)（ -XX：+ ShrinkHeapInSteps ）來(lái)調(diào)節(jié)JDK9中的GC算法行為。 該設(shè)置應(yīng)更改為-XX：-ShrinkHeapInSteps，以禁用4個(gè)完整的GC周期。 這樣可以更快地釋放未使用的RAM資源，并最大程度地減少負(fù)載可變的應(yīng)用程序中Java堆大小的使用。

減少內(nèi)存使用以加快實(shí)時(shí)遷移

占用大量?jī)?nèi)存的Java應(yīng)用程序的實(shí)時(shí)遷移需要大量時(shí)間。 為了減少總遷移時(shí)間和資源開(kāi)銷(xiāo)，遷移引擎應(yīng)盡量減少主機(jī)之間傳輸?shù)臄?shù)據(jù)。 這可以通過(guò)在實(shí)時(shí)遷移過(guò)程之前借助整個(gè)GC周期壓縮RAM來(lái)完成。 對(duì)于克服GC周期期間性能下降的情況，這種方法對(duì)于各種應(yīng)用程序而言，與使用未打包的RAM進(jìn)行遷移相比可能更具成本效益。

我們發(fā)現(xiàn)了與該主題相關(guān)的出色研究工作： GC輔助Java Server Applications的JVM Live Migration 。 作者將JVM與CRIU（在用戶空間中的Checkpoint / Restore）集成在一起，并引入了一種新的GC邏輯，以減少Java應(yīng)用程序從一臺(tái)主機(jī)實(shí)時(shí)遷移到另一臺(tái)主機(jī)的時(shí)間。 提供的方法允許在獲取Java進(jìn)程狀態(tài)的快照之前啟用可感知遷移的垃圾收集，然后通過(guò)在磁盤(pán)上檢查點(diǎn)來(lái)凍結(jié)正在運(yùn)行的容器，然后從凍結(jié)點(diǎn)恢復(fù)容器。

另外，Docker社區(qū)正在將CRIU集成到主流中。 目前，此功能仍處于試驗(yàn)階段。

Java和CRIU的組合可以釋放仍未發(fā)現(xiàn)的性能和部署優(yōu)化機(jī)會(huì)，以改善云中Java應(yīng)用程序的托管。 您可以在“ 容器實(shí)時(shí)遷移：幕后 ”一文中找到有關(guān)容器實(shí)時(shí)遷移如何在云中工作的更多詳細(xì)信息。

Java很棒，并且已經(jīng)在云中（特別是在容器中）很好地工作了，但是我們相信它會(huì)更好。 因此，在本文中，我們介紹了一系列當(dāng)前問(wèn)題，可以對(duì)這些問(wèn)題進(jìn)行改進(jìn)，以平穩(wěn)高效地運(yùn)行Java應(yīng)用程序。

在Jelastic，我們?cè)谌驍?shù)百個(gè)數(shù)據(jù)中心中運(yùn)行著數(shù)千個(gè)Java容器。 良好的內(nèi)存管理對(duì)我們至關(guān)重要。 這就是為什么我們不斷將有關(guān)Java內(nèi)存的新發(fā)現(xiàn)納入我們的平臺(tái)的原因，因此開(kāi)發(fā)人員不必明確處理這些問(wèn)題。 嘗試在Jelastic增強(qiáng)平臺(tái)上運(yùn)行Java容器 。

翻譯自: https://www.javacodegeeks.com/2017/04/java-ram-usage-containers-top-5-tips-not-lose-memory.html

總結(jié)

以上是生活随笔為你收集整理的容器中Java RAM的使用：不会丢失内存的5大技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。