5 JVM command-line flags Each Java programmer must know

This article is the president of Neward & Associates Ted Neward for Developerworks exclusive contributor "You don't know 5 ..." In one of the series, the JVM is the heavy-duty machine Behind the Java features and performance that most developers take for granted. However, few of us can understand how the JVM works-like task allocation and garbage collection, turning threads, opening and closing files, interrupting and/or JIT compiling Java bytecode, and so on.

Not being familiar with the JVM will not only affect application performance, but it can also be difficult to try to fix when a JVM goes wrong.

This article describes some command-line flags that you can use to diagnose and tune your Java Virtual machine performance.

1.DisableExplicitGC

I can't remember how many times the user asked me to provide advice on application performance issues, but as long as you run grep quickly across the code, you'll see the problem shown in Listing 1-The original Java performance Anti-pattern:

Listing 1. System.GC ();

We just released a bunch of objects, so tell the stupid  //garbage collector to collect them already!  System.GC ();

Explicit garbage collection is a very bad idea-it's like locking you and a crazy bulldog in a phone booth. Although the syntax of the call is dependent on implementation, if your JVM is running a generational garbage collector (mostly) System.GC (), forcing VMs to perform a heap of "sweep all", though some are not necessary. Sweeping is a few orders of magnitude more expensive than a regular GC operation, which is just a simple math problem.

You can not take my words to heart-sun engineers provide a JVM flag for this particular manual error, and the-XX:+DISABLEEXPLICITGC flag automatically transforms the System.GC () call into an empty operation, giving you the opportunity to run the code. See for yourself whether System.GC () is harmful or advantageous to the entire JVM execution.

2.HeapDumpOnOutOfMemoryError

Have you ever experienced a situation where the JVM cannot be used, throws OutOfMemoryError, and you can't create a debugger for yourself to capture it or see what's going on? Such occasional and/or uncertain issues as these often make developers mad.

Buyers at their own risk

Not all command-line flags are supported by any VM, except for Sun/oracle VMs. The best way to find out if a flag is supported is to try it and see if it works. If these logos are technically unsupported, then you are solely responsible for using them. I, Sun/oracle and IBM will not be responsible if any one of these signs disappears without a trace of your code, your data, your server, or you. As a precaution, it is recommended to experiment in a virtual (very productive) environment first.

What you want at this point is to capture a snapshot of the heap as the JVM dies--exactly the-xx:+heapdumponoutofmemoryerror command can do.

Running this command notifies the JVM to take a "heap dump snapshot" and saves it in a file for processing, usually using the Jhat utility (as I described in the previous article). You can use the corresponding-xx:heapdumppath flag to specify the actual path to the saved file. (regardless of where the file is stored, it is important to ensure that the file system and/or Java processes must have permission configurations where they can be written.) ）

3.bootclasspath

It is helpful to put a class in a class path on a regular basis, which is slightly different from the classpath that came with the inventory JRE or in a way that extends the JRE classpath. (A new Java Crypto API provider is an example). If you want to extend the JRE, your custom implementation must be able to use the bootstrapper ClassLoader, which can load java.lang.Object and all its related files in Rt.jar.

Although you can illegally open Rt.jar and move your custom implementation or new packets into it, technically you violate the agreement you agreed to when you downloaded the JDK.

Instead, use the JVM's own-xbootclasspath options, as well as skin-xbootclasspath/p and-xbootclasspath/a.

-xbootclasspath allows you to set the full boot classpath (which typically includes a reference to Rt.jar), as well as some of the other JDK (not part of the Rt.jar) jar file. -xbootclasspath/p the value to the existing Bootclasspath and attaches the-xbootclasspath/a to it.

For example, if you modify the Java.lang.Integer in the library and place the modifications under a sub-path of mods, the-xbootclasspath/amods parameter puts the new Integer in front of the default parameter.

4.verbose

For virtual or any type of Java applications,-verbose is a useful first-level diagnostic utility. The flag has three sub-flags: GC, class, and JNI.

Developers are trying to find out if the JVM garbage collector has failed or is causing poor performance, and usually the first thing to do is to perform a GC. Unfortunately, explaining the GC output is cumbersome-enough to write a book. Worse, the output printed on the command line changes in different Java versions or not in different JVMs, making it harder to interpret correctly.

In general, if the garbage collector is a generational collector (most "enterprise" VMs are). A virtual flag will appear to indicate a full sweep of the GC pathway; in the Sun JVM, the flag starts at the start of the GC output line with "[FULLGC ...]" form appears.

To diagnose classloader and/or mismatched class conflicts, class can be a big help. It not only reports when the class is loaded, it also reports where the class is loaded, including the path to the jar (if it comes from a jar).

JNI is seldom used, except when using JNI or local libraries. When turned on, it will report various JNI events, such as when the local library is loaded, when the method bounces back, and again, the output changes in different JVM versions.

5.command-line-x

I've listed my favorite command line options available in the JVM, but there are a few more that you need to find yourself running command-line parameter-X, which lists all non-standard (but mostly safe) parameters provided by the JVM-for example:

-xint, run the JVM in interpreted mode (this is useful for testing whether the JIT compiler is actually working on your code or verifying that there is a bug in the JIT compiler).

-XLOGGC:, and-VERBOSE:GC do the same thing, but record a file without outputting it to the command Line window.

JVM command-line options vary from time to time, so regular viewing is a good idea. Even if you stare at the monitor late at night and have dinner with your wife and kids 5 o'clock in the afternoon, (or destroy your enemies in mass Effect 2, depending on your preferences), they are all different.

Conclusion

In a production environment, command-line flags are not designed for permanent use-in fact, there is no nonstandard command-line tag that is dedicated to production, except that you terminate the flag used to tune the JVM garbage collector. However, it is very useful as a tool to spy on the internal work of virtual machines that are completely opaque in other ways.

The above excerpt from the code farm: http://www.codeceo.com/article/jvm-java-performance.html

5 JVM Command-line flags Each Java programmer must know