JDK's own monitoring and analysis tool Jconsole

A lot of developers think they know Java programming. The truth is that most developers are just scratching the surface of the Java platform. The study is only enough to cope with the work.

The author will dig deep into the core features of the Java platform. Reveal some little-known facts. help you solve the toughest programming challenges.


When application performance is compromised, most developers are panicked. This is understandable.

Tracking the source of Java application bottlenecks has always been cumbersome because Java virtual machines have black-box effects and Java Platform Analysis tools are consistently flawed.


However, with the introduction of Jconsole in Java5, everything has changed.

Jconsole is a built-in Java Performance Analyzer that can be executed from the command line or in Guishell. It's not perfect, but it's much better to use it when the tip boss asks you questions about performance--it's more than a query papagoogle.


We'll show you 5 ways to easily monitor Java application performance and track code in Java using Jconsole (or its more advanced "close relatives" VisualVM).


1.JDK Companion Analyzer


Many developers are unaware of the inclusion of a parser in the JDK starting with Java 5.

JConsole (or the latest version number of the Java platform.) VisualVM) is a built-in parser that is as easy to start as the Java compiler.

Assume that you start from the command line so that the JDK is on path and executes Jconsole.

Assuming booting from Guishell, find the installation JDK path, open the Bin directory, and double-click Jconsole.


When the analysis tool pops up (depending on the Java version number being executed and the number of Java programs being executed), a dialog box may appear, requiring the URL of a process to be entered to connect, or a number of different native Java processes (sometimes including the jconsole process itself) to be connected.

Working with the Jconsole


In Java 5, Java processes are not set to be parsed by default. Instead, a command-line parameter--dcom.sun.management.jmxremote--tells the Java 5 VM to open the connection at startup so that the parser can find them, and when the process is picked up by jconsole, you can simply double-click it to start the analysis.

The profiler has its own overhead, so the best way to do this is to take the time to figure out what the overhead is. The simplest way to find jconsole overhead is to. First execute an application alone. It is then executed under the parser. and measure the difference.

(the application cannot be too large or too small; I prefer to use the SwingSet2 sample that came with the JDK.)

Therefore, I use-VERBOSE:GC to try to perform SwingSet2 to view garbage collection cleanup, then execute the same application and connect the Jconsole parser to it. When the Jconsole is connected. A stable GC cleanup stream appears, otherwise it will not appear. This is the profiler's performance overhead.

Jconsole or VISUALVM?

Jconsole has been advertised with the Java platform version number since Java 5, and VISUALVM is a parser that was upgraded on NetBeans basis, and was first published in Update 12 of Java 6. Most techniques are related to both analyzers, where the main analysis is Jconsole


2. Remote connection process


Because the Web application profiling tool uses a socket for connectivity analysis, you only need to make a little configuration to set up Jconsole (or JVMTI-based analyzers. In this case), monitor/analyze remotely executed applications.

Suppose Tomcat executes on a machine called "Webserve", and the JVM has started jmx and listens on port9004, connecting it from Jconsole (or whatever jmxclient) requires a jmx URL "Service:jmx:rmi :///jndi/rmi://webserver:9004/jmxrmi ".


Basically, to analyze an application server that executes in a remote datacenter, you need a jmx URL.


3. Tracking statistics


Jconsole has a number of useful tabs for collecting statistics, including:


Memory: The activity is tracked for each heap in the JVM garbage collector.


Threads: Checks the current thread activity in the target JVM.


Classes: Observe the total number of classes that the VM is loaded into.

These tabs (and related diagrams) are provided by a JMX object that is registered by each Java 5 and later VM on Jmxserver. is built into the JVM. A complete list of the beans available in a given JVM is listed on the Mbeans tab, containing some metadata and a limited user interface to view data or run operations. (However, the notification is outside the Jconsole user interface.) )


Using statistical data


Suppose a tomcat process dies from OutOfMemoryError. Suppose you want to figure out what happened, open Jconsole, click the Classes tab. Once in a while to see the class count. Assuming a steady increase in the number, you can assume that the application server or your code has a classloader vulnerability somewhere, and will soon run out of PermGen space. Suppose a further confirmation is required. Please look at the Memory tab.


Don't be a typical


The frequently used responses to performance problems found in application code are varied, but can be predicted. Early Java programmers could be very angry with the old IDE. and start the code in the main part of the code review, in the source to find familiar "red flag", such as asynchronous blocks, object quotas and so on.

As programming experience is added, developers may be careful to examine the X flags supported by the JVM. Find ways to optimize your garbage collector.

Of course, for the novice, go directly to Google query, hoping that someone else discovered the JVM's wonderful "Make It Go fast" conversion, avoid rewriting code.


In essence, there is nothing wrong with these methods, but they are risky. The most effective response to a performance problem is to use a parser--now they're built into the Java platform, and there's really no reason to do it!


4. Create a heap dump for offline analysis


Everything is happening at a high speed in the production environment, and you may not have time to spend on your Application analyzer, on the contrary. You can take a snapshot of each event in the Java environment and then look at it. You can do the same in jconsole and even do better in VISUALVM.


Find the Mbeans tab first, open the Com.sun.management node, and then the Hotspotdiagnostic node. Now. Select operations, and note the "dumpheap" button in the right panel.

Suppose you pass a file name to Dumpheap in the first ("string") input box to dump it, and it will take a snapshot of the entire JVM and dump it to that file.


Later, you can use a variety of different business analyzers to analyze your files. or use VISUALVM to analyze the snapshot. (Remember, VISUALVM is available in Java 6.) and are downloaded separately. )


5.JConsole is not a highly unpredictable


Useful tool as a parser. The Jconsole is excellent. But there are better tools. Some analysis plugins come with a parser or a clever user interface, which by default tracks a lot of other data than Jconsole.


What really appeals to jconsole is that the entire program is written in "plain old java." This means that no Java developer can write such a useful tool. In fact. The JDK even includes a demo sample of how to customize Jconsole by creating a plugin.

The VISUALVM built on top of NetBeans further extends the plugin concept.

Suppose Jconsole (or VISUALVM, or any other tool) does not meet your needs, or you cannot track what you want to track, or you cannot track it in your own way. You can write your own tools.

Suppose you think Java code is cumbersome, groovy or jruby or a lot of other JVM languages can help you finish faster.


What you really need is a high-speed and coarse (quick-and-dirty) JVM-connected command-line tool that keeps track of the data you're interested in exactly the way you want it to.


Conclusion

Java performance monitoring is more than jconsole or visualvm--hides a complete set of tools in the JDK. It's just that most developers don't know.

JDK's own monitoring and analysis tool Jconsole