一次生产OOM问题排查javajiexiu4617的博客-

现象分析：
我们有一个生产服务，规模是12台机器*6个节点 = 72个节点的服务，最近老是出现某个节点突然挂掉的情况，问题出现频繁，一天需要重启很多个节点
查看tomcat日志，发现是堆内存溢出
使用jmap -heap pid查看各个JVM内存空间的使用情况发现，所有的内存都被占满了，如下图所示：

发现堆内存的确都被吃完了
使用top查看各个pid吃资源的情况后发现OOM的节点的CPU资源占用特别高，基本都在100%以上

疯狂吃CPU推断应该是在JVM在进行fullGC(回收老年代，在进行fullGC的时候，程序不提供任何其他服务)，使用jstat -gc pid查看GC情况

其中每个字段的意思对应如下

S0C：第一个幸存区的大小 S1C：第二个幸存区的大小 S0U：第一个幸存区的使用大小 S1U：第二个幸存区的使用大小 EC：伊甸园区的大小 EU：伊甸园区的使用大小 OC：老年代大小 OU：老年代使用大小 MC：方法区大小 MU：方法区使用大小 CCSC:压缩类空间大小 CCSU:压缩类空间使用大小 YGC：年轻代垃圾回收次数 YGCT：年轻代垃圾回收消耗时间 FGC：老年代垃圾回收次数 FGCT：老年代垃圾回收消耗时间 GCT：垃圾回收消耗总时间 

看到其中fullGC的次数非常高，达到200-9000次，时间高达以小时计数，所以推断应该是有大对象在内存中，并且一直在被引用

使用jmap -histo pid查看哪些对象占用了空间发现char对象占据了特别大的空间

在程序OOM的时候使用jmap -dump:live,format=b,file=tai.hprof pid这个命令dump下当时的内存文件到磁盘中。使用gzip压缩文件（VPN限速太慢，时间可能很长）并且拉去到本机上

使用eclipse的插件分析dump文件tai.hprof

发现其中一个异常，一个线程对象持有了大量内存空间

点击see stacktrace查看对应的堆栈信息

发现最后一步在程序中的堆栈信息是这一行代码是最后执行代码

查看内存占用发现一个String对象使用内存非常多，并且结构有点像第三方返回对象

将值存储到对应文件中发现这个字符串大小为660MB，其中的值截取如下：

结果：结果是发现是调用下层的Go项目返回的HTTP response中返回的对象太大，经过各种装换之后，一个线程持有的内存达到了4G多，而一个tomcat进程分配的内存总共也就5G，造成的OOM。经过排查Go项目。的确有一个地方有bug，存在笛卡尔积，在数据条数100+条列表的时候产生的对象会产生大对象的String返回到我们这个生产服务 。