对Docker中Spring Boot应用的内存分析 - 经验教训(翻译)

我有一个运行嵌入式Tomcat服务器的Spring Boot应用程序，非常简单…
它运行在一个Docker容器中。 若我用$ docker run运行镜像（没有内存限制），它的资源占用情况是这样：

docker stats
一个相当简单的spring boot应用的容器就占了677MB？ are you kidding me？开始挖掘真相吧…

首先，我需要看到容器中实际运行的进程。

docker exec my-app top -m
啊哈！ 有一个Gradle进程正在运行，它报告的RSS（ Resident Set Size ）与我们的Spring Boot应用程序一样大。 看看Dockerfile，很容易看出原因：

FROM anapsix/alpine-java:8_jdk

# Create app directory
RUN mkdir -p /app  
WORKDIR /app

# Bundle app source
COPY . /app

# Build the solution (using the gradle task)
RUN ./gradlew build

EXPOSE 8080

CMD ["./gradlew", "bootRun"] 

CMD使用gradle任务来运行应用程序。 gradle启动应用程序后没有退出，它挂在了那里。

1 第一次优化

所以，第一次内存优化的目的很简单 - 干掉Gradle过程！ 我只需要从使用Gradle任务引导应用程序改为直接使用Java执行.jar文件。
CMD ["java", "-jar", "build/libs/{app name}.jar"]
现在让我们看看容器中的top
Gradle进程被干掉了！ 我们削减了50％内存消耗。

2 第二次优化

即使我对Spring和Java runtime不甚了解，我仍然认为我们可以做得更好。 一个没有流量的简单API居然要382MB内存，…我们肯定错过了什么。
使用-Xmx56m指定运行时的 heap size limit（堆栈大小） 。 我想每个Java开发人员都知道这一点。 将这个参数添加到我们的$ java -jar命令将会限制Java堆栈大小为56MB。 运行时将尝试通过运行垃圾回收来保持它低于这个数字。要设置堆栈大小，我们可以在JAVA_OPTS环境变量设置Xmx参数：
docker run -e "JAVA_OPTS=-Xmx52m" app-image
这就OK了吗？ 非也！Java实际上忽略了我们的变量，并启用了默认值。
其原因在于Spring Boot。 Spring Boot会将任何环境变量传递给应用程序 - 但是我们的JAVA_OPTS并非是针对应用程序的，而是针对Java runtime本身的。 所以我们需要使用$ JAVA_OPTS变量来 exec java。 这需要对Dockerfile进行一些小改动：
ENTRYPOINT exec java $JAVA_OPTS -jar build/libs/{app name}.jar
我在命令中使用’exec’，以便它创建的子进程替换主进程。 保持容器整洁。
现在，当我们运行容器时，$JAVA_OPTS被传递给runtime，正如我们所料。 我们设置的其他任何环境变量当然也可以被Spring Boot应用拿到。
这使我们能够按照自己的意思调优Java。 以下是应用-Xmx56m参数后的结果:
得到的教训
构建工具
不要使用Gradle运行应用程序。 它在开发过程中非常棒，但是Gradle进程挂在那，占用了容器不少的内存。
JAVA_OPTS
我不太明白为什么我需要这样做。 Spring Boot本身不是应该优化了效率和性能并且拆箱即用吗？ 为什么我必须通过在堆栈上添加内存限制来增加这个风险 ？ 或者更好的问题是：为什么默认值想要这么多内存？ 我对JVM经验缺乏阻止我回答这个问题！