Open source tools Efficient analysis of Java applications __java

More than once, we all had the idea of trying to find out what was going on in the bottom of a running program. This need may be due to slow service, Java Virtual Machine (JVM) crashes, hangs, deadlocks, frequent JVM pauses, sudden or persistent high CPU usage, and even terrible memory overflows (oome). The good news is that there are a number of tools available to help you get the different parameters of the Java Virtual machine running, which will help you understand its internal situation and diagnose all of the above.

In this article, I'll introduce some of the best open source tools. Some of these are from the JVM and others are third-party tools. I'll start with the simplest tools and move on to some of the more complex tools. The purpose of this article is to help you find the right debugging diagnostic tool, so that when the program appears to perform abnormally, slowly, or at all, there are tools available at hand.

All right, let's go.

If your program has an abnormally high memory load, no response, or memory overflow, the most common point of analysis is to view the memory object. Fortunately, the JVM has built-in tool "Jmap", which makes it inherently capable of accomplishing this task.

Jmap (with a little help from JPM)

Oracle describes Jmap as a program to "output processes, core files, shared object memory mappings for remote debugging servers, and heap memory details." This article will use Jmap to print a memory count chart.

In order to run Jmap, you need to know the PID (process identifier) of the program being debugged. The simple way to get the PID is to use the JPS provided by the JVM, which lists each JVM process and its PID on the machine. The JPS output is shown below:

Figure 1:JPS Command's terminal output

To print the memory statistics, we need to open the Jmap console program and enter the PID and "-histo:live" options for the program. If you do not add this option, Jmap will completely export the program's heap memory, which is not the result we want. So, if you want the "Eureka" in the picture above. Proxy program's memory statistics diagram, we should run Jmap with the following command:

Jmap–histo:live 45417

The output of the above command is as follows:

Figure 2: The output from the command jmap-histo:live shows the number of existing objects in the heap

Each row in the result displays information about each type of class in the current heap, including the number of instances allocated and the number of bytes consumed.

In this case, I asked my colleagues to add an obvious memory leak to the program. Please pay special attention to the class at line 8th, Celledata. Compare it to the screenshot shown in the following illustration 4 minutes later:

Turn from: http://webservices.ctocio.com.cn/387/12198887.shtml