10 Jdk Built in Graphical Tools the Vast Ocean Allows Fish to Leap; the Vast Sky Allows Birds to Fly

10 JDK Built-in Graphical Tools- The Vast Ocean Allows Fish to Leap; The Vast Sky Allows Birds to Fly #

GUI graphical interface tools, mainly include 3 ones: JConsole, JVisualVM, JMC. In fact, these three products can be said to be 3 different generations of JVM analysis tools.

These three tools all support analyzing local JVM processes or connecting to remote JVM processes through JMX and other methods. Of course, the version number of the graphical interface tool should not be too different from the target JVM, otherwise, there may be errors.

Let’s introduce them separately.

JConsole #

As the name suggests, JConsole is the “Java console” where we can monitor the internal and external indicators of a Java process from multiple dimensions and time ranges. Through these indicator data, we can analyze and judge the state of the JVM, providing a basis for our optimization.

In the command prompt or terminal window on Windows or macOS, enter “jconsole” and press enter. You will see the following interface:

The local process list lists all Java processes on the local machine (we will explain remote processes in the JMX course). Select a Java process to connect to and click “Connect”, then you will see the following interface:

Note that you can connect or disconnect the Java process by clicking on the green connection icon in the upper right corner.

The above figure shows a total of 6 tabs, each corresponding to a monitoring panel, namely:

Overview: View the four indicators and their histories of heap memory, threads, classes, and CPU usage of the Java process in chart format.
Memory: The usage and details of each memory pool in the JVM.
Threads: A list of all threads in the JVM and specific status information.
Classes: Summarized information about the number of loaded and unloaded classes in the JVM.
VM Summary: The vendor, running time, JVM parameters, and summary of other data in the JVM.
MBean: MBeans related to JMX, which we will explain in the later JMX course.

Overview #

The overview information is shown in the above figure, and the four indicators are as follows:

Heap memory usage: This shows the usage of heap memory mentioned in the previous Java memory model course. From the chart, you can see that the heap memory has used about 94MB and has been continuously increasing.
Threads: Displays the number of active threads in the JVM. Currently, there are 17 active threads.
Classes: A total of 5563 classes have been loaded by the JVM, and no classes have been unloaded.
CPU usage: The current CPU usage is 0.2%, which is very low. The highest usage is also less than 3%. It can be tentatively judged that the system does not have much load or pressure.

In the overview panel, we can see all the data after connecting to the Java process from JConsole. But if the time from connecting to the process to the present is long, such as 2 days, the charts here will be crowded together due to being displayed in one interface, and the historical data will be smoothed. The current change details cannot be seen clearly.

Therefore, JConsole provides multiple time ranges for us to choose from. Click the drop-down list behind the time range to view data in different intervals. There are several time dimensions to choose from:

1 minute, 5 minutes, 10 minutes, 30 minutes, 1 hour, 2 hours, 3 hours, 6 hours, 12 hours, 1 day, 7 days, 1 month, 3 months, 6 months, 1 year, All, a total of 16 levels.

When we want to focus on the data of the last 1 hour or 1 minute, we can choose the corresponding level. The other three tabs (Memory, Threads, Classes) also support selecting time ranges.

Memory #

Memory monitoring is the most commonly used panel in JConsole. The main area of the memory panel displays the graph of memory usage over time, which can be used to intuitively judge the usage and trend of memory.

At the top left, we can select different memory areas in the drop-down box behind the chart:

In this example, we are using JDK 8, and GC startup parameters are not configured by default. Please pay attention to the GC content later for details about GC parameters. The memory chart provided by this JVM includes:

Heap memory usage, mainly including old generation (memory pool “PS Old Gen”), young generation (“PS Eden Space”), survivor space (“PS Survivor Space”);
Non-heap memory usage, mainly including memory pools such as “Metaspace”, “Code Cache”, “Compressed Class Space”;
You can select the corresponding 6 memory pools separately.

Through the memory panel, we can see the usage and changes of various memory areas, and we can:

