JVM设置不当造成的生产事故

说来你可能不信，但是这就是事实，JVM设置不当会选成严重的生产事故；这段时间随着业务数据量的不断提升，遇到了很多性能方面的问题，其中就包括JVM的配置；

1.服务频繁重启

我的系统上游对接了一些系统A，系统A会间隔1小时推一次数据，每次推送大概40-50W的数据量，就在上周，系统其中一个节点突然频繁重启，一到整点就收到服务重启的告警，我的个去，这让我很尴尬（毕竟这个节点前几天刚出过事故）；

2.原因分析

查看CPU、IO、内存、JVM的监控都没有查出为什么，只是看出内存的可用空间剩余不多了，但也还有20G左右；查日志文件发现日志文件中有提示内存剩余30%,20%的提示，然后就是重启日志；
生产的内存是130G，就算是剩余20%那还有20多G呢，为什么会重启呢？
没找到原因，只好服务重启上线，在后台观察发现整点内存就会突然升高，JVM的年轻代占用一直上升，却没有触发YGC，在服务器后台执行手动触发GC，内存就会大幅度下降；

手动触发FGC命令：jmap -histo:live

感觉有些眉目了，开始找运维同学一起去看JVM参数的配置，年青代大小占30G左右空间，老年代占用40G；运维同学给了一条重要的提示：

服务器有自我保护机制，内存超过配置的比例后，会kill掉占用内存最大的进程；

之前这台服务器只有我的服务器在跑，内存设置的超大，但后来上面部署了很多的其它服务，导致物理内存整体不够用时，启动自我保护机制，杀掉消耗内存最大的进程；
原因虽然找到了，但我的JVM参数配置也确实有问题，我举个例子，如果你的年轻代设置的过大，只要年青代还有空间，就不会触发YGC，那就导致年轻代一直占用内存不释放；

回顾下JVM的相关知识：
年青代和老年代的比例默认：1：2
年青代Eden和S0,S1默认：8：1：1
年青代只有当Eden满时，才会触发YGC；

3.总结

经过上面混乱的分析，我简单总结下：就是如果你的年青代设置过大，年青代只要不满的时候，就不会触发YGC，会导致你的物理内存一直处于一个占用状态；
1.合理分配JVM内存，选择合适的垃圾回收器
2.建设系统的监控