1:GC Log Output
Add-xx:+printgc-xx:+printgcdetails-xx:+printgctimestamps-xx:+printgcapplicationstopedtime to the JVM startup parameters. The JVM will output GC profiles, details, GC time information, and the application pause time caused by the GC, in the order of these parameters. If you add the parameter-XLOGGC after the argument: the file path, the GC information will be exported to the specified file. Other parameters also include
-VERBOSE:GC and-xx:+printtenuringdistribution and so on.
2:jconsole
Jconsole is the JDK's own memory analysis tool, which provides a graphical interface. You can view memory information, thread information, class load information, mbean information for the monitored JVM.
Jconsole is located under the JDK directory in the bin 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 application, the execution Jconsole Pid,pid is the running Java process ID, and if you do not take the PID parameter, after executing the jconsole command, you will see a dialog box pops up, listing the local Java process and selecting one to monitor. If you want to monitor remotely, add something to the JVM parameters of the remote server, because Jconsole remote monitoring is based on JMX, and for jconsole detailed usage, see the article specifically Jconsle, and I'll give you a detailed description of jconsole in my blog.
3:JVIUSALVM
After JDK6 update 7, the JDK introduced another tool: the Jvisualvm,java visual virtual machine, which not only provides jconsole-like functionality, but also provides JVM memory and CPU real-time diagnostics, as well as manual dump of JVM memory to manually execute GC.
Like Jconsole, running JVIUSALVM, under the JDK's Bin directory execution jviusalvm,windows under Jviusalvm.exe,linux and Unix is jviusalvm.sh.
4:jmap
Jmap is the JDK's own tool for JVM memory analysis, located in the JDK Bin directory. Jmap command usage in jdk1.6:
Copy Code code as follows:
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 native example, execute the command, and the screen shows:
Num #instances #bytes class name
----------------------------------------------
1:242062791864 <constMethodKlass>
2:223712145216 [C
3:242061940648 <methodKlass>
4:19511364496 <constantPoolKlass>
5:265431282560 <symbolKlass>
6:63771081744 [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
Total239019 17140408
I deleted some lines for ease of viewing. It is easy to see from the information above that, #instance指的是对象数量, #bytes指的是这些对象占用的内存大小, class name refers to the object type.
Looking at the dump option for Jmap, this option is to output the JVM's heap of memory information into a file that I perform on my native
Jmap-dump:file=c:dump.txt 340
Note that 340 is my native Java process pid,dump out of the file is a lot more than 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 large. What you need to know is that the dump file information is very primitive, it's not for people to watch directly, and the Jmap-histo display is too simple, such as showing just how much memory a certain type of object consumes, and the number of objects, but no more detail, such as who created the objects. So what's the use of dump files? Of course, because there are tools that specialize in analyzing the memory dump files of the JVM.
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, execution jhat-j-xmx512m [file], file is the dump file path. Jhat built-in a simple Web server, which, after execution, jhat the access address of the analysis results in the command line, you can specify the port with the-port option, which can be used to perform jhat-heap viewing help information. When you visit the specified address, you can see the information displayed on the page, much richer and more detailed than the Jmap-histo command displays.
6:eclipse Memory Analyzer
It says Jhat, which analyzes the dump file of the JVM, but it's all text, and Eclipse Memory Analyzer is an eclipse that provides a plug-in for analyzing the JVM heap dump, which is faster than jhat, and the result is graphical interface display, is more readable than jhat. In fact, JVISUALVM can also analyze the dump file, also has a graphical interface display.
7:jstat
If Jmap tends to analyze object information in the JVM's memory, then Jsta is inclined to analyze the GC case of 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 are specific to view Jsat help information, I often use-gcutil, the role of this parameter constantly shows the current specified JVM memory garbage collection information.
I perform jstat-gcutil 340 10000 in my native computer, which is the GC information that outputs a JVM every 10 seconds, and 10000 refers to a time interval of 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 will be a lot of rows when actually executing):
Copy Code code as follows:
S0 S1 E O P ygc ygctfgcfgct GCT
54.62 0.00 42.87 43.52 86.24 17925.093337.670 12.763
The amount of ... How to say, to understand what this information means, you must also have a certain understanding of the JVM's GC mechanism. In fact, if people who know about the sun's hot spot JVM are more likely to understand this information, but the GC mechanism is a bit confusing, I'd like to talk about the GC mechanism of the Sun's JVM first. When it comes to GC, it's not just a Java concept, in fact, before the Java, there are many languages have the concept of GC, GC is the meaning of garbage collection, more is a kind of algorithmic things, but with the specific language does not have much relationship, so on the history of GC, GC's mainstream algorithm I will not speak, That's too far to pull, too far to pull is nonsense. Sun is now the JVM, the memory management model is a generational model, so the GC is of course collected by generational. What does the generational mean? is to divide the object into three levels according to the life cycle, namely: Cenozoic, old generation, lasting generation. When objects are first allocated, most are in the Cenozoic, and when the Cenozoic GC submissions are triggered, a new generation-wide GC is executed, which is called the minor GC, and if a few minor GC is executed, the object survives, transferring these objects to the old generation, Because these objects have been tested by the organization, wow. The GC frequency of the old generation will be lower, if the old generation executes the GC, that is the full GC, because it is not a local GC, but a fully-scoped GC, which can cause applications to pause because full memory collection must block memory, and no new objects to be allocated to memory, and the persistence generation is some JVM Objects that are essentially not disappearing, such as class definitions, JVM method area information, such as static blocks. The main thing is that there are three more spaces in the new generation: the Eden,susvivor0,susvivor1, literally, is the Garden of Eden, surviving 1, and surviving the area of Zone 2. New objects are allocated in the Eden area, and the Eden area is full, using a marker-copy algorithm that checks out the surviving objects in the Eden area and copies them into S0 or S1, then empties the Eden area. The JVM's GC approach is not just that simple, for example, serial collection, parallel collection, concurrent collection, and a famous train algorithm, but that's too far to go, and now it's a good idea. Here, let's take a look at the information that is printed above:
Copy Code code as follows:
S0 S1 EO P ygc ygctfgcfgct GCT
54.62 0.00 42.87 43.52 86.24 17925.093337.670 12.763
S0: The new generation of Susvivor0 area, the space utilization rate is 5,462%
S1: The new generation of Susvivor1 area, the space utilization rate is 0% (because has not performed the second minor collection)
E:eden area, space utilization rate 42.87%
O: Old generation, space use rate 43.52%
P: Lasting band, space usage 86.24%
Ygc:minor gc Execution times 1792 times
Ygct:minor GC takes 5.093 milliseconds
Fgc:full GC Execution Times 33
Fgct:full GC takes 7.670 milliseconds
Total time spent in GCT:GC 12.763 milliseconds
How to choose a tool
Some of the tools listed above, each have advantages and disadvantages, in fact, if the development environment, the use of what kind of tool is indifferent, as long as the results are good. But in the production environment, but can not be indiscriminate, because these tools themselves will consume a lot of system resources, if a production server when the pressure is very high, the execution of these tools, may cause a very unexpected situation. It is best not to monitor on the server, remote monitoring will be better, but if you want to remote monitoring, server-side startup scripts to add some JVM parameters, such as the use of Jconsloe remote monitoring Tomcat or JBoss, you need to set the JVM's JMX parameters, If you are simply analyzing the server's memory allocation and GC information, it is highly recommended that you first use Jmap to export the heap dump files of the server-side JVM, and then use Jhat, or JVISUALVM, or the Eclipse Memory Analyzer to analyze the memory situation.
