Nicolas Fränkel recently published a survey of command-line tools delivered with OpenJDK 11 in the blog post "OpenJDK 11, tools of the trade." In that post, he briefly summarizes the tools jps (a JVM process status tool), jinfo (JVM configuration details), jmap (classes/objects on the heap), jstack (thread analysis), and graphical tool JConsole (monitor Java applications).
All of these tools are handy for Java developers to be aware of to apply as needed and Fränkel's post provides a nice introductory overview for those new to these tools. In recent years, I've moved toward applying the single jcmd tool instead of most of the other command-line tools (though it doesn't replace graphical tool JConsole in any way) as I've discussed in the post "jcmd: One JDK Command-Line Tool to Rule Them All."
There is a brief discussion on the related /r/java subreddit thread regarding jcmd
versus the individual tools. I can see advantages to both approaches (using jcmd
or using multiple individual tools). I contrast my perceptions of their relative advantages and disadvantages here.
jcmd Versus the Rest | |
---|---|
jcmd | Other Tools |
Single interactive tool | Different tools with varying names and options |
More keystrokes/commands required to run functionality due to interactive nature | Fewer keystrokes required for those familiar with commands and options and for cases where command/options being used are supported for the given JVM process |
jcmd <pid> help provides the specific functions supported on that JVM process for jcmd analysis |
Results of running individual tool against JVM process is primary method of detecting that tool's support (or lack thereof) for that process |
Supports only most commonly used subset of functionality of some of the individual tools | Each tool, by its nature, sets the bar for supported functionality |
Newer with fewer online resources | Older with more online resources |
Not considered "experimental" | Several of the individual tools (jps , jinfo , jmap , jstack , and more) are labeled "experimental" and are subject to change/removal (Tools Reference states that "experimental tools are unsupported and should be used with that understanding. They may not be available in future JDK versions. Some of these tools aren’t currently available on Windows platforms.") |
Significant jcmd provided-details are available programmatically via DiagnosticCommandMBean |
Direct corresponding programmatic access is rarely available for individual tools |
Whether to use jcmd or one of the individual tools largely comes down to individual taste and preferences. Those who are already experienced with existing individual tools may prefer the more direct approach of those tools while those not familiar with the individual tools may prefer the interactive ability provided by jcmd
for determining what tools and options are available. I certainly prefer non-experimental tools over "experimental" tools, but many of these tools have been labeled "experimental" for many versions of the JDK and are still with us.
The previously mentioned blog post "jcmd: One JDK Command-Line Tool to Rule Them All" describes how to use jcmd
's interactive features to identify its capabilities supported for various JVM processes. There is a table toward the end of that post that "maps" jcmd
options to some of the corresponding individual tools' commands and options. I reproduce that here for convenience.
Functionality | jcmd | Similar Tool |
---|---|---|
Listing Java Processes | jcmd |
jps -lm |
Heap Dumps | jcmd <pid> GC.heap_dump |
jmap -dump <pid> |
Heap Usage Histogram | jcmd <pid> GC.class_histogram |
jmap -histo <pid> |
Thread Dump | jcmd <pid> Thread.print |
jstack <pid> |
List System Properties | jcmd <pid> VM.system_properties |
jinfo -sysprops <pid> |
List VM Flags | jcmd <pid> VM.flags |
jinfo -flags <pid> |
The jcmd
tool continues to be enhanced. JDK 9 saw several enhancements to jcmd
via JEP 228 ("Add More Diagnostic Commands"). In JDK 11, support for displaying classloader hierarchies was added to jcmd
. Here is a simple screen snapshot of that support for classloaders hierarchies in action.
As Fränkel concludes in his post, "The JDK offers a lot of out-of-box tools to help developers" and "they are a huge asset in a developer’s day-to-day job." This sentiment applies whether one chooses to use the individual JDK-provided tools or chooses to use jcmd
.
No comments:
Post a Comment