Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to monitor and tune the performance of JVM. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

JVM tuning is an important knowledge point in Java, especially in analyzing JVM and monitoring the running status of JVM.

1. JVM performance monitoring

1. Positioning system problems

According to

GC log

Heap dump snapshot (heapdump/hprof file)

Thread snapshot (threaddump/javacore file)

Running log

Exception stack

Tools for analyzing the basis

Jps: displays all JVM processes in the specified system

Jstat: collect operation data of all aspects of JVM

Jinfo: displaying JVM configuration information

Jmap: forms a heap dump snapshot (heapdump file)

Jhat: analyzing heapdump fil

Jstack: shows thread snapshots of JVM

Jconsole

VisualVM

Description: the latter two have a graphical interface.

2. Jps (the basis of all other commands)

Purpose: list all JVM virtual machine processes.

Format: jps-l

3. Jstat (it is the first choice to locate JVM performance issues at run time without GUI interface)

Purpose: view gc data and class load and unload data

Format: jstat option PID interval count

Meaning: do option every interval millisecond for a total of count times

Description: 3683 classes are loaded, with a total of 4355.3 bytes; 0 classes are unloaded, and the number of bytes unloaded is 0. It takes 3.16 seconds to load and unload classes.

For more use of jstat, see http://my.oschina.net/skyline520/blog/304805

4 、 jinfo

Purpose: view and modify the configuration parameters of JVM at run time

Format: jinfo-flag parameter PID

Description: modify the MaxTenuringThreshold parameter value under the 3732 process, but failed under windows.

5 、 jmap

Purpose: generate heap dump snapshots and view the most memory-intensive elements to analyze memory leaks

Format (generate heap dump snapshot): jmap-dump:format=b,file= file name PID

Explanation: as a result, I went to see for myself, it was too much.

6 、 jhat

Purpose: analyze heap dump snapshots (in conjunction with jmap)

Format: jhat file name

Note: this tool is used as a last resort.

Launch command using "ctrl+c"

7 、 jstack

Function: generate thread snapshot and locate the cause of thread stutter for a long time (deadlock between threads, deadloop, long wait caused by request for external resources)

Format: jstack-l PID

Description: view stack information for all threads in the 3732 process

The author of "in depth understanding the Java Virtual Machine" provides a tool jsp page that allows us to run the jsp page at any time while the program is running to view thread stack information, as follows:

1 Note: I commented out a paragraph in the code because I wanted to find out the stack information of the current thread, but the author did not have this comment. Summary: six commonly used JDK commands related to JVM performance: jps: query all processes in JVM to find out the PID to be operated, which is the basic jstat of all commands: view the gc of the corresponding JVM process, class load and unload information, and is the preferred jinfo for viewing JVM running data without GUI interface: view and dynamically modify JVM configuration parameters jmap: generate heap dump snapshots and compare memory-intensive objects jhat: cooperate with jmap to analyze heap dump logs Unless there is no other tool to do this, do not use the tool jstack: generate thread snapshots The reasons for locating thread stutter for a long time (deadlock between threads, dead loop, Output gc information to the console-XX:+PrintGCDetails: output GC details-XX:+PrintGCTimeStamps: output GC time information-time output gc information caused by XX:+PrintGCApplicatonStoppedTime:GC to file the above three parameters are still applicable here-Xloggc: file path / gc.log: output to file graphical JVM performance monitoring 1, graphical fault handling tool JconsolevisualVM2, Jconsole goes to "E:\ Java\ jdk1.6\ bin" Double-click "jconsole.exe" and pop up as follows: description: here is a list of all JVM processes, a Jconsole process, an eclipse (PID:4684), which is equivalent to the jps command. Select one of the PID, suppose eclipse is selected, double-click, and the following figure appears: (note: each leaf tag after that is refreshed every 4 seconds) "memory": equivalent to jstat-gc, in the details section of the above figure, the corresponding information is the parameters written in the header chart section (here is the case of "whole heap") At the same time, it also corresponds to the column selected by the column chart in the lower right corner (here is "heap"). For "non-heap", it means "method area" (or "permanent generation"). Of course, you can also select the time range to view the corresponding information. "class": equivalent to jstat-class, lists the relevant information about loading and unloading classes. "Thread": equivalent to jstack, the line chart shows the changes in the number of threads, including the number of peak threads, the number of active threads; the lower left corner shows the names of all threads. Double-click the corresponding thread name "VM feed": equivalent to jinfo finally, test the thread deadlock phenomenon. The code is as follows: View Code executes the main () method, then check the "thread" tab, click "detect deadlock", as follows: find thread Thread-95 and Thread-106 deadlock (each has the lock the other wants) Analysis: 1) Integer cache mechanism Integer.valueOf (int xxx), in order to reduce the creation of objects and save memory, this method will cache xxx into Integer objects, as long as they are the same xxx Then this method fetches the object directly from the cache. Assuming that the object generated by Integer.valueOf (1) in the code is java.lang.Integer@987197 and the object generated by Integer.valueOf (2) is java.lang.Integer@15e293a, then no matter how many times Integer.valueOf (1) is called, and no matter which thread invokes the method, only the same object java.lang.Integer@987197 is returned. In other words, Integer.valueOf (I) in the above code will only generate two different objects, java.lang.Integer@987197 and java.lang.Integer@15e293a, which are our lock objects. 2) the timing of the deadlock assumes that when the thread "Thread-95" executes into its first synchronized block (assuming that the lock object java.lang.Integer@987197 has just been acquired), the CPU time slice is switched to the thread "Thread-106", and the "Thread-106" executes its first synchronized block (obtaining the lock object java.lang.Integer@15e293a), and then "Thread-106" executes the second synchronized block to obtain the lock object java.lang.Integer@987197. At this time, it cannot be obtained, because the lock object is held by "Thread-95", so "Thread-106" is blocked on the lock object java.lang.Integer@987197. At this time, suppose the CPU time slice is switched to "Thread-95", and the thread will execute a second synchronized block to get the java.lang.Integer@15e293a. Because the lock object has been held by "Thread-106" 3) as a result, "Thread-95" holds the lock object java.lang.Integer@987197, blocking the lock object java.lang.Integer@15e293a "Thread-106" holds lock object java.lang.Integer@15e293a, blocking lock object java.lang.Integer@987197 3. VisualVM is a more comprehensive GUI monitoring tool, including many plug-ins (need to download by yourself). For details, see "in-depth understanding of Java Virtual Machine (second Edition)" JVM tuning 1. JVM tuning is mainly memory tuning. Mainly adjust two aspects: the size of each generation of garbage collector selection 2, each generation of commonly used adjustment parameters-Xmx-Xms-Xmn-XX:SurvivorRatio-XX:MaxTenuringThreshold-XX:PermSize-XX:MaxPermSize principle in the actual development, the foreground do not use jsp, the use of velocity and other template engine technology do not introduce extraneous jar-XX:SurvivorRatio too large: the survival time of objects in the younger generation is longer It may be recycled in the younger generation without having to enter the older generation, but the survivor area will be taken up more space when replicated accordingly. -XX:SurvivorRatio is too large: the survival time of objects in the younger generation becomes shorter, and they may enter the older generation early and lose the chance to be recycled in the younger generation, but there is more memory in the survivor area during the corresponding replication, which may prevent some large objects from entering the older generation directly.-XX:SurvivorRatio is too large: Eden becomes larger, Survivor becomes smaller, minor GC may be reduced, but due to the decrease of suvivor. So if minor GC survives objects larger than suvivor, it will directly enter the older generation-XX:SurvivorRatio is too small: Eden becomes smaller, Survivor becomes larger, minor GC may increase, but as suvivor becomes larger, more surviving objects can be stored, and objects entering the older generation may have less timing to adjust: minor GC too often-Xmn too small: minor GC too frequent Small objects may also directly enter the older generation, leading to excessive Full GC-Xmn in advance: the younger generation is older, the minor GC time is longer; when the older generation is smaller, the Full GC will frequently adjust the strategy: if the-Xmx is adjustable, it will be larger, and keep-Xmn==-Xmx/4~-Xmx/3. If-Xmx cannot be adjusted, increase-Xmn within the range of keeping-Xmn==-Xmx/4~-Xmx/3, and if-Xmn cannot be adjusted, try to increase-XX:SurvivorRatio to see the situation-Xmx==-Xms: to prevent frequent adjustment of heap memory, see "Chapter 1 JVM memory structure"-Xmn: usually set to-Xmx/4 (this is the way I set it when I was an intern in an enterprise, and the system runs normally, smoothly and fast) Lin Hao recommended-Xmx/3, so-Xmn==-Xmx/4~-Xmx/3-XX:SurvivorRatio: default 8-XX:MaxTenuringThreshold: default is 15-XX:MaxPermSize==-XX:PermSize3, and garbage collector selects the two most commonly used combinations in enterprises: (here, most large enterprises still use JDK1.6 So for detailed principles of the following two sets of garbage collectors, see: chapter 5 JVM garbage Collector (1) Parallel Scavenge/Parallel Old focuses on throughput (the greater the throughput, the higher the CPU utilization). It is mainly used to handle a lot of CPU computing tasks while fewer user interaction tasks are also used to allow JVM to tune automatically while we stand idly by (- XX:+UseParallelOldGC,-XX:GCTimeRatio,-Xmx). -XX:+UseAdaptiveSizePolicy)-XX:+UseParallelOldGC: specify the combination ParNew/CMS to focus on the shortening of STW (the shorter the time, the better the user experience, and reduce the request timeout problem of some requests)-XX:+UseConcMarkSweepGC: specify the use of this combination-XX:CMSInitiatingOccupancyFraction: to specify how much space is full (percentage) for garbage collection in the current year. Generally speaking, there are more CPU on the above two combinations in enterprises. And the computing power of CPU will not become a bottleneck, so it is not a big deal that the concurrent marking and clearing phase of CMS will take up CPU resources. However, it is not a big deal for Parallel to focus on throughput. After all, CPU is powerful, so ParNew/CMS is the first choice (when G1 is not available). Parallel Scavenge/Parallel Old can only use JVM to manage memory automatically. Note: in the actual tuning process, you can use the test data of jstat, jconsole, visualVM or GC logs to tune. For a specific example, see "in-depth understanding of the java Virtual Machine (second Edition)" P142 tuning the running speed of eclipse. On the meaning of the parameters of the GC log and the format of the GC log of each garbage collector, check out "in depth understanding of the Java Virtual Machine (second edition)" and "in-depth Analysis of the inside of java web Technology (revised version)" in P224. The above is what Xiaobian shares with you how to carry out JVM performance monitoring and tuning. If you happen to have similar doubts, please refer to the above analysis for understanding. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.