Performance analysis Tools-Eclipse Memory Analyzer tool (MAT) (i) "Turn"

Objective

In the ordinary course of work, sometimes encounter outofmemoryerror, we know that encountered error generally indicates that the program has a serious problem, may be catastrophic. So it is very important to find out what causes outofmemoryerror. Now we introduce the Eclipse Memory Analyzer tool (MAT) to resolve the challenges we face. If not stated, this article uses the Java 5.0 on Windows XP SP3 environment.

Why use Mat?

Previously, I think it's right to use tools like real-time profiling/monitoring to analyze where a memory leak exists in a very real-time way. At the beginning of the year, a profiler tool was used to test the memory leaks in the message middleware and found that the profiler tool could not respond when throughput was high, which was a headache. It was later learned that such a tool would consume performance, and that leaks could not be found under certain conditions. So it's important to analyze off-line data, and mat is one such tool.

Why is Memory overflow

We know that the JVM performs GC according to Generation (generation), which is divided into young generation (younger generation), tenured generation (old age), permanent generation (permanent generation, perm), as shown. Gen), Perm Gen (or non-heap non-heap) is a heterogeneous one that will be described later. Note that the heap space does not include Perm Gen.

The vast majority of the objects are assigned in young generation, and also in young generation, when young generation's space is filled, the GC will minor collection (secondary recovery), This recovery does not involve other Generation,minor in the heap collection according to weak generational hypothesis (weak-age hypothesis) to assume that a large number of objects in young generation are garbage collection. The process of minor collection will be very fast. The objects that were not reclaimed in young generation are transferred to the tenured generation, but tenured generation is also filled, eventually triggering major collection (Master Recycle), which is for the entire heap, Because of the large number of objects involved, so much slower than minor collection.

The JVM has three kinds of garbage collector, which is throughput collector, which is used for parallel young generation recovery, which is initiated by the parameter-XX:+USEPARALLELGC; concurrent low pause collector, Used to do tenured generation concurrent collection, initiated by the parameter-XX:+USECONCMARKSWEEPGC, incremental low pause collector, can be considered as the default garbage collector. It is not recommended to use a garbage collector directly, it is best to let the JVM decide for itself, unless you are confident enough.

How are the generation spaces in the heap divided? The-xmx=n parameter of the JVM allows you to specify the maximum heap space, and the-Xms=n Meansminimum heap space. In the case of JVM initialization, if the minimum heap space is less than the maximum heap space, the JVM shown will mark unused space as virtual. In addition to these two parameters there are-xx:minheapfreeratio=n and-xx:maxheapfreeratio=n to control the maximum and minimum ratio of the remaining space to the active object respectively. Under the 32-bit Solaris SPARC operating system, the default values are as follows, and under 32-bit Windows XP, the default values are similar.

Parameters	Default value
Minheapfreeratio	40
Maxheapfreeratio	70
-xms	3670k
-xmx	64m

Because the tenured generation major collection is slower, so tenured generation space is smaller than young generation, will cause frequent major collection, affecting efficiency. The default size of the Server JVM for young generation and tenured generation is 1:2, which means that the sum of the Eden and survivor spaces of young generation is the entire heap (excluding perm, of course) Gen) of One-third, the ratio can be controlled by the-xx:newratio=n parameter, while the client JVM default-xx:newratio is 8. As for the newsize=n and Maxnewsize=n parameters to adjust the size of young generation, please refer to the following information.

The surviving objects in young generation were transferred to tenured generation, but unfortunately the concurrent collector thread was major collection here, and the space was exhausted before the recycling task ended. Full collections will occur, and the entire application will stop until the recycle is complete. Full GC is a nightmare for high-load production environments ...

Now for the heterogeneous Perm Gen, it is the JVM used to store objects that cannot be described at the Java language level, which are class and method data (related to class loader) and interned strings (string dwell). General 32-bit OS perm gen default 64m, can be specified by parameter-xx:maxpermsize=n, JVM Memory structure said, for this area, there is no more detailed literature, mystery.

Back to the question "Why is memory overflow?" ”。

To answer this question and to elicit another topic, what kind of object GC will be recycled? Of course, the GC finds that the object is reclaimed by any reference chain (reference chain) that cannot access an object. The noun GC Roots is the starting point for the analysis of the process, such as the JVM itself ensuring the accessibility of the object (then the JVM is GC Roots), so the GC Roots is how to keep the object reachable in memory and, once unreachable, is recycled. Typically GC roots is an object on the call stack (the calling stack) on the current thread (for example, method parameters and local variables), or either the thread itself or the System class loader (the ClassLoader) The class that is loaded and the active object that native code (local code) retains. So GC roots is a powerful tool for analyzing why objects still exist in memory. If you know what kind of object GC will be recycled, then learn what the object references contain.