Manually perform GC: as indicated by number 1 in the figure, clicking the button will execute System.gc() in the JDK, triggering GC operation directly. Generally speaking, unless manually GC is explicitly prohibited when starting, the JVM will immediately perform a FullGC (guess how the suppliers of JSP space for rent in the past few years will choose);
Through the interface indicated by number 2 in the lower right corner of the figure, you can see the percentage usage of each memory pool, as well as the summary usage of heap/non-heap space. This chart will change in real-time, and you can directly click on these parts to quickly switch to the corresponding memory usage in the above chart;
From the interface indicated by number 3 in the lower left corner, you can see the garbage collectors used by the JVM, the number of times garbage collection is performed, and the corresponding time consumption.

After opening for a period of time, you can see a sharp decline in memory usage (as shown in the figure below), which indicates that a GC has just been performed, and the JVM has performed garbage collection.

In fact, we can notice that the memory panel is actually a graphical display of the jstat -gc or jstat -gcutil command. Their essence is the same, which is to sample JVM’s various memory pools data for statistics and display. There is actually a problem with the graphical interface. If garbage collection (GC) is frequent and occurs many times per second, the chart format is unable to reflect the changing information for each occurrence.

Threads #

The Threads panel displays information about the changing number of threads and a list of detected threads.

We can directly view the status of each thread (running or waiting) and its call stack (what operation it is currently executing) based on its name.
In particular, we can click the “Detect Deadlock” button to check for deadlocks. If no deadlocks are found, it will display a message saying “No deadlocks detected.”

Classes #

The Classes monitoring panel provides a summary of the number of classes loaded and unloaded by the JVM.

VM Overview #

The VM Overview data is also useful and consists of five parts:

The first part provides information about the virtual machine.
The second part shows the number of threads and class loading summary information.
The third part displays heap memory and GC statistics.
The fourth part presents information about the operating system and host machine, such as CPU count, physical memory, virtual memory, etc.
The fifth part contains JVM startup parameters and several key paths. These pieces of information are similar to what can be seen using the jinfo command.

This information allows us to quickly understand the basic situation of the JVM.

JVisualVM Graphical Interface Monitoring Tool #

To start JVisualVM, simply type jvisualvm in the command line or run window:

$ jvisualvm

After starting JVisualVM, the interface will look roughly like this:

You can see the local JVM instances within it.

By double-clicking on a local process or right-clicking to open it, you can connect to a specific JVM. The basic information displayed at this moment is shown in the following image:

As we can see, the Overview tab provides information such as PID, startup parameters, system properties, etc.

Switch to the Monitoring tab:

In the Monitoring tab, you can see the overall performance of the JVM, such as CPU, heap memory, classes, threads, etc. You can also perform operations like “Force Garbage Collection” and “Heap Dump.”

The “Threads” tab displays a list of threads in the JVM. Once again, we can see the benefits of naming threads (or thread pools) in the program.

Compared to JConsole, which only shows the call stack and status information of threads, here we can visually see the color-coded status and running time of all threads, helping us analyze which threads have consumed more CPU resources during a certain period of time.

Sampler and Profiler #

By default, JVisualVM includes two additional tools compared to JConsole: Sampler and Profiler.

For example, with the Sampler, we can see what each thread is doing or how much memory has been allocated to each class, etc. while performing performance testing.

When using the Profiler, you need to calibrate the analyzer first.

Then, you can use it similar to the Sampler.

From this panel, you can directly see the hot method with its execution time, memory usage, and ratio. You can also set filtering conditions.

At the same time, you can directly save the current data and analysis as a snapshot, or export the data for later loading and analysis.

Plugins #

The most powerful feature of JVisualVM lies in its plugins.

For JDK 8, you need to install a higher version (such as Java SE 8u211) to install/update JVisualVM’s plugins from the official server (otherwise, you can only rely on luck to find the corresponding historical version).

Steps to install the MBeans plugin for JVisualVM:

Go to Tools (T) - Plugins (G) - Available Plugins - Select specific plugins - Install - Next - Wait for installation to complete.

The most commonly used plugins are VisualGC and MBeans.

If you cannot see available plugins, please install the latest version or download the plugins for local installation. First, exclude network issues or check for updates and try restarting.

After installation, reconnect to a JVM and you will see the newly installed plugins.

Switch to the VisualGC tab:

Here, you can see the usage of various memory pools, as well as information such as class loading time, total number of GCs, and total GC time. It’s much simpler than using command-line tools.

Switch to the MBeans tab:

Most people may not pay much attention to MBeans, but MBeans are quite useful for understanding the principles of GC.

