内存溢出

dump文件分析结果

导致原因，缓存未及时清理

分析工具    HeapAnalyzer  

最近同事写的一个接口大批量调用，产生内存溢出。需要接口优化。

大致看了下代码产生原因如下：

1：接口里有大量hashmap非线程安全

2：接口用mvc封装，我认为封装后肯定跟项目启动就加载的servlet 的速度没法比

3：报文格式化用了模版，我认为每次加载模版肯定影响速度。

等优化完再记录

IBM HeapAnalyzer是一款JAVA内存泄露检测工具。下载之后首先阅读一下readme，这上面详细写了HeapAnalyzer的使用方法。

可以在命令行中输入<Java path>java –Xmx[heapsize] –jar ha26.jar <heapdump file>来启动工具并加载heapdump文件。对于比较大的heapdump，将-Xmx设置一个较大的值（大于heapdump的大小），来避免加载过程中的OOM。对于64位机器上产生的超大heapdump，个人机器上分析就不大可能了。

打开heapdump文件后，我一般点击“Analysis”里的“Tree View”，以树的形式从根节点展示内存对象分配的信息

第一行java.lang.ref.Refenrence这个class及它的76个children占用了67%的已用堆大小（31M/46M），它本身仅占用了76bits。双击java.lang.ref.Refenrence，我们可以看到它所引用的两个子节点。其中一个子节点java.lang.ref.Finalizer后的67%指引我们内存泄漏的问题应该在它的引用上。

接下去你可以逐级展开，或者右键点击“Locate a leak suspect”，让HeapAnalyzer帮你找到泄漏可能发生的地方。泄漏一般发生在那些拥有“超乎寻常多”的引用（子节点）的class上，正是这些创建后没有释放、累积了成千上百的对象，造成了OutOfMemory。右键中的“Go to the largest drop subtrees”也是以此为原理而设的，它的解释为：

“Search for total size drop” will find a size drop between the total size of a parent and the biggest total size of child of the parent.

因为出现泄漏的点，每个子节点占用的内存空间不大，但是巨大的数量会导致父节点占用的total size很大。不过反过来寻找到的点都是泄漏发生的地方这种说法是不成立的，否则也不需要我们来分析了。