Java Memory Viewing and analysis

1:GC Log Output

Add-xx:+printgc-xx:+printgcdetails-xx:+printgctimestamps-xx:+printgcapplicationstopedtime to the JVM startup parameters, The JVM will output GC profile, details, GC time information, and application pause times caused by GC in these parameter sequences. If you add the parameter-XLOGGC: file path After the parameter, the GC information will be output to the specified file. Other parameters are

-VERBOSE:GC and-xx:+printtenuringdistribution and so on.

2:jconsole

Jconsole is a memory analysis tool that comes with the JDK, which provides a graphical interface. You can view memory information, thread information, class load information, and mbean information for the monitored JVM.

Jconsole is located in the Bin directory under the JDK directory, under Windows is Jconsole.exe, under UNIX and Linux is jconsole.sh,jconsole can monitor the local application, also can monitor the remote application. To monitor the local app, execute Jconsole pid,pid is the Java process ID that is running, and if you do not have the PID parameter, then after executing the jconsole command, you will see a dialog box pops up, listing the local Java process, you can choose one to monitor. If you want to remotely monitor, you want to add something to the JVM parameters of the remote server, because Jconsole's remote monitoring is based on JMX, for jconsole detailed usage, please see the article about Jconsle, I will specifically introduce jconsole in the blog.

3:JVIUSALVM

After JDK6 update 7, the JDK launched another tool: Jvisualvm,java visual virtual machine, which not only provides jconsole similar functions, but also provides the JVM memory and CPU real-time diagnostics, as well as manual dump out of the JVM memory, manually perform GC.

Like Jconsole, running JVIUSALVM, under the bin directory of the JDK jviusalvm,windows under Jviusalvm.exe,linux and Unix is jviusalvm.sh.

4:jmap

The Jmap is a tool for the JDK's own JVM memory analysis, located in the JDK's Bin directory. Jmap command usage in jdk1.6:

Usage:

Jmap-histo <pid>