From the strongest to the weakest, different reference (reachable) levels reflect the life cycle of the object.

L Strong ref (strong quote): Usually we write code that is strong Ref, which corresponds to strong accessibility, and the object is recycled only if you remove the strong.

L Soft Ref (soft Reference): corresponds to soft accessibility, so long as there is enough memory, the object is persisted until the memory is found to be tight and no strong Ref is collected. Generally available for caching, implemented through the Java.lang.ref.SoftReference class.

L Weak ref (weak reference): is weaker than soft ref, and when no strong ref is found, the object is reclaimed immediately without waiting for the memory to be tight. Implemented through the Java.lang.ref.WeakReference and Java.util.WeakHashMap classes.

L Phantom ref (virtual Reference): No object is persisted in memory, you can only use Phantom ref itself. Typically used to perform a special cleanup process after entering the Finalize () method, implemented through Java.lang.ref.PhantomReference.

With all the above I believe it's easy to burst the heap and Perm Gen, yes. Use strong Ref, store large amounts of data until the heap burst, and use interned strings (or class loader to load a large number of classes) to Perm Gen Bursting.

About shallow size, retained size

Shallow size is the amount of memory that the object itself occupies, and does not contain references to other objects, that is, the sum of the object headers plus member variables (not the values of member variables). On a 32-bit system, the object header occupies 8 bytes, and int occupies 4 bytes, regardless of whether the member variable (object or array) refers to another object (instance) or is assigned null, it always consumes 4 bytes. Therefore, for a string object instance, it has three int members (3*4=12 bytes), one char[] member (1*4=4 bytes), and one object header (8 bytes), with a total of 3*4 +1*4+8=24 bytes. According to this principle, for string a= "Rosen Jiang", the shallow size of instance A is also 24 bytes (many people dispute this, please crossing screening and leave a message to me).

Retained size is the object's own shallow size, plus the sum of the shallow size from which the object can be accessed directly or indirectly to the object. In other words, the retained size is the sum of the memory that the object can be recycled to after it has been GC. For a better understanding of retained size, consider an example.

The objects in memory are treated as nodes in, and objects and objects are referenced to each other. Here's a special node GC Roots, Positive solution! This is the beginning of reference chain.

Starting with obj1, the middle blue node represents only objects that can be accessed directly or indirectly through OBJ1. Because it can be accessed through GC roots, the OBJ3 on the left is not a blue node, whereas on the right the picture is blue because it is already contained within the retained collection.

So for the left, the retained size of the obj1 is the sum of the obj4 size of obj1, obj2, Shallow, and the retained size of Obj1, Obj2, Obj3, Obj4 is the sum of shallow size for the right figure. The obj2 retained size can be computed in the same way.

Heap Dump

Heap dump is a memory snapshot of the Java process at a specific point in time. There are different formats for storing this data, which in general contains the case of Java objects and classes in the heap when the snapshot is triggered. Because the snapshot is just an instant thing, the heap dump cannot contain information about when, where, and in what way an object is assigned.

There are different ways to get heap dump in different platforms and different Java versions, and the mat requires a heap dump binary in hprof format.

How do I get a heap dump file?

Typically, as long as you set the JVM parameters as shown below:

-xx:+heapdumponoutofmemoryerror

The JVM captures the memory state at the time when a memory leak occurs, which is the heap dump file we want.

If you don't want to wait for a crash error to get a heap dump file, you can also get the heap dump file on demand by setting the following JVM parameter.

-xx:+heapdumponctrlbreak

In addition, there are a lot of tools, such as Jmap,jconsole, that can help us get a heap dump file. The command to get heap dump using Jmap is as follows:

Jmap-dump:format=b,file=<dumpfile> <pid>

EXPLANATION:format=b--> Specifies the format for binary;file=<dumpfile>--> specifies the file name, custom;<pid>-to-process ID

Since I am a windows+jdk5, I chose-xx:-heapdumponoutofmemoryerror this way, for more configuration please refer to the Mat Wiki.

Performance analysis Tools-Eclipse Memory Analyzer tool (MAT) (i) "Turn"