记一次Docker下SpringBoot占用优化

---

操作:

Step.1

1.删除不必要的POM依赖

2.dockerFile部分

• FROM openjdk:8 -> FROM openjdk:8-jre-alpine

1.有 attach 容器的需求，又希望最小化镜像的大小，可以选用 alpine 作为基础镜像。Alpine 镜像的特点是体积非常下，基础款镜像的体积仅 4 MB 左右

2.这里并未直接继承基础款 alpine，而是选用从 alpine 构建出的包含 java 运行时的openjdk:8-jre-alpine（80MB左右）作为基础镜像

优化前

优化后

镜像:整体减少了:(574-129)+(526-84.9)=886.1m ,四舍五入1个G

内存:整体减少了:(249.2-229.7)=19.5m ,没多少

这里参考了:

1.https://developer.aliyun.com/article/686040

Step.2

体积是小了,但是内存还是很大…

继续操作操作…

前言: 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的最小限制。

操作

1.依旧是dockerFile部分

• FROM openjdk:8-jre-alpine	变成->	FROM adoptopenjdk/openjdk8-openj9:alpine-slim
  

• # 设置环境变量
  ENV JAVA_OPTS="-server -Xms512m -Xmx512m"
  

• ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/batchsendemail.jar"] 变成-> ENTRYPOINT java $JAVA_OPTS -Xshareclasses -Xquickstart -jar /batchsendemail.jar
  

整体的DockerFile:

# 设置基础镜像 jdk8
FROM adoptopenjdk/openjdk8-openj9:alpine-slim
# 维护人员信息
MAINTAINER JinSc
VOLUME /tmp
ENV LANG C.UTF-8
ENV LANGUAGE zh_CN.UTF-8
#这个会引起中文乱码(控制台以及html里面的中文),不知道为何不
#ENV LC_ALL C.UTF-8
ENV TZ Asia/Shanghai
# 设置环境变量
ENV JAVA_OPTS="-server -Xms512m -Xmx512m"
ADD batchsendemail-0.0.1-SNAPSHOT.jar /batchsendemail.jar
ENTRYPOINT java $JAVA_OPTS -Xshareclasses -Xquickstart -jar /batchsendemail.jar

来看一看结果:

这里参考了:

​ 1.https://blog.csdn.net/fly910905/article/details/119877617

总结:

1.镜像体积

比Step.1
	(191+147)-(129+84.9) = 124.1m
	多了 124.1m
比未优化前
	(574+526)-(191+147)=762m
	少了762m

2.占用内存

比Step.1
	229.7-166.1=63.6m
	少了63.6m
比未优化前
	249.2-166.1=83.1m
	少了83.1m

用80G的硬盘空间中的极小占比(0.15%)的:124.1m,换取4G内存中不小占比(1.55%)的:63.6m, 值不值得,应该显而易见,毕竟内存多贵啊…

所以维持Step.2的优化

注意:

本次优化不针对大型生产环境(但是不排除不能用)

如有大佬,还请留言赐教

Q.E.D.