文章目录
惨案的发生
Full GC很正常，但是频繁的Full GC并且导致线上CPU飙升，然后服务直接宕掉，这是很可怕的。
2018年11月19号，项目升级，起初观察日志都OK，但是半小时后，服务无法访问，界面无法打开（最初是Zabbix监控CPU飙升，然后邮件告警才知道）。
然后拜托性能测试的同事帮忙一起分析问题，首先是线上Full GC异常频繁，每隔几十秒一次，半小时后CPU飙升直接宕机。我们再结合本次升级的内容及排查是否有频繁的外部请求、频繁的读取数据库的操作，终于找到问题所在：
外部会请求一个http接口，然后该接口内部，在本次升级过程中有个功能是会去读取数据库
- 外部请求该接口每秒十几笔
- 读取数据库的数据量是400万+
综上，相当于每秒会有十几次的请求数据库几百万的数据！！！
解决方案
临时解决方案
为了上线成功，当时的临时解决方案是，先将该接口的读取数据库的这一部分功能下架（因为该功能外部还不会使用到这些数据）。
后续解决方案
将这部分数据缓存起来，然后每次请求都会拿缓存的数据，而不是读取数据库（这部分数据主要是拿来对比用的）
后续分析
因为这次的惨案，我专门在后续抽时间分析了这个项目的内存使用情况，不分析不知道，一分析吓死人！造成升级惨案的根本原因，其实另有隐情！而那个接口是直接导火索而已！
JVM设置情况
线上的JVM配置信息如下：
-Xms4096m
-Xmx20480m
-XX:PermSize=256m
-XX:MaxPermSize=2048m
-XX:-UseGCOverheadLimit
堆设置的非常大，足足20G！！！这种情况下竟然还会频繁FullGC且服务宕掉，令人匪夷所思。
UAT环境
因为我们线上不能操作，非常严格。所以我转移到UAT环境进行持续观察，UAT的数据量、环境配置和线上是一致的。
为了观察方便，我使用本地电脑安装好的JDK工具jvisualvm进行观察，不过在观察之前需要手动配置一些东西。
- 开放jmx连接：
因为我们项目是web项目，因此需要修改tomcat中的JVM配置cd /usr/local/tomcat/bin vim setenv.sh #JAVA_OPTS中添加如下参数 JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Xms20480m -Xmx20480m -XX:PermSize=256m -XX:MaxPermSize=2048m -XX:-UseGCOverheadLimit -Dcom.sun.management.jmxremote.port=19999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=183.61.26.210" export JAVA_OPTS - 本地打开jvisualvm进行连接
观察结果
- 永久代
永久代很正常，没问题。不过也是理所当然，因为永久代主要是保存一些常量、类、方法等信息
- 堆对象
令人可怕的地方就在这里，每隔两分钟Full GC，一次持续8秒左右，全世界都安静了！！！（后续我和朋友聊起这个，他说只要有回收回来，机器不死，管他一天Full GC几次~~~哈，一笑而过）因为这个原因，CPU也不断持续的跑高。
这里顺便用命令行工具查看下堆的情况：
sudo -u tomcat jps
sudo -u tomcat jstat -gcutil 3168 1000 #每隔10秒显示堆比例
sudo -u tomcat jstat -gc 3168 10000 #每隔10秒显示堆使用大小，单位KB
堆区域说明：
* S0C：第一个幸存区的大小，单位ｋｂ
* S1C：第二个幸存区的大小，单位ｋｂ
* S0U：第一个幸存区的使用大小，单位ｋｂ
* S1U：第二个幸存区的使用大小，单位ｋｂ
* EC：伊甸园区的大小，单位ｋｂ
* EU：伊甸园区的使用大小，单位ｋｂ
* OC：老年代大小，单位ｋｂ
* OU：老年代使用大小，单位ｋｂ
* MC：方法区大小，单位ｋｂ
* MU：方法区使用大小，单位ｋｂ
* CCSC:压缩类空间大小，单位ｋｂ
* CCSU:压缩类空间使用大小，单位ｋｂ
* YGC：年轻代垃圾回收次数，单位ｓ
* YGCT：年轻代垃圾回收消耗时间，单位ｓ
* FGC：老年代垃圾回收次数，单位ｓ
* FGCT：老年代垃圾回收消耗时间，单位ｓ
* GCT：垃圾回收消耗总时间，单位ｓ
由上图可知：
- Eden区一直在创建新对象，请求内存空间
- 当Eden区100%时触发一次YGC，然后回收垃圾，S0和S1互换，然后存活对象移到老年代O区
- 当老年代O区100%时，则触发一次Full GC，进行所有的垃圾回收
- 可以看出，主要原因是Eden区一直不断的产生很多大对象，导致很多还未来得及退出方法的对象（即某个方法执行时间比较久，方法内产生的对象有被引用，会被当做存活对象）被当做存活对象移到老年代，如此反复，发生Full GC
除此之外，我们还能知道各个区域的内存大小：
S0：1.5g
S1：1.5g
Eden：3.5g
Old：14g
这种分配比例是合理的
分析
因为这个项目是我从别人手里接手的，凭经验觉得应该是有两个线程（这里定为线程A、线程B吧）在反复的读取、组装、缓存、写文件造成的，这两个线程是每个10S运行一次的！
然后我就暂时把这两个线程停止掉，再次观察CPU和堆的消耗，结果是：一条直线，非常平稳，世界不再因此而喧闹！！！果然是这两个线程搞的鬼。（因为当时还原场景的时候没有保存图片，这里就不附图了，也懒得再去还原一遍了，程序猿很懒的~~）
进一步分析
知道是这两个线程搞的鬼，但是这两个线程里面的业务逻辑非常复杂，一坨坨的，具体是哪个环节出问题呢？
好的，JVM最强大的分析工具要上场了：MAT
当然，第一步是要先dump文件啦！visualVM工具有dump功能。
这里是手动dump，在接近Full GC那个点的时候，请戳一下"堆 dump"按钮。会生成到指定的路径
除此之外，还可以自动在Full GC的时候出发文件dump，不过需要在JVM配置（如果dump文件巨大，比如6G以上，那么线上环境请谨慎开启，因为dump一次要几十秒）：
-XX:+HeapDumpOnOutOfMemoryError
笔者dump下来的文件足足有8G多~~
第二步使用MAT工具啦。Eclipse有支持MAT的插件，具体使用百度。笔者用的是IntelliJ IDEA，如果为了一个MAT再去下载安装Eclipse，那是及其麻烦的！那么，集成版、绿色版的MAT工具来了。
下载地址：https://eclipse.org/mat/downloads.php
双击打开即可
友情提示：如果你的dump文件太大，比如我的8.5G，那么需要配置MAT的JVM参数。修改安装目录下的MemoryAnalyzer.ini文件（这里我直接上8G，电脑配置好就是任性）：
这里上几张MAT分析的图吧：
其中，占据内存空间最大的是三个东东：InitListener、myScheduler-3、NgbLastCoverUtil。
其中InitListener这个类缓存很多数据，属于真正存活的对象，所以问题不是这个类。（别问我为什么会缓存这么大的数据，而不存储在redis，抱歉！这个项目不是我架构的，我也很无奈！）
myScheduler-3就是我上面所猜测的线程A、B，NgbLastCoverUtil类是线程A、B中会引用的类，所以之前的猜测是正确的！
继续分析，看下myScheduler-3堆栈信息，发现最终会指向String.split()这个函数
可怕的String.split()
赶紧追溯代码，看看是不是哪里有用到String.split()函数。果不其然：
for (String line : lines) {
String[] segments = line.split("\t");
......
}
是的，有一段逻辑会用到这个函数，乍一看，lines这个变量是List< String >类型，数据量最大的时候是66w条，每一条数据按 \t 切割后，平均会有5个数组对象。
冷静思考，先google下String.split()的可怕之处，发现JDK1.6和JDK1.7下的这个方法处理方式还不一样。
JDK1.6
底层实现是这样的：
public String substring(int beginIndex, int endIndex) {
if (beginIndex < 0) {
throw new StringIndexOutOfBoundsException(beginIndex);
}
if (endIndex > count) {
throw new StringIndexOutOfBoundsException(endIndex);
}
if (beginIndex > endIndex) {
throw new StringIndexOutOfBoundsException(endIndex - beginIndex);
}
return ((beginIndex == 0) && (endIndex == count)) ? this :
new String(offset + beginIndex, endIndex - beginIndex, value);
}
public String(int offset, int count, char value[]) {
this.value = value;
this.offset = offset;
this.count = count;
}
JDK1.6中使用String.split()，切割出来的字符串数据是直接复用了原String对象的char[]，用偏移量和长度来表示不同的字符串内容，并不会创建新对象！
JDK1.7
底层实现是这样的：
public String substring(int beginIndex, int endIndex) {
if (beginIndex < 0) {
throw new StringIndexOutOfBoundsException(beginIndex);
}
if (endIndex > value.length) {
throw new StringIndexOutOfBoundsException(endIndex);
}
int subLen = endIndex - beginIndex;
if (subLen < 0) {
throw new StringIndexOutOfBoundsException(subLen);
}
return ((beginIndex == 0) && (endIndex == value.length)) ? this
: new String(value, beginIndex, subLen);
}
public String(char value[], int offset, int count) {
if (offset < 0) {
throw new StringIndexOutOfBoundsException(offset);
}
if (count <= 0) {
if (count < 0) {
throw new StringIndexOutOfBoundsException(count);
}
if (offset <= value.length) {
this.value = "".value;
return;
}
}
// Note: offset or count might be near -1>>>1.
if (offset > value.length - count) {
throw new StringIndexOutOfBoundsException(offset + count);
}
this.value = Arrays.copyOfRange(value, offset, offset+count);
}
public static char[] copyOfRange(char[] original, int from, int to) {
int newLength = to - from;
if (newLength < 0)
throw new IllegalArgumentException(from + " > " + to);
char[] copy = new char[newLength];
System.arraycopy(original, from, copy, 0,
Math.min(original.length - from, newLength));
return copy;
}
char[] copy = new char[newLength]
是的，在JDK1.7中，切割出来的每一个字符串都会创建一个新的char[]对象，而我们项目用的就是JDK1.7
那么，按照上述的数据量，则创建的新对象总数有：66w * 5 = 330w，一个巨量级，可怕！
验证
那么我们来验证一下吧，把这个线程中有关String.split()的代码去掉吧，部署上去，观察结果如下：
Full GC现在变为每隔6分钟执行一次了，虽然情况仍然很糟，但是至少有所改善，String.split()确实是一个原因所在。
其实分析到这里，我已经很累了，不想继续了。哈？你问我为什么？线程A和线程B内部的处理逻辑非常复杂，很多申请的大对象都重用了，想优化？可以的，全部推翻重写吧！
是的，这也是我下一步的工作任务！
总结
- 大数据量情况，避免使用String.split()
- 面对复杂的业务逻辑、大数据量的时候，如何定义数据结构、如何保存数据确实是一个难题，一定要慎重！
- 别人做好的项目，你接手，那就要做好万全准备，因为这里水很深！