Docker環境下Spring Boot應用內存飆升分析與解決場景分析
Spring Boot應用內存飆升
一個簡單的Spring Boot應用, 幾乎隻有一個用戶在用,內存竟然達到1.2G, 可怕
服務現狀
由於之前服務比較少，服務器資源充足，許多服務啟動時都未添加JVM參數（遺留問題）。結果就是每個服務啟動都占用瞭1.2G-2G的內存，有些服務的體量根本用不瞭這麼多。那麼，在Spring Boot中如果未設置JVM內存參數時，JVM內存是如何配置的呢？
JVM默認內存設置
當運行一個Spring Boot項目時，如果未設置JVM內存參數，Spring Boot默認會采用JVM自身默認的配置策略。在資源比較充足的情況下，開發者倒是不太用關心內存的設置。但一旦涉及到資源不足，JVM優化，那麼就需要瞭解默認的JVM內存配置策略。
關於JVM內存最常見的設置為初始堆大小（-Xms）和最大堆內存（-Xmx）。很多人懶得去設置，而是采用JVM的默認值。特別是在開發環境下，如果啟動的微服務比較多，內存會被撐爆。
而JVM默認內存配置策略分兩種場景，大內存空間場景和小內存空間場景（小於192M）。
以4GB內存為例，初始堆內存大小和最大堆內存大小如下圖：
默認情況下，最大堆內存占用物理內存的1/4，如果應用程序超過該上限，則會拋出OutOfMemoryError異常。初始堆內存大小為物理內存的1/64。
如果應用程序運行在手機上或物理內存小於192M時，JVM默認的初始堆內存大小和最大堆內存大小如下圖：
最大堆內存為物理內存的1/2，初始堆內存大小為物理內存的1/64，但當初始堆內存最小為8MB，則為8MB。
默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆內存大於70%時，JVM會減少堆直到 -Xms的最小限制。
因此，服務器一般設置-Xms、-Xmx相等以避免在每次GC後調整堆的大小。對象的堆內存由稱為垃圾回收器的自動內存管理系統回收。
其中最大堆內存是JVM使用內存的上限，實際運行過程中使用多少便是多少。默認，分配給年輕代的最大空間量是堆總大小的三分之一。
針對最開始的問題，如果每個程序都按照默認配置啟動，一臺服務器上部署多個應用時，就會出現內存吃緊的情況，造成一定的浪費。最簡單的操作就是在執行java -jar啟動時添加上對應的jvm內存設置參數。
java -Xms64m -Xmx128m -jar xxx.jar
項目使用的是Docker部署, 我們先來查看 原來的Dockerfile文件
確實沒有設置-Xms、-Xmx
#設置鏡像基礎，jdk8 FROM java:8 #維護人員信息 MAINTAINER FLY #設置鏡像對外暴露端口 EXPOSE 8061 #將當前 target 目錄下的 jar 放置在根目錄下，命名為 app.jar，推薦使用絕對路徑。 ADD target/certif-system-2.1.0.jar /certif-system-2.1.0.jar # 時區設置 RUN echo "Asia/shanghai" > /etc/timezone #執行啟動命令 ENTRYPOINT ["java", "-jar","/certif-system-2.1.0.jar"]
優化
限制JVM內存
#設置變量 JAVA_OPTS
ENV JAVA_OPTS=""#這樣寫會以shell方式執行，會替換變量
ENTRYPOINT java ${JAVA_OPTS}-Djava.security.egd=file:/dev/./urandom -jar /app.jar
#下面這樣寫法不行，他隻是拼接不會識別變量
#ENTRYPOINT ["java","${JAVA_OPTS}","-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]
Spring Boot會將任何環境變量傳遞給應用程序 – 但是我們的JAVA_OPTS並非是針對應用程序的，而是針對Java runtime本身的。 所以我們需要使用$ JAVA_OPTS變量來
exec java。 這需要對Dockerfile進行一些小改動：
ENTRYPOINT exec java $JAVA_OPTS -jar app.jar
運行docker run命令
意思是運行時通過-e重置覆蓋環境變量中JAVA_OPTS參數信息。
docker run -e JAVA_OPTS='-Xmx1344M -Xms1344M -Xmn448M -XX:MaxMetaspaceSize=192M -XX:MetaspaceSize=192M'
參數解釋
JVM常見參數
可通過JAVA_OPTS設置
參數說明：
-server:一定要作為第一個參數，在多個CPU時性能佳
-Xms：初始Heap大小，使用的最小內存,cpu性能高時此值應設的大一些
-Xmx：java heap最大值，使用的最大內存
-XX:PermSize:設定內存的永久保存區域
-XX:MaxPermSize:設定最大內存的永久保存區域
-XX:MaxNewSize:
+XX:AggressiveHeap 會使得 Xms沒有意義。這個參數讓jvm忽略Xmx參數,瘋狂地吃完一個G物理內存,再吃盡一個G的swap。
-Xss：每個線程的Stack大小
-verbose:gc 現實垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
-Xmn：young generation的heap大小，一般設置為Xmx的3、4分之一
-XX:+UseParNewGC ：縮短minor收集的時間
-XX:+UseConcMarkSweepGC ：縮短major收集的時間
提示：此選項在Heap Size 比較大而且Major收集時間較長的情況下使用更合適。
java.security.egd 作用
SecureRandom在java各種組件中使用廣泛，可以可靠的產生隨機數。但在大量產生隨機數的場景下，性能會較低。這時可以使用”-Djava.security.egd=file:/dev/./urandom”加快隨機數產生過程。
建議在大量使用隨機數的時候，將隨機數發生器指定為/dev/./urandom。
bug產生的原因請註意下面第四行源碼，如果java.security.egd參數指定的是file:/dev/random或者file:/dev/urandom，則調用瞭無參的NativeSeedGenerator構造函數，而無參的構造函數將默認使用file:/dev/random 。openjdk的代碼和hotspot的代碼已經不同，openjdk在後續產生隨機數的時候沒有使用這個變量。
abstract class SeedGenerator {
......
static {
String egdSource = SunEntries.getSeedSource();
if (egdSource.equals(URL_DEV_RANDOM) || egdSource.equals(URL_DEV_URANDOM)) {
try {
instance = new NativeSeedGenerator();
if (debug != null) {
debug.println("Using operating system seed generator");
}
} catch (IOException e) {
if (debug != null) {
debug.println("Failed to use operating system seed "
+ "generator: " + e.toString());
}
}
} else if (egdSource.length() != 0) {
try {
instance = new URLSeedGenerator(egdSource);
if (debug != null) {
debug.println("Using URL seed generator reading from "
+ egdSource);
}
} catch (IOException e) {
if (debug != null)
debug.println("Failed to create seed generator with "
+ egdSource + ": " + e.toString());
}
}
......
}
優化後的Dockerfile文件
#設置基礎鏡像jdk8
FROM java:8
#維護人員信息
MAINTAINER FLY
#設置鏡像對外暴露端口
EXPOSE 8061
#將當前 target 目錄下的 jar 放置在根目錄下，命名為 app.jar，推薦使用絕對路徑。
ADD target/certif-system-2.1.0.jar /certif-system-2.1.0.jar
# 設置環境變量
ENV JAVA_OPTS="-server -Xms512m -Xmx512m"
# 時區設置
RUN echo "Asia/shanghai" > /etc/timezone
#執行啟動命令
#ENTRYPOINT ["java", "-jar","/certif-system-2.1.0.jar"]
ENTRYPOINT exec java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /certif-system-2.1.0.jar
優化後的效果
JVM參數設置是否生效
通過 docker exec -it 5a8ff3925974 ps -ef | grep java 查看
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS 5a8ff3925974 certif-system 0.74% 493.3MiB / 800MiB 61.66% 272kB / 304kB 7.54MB / 0B 97 [root@localhost certif]# docker exec -it 5a8ff3925974 ps -ef | grep java root 1 0 5 12:13 ? 00:01:02 java -server -Xms512m -Xmx51
基礎鏡像優化
減少Spring Boot減少JVM占用的三種Dockerfile鏡像配置：
OpenJ9
OpenJ9：取代Hotspot的IBM Eclipse項目。它已經被開發很長一段時間，看起來已經足夠成熟，可以用於生產。您可以立即輕松地獲益，替換一些基本鏡像和一些參數可能足以為您的應用程序提供巨大的推動力 – 我已經通過更改 Dockerfile基本映像替換瞭一些應用程序，節約瞭大約 1/3的內存占用，增強瞭吞吐量。
FROM adoptopenjdk/openjdk8-openj9:alpine-slim COPY target/app.jar /my-app/app.jar ENTRYPOINT java $JAVA_OPTS -Xshareclasses -Xquickstart -jar /my-app/app.jar
GraalVM
GraalVM：圍繞這個由Oracle實驗室開發的有前途的虛擬機進行瞭大量宣傳。它為您提供瞭將應用程序編譯為本機鏡像的選項，生成鏡像非常非常快且內存消耗很少，吸引人眼球的另一個功能是能夠與多種語言（如Javascript，Ruby，Python和Java）進行交互操作。
FROM oracle/graalvm-ce:1.0.0-rc15 COPY target/app.jar /my-app/app.jar ENTRYPOINT java $JAVA_OPTS -jar /my-app/app.jar
Fabric8
Fabric8 shell：一個bash腳本，可根據應用程序當前運行環境自動為您配置JVM參數。它可以在這裡下載，是這個研究項目的產物。它降低瞭不少內存：
FROM java:openjdk-8-alpine
COPY target/app.jar /my-app/app.jar
COPY run-java.sh /my-app/run-java.sh
ENTRYPOINT JAVA_OPTIONS=${JAVA_OPTS} JAVA_APP_JAR=/my-app/app.jar /my-app/run-java.sh
雖然我們在應用解決方案時總是需要考慮上下文，但對我來說，獲勝者是OpenJ9，從而以最少的配置實現瞭生產就緒的性能和內存占用。
雖然仍然沒有找到使用不合適的情況，但這並不意味著它將成為一個銀彈解決方案，請記住，最好是測試替代品，看看哪種更適合您的需求。
優化後的Dockerfile文件
#設置鏡像基礎，jdk8
FROM adoptopenjdk/openjdk8-openj9:alpine-slim
#維護人員信息
MAINTAINER FLY
#設置鏡像對外暴露端口
EXPOSE 8061
#將當前 target 目錄下的 jar 放置在根目錄下，命名為 app.jar，推薦使用絕對路徑。
ADD target/certif-system-2.1.0.jar /certif-system-2.1.0.jar
# 設置環境變量
ENV JAVA_OPTS="-server -Xms512m -Xmx512m"
# 時區設置
RUN echo "Asia/shanghai" > /etc/timezone
#執行啟動命令
#ENTRYPOINT ["java", "-jar","/certif-system-2.1.0.jar"]
#ENTRYPOINT exec java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /certif-system-2.1.0.jar
#ENTRYPOINT java $JAVA_OPTS -Xshareclasses -Xquickstart -jar /certif-system-2.1.0.jar
ENTRYPOINT java $JAVA_OPTS -Xshareclasses -Xquickstart -jar /certif-system-2.1.0.jar
優化後的效果
備註
Xmx < limit
docker鏡像的內存上限，不能全部給“-Xmx”。因為JVM消耗的內存不僅僅是Heap，如下圖：
JVM基礎結構如下：棧、堆。
棧
JVM中的棧主要是指線程裡面的棧，裡面有方法棧、native方法棧、PC寄存器等等；每個方法棧是由棧幀組成的；每個棧幀是由局部變量表、操作數棧等組成。每個棧幀其實就代表一個方法
堆
java中所有對象都在堆中分配；堆中對象又分為年輕代、老年代等等，不同代的對象使用不同垃圾回收算法。-XMs：啟動虛擬機預留的內存 -Xmx：最大的堆內存
因此
JVM = Heap + Method Area + Constant Pool + Thread Stack * num of thread
所以Xmx的值要小於鏡像上限內存。
支持springboot多環境和jvm動態配置的Dockerfile
假設springboot項目 myboot-api ， 在其根目錄下創建文件Dockerfile
內容如下：
FROM java:8
MAINTAINER xxx
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
RUN echo 'Asia/Shanghai' >/etc/timezone
ENV LANG=zh_CN.UTF-8 \
JAVA_OPTS="-server -Xms512m -Xmx512m" \
SPRING_PROFILES_ACTIVE="dev"
#ARG JAR_FILE
#ADD ${JAR_FILE} app.jar
ADD target/myboot-api.jar app.jar
ENTRYPOINT exec java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar -Dspring.profiles.active=${SPRING_PROFILES_ACTIVE} /app.jar
其中ENV 環境變量
JAVA_OPTS JVM堆內存起始最大值配置
SPRING_PROFILES_ACTIVE application.yml環境
Linux 命令行創建鏡像 啟動容器
echo "===============動態參數配置 begin===============>" APPLICATION_NAME=xxx-srm-api echo "image and container name is $APPLICATION_NAME" # springboot啟動的端口號 BootPort=8082 echo "the spring boot ($APPLICATION_NAME) port is $BootPort" # docker中的springboot啟動的端口號 DockerBootPort=8082 echo "===============動態參數配置 end===============>" echo "build docker image" # mvn dockerfile:build docker build -f Dockerfile -t $APPLICATION_NAME:latest . echo "current docker images：" docker images | grep $APPLICATION_NAME echo "start container ===============> " docker run -d -p $BootPort:$DockerBootPort -e JAVA_OPTS="-server -Xms512m -Xmx512m" -e SPRING_PROFILES_ACTIVE="test" --name $APPLICATION_NAME $APPLICATION_NAME:latest
參考
https://medium.com/@cl4r1ty/docker-spring-boot-and-java-opts-ba381c818fa2
到此這篇關於Docker環境下Spring Boot應用內存飆升分析與解決的文章就介紹到這瞭,更多相關Docker Spring Boot內存內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！
推薦閱讀：
- Spring Boot 分層打包 Docker 鏡像實踐及分析(推薦)
- Spring Boot使用Docker分層打包的設置方法
- 使用docker在linux環境中部署springboot包的教程
- Springboot打包為Docker鏡像並部署的實現
- IDEA 配合 Dockerfile 部署 SpringBoot 工程的註意事項