Practical Methods for Retrieving Running JVM Parameters: A Comprehensive Analysis from jps to jcmd

Introduction and Problem Context

In the operation and performance tuning of Java applications, understanding the actual parameter configuration of a running JVM is crucial. Especially in production environments, developers and system administrators often need to verify key parameters specified at JVM startup, such as heap memory size (-Xmx and -Xms) and garbage collection policies, to ensure applications run as configured. However, directly accessing these parameters can be challenging, particularly on production servers where minimal disruption is required.

Traditional monitoring tools like jvisualvm, while powerful, typically require starting the jstatd service and modifying security settings for remote connections, which may introduce unnecessary risks and interruptions in production environments. Therefore, finding a simple, non-intrusive command-line tool becomes an urgent need. This article systematically introduces several practical methods, focusing on the jps command and its alternative, jcmd.

Core Method: Using the jps Command

jps (Java Virtual Machine Process Status Tool) is a lightweight utility included in the JDK, designed to list the PIDs (Process Identifiers) and related information of all Java processes in the current system. By adding the -lvm option, jps can display the complete startup parameters of each JVM process, including all user-specified JVM options.

The basic command format is as follows:

jps -lvm

After executing this command, the output typically includes multiple lines, each corresponding to a Java process. For example:

4050 com.intellij.idea.Main -Xms128m -Xmx512m -XX:MaxPermSize=250m -ea -Xbootclasspath/a:../lib/boot.jar -Djb.restart.code=88
4667 sun.tools.jps.Jps -lvm -Dapplication.home=/opt/java/jdk1.6.0_22 -Xms8m

From the above output, we can clearly see the startup parameters of the process with PID 4050 (IntelliJ IDEA): -Xms128m (initial heap size), -Xmx512m (maximum heap size), etc. This method requires no modification of JVM configuration or starting additional services, operating entirely via the command line, making it highly suitable for production environments.

It is important to note that the output of the jps command may vary slightly depending on the JDK version and operating system, but its core functionality remains consistent across all major platforms. For automated monitoring scenarios, scripts can parse jps output to extract specific parameters for logging or alerting.

Modern Alternative: The jcmd Tool

With the evolution of the JDK, Oracle recommends using jcmd (Java Command) as a new-generation diagnostic tool, integrating functionalities of older tools like jstack, jinfo, and jmap, while offering lower performance overhead. Although jps excels in simplicity, jcmd provides richer information and better scalability in certain scenarios.

The basic steps to retrieve JVM parameters using jcmd are as follows:

First, list all Java processes and their PIDs using jcmd -l:

jcmd -l

11441 Test
6294 Test
29197 jdk.jcmd/sun.tools.jcmd.JCmd -l

Then, use the VM.flags subcommand for a specific PID to obtain JVM flags (including -Xmx and -Xms):

jcmd 11441 VM.flags

Example output:

11441:
-XX:CICompilerCount=3 -XX:ConcGCThreads=1 -XX:G1ConcRefinementThreads=4 -XX:G1HeapRegionSize=1048576 -XX:InitialHeapSize=67108864 -XX:MaxHeapSize=1073741824 -XX:MaxNewSize=643825664 -XX:MinHeapDeltaBytes=1048576 -XX:NonNMethodCodeHeapSize=5830092 -XX:NonProfiledCodeHeapSize=122914074 -XX:ProfiledCodeHeapSize=122914074 -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:-UseAOT -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC

Here, InitialHeapSize corresponds to -Xms, and MaxHeapSize corresponds to -Xmx. jcmd also supports the VM.system_properties subcommand to retrieve system properties, but this is not the focus of this article.

Compared to jps, jcmd offers more structured output, facilitating programmatic processing, but its command syntax is slightly more complex and requires JDK 7 or later. In production environments with newer JDK deployments, jcmd is a worthwhile upgrade consideration.

Other Methods and Considerations

Beyond jps and jcmd, there are auxiliary methods for obtaining JVM parameters, though they are typically suited for specific scenarios or as supplements.

A common approach is using the java command with the -XX:+PrintFlagsFinal option, combined with grep (Linux/Mac) or findstr (Windows) to filter key parameters. For example:

java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize|PermSize|ThreadStackSize'

However, this method is primarily for viewing default or final flag values of the JVM, not the actual parameters of a running process, thus its applicability is limited.

In practical applications, selecting the appropriate method should consider the following factors:

• Environmental Constraints: Production servers often require minimal disruption, so command-line tools that do not require JVM configuration changes are preferred.
• JDK Version: Older JDK versions may not support jcmd, making jps a reliable choice.
• Output Parsing: Automated scripts need to handle outputs from different tools to extract parameters; jps output is more direct, while jcmd output is more structured.
• Security: Avoid enabling unnecessary remote monitoring services in production environments to reduce security risks.

Additionally, for containerized Java applications, commands from Docker or Kubernetes must be integrated to obtain process information, though the basic principles are similar to the methods described above.

Conclusion and Best Practices

Retrieving running JVM parameters is a fundamental yet critical task in Java operations. This article systematically introduces two main tools, jps and jcmd, both capable of providing accurate parameter information without service interruption.

Based on the stability requirements of production environments, the following best practices are recommended:

1. Prefer the jps Command: For most scenarios, using jps -lvm is the simplest and most compatible method. It supports all major JDK versions, outputs intuitively, and is easy to integrate into monitoring scripts.
2. Consider jcmd as a Supplement: If the environment uses JDK 7 or later and requires more detailed diagnostic information, jcmd can be gradually introduced. Its VM.flags subcommand provides structured parameter lists.
3. Avoid High-Risk Operations: On production servers, avoid tools that require modifying security settings or starting additional services, such as remote connections with jvisualvm.
4. Automate Monitoring: By regularly executing jps or jcmd commands and parsing the output into logging systems, continuous monitoring and anomaly detection of JVM parameters can be achieved.

By appropriately selecting tools and methods, developers can efficiently and securely manage the runtime configuration of Java applications, ensuring system performance and stability.