祖传代码的OOM

有一个祖传代码出OOM了，我已经去弄了几回了，每次原因还不一样，随意写一个，以后一定得远离这些代码了

    

这个图其实从Retianed Size 看前三行本质上都是有一定的关联关系，

看一个VIEW就可以证明上面的推测了

其实就是bufferedImage的raster变量的对象是byteInterleavedRaster.

感兴趣的直接翻源代码就知道了，代码中一眼还不好看了来是，他是父类形式的，不能一眼看出来具体引用的是哪个子类。

这个图其实已经很清晰了，不过我们看一下更有意思的

这是栈上的，并不是释放的问题。

当时并没让我去解决这个问题，因为我没有参与过这个项目。 后来我听说他们的解决这个问题 1 限制个数（pdf转image) 2 压缩一下图片吧 这个也没毛病，解决了一部分问题。

但是后来还是有这个问题的出现，只是频率低了些。于是让我去看看。

   我自己看了，是对一个 java.awt.MediaTracker  使用不当导致的，大概的代码

   

本来这个方法 也没毛病，但是他们把这个搞成了一个static的持有  MediaTracker 

 看看waitForID的源码

  

看调用

 这造成的后果是多线程的时候会多等待，然后这个会把内存（BufferImage占用的内存比较大）占用变成积累，最终OOM了

  所以对OOM分析 的时候 ，看看gc path之外，也有时看对象所持的线程也非常重要，我就是看这个持有的线程发现某个static 对象被多多个线程持有，才去检查了这块的代码从而发现的问题。