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内存也没有太离谱,优化到此结束。


你可能感兴趣的:(Java)