上周由于工作原因，公司安排写单元测试，开始都很顺利,但是随着写的测试案例越来越多，项目单元测试运行就特别卡，极端情况下内存溢出,因此进行了排查
首先内存溢出问题,首先能想到的导致内存溢出的原因
- 代码问题，可能出现死循环,死锁,一次性加载过多数据,或者代码出现内存泄漏
- 项目单元测试的jvm设置本身就不够
一开始本人没有人使用任何工具排查，仅仅是排查了自己写的代码，首先如线程池进行排查,是否进行关闭,全局变量都搞成了局部变量(局部变量会随着方法结束而自动销毁),以及是否加载了过多的数据(因为单元测试都是进行mock的数据库数据,基本不可能导致加载过多数据)，再次运行还是会卡，最终导致内存泄露,但是看到下面报错
代码语言：javascript复制java.lang.OutOfMemoryError: GC overhead limit exceeded这个是JDK6新添的错误类型。是发生在GC占用大量时间为释放很小空间的时候发生的，是一种保护机制。一般是因为堆太小，导致异常的原因：没有足够的内存,
因此本人首先使用了jdk自带的工具visualvm,这个工具可以观察内存以及cpu等情况如下图
上图看到我们的堆和元空间不断的上升
此时我们就用下面命令看了一下我的jvm配置
代码语言：javascript复制jmap -heap pid
可以清晰看到内存存是512M,新生代和老年代基本都满了,为了更好的看效果，当时我还用了jdk自带的工具Jconsole,这个工具非常直观，如下图，
看到这里时候,原因就差不多出来了,基本就是我们的JVM配置过小,在运行单元测试的时候,不断的有对象在新生代存活,而新生代170M,很快就满了，然后又进入了老年代,而老年代的内存也不到341M也很快满了，最终到gc回收的时候，内存回收不了多少内存，导致的内存溢出,
但是当时让本人疑惑的是,我的配置和别的项目一样呀,都是从别人那里复制过来的,然后我对比了一下，果然是我的Jvm配置有问题,根本就没有配置JVM参数,然后查了一下,少了设置堆内存大小
代码语言：javascript复制maxHeapSize="2G"然后设置之后，重新运行了一下单元测试，果然效果明显，不再发生内存溢出,也不是卡的一动不动了，然后我们又观察了一下内存情况，如下图
基本都是新生代来回进行复制进行垃圾回收，很少有进入老年代,到此基本就解决了问题
但是我们再次期间还看到了对于单元测试卡顿的一些优化方式，我们项目使用的gradle,下面两个参数(maxParallelForks,forkEvery)可以适当的优化我们的项目，
代码语言：javascript复制test {
doFirst {
// 有多少个工人执行任务,默认为1
maxParallelForks = 2
//每个工人可以执行多少任务
forkEvery=5
}
maxHeapSize="2G"
jacoco {
destinationFile = file("$buildDir/jacoco/test.exec")
classDumpDir = file("$buildDir/jacoco/classpathdumps")
}
}
再排查过程，其实非常曲折,一开始想把内存溢出的的dump文件打印出来,尝试了各种办法，都没有办法打印出来,然后放弃了，设置jvm参数也是不起作用,研究了很长时间，谁知道配置错了文件
最终再把排查使用到的命令也分享一下，也是非常有用的命令
代码语言：javascript复制jstack pid 查看堆栈信息
jmap -dump:format=b,file=[dump文件路径] [PID] 生成dump日志文件
jmap -heap [PID]”命令，查看GradleWorkerMain进程的内存使用情况
jstat -gccause [PID] [时间间隔] [次数]”命令查看GradleWorkerMain进程的GC情况
jstat -gc [PID] [时间间隔] [次数]”命令查看GradleWorkerMain进程的内存各分区使用情况当然也是用内存溢出排查神器MAT,也是非常好用,关注回复MAT,即可获取安装包
