5 things you don't know about JVM command line flags: Tuning JVM performance and Java runtime

The JVM is the heavy load machine behind Java features and performance, which most developers take for granted. However, few of us understand how the JVM works-like task assignments 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 repair when the JVM goes wrong.

The 5 things series in this issue will introduce 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 advise on application performance issues, but as long as you run grep quickly across code, you'll find 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 invoked is dependent on implementation, if your JVM is running a generational garbage collector (mostly) System.GC (); Forcing the VM to perform a heap of "sweeping", although some are not necessary. Sweeping is a few orders of magnitude more expensive than a regular GC operation, which is a simple mathematical problem.

You may not take my word for it.-sun's engineers provide a JVM flag for this particular human error; The-XX:+DISABLEEXPLICITGC flag automatically converts System.GC () calls into an empty operation, giving you the opportunity to run your code, and see for yourself Whether System.GC () is harmful or beneficial for the entire JVM execution.

2. Heapdumponoutofmemoryerror

Have you ever experienced a situation where the JVM cannot be used, constantly throwing outofmemoryerror, and you can't create a debugger for yourself to catch it or see what's wrong? Occasional and/or indeterminate problems such as these often cause developers to go mad.

Buyers are conceited

Not every VM supports all command-line flags, except for Sun/oracle VMs. The best way to find out if a flag is supported is to try it out and see if it works. If these logos are not technically supported, then you have to take full responsibility for using them. If any of these flags make your code, your data, your server, or your everything disappear without a trace, I, sun/oracle, and IBM® will be irresponsible. In case of precaution, it is recommended to experiment in a virtual (very productive) environment first.

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

Run this command to notify the JVM to take a "heap dump snapshot" and save it in a file for processing, usually using the Jhat utility (which I introduced in the previous article). You can use the appropriate-xx:heapdumppath flag to specify the actual path to the saved file. (regardless of where the file is saved, make sure that the file system and/or Java process must have a permission configuration in which to write.) ）

3. Bootclasspath

It is helpful to periodically put a class into the classpath, which is slightly different from the classpath that came with the inventory JRE or the JRE class path that was extended in some way. (The 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 related files in Rt.jar.

Although you can illegally open Rt.jar and move your custom implementation or new packets into it, technically you are violating 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) and some other (not Rt.jar) jar files that are included with other JDK. -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 subpath mods, the-xbootclasspath/a mods parameter places the new Integer before the default parameter.

4. Verbose

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

The developer tries to find out whether the JVM garbage collector has failed or caused poor performance, and usually the first thing to do is to execute the GC. Unfortunately, interpreting 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.

Generally, 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 appears as a "[Full GC ...]" at the beginning of the GC output line.

Class can be a big help when you want to diagnose ClassLoader and/or mismatched class conflicts. It not only reports when the class is loaded, but also reports where the class is loaded, including the path to the jar, if it comes from a jar.

JNI is rarely used, except when using JNI or local libraries. When opened, it reports various JNI events, such as when the local library is loaded, when the method bounces back, and again, in different JVM versions, the output changes.

5. Command-line-x

I've listed the command-line options that are available in the JVM, but there are a few more that need you to find out for yourself, Run command line parameter-X, and list all the non-standard (but mostly secure) parameters provided by the JVM-for example:

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

-XLOGGC: Do the same thing as-VERBOSE:GC, but log a file without outputting to the command line window.

JVM command-line options often change, so it's a good idea to view them regularly. 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 preference), they are all different.

Conclusion

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