Focus on the MBeans under the java.lang package. For example, memory pools or garbage collectors.

From the diagram, you can see that the Type of the Metaspace memory pool is NON_HEAP.

Of course, you can also look at the garbage collectors (GarbageCollector).

For all garbage collectors, the information obtained through the JMX API includes:

CollectionCount: the total number of GCs the garbage collector has performed.
CollectionTime: the cumulative runtime of the collector, which is equal to the sum of the durations of all GC events.
LastGcInfo: detailed information about the most recent GC event. It includes the duration, start time, and end time of the GC event, as well as the usage of each memory pool before and after the most recent GC.
MemoryPoolNames: the names of each memory pool.
Name: the name of the garbage collector.
ObjectName: the name of the MBean defined by the JMX specification.
Valid: whether this collector is valid. Personally, I have only seen cases where it’s “true”.

Based on experience, these pieces of information cannot draw any conclusions when analyzing GC performance. Only by writing programs and obtaining JMX information related to GC can we perform statistics and analysis.

Now let’s see how to perform remote real-time monitoring.

As shown in the above diagram, from the File menu, we can select “Add Remote Host” and “Add JMX Connection”.

For example, when adding a JMX connection, after entering the IP and port number, select “Do not require SSL connection” and click the “OK” button.

Regarding how to start JMX support for the target JVM, please refer to the following section on JMX.

Remote hosts require support from JStatD. Please refer to the JStatD section.

JMC Graphical Client #

JMC and JVisualVM have similar functions because JMC was originally JRMC, an analysis tool that came with BEA’s JRockit JDK. After Oracle’s acquisition, it was integrated into the JMC tool. Oracle is trying to replace JVisualVM with JMC and use JMC for commercial usage of JFR requires authorization and payment.

After entering “jmc” in the command line, the launched interface is as follows:

Click on the relevant button or menu to enable the corresponding function. The features provided by JMC are similar to JVisualVM.

Flight Recorder #

In addition to the common functions of JConsole and JVisualVM (including JMX and plugins), the highlight of JMC is the Flight Recorder.

After clicking on “Flight Recorder” on the process, you need to confirm the option to disable the locking of commercial features for the first use:

Then you can see the Flight Recorder wizard:

Clicking “Next” will show more configurations:

Here we can also select the options for analyzing Heap Memory and Class Loading. Click “Finish” and wait for a minute to see the Flight Recording.

In the Summary section, you can use the dashboard to view data such as Heap Memory, CPU Usage, and GC Pause Time.

In the Memory panel, you can see detailed analysis of the GC:

In the Code panel, you can see the execution of hot methods:

In the Thread panel, you can see the contention of threads:

Compared with JConsole and JVisualVM, there are already a lot of analysis data here, such as memory allocation rate, average time for GC, etc.

Finally, we can also save the flight recording as a JFR file for later viewing and analysis, or send it to others for analysis.

JStatD Server Tool #

JStatD is a powerful server-side support tool used for remote monitoring, so it is mentioned in the graphical interface section.

However, because it involves exposing some server information, a security policy file needs to be configured.

$ cat /etc/java/jstatd.all.policy

grant codebase "file:${java.home}/../lib/tools.jar" {
   permission java.security.AllPermission;
};

Start JStatD in the background:

jstatd -J-Djava.security.policy=jstatd.all.policy
  -J-Djava.rmi.server.hostname=198.11.188.188 &
  
Where 198.11.188.188 is the public IP. If there is no public IP, it will be the internal IP.

Then use JVisualVM or JConsole to connect to the remote server. The IP is 198.11.188.188 and the default port number is 1099. Of course, the port number can be customized with parameters.

Note: The major version of the client and server JVM must be the same or compatible.

The CPU graph is not displayed because JStatD does not monitor CPU for individual instances. You can add JMX monitoring configuration in the startup parameters of the corresponding Java application. Please refer to the JMX course later for details.

More Tools #

The JDK also comes with other tools, such as jsadebugd, which can start an RMI server on the server host, and jhat, which can be used to analyze hprof memory dump files, etc. They are not introduced here, but you can search for them if you are interested.

In the actual JVM performance analysis process, we can choose the appropriate tools from these tools according to our needs to understand the system’s metrics and status, and provide a basis for our optimization decisions.