记录线上的一次OOM

背景

“星哥，不好了，线上的一个服务出现了OOM”
我：“怎么回事？查到原因了吗？”
“还没有，初步估计是因为并发过大导致”
我：“嗯，你先去解决一下，不行我在上！”
一个月后
“星哥，不好了，那个服务还是出现OOM了”
我：“这个服务是干什么的？”
“就是调用微信接口，跟微信交互的！”
我：“那你是怎么解决的？
“我走读了一圈代码，没有发现会出现漏洞的情况，初步估计是因为并发过大导致的，所以增加了256M的内存，原来是每两周出现了一次，改了之后，我观察了两周，发现没有问题，就以为好了，但是过了两周再次出现了！”
我：“找没找江江拿dump日志？”
”额，没有！“
我：”先根据dump出来的日志看看！“

流程梳理

线上的一个服务主要跟微信进行交互，提供微信授权、场景二维码生成、支付、退款、对账等，非常纯粹的接口服务，通过代码排查，并没有发现可能导致的泄露问题，那么大概率是来自第三方jar包中

通过工具排查

作者使用的是eclipse带的memory analysis，其实还有其他更加好用的工具，不过分析这个问题，memory analysis已经足够了。我们先把dump文件导入进去

不需要什么复杂的套路，先去’Unreachable Objects Histogram‘里面看看

其实作者当时为排查问题，查看了不少的内容，比如：Dominator Tree、Histogram等等，这里都进行简化了。一个类com.thoughtworks.xstream.core.util.CompositeClassLoader引起了我的注意，这个对象有点虚高啊，而且xstream主要是用来解析xml，按理不可能达到这个数量级，ok既然已经知道是由于xml解析导致的问题，那么就好办了，遛一遛代码

在这里作者发现了xml解析的痕迹，在往里面看看

感觉比较接近了啊，instance()单例里边看看

咦，不是单例啊，每次都new一个新的，难怪有点烧，在进去看看


咦，这不就是com.thoughtworks.xstream.core.util.CompositeClassLoader吗？我靠哦，每次new stream的时候，都new了一个CompositeClassLoader，但是释放的时候，CompositeClassLoader根本就没有释放啊，难怪令郎的胸大肌居然如此的浮夸，简直是在逗我啊！

后记

既然已经发现了问题，那么后续的解决已经没有任何套路，按部就班即可，不在叙述了。