(to connect to running process and print histogram of Java object heap

Jmap-dump:<dump-options> <pid>

(to connect to running process and dump Java heap)

Dump-options:

Format=b binary Default

File=<file> dump Heap to <file>

Example:jmap-dump:format=b,file=heap.bin <pid>

Jmap-histo <pid> Displays the JVM memory status of the specified PID on the screen. Take my machine as an example, the command is executed and the screen displays:

Num #instances #bytes class name

----------------------------------------------

1:24206 2791864 <constMethodKlass>

2:22371 2145216 [C

3:24206 1940648 <methodKlass>

4:1951 1364496 <constantPoolKlass>

5:26543 1282560 <symbolKlass>

6:6377 1081744 [B

7:1793 909688 <constantPoolCacheKlass>

8:1471 614624 <instanceKlassKlass>

9:14581 548336 [Ljava.lang.Object;

10:3863 513640 [I

11:20677 496248 java.lang.String

12:3621 312776 [Ljava.util.hashmap$entry;

13:3335 266800 Java.lang.reflect.Method

14:8256 264192 Java.io.objectstreamclass$weakclasskey

15:7066 226112 Java.util.treemap$entry

16:2355 173304 [S

17:1687 161952 Java.lang.Class

18:2769 150112 [[I

19:3563 142520 Java.util.HashMap

20:5562 133488 Java.util.hashmap$entry

Total 239019 17140408

For ease of viewing, I deleted some lines. It is easy to see from the above information that #instance指的是对象数量, #bytes指的是这些对象占用的内存大小, class name refers to the object type.

And then look at the dump option of jmap, this option is to output the JVM's heap memory information to a file that I perform in my native

Jmap-dump:file=c:dump.txt 340

Note 340 is my native Java process pid,dump out of the file compared to a lot of 10 m, and I just opened Tomcat, ran a very simple application, and no access, can imagine, large busy server, dump out of the file how big. What you need to know is that the dump file information is very primitive, not suitable for people to watch directly, and Jmap-histo display is too simple, such as showing only some types of objects occupy how much memory, as well as the number of these objects, but there is no more detailed information, such as who created these objects. So what's the use of the dump file? Of course it works because there are tools that specialize in analyzing the JVM's memory dump files.

5:jhat

As mentioned above, there are many tools to analyze the JVM's memory dump file, Jhat is the sun Jdk6 and the above version of the tool, located in the JDK Bin directory, execute jhat-j-xmx512m [file], file is the dump file path. Jhat built-in a simple Web server, after this command executes, jhat the command line to display the analysis results of the access address, you can use the-port option to specify the port, specific use can be performed jhat-heap view help information. Once you have accessed the specified address, you can see the information displayed on the page, which is much richer and more detailed than the Jmap-histo command displays.

6:eclipse Memory Analyzer

Above said Jhat, it can analyze the JVM dump file, but all is text display, Eclipse Memory Analyzer, is an eclipse provides for analysis JVM heap dump plug-in, it's analysis faster than jhat, analysis results are graphical interface display, More readable than the jhat. In fact, JVISUALVM can also analyze the dump file, also has a graphical interface display.

7:jstat

If Jmap is inclined to analyze the JVM's in-memory object information, then Jsta is a GC case that tends to analyze JVM memory. are JVM memory analysis tools, but obviously they are analyzed from different dimensions. Jsat commonly used parameters are many, such as-gc,-gcutil,-gccause, these options specific role can see Jsat help information, I often use-gcutil, the role of this parameter constantly displays the current specified JVM memory garbage collection information.

I am performing jstat-gcutil 340 10000 on this machine, this command is to output the JVM's GC information every 10 seconds, 10000 means the interval is 10000 milliseconds. The following information is displayed on the screen (I only take the first line, because it is displayed at a certain frequency, so there are many rows when actually executing):

S0 S1 E O P ygc ygct FGC fgct GCT

54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763

    ... How to say, to understand what this information means, you must also have a certain understanding of the GC mechanism of the JVM. In fact, if you know more about Sun's hot spot JVM's GC, it should be easy to understand this information, but it's not clear that the GC mechanism is a bit confusing, so here I'm going to talk about the Sun's JVM's GC mechanism. When it comes to GC, in fact, not just Java concept, in fact, before Java, there are many languages have the concept of GC, GC is garbage collection meaning, more is an algorithmic thing, and the specific language is not much related, so about the history of GC, GC mainstream algorithm I do not speak That's too far, too far to pull. Sun's current JVM, the memory management model is a generational model, so the GC is of course a generational collection. What does the generational mean? The object is divided into three levels according to the life cycle, namely: The Cenozoic, the old generation, the lasting generation. When the object was first allocated, most of them were in the Cenozoic, and when the new generation GC submission was triggered, a new generation-wide GC was executed, called the minor GC, and if a few minor GCs were executed, the objects survived, and the objects were transferred to the old generation, Because these objects have been tried and tested by the organization. The GC frequency of the old generation is lower, if the old generation performs the GC, that is the full GC, because it is not a local GC, but a whole memory-scoped GC, which can cause the application to stall, because full memory is collected, the memory must be blocked, new objects are not allocated to memory, and the persistent generation is some JVM, Objects that are basically not disappearing, such as the definition of class, JVM method area information, such as static blocks. The main thing is that the Cenozoic is divided into three spaces: eden,susvivor0,susvivor1, literally understood, is the Garden of Eden, surviving 1 districts, surviving 2 districts. The new object is allocated in the Eden area, and when Eden is full, the tag-copy algorithm is used to check out the surviving objects in the Eden area, copy the objects into S0 or S1, and then empty the Eden area. The JVM's GC says, not just so simple, for example, serial collection, parallel collection, concurrent collection, and the name of the train algorithm, but that's too far, and now the general understanding of this is good. Speaking of which, let's take a look at the output information above:

S0 S1 E O P ygc ygct FGC fgct GCT

54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763

S0: The new generation of Susvivor0 area, with a space utilization rate of 5,462%

S1: The Susvivor1 area of the Cenozoic, with a space utilization of 0% (since no second minor collection has been performed)

E:eden area, Space utilization 42.87%

O: Old generation, space utilization 43.52%

P: Durable belt, space utilization 86.24%

Ygc:minor gc Execution times 1792 times

Ygct:minor GC time spent 5.093 milliseconds

Fgc:full GC Execution Times 33

Fgct:full GC time spent 7.670 milliseconds

Total time spent in GCT:GC 12.763 MS

How to choose a tool

Some of the tools listed above, each have pros and cons, in fact, if in the development environment, the use of what kind of tools is irrelevant, as long as the results can be good. However, in the production environment, but can not be arbitrarily selected, because these tools themselves will consume a lot of system resources, if the pressure on a production server, the hasty implementation of these tools, may cause a very unexpected situation. It is best not to monitor the server, remote monitoring will be better, but if you want to remotely monitor, server-side startup script to add some JVM parameters, such as using Jconsloe remote monitoring tomcat or JBOSS, etc., need to set the JVM's JMX parameters, If you are simply analyzing the server's memory allocations and GC information, it is highly recommended that you first export the heap dump file of the server-side JVM with Jmap, and then use Jhat, or JVISUALVM, or Eclipse Memory Analyzer to analyze the memory status.

Java Memory Viewing and analysis