Reprinted Source: https://wensong.iteye.com/blog/1986449
The most recently has been studying hot deployment, hot deployment issues related to a relatively headache is to check the memory leaks (Memory Leak), and thus be in the process of research hot deployment, dry up the one thing that is a memory leak check.
When the memory leak check, most began experimenting with its own JDK tools to solve this matter, by jstat and jmap, to find out whether there is a memory leak when it is determined there is a memory leak exists, try to go in search of the point of memory leaks, find a simple use JDK tool itself provides no good way, I tried jhat, found it too difficult to check, and later recommended online comparison tool, I chose the MAT (Memory Analyzer tool).
MAT is an eclipse plug-in, started up more quickly. It can quickly analyze the dump file, you can visually see the relevant information for each object reference relationship between the amount of memory footprint size, and the number of instances of the class, object, find the object GC Roots, in addition also generates memory leaked report, large object suspected of leaking the report and so on.
- Installation MAT
- You can choose to eclipse plug-in installed
- http://download.eclipse.org/mat/1.3/update-site/
- You can also choose to download and install a separate program MAT
- http://www.eclipse.org/mat/downloads.php
- Use MAT check out of memory
- Generate dump
- Generating a dump file can be directly used jmap -dump: format = b, file = xxx.bin $ {pid} manner
- MAT can also be used to generate direct, File- "Acquire Heap Dump -" choose to dump the java process - "finish on it
- After generating dump, can be opened by MAT dump (if parsed automatically will dump after MAT), File- "Open Heap Dump to dump file is parsed to generate a final Overview view, this figure is a schematic view showing a Some statistics, including the number of the entire size of the size, number class, and objects, will also generate a large object in FIG top, and line shows a large percentage of memory occupied by the object.
- 类似：size:2.2MB Classes:3.3k Objects:50.1k ClassLoader:84 Unreachable Objects Histogram
- Identify the source overflow
- Histogram view (screenshot pillars of that, the edge is the Dominator Tree): Lists each class had a number of instances, and occupy much memory, percentage
-
- You can easily find out the station memory up to a few classes, according to Retained Heap sort, to find the first few.
- Dimensions can be divided into different classes Histogram view to view, Group by class, Group by superclass, Group by class loader, Group by package
- As long as there is an overflow, over time, the number of instances of the class or overflow its possession more and more memory, more and more ranking it before, many times by comparison chart comparing Histogram at different points in time can be very easy to overflow class find out.
- Dominator Tree (dominant tree): lists each object (Object instance) and its reference tree relations, also contains occupy much memory, percentage
- You can easily find memory for up to several objects, according to Percentage (percentage) to sort.
- It can be divided into different dimensions to view objects Dominator Tree view, Group by class, Group by class loader, Group by package
- 和Histogram类似，时间久了，通过多次对比也可以把溢出对象找出来，Dominator Tree和Histogram的区别是站的角度不一样，Histogram是站在类的角度上去看，Dominator Tree是站的对象实例的角度上看，Dominator Tree可以更方便的看出其引用关系。
- 定位溢出的原因
- 通过Path to GC Roots或者Merge Shortest Paths to GC Roots
- 通 过Histogram视图或者Dominator Tree视图，找到疑似溢出的对象或者类后，选择Path to GC Roots或者Merge Shortest Paths to GC Roots，这里有很多过滤选项，一般来讲可以选择exclude all plantom/weak/soft etc. references。这样就排除了虚引用、弱引用、以及软引用，剩下的就是强引用。从GC上说，除了强引用外，其他的引用在JVM需要的情况下是都可以 被GC掉的，如果一个对象始终无法被GC，就是因为强引用的存在，从而导致在GC的过程中一直得不到回收，因此就内存溢出了。
- 接下来就需要直接定位具体的代码，看看如何释放这些不该存在的对象，比如是否被cache住了，还是其他什么原因。
- 找到原因，清理干净后，再对照之前的操作，看看对象是否还再持续增长，如果不在，那就说明这个溢出点被成功的堵住了。
- 最后用jstat跟踪一段时间，看看Old和Perm区的内存是否最终稳定在一个范围内，如果长时间稳定在一个范围，那溢出的问题就解决了，如果还再继续增长，那继续用上述方法，看看是否存在其他代码的溢出点，继续找出，将其堵住。
- 此外通过list objects或show objects by class也可以达到类似的效果，不过没看GC Roots的方式直观，这里就不细说了。
- list objects -- with outgoing references : 查看这个对象持有的外部对象引用。
- list objects -- with incoming references : 查看这个对象被哪些外部对象引用。
- show objects by class -- with outgoing references ：查看这个对象类型持有的外部对象引用
- show objects by class -- with incoming references ：查看这个对象类型被哪些外部对象引用