我有一个运行嵌入式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经验缺乏阻止我回答这个问题！
英文原文：
Memory analysis of a Spring Boot application in docker - lessons learnt
