发现的问题

1.部分服务对于jvm的堆的参数并没有进行限制。
2.服务初始化占用的内存偏大(相比起c,go等原生的语言)
3.服务在并发高的时候内存占用也偏高。

不设置相关jvm参数

jvm的默认堆内存大小

1.由于现在使用的物理机，内存基本都是>=16G。
所以jvm的默认初始堆为物理内存的64分之一。
默认最大堆是物理内存的四分之一。

服务器内存

某个未设置的服务的内存使用情况

假设在32G的内存下，存在这么一个服务，没有对jvm参数进行设置。
那么初始堆内存默认为512MB，最大堆内存为4GB.
容易导致以下几个问题：

1.服务初始堆内存的利用率低(在初始化后，预热前，初始化内存的利用效率可能是不高的。
如果并发并不高，没有必要将其设置过大，并发高的前提下可以设置大一些,后期如果很快需要拓展，还不如一开始就给与足够的空间)
2.默认堆内存的空间过大，会导致GC的回收时间变长。因为单位时间内需要回收的垃圾变多了，这无疑是很耗费cpu资源的。
3.此外由于像老年代的回收，是需要占用到一定的比例，才会进行回收，那由于本身的内存较大，当触发回收时，其实有很多没用的对象已经占用内存很久了。

所以不设置的话会导致几个特点：
1.初始堆内存过大，初始化时，存在内存利用率低的可能性
2.最大堆内存过大，内存迟迟不被回收，占用过多内存空间。
3.回收时间过长，降低吞吐量,甚至服务不可用。

所以在服务运行前，需要设置好对应的参数。
-Xmx以及-Xms，将初始化堆内存以及最大堆内存设置好，这里需要根据实际应用的运行情况进行调整。

应用初始化内存占用大

暂时没有太成熟的框架可以去解决。
目前大多数框架都是针对预热稳定之后去减少资源浪费的(如基于netty框架为底层的容器undertow等)

贴近原生确实可以减少初始化服务需要使用的内存，如aot编译。
aot技术可以做到提前编译，但是这样做会牺牲平台无关性(jvm支持的其实不是java语言，而是以class文件为基础。
任何语言只要可以编译成class文件即可在jvm上运行)，aot是直接将java文件编译成可以直接运行的机器语言。
相比之下，少了classCode的缓存，自然会轻许多，像一个普通的spring服务，相关的class以及classCodeCache加起来上百兆是有的。如下图所示。

某个服务的内存使用情况

存在的弊端：

jlt提供的优化功能就失效了。
假设一个代码被运行了若干次，经过jlt优化后，每次可以节省1ms的时间。
随着服务运行时间越长，那么带来的损失就是 n * 1ms了。

疑问：真的有必要为了所谓的节省初始化内存，而舍弃后面的优化？

并发高时，内存占比高

使用openJDK9

如果在低频的场景中。其实使用openjdk9能节省的内存比较少。
单个服务在其初始化后可能也就1~200兆，这是openjdk9源于对容器的优化与支持。
如果所有项目都是处于运行高频，收益才会比较大，可以节省很多的内存。
针对非web服务，或者是低频的服务，可以考虑将初始内存调低，设置多了也是浪费。
目前来看，大多数服务都是256m既满足。
openjdk9的优势在于高频时，对内存的占用小(HotSpot的OpenJDK 8少大约63％)，另外吞吐量也大致相同。
但是这种优势只有在高频时，才可以发挥优势，如果资源够用没必要对堆内存进行压缩。

DockerFIle
FROM adoptopenjdk/openjdk8-openj9:alpine-slim VOLUME /tmp ARG artifactId ARG VERSION ADD ./target/${artifactId}-${VERSION}.war /${artifactId}.jar ENV JAVA_OPTS="-Xms256m -Xmx512m" ENV JAR_FILE_NAME ${artifactId} ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 /$JAR_FILE_NAME.jar" ]