1. Application of basic commands
1.1 jps ( source operation document )
By default, the output information of jps includes the process ID of the Java process and the name of the main class. We can also print additional information by appending parameters. If a Java process turns off the UsePerfData parameter that is enabled by default (that is, using the parameter -XX:-UsePerfData), the jps command (and jstat described below) will not be able to detect the Java process.
Commonly used parameters:
-l: The module name and package name will be printed;
-v: Print the parameters passed to the Java virtual machine (such as -XX:+UnlockExperimentalVMOptions -XX:+UseZGC);
-m: Print the parameters passed to the main class.
1.2 jstat ( source operation document )
The jstat command can be used to print the performance data of the target Java process.
-class: Load related data for the print class.
-compiler and -printcompilation: will print the data related to instant compilation.
-gc: Prefix subcommands, they will print garbage collection related data.
For example, the command: jstat -gc 22126 1s 4 means to print once and print four times every second
1.3 jmap ( source operation document )
The jmap command analyzes the objects in the Java virtual machine heap. jmap also includes multiple subcommands.
-clstats, this subcommand will print the information of the loaded class.
-finalizerinfo, this subcommand will print all objects to be finalized.
-histo, this subcommand will count the number of instances of each class and the memory occupied, and arrange them in the order of least memory usage. In addition,
-histo:live only counts the live objects in the heap.
-dump, this subcommand will export a snapshot of the Java virtual machine heap. live only saves live objects in the heap. We usually use jma
1.4 jinfo ( source operation document )
The jinfo command (help document) can be used to view the parameters of the target Java process.
-X: output jvm_args in the Java virtual machine
-XX: Parameters (that is, the VM Flags in the output), and the -D parameters (that is, the System Properties in the output) that can be obtained through System.getProperty at the Java level.
1.5 jstack ( source operation document )
The jstack command (help document) can be used to print the stack trace of each thread in the target Java process and the locks held by these threads. One of the application scenarios of jstack is deadlock detection. Here I use jstack to get the stack information of a deadlocked Java program. We can see that jstack not only prints the thread stack trace, thread status (BLOCKED), held locks (locked...) and the locks being requested (waiting to lock...), but also analyzes specific deadlocks.
1.6 jcmd ( source operation document )
You can use the jcmd command directly to replace all the previous commands except jstat. As for the function of jstat, although jcmd copies part of the code of jstat and supports printing all Performance Counters through the PerfCounter.print subcommand, it does not retain the output format of jstat, nor does it have the function of repeating printing.
(The above content is a study note for the learning content of the jvm of geek time, such as intrusion and deletion)
2. Own practice
2.1 Background
Below I will give a program that simulates an endless loop, and then monitor and exclude the program in the system. First of all, we cannot perceive whether there is an infinite loop in this program. Then we monitor and investigate the program.
2.1 Monitor the program
1. First enter jps to view the java program on the running service.
2. Use the command jstat -gc 6388 1s 20 to view the program's virtual machine operation
First have a basic understanding of the printed parameters of the -gc parameter:
S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
The above used the jstat -gc xxxxx 5s 100 command to view the performance of the jvm
You can see the green in the above figure is to monitor the performance data of jvm, which mainly includes EU, OU, YGC.
First look at the green set of data:
From the 20th to the 21st gc of gc, s1u was emptied and s0u increased. Because of gc, the surviving objects of s1u and the objects promoted in edn area were copied to s0u area, and then the objects of s1u were cleared.
Then look at the yellow and red data:
It can be seen that the data in the OU has basically increased a lot, while the data in the su area has decreased, because a full gc was performed during the period to promote the objects in the su area to the old generation.
Seeing the above data can only see the basic internal operation in the jvm, and can not see whether it is abnormal, but the basic clues can be seen for the programs that you are familiar with. Because it has been gc again in a short period of time, let's continue to observe.
Then look at the same command:
First observe the values of OU and OC. OU keeps increasing and the value is very close to OC, which means that the program will throw OutOfMemoryError soon, which is a very serious error. Therefore, we must pay attention to the ratio between these two values of jvm. According to a reasonable situation, a program that runs OU for a long time should be more stable and fluctuate according to one up and down. If it increases again, and the growth rate is abnormal, the program must have bugs. According to the teaching content, OU usually accounts for less than 20% of the OC, and if it exceeds 20%, an early warning is necessary. There is already a clue of OutOfMemoryError.
First, a full gc was performed in a short period of 30 seconds, and the program would crash after another 30 seconds at this rate of increase. In fact, it really collapsed.
Now that we have problems with the operation of the program, the next step is to analyze the program.
Using Jstack -l PID >> file location, you can output the running status of all threads of a business process.
After the output, you can see that a nid thread is business code and is always Runable, indicating that it has been occupying the cpu and cannot be released. So it is very likely that there is a problem in this position, and then I have to check the familiarity of the code, debug and other operations.
Finally, use the kill command to kill the process.
1.kill -3 pid can print the thread information of the current process, but will not close the Java application!
2. Kill pid, which is kill -15 pid, will call the hook function ShutdownHook . Generally, some operations will be performed in ShutdownHook, such as saving data and closing connections.
3. kill -9 pid. The hook function ShutdownHook will not be called .
3. Summary of personal thoughts:
The most common thing is in the project, when there is an infinite loop, the situation that has been occupied is not released. If it is a thread in a common request in the web system, an ordinary request, and the request is expected to be executed quickly, not time-consuming Tasks, you will find that multiple threads have been processing the Runable or wait state, and the same method, the same piece of code has been executed and occupied. At this time, there is a high probability that there is an infinite loop for this method. You can kill it. However, killing the program in this way is very harmful to the degree of program damage. In order to better eliminate this situation early, I personally feel that it is recommended to add a log in the cycle, even if the infinite cycle can be predicted and dealt with in advance to reduce the occurrence of major accidents.
(Due to the limited ability and time, I will analyze it for the time being. If there is something wrong, I hope everyone will come out and correct it in the future)