Spring boot内存压榨

     项目中需要一个Java HTTP服务器作为代理，这个服务只是偶尔执行几个命令，并没有什么负载(这个很关键)。基于Java语言、web服务器和开发效率上的考虑，我们选择了Spring boot框架。但是，服务上线后问题来了，本来只有1G内存的容器，Spring boot占用了400M内存。接下来就得优化Spring boot的内存了。

    第一个想到的是JVM Xmx Xms的设置问题。通过jmap -heap命令查看，eden +from + to +old内存占用了200M，由于Xmx设置比较大，eden区的内存区域比较大，这样就推迟了GC的动作。导致Spring boot占用了比较大的内存。之后，Xms设置为了64M，Spring boot程序内存减少到200M。

    问题来了，Heap内存设置这么小，为什么还占用这么多内存。接下来用jstack查看内存发现了大量的线程在运行，主要有GC task thread，http-nio thread，C2 CompilerThread，足有上百个线程在运行。Docker容器虽然隔离了资源，但是共用了操作系统内核，Spring boot发现有72个核，那就开足了马力跑线程，导致线程数量巨多。JVM默认线程栈大小是1M，光线程的开销就耗去了100多M。

                GC task thread：垃圾回收线程

                http-nio thread：tomcat网络处理网络请求线程

                C2CompilerThread：JIT编译线程，动态编译Java运行代码，C2表示编译的是server端代码

    agent的服务比较简单，不会有太深栈层次，因此把Xss设置为256k，这样可以减少大部分栈内存的开销。Gc线程数量太多，减少为两个=> -XX:ParallelGCThreads=2。

    Spring boot自带的tomcat线程数默认值为200个，我们没有这么大的并发量，这里修改Spring boot的配置application.properties的内容=> server.tomcat.max-threads = 10。

    JIT是JVM为了优化执行频率比较高的字节码设计的技术，JIT把字节码编译为机器码，之后执行则不需要解释字节码，直接运行机器码即可。我们的服务没有什么负载，即使不优化也不受影响，这里的优化是把JIT关掉，在Java启动的参数中添加 => -Djava.compiler=NONE，这样就不会再有CompilerThread了。

    经过线程的优化，JVM省去了大量的线程栈开销，最后把程序压到了100M。Java本身就是内存消耗大户，裸程序启动即消耗了30M内存，这里融合了Spring框架Tomcat服务器消耗100M内存也没有太离谱，优化到此结束。