問(wèn)題一：內(nèi)存

時(shí)至今日，絕大多數(shù)產(chǎn)品級(jí)應(yīng)用仍然在使用Java 8(或者更舊的版本)，而這可能會(huì)帶來(lái)問(wèn)題。Java 8(update 131之前的版本)跟docker無(wú)法很好地一起工作。問(wèn)題是在你的機(jī)器上，JVM的可用內(nèi)存和CPU數(shù)量并不是Docker允許你使用的可用內(nèi)存和CPU數(shù)量。

比如，如果你限制了你的Docker容器只能使用100MB內(nèi)存，但是呢，舊版本的Java并不能識(shí)別這個(gè)限制。Java看不到這個(gè)限制。JVM會(huì)要求更多內(nèi)存，而且遠(yuǎn)超這個(gè)限制。如果使用太多內(nèi)存，Docker將采取行動(dòng)并殺死容器內(nèi)的進(jìn)程！JAVA進(jìn)程被干掉了，很明顯，這并不是我們想要的。

為了解決這個(gè)問(wèn)題，你需要給Java指定一個(gè)最大內(nèi)存限制。在舊版本的Java(8u131之前)，你需要在容器中通過(guò)設(shè)置-Xmx來(lái)限制堆大小。這感覺(jué)不太對(duì)，你可不想定義這些限制兩次，也不太想在你的容器中來(lái)定義。

幸運(yùn)的是我們現(xiàn)在有了更好的方式來(lái)解決這個(gè)問(wèn)題。從Java 9之后(8u131+)，JVM增加了如下標(biāo)志：-XX:+UnlockExperimentalVMOptions

-XX:+UseCGroupMemoryLimitForHeap

這些標(biāo)志強(qiáng)制JVM檢查L(zhǎng)inux的cgroup配置，Docker是通過(guò)cgroup來(lái)實(shí)現(xiàn)最大內(nèi)存設(shè)置的。現(xiàn)在，如果你的應(yīng)用到達(dá)了Docker設(shè)置的限制(比如500MB)，JVM是可以看到這個(gè)限制的。JVM將會(huì)嘗試GC操作。如果仍然超過(guò)內(nèi)存限制，JVM就會(huì)做它該做的事情，拋出OutOfMemoryException。也就是說(shuō)，JVM能夠看到Docker的這些設(shè)置。

從Java 10之后(參考下面的測(cè)試)，這些體驗(yàn)標(biāo)志位是默認(rèn)開(kāi)啟的，也可以使用-XX:+UseContainerSupport來(lái)使能(你可以通過(guò)設(shè)置-XX:-UseContainerSupport來(lái)禁止這些行為)。

問(wèn)題二：CPU

第二個(gè)問(wèn)題是類似的，但它與CPU有關(guān)。簡(jiǎn)而言之，JVM將查看硬件并檢測(cè)CPU的數(shù)量。它會(huì)優(yōu)化你的runtime以使用這些CPUs。但是同樣的情況，這里還有另一個(gè)不匹配，Docker可能不允許你使用所有這些CPUs。可惜的是，這在Java 8或Java 9中并沒(méi)有修復(fù)，但是在Java 10中得到了解決。

從Java 10開(kāi)始，可用的CPUs的計(jì)算將采用以不同的方式(默認(rèn)情況下)解決此問(wèn)題(同樣是通過(guò)UseContainerSupport)。

Java和Docker的內(nèi)存處理測(cè)試

作為一個(gè)有趣的練習(xí)，讓我們驗(yàn)證并測(cè)試Docker如何使用幾個(gè)不同的JVM版本/標(biāo)志甚至不同的JVM來(lái)處理內(nèi)存不足。

首先，我們創(chuàng)建一個(gè)測(cè)試應(yīng)用程序，它只是簡(jiǎn)單地“吃”內(nèi)存并且不釋放它。javaimport?java.util.ArrayList;

import?java.util.List;

public?class?MemEat?{

public?static?void?main(String[]?args)?{

List?l?=?new?ArrayList<>();

while?(true)?{

byte?b[]?=?new?byte[1048576];

l.add(b);

Runtime?rt?=?Runtime.getRuntime();

System.out.println(?"free?memory:?"?+?rt.freeMemory()?);

}

}

}

我們可以啟動(dòng)Docker容器并運(yùn)行這個(gè)應(yīng)用程序來(lái)查看會(huì)發(fā)生什么。

測(cè)試一：Java 8u111

首先，我們將從具有舊版本Java 8的容器開(kāi)始(update 111)。docker?run?-m?100m?-it?java:openjdk-8u111?/bin/bash

我們編譯并運(yùn)行MemEat.java文件：javac?MemEat.java

java?MemEat...

free?memory:?67194416

free?memory:?66145824

free?memory:?65097232

Killed

正如所料，Docker已經(jīng)殺死了我們的Java進(jìn)程。不是我們想要的(！)。你也可以看到輸出，Java認(rèn)為它仍然有大量的內(nèi)存需要分配。

我們可以通過(guò)使用-Xmx標(biāo)志為Java提供最大內(nèi)存來(lái)解決此問(wèn)題：javac?MemEat.java

java?-Xmx100m?MemEat...

free?memory:?1155664

free?memory:?1679936

free?memory:?2204208

free?memory:?1315752

Exception?in?thread?"main"

java.lang.OutOfMemoryError:?Java?heap?space

at?MemEat.main(MemEat.java:8)

在提供了我們自己的內(nèi)存限制之后，進(jìn)程正常停止，JVM理解它正在運(yùn)行的限制。然而，問(wèn)題在于你現(xiàn)在將這些內(nèi)存限制設(shè)置了兩次，Docker一次，JVM一次。

測(cè)試二：OpenJ9

我最近也在試用OpenJ9，這個(gè)免費(fèi)的替代JVM已經(jīng)從IBM J9開(kāi)源，現(xiàn)在由Eclipse維護(hù)。 它運(yùn)行速度快，內(nèi)存管理非常好，性能卓越，經(jīng)常可以為我們的微服務(wù)節(jié)省多達(dá)30-50％的內(nèi)存。這幾乎可以將Spring Boot應(yīng)用程序定義為’micro’了，其運(yùn)行時(shí)間只有100-200mb，而不是300mb+。我打算盡快就此寫一篇關(guān)于這方面的文章。 但令我驚訝的是，OpenJ9還沒(méi)有類似于Java 8/9/10+中針對(duì)cgroup內(nèi)存限制的標(biāo)志(backported)的選項(xiàng)。如果我們將以前的測(cè)試用例應(yīng)用到最新的AdoptAJDK OpenJDK 9 + OpenJ9 build：docker?run?-m?100m?-it?adoptopenjdk/openjdk9-openj9?/bin/bash

我們添加OpenJDK標(biāo)志(OpenJ9會(huì)忽略的標(biāo)志)：java?-XX:+UnlockExperimentalVMOptions?-XX:+UseCGroupMemoryLimitForHeap

MemEat...

free?memory:?83988984

free?memory:?82940400

free?memory:?81891816

Killed

Oops，JVM再次被Docker殺死。 我真的希望類似的選項(xiàng)將很快添加到OpenJ9中，因?yàn)槲蚁Ｍ谏a(chǎn)環(huán)境中運(yùn)行這個(gè)選項(xiàng)，而不必指定最大內(nèi)存兩次。 Eclipse/IBM正在努力修復(fù)這個(gè)問(wèn)題，已經(jīng)提了issues，甚至已經(jīng)針對(duì)issues提交了PR。

測(cè)試三：OpenJ9(Nightly)

有人建議使用OpenJ9的最新nightly版本。docker?run?-m?100m?-it?adoptopenjdk/openjdk9-openj9:nightly?/bin/bash

最新的OpenJ9夜間版本，它有兩個(gè)東西： 另一個(gè)有問(wèn)題的PATH參數(shù)，需要先解決這個(gè)問(wèn)題 JVM支持新標(biāo)志UseContainerSupport(就像Java 10一樣)export?PATH=$PATH:/opt/java/openjdk/jdk-9.0.4+12/bin/javac?MemEat.java

java?-XX:+UseContainerSupport

MemEat...

free?memory:?5864464

free?memory:?4815880

free?memory:?3443712

free?memory:?2391032

JVMDUMP039I?Processing?dump?event?"systhrow",?detail?"java/lang/OutOfMemoryError"

at?2018/05/15?21:32:07?-?please?wait.JVMDUMP032I

JVM?requested?System?dump?using?'//core.20180515.213207.62.0001.dmp'?in?response?to?an?eventJVMDUMP010I

System?dump?written?to?//core.20180515.213207.62.0001.dmpJVMDUMP032I

JVM?requested?Heap?dump?using?'//heapdump.20180515.213207.62.0002.phd'?in?response?to?an?eventJVMDUMP010I

Heap?dump?written?to?//heapdump.20180515.213207.62.0002.phdJVMDUMP032I

JVM?requested?Java?dump?using?'//javacore.20180515.213207.62.0003.txt'?in?response?to?an?eventJVMDUMP010I

Java?dump?written?to?//javacore.20180515.213207.62.0003.txtJVMDUMP032I

JVM?requested?Snap?dump?using?'//Snap.20180515.213207.62.0004.trc'?in?response?to?an?eventJVMDUMP010I

Snap?dump?written?to?//Snap.20180515.213207.62.0004.trcJVMDUMP013I

Processed?dump?event?"systhrow",?detail?"java/lang/OutOfMemoryError".

Exception?in?thread?"main"?java.lang.OutOfMemoryError:?Java?heap?space

TADAAA，正在修復(fù)中！ 奇怪的是，這個(gè)標(biāo)志在OpenJ9中默認(rèn)沒(méi)有啟用，就像它在Java 10中一樣。再說(shuō)一次：確保你測(cè)試了這是你想在一個(gè)Docker容器中運(yùn)行Java。 結(jié)論 簡(jiǎn)言之：注意資源限制的不匹配。測(cè)試你的內(nèi)存設(shè)置和JVM標(biāo)志，不要假設(shè)任何東西。 如果您在Docker容器中運(yùn)行Java，請(qǐng)確保你設(shè)置了Docker內(nèi)存限制和在JVM中也做了限制，或者你的JVM能夠理解這些限制。 如果您無(wú)法升級(jí)您的Java版本，請(qǐng)使用-Xmx設(shè)置您自己的限制。 對(duì)于Java 8和Java 9，請(qǐng)更新到最新版本并使用：-XX：+UnlockExperimentalVMOptions

-XX：+UseCGroupMemoryLimitForHeap

對(duì)于Java 10，確保它支持’UseContainerSupport’(更新到最新版本)。

對(duì)于OpenJ9(我強(qiáng)烈建議使用，可以在生產(chǎn)環(huán)境中有效減少內(nèi)存占用量)，現(xiàn)在使用-Xmx設(shè)置限制，但很快會(huì)出現(xiàn)一個(gè)支持UseContainerSupport標(biāo)志的版本。

總結(jié)

以上是生活随笔為你收集整理的java对docker_Java和Docker限制问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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