从去年11月份把我的定时抢红包程序从阿里云ECS迁移到百度云的BCC之后,就经常出现OOM异常.一开始运行正常,然后等大概3天出现.
准备结合JVM的知识来找到问题的源头.
01 jps获取进程ID
首先我登录到百度云主机,输入jps,可以通过jps命令获取到的的java进程id
jps -v
我的应用进程ID是 1961
02 jstat获取到虚拟机的统计信息
通过jstat -gc可以获取到Java堆中的状况
jstat -gc 1961
目前老年代OU还没有耗尽OC,所以暂时还不会OOM,并且老年代发生了8次GC,新生代发生了190次GC了
jstat -gc 1961 250 200
连续打印日志发现Eden区的日志是不断上升的,所以新建对象一般是分在了eden区
03 jmap 获取到对象的统计数量
jmap -dump 命令可以把我的java应用的内存镜像导出,但是导出来有300多M,因为要导出到我的本地时间比较慢,所以我直接查看对象数量
jmap -histo 1961 > a.txt
发现排在前面的有一个DTO对象和一个lamda对象,通过查询源代码发现这个lamda对象是一个线程池中的task.
源码的这两处和JVM堆中的对象一一对应,也就是在任务提交这里出现了大量的任务未被执行,并且放入到了队列当中.
查下了下线程池,果不其然,队列的数据结构是默认的LinkedBlockQuee,这种数据结构的队列可存放任务数是Integer的最大值.
大概是没间隔3秒,往这个线程池中提交3个任务.
现在可以判断是线程池任务的笑话速度比不过往线程池中添加任务的速度.所以导致出现了对象的大量的积压最终堆中的内存不足以承载这么多的任务.所以出现了内存溢出OOM.
04 jstack打印当前应用的线程栈
目前线程池中有20个线程,同时并发消耗任务,为什么会消耗慢于任务提交呢
jstack -l 1961
jstack打印了当前所有的线程,整理了一下,执行任务线程池的线程,一共有20个.其中5个是处于RUNNABLE,另外15个是WAITING状态.
并且阻塞的地方都是在HttpClient.doExecute方法下,我使用的是RestTemplate.
RestTemplate是对HttpClient的封装.而HttpClient里面是有维护一个连接池的,我想到连接池的参数是不是过小,所以继续获取需要线程等待,
查看源码果然是设置最大连接数为5
05 还是有问题
到这里,我已经知道了为什么我的线程池有20个线程,但是线程池只有5个线程在工作,其他的在等待是因为httpclient里面内置的连接池最大连接只有5个.
但是当我断点的时候,发现这5个线程永久性的"卡"在了http连接这一步,到底是为什么呢?
首先我想到的是不是没有超时导致的,果然,在源码和断点中发现超时时间是-1导致了永久性的卡主.
06 总结
通过这次问题排查,我总结一下这次生产问题的原因.
最终造成的结果是出现OOM.
通过JDK的工具排查发现堆中对象数最多的是一个DTO和一个lambda对象,可见是不断的堆积,并且没有被垃圾回收最终导致的OOM.
按图索骥发现是线程池的拒绝策略无效,因为线程池的队列是LinkedBlockQuee,所以每过3秒就会往队列里面添加对象,并且不断累积.
通过jstack发现线程池的20条线程,只有5个是运行,15个waitting,从而找到这个任务方法里面的Httpclient的内置连接池只有5个连接,所以导致线程池20个线程无效.
为什么会队列任务消耗数量比不过任务的累计数量呢?
说明任务的执行时间很长,但是每天添加任务的时段是7点-23点,也就是还有8个小时的时间来消耗任务,但是依然没有消耗完.就像是任务一直卡在那个lambda里面了.
通过源码和断点发现,由于httpclient连接池里面的超时时间为-1,也就是永远的超时.
07 解决方案
首先设置restemplate的连接超时时间,并且设置最大连接数为20.
修改线程池的队列数量为ArrayBlockQuee,并且限制数量,拒绝策略为直接拒绝,因为是抢红包任务,不怕任务丢失
