Java Startup parameter collation

http://blog.csdn.net/turkeyzhou/article/details/7619472 Java startup parameters are divided into three categories;

The first is the standard parameter (-), all JVM implementations must implement the functions of these parameters, and backward compatibility;
The second is the non-standard parameter (- x), the default JVM implements the functions of these parameters, but does not guarantee that all JVM implementations are satisfied, and does not guarantee backward compatibility;
The third is the non-stable parameter (-XX), such parameters of each JVM implementation will be different, in the future may be canceled at any time, need to use cautiously;

A Standard parameters

-client
The provisioning JVM uses the client mode, which is characterized by faster startup, but inefficient runtime performance and memory management, typically used for client application or PC application development and debugging.

-server
Set the JVM to make the server mode, characterized by a slow start-up speed, but run-time performance and memory management is very efficient, suitable for production environments. This mode is enabled by default in a JDK environment with 64-bit capability, and the-client parameter is ignored.

-agentlib:libname[=options]
For loading local LIB packets;
Where Libname is the local agent library file name, the default search path is the path in the environment variable path, options is passed to the local library when the parameter is started, and multiple parameters are separated by commas. On the Windows platform, the JVM searches for files with local libraries named Libname.dll, and on Linux the JVM searches for files with local libraries named Libname.so, and the search path environment variables differ on different systems, such as the default search on Solaries ld_ Library_path.
For example:-agentlib:hprof
Used to obtain the operation of the JVM, including CPU, memory, thread and other running data, and can be output to the specified file; The search path in Windows is Jre_home/bin/hprof.dll.

-agentpath:pathname[=options]
Loading local libraries by full path, no longer searching paths in path, other functions are the same as agentlib, and more information will be continued in the subsequent JVMTI section.

-classpath Classpath
-CP Classpath
Tell the JVM to search directory names, jar document names, zip document names, separated by semicolons; the JVM will no longer use the class search path in classpath after using-classpath, and if neither-classpath nor Classpath are set, the JVM uses the current path (.) As a class search path.
The way and order in which the JVM searches for classes is: Bootstrap,extension,user.
The path in bootstrap is the jar or zip file that the JVM comes with, the JVM searches for these package files first, and the System.getproperty ("Sun.boot.class.path") to obtain the search path.
Extension is a jar file located in the Jre_home/lib/ext directory, and the JVM searches for the jar file under the directory after bootstrap, using System.getproperty ("Java.ext.dirs") The search path can be obtained.
The user search order is the current path., CLASSPATH,-CLASSPATH,JVM the last search for these directories, with System.getproperty ("Java.class.path") to obtain the search path.

-dproperty=value
Sets the system attribute name/value pair, and the application running on top of this JVM can get the value of the System.getproperty ("property").
If there are spaces in value, you need to enclose the value in double quotation marks, such as-dname= "space string".
This parameter is typically used to set system-level global variable values, such as a configuration file path, so that the property is accessible anywhere in the program.

-enableassertions[:<package name> "..." |:<classname>] 
-ea[:< Package name> "..." | : <class name>]  
  The above parameters are used to set whether the JVM starts the assertion mechanism (supported from JDK 1.4), and the JVM shuts down the assertion mechanism by default.
  Use-ea to open the assertion mechanism, run all the assertions in packages and classes without <packagename> and classname, and if you want to run only assertions in certain packages or classes, add the package or class name to-ea. For example, to start an assertion in package Com.wombat.fruitbat, the command Java-ea:com.wombat.fruitbat...<main class> is available.

-disableassertions[:<package name> "..." |: <class;]
-da[:<package name> "..." |: <class name>]
Used to set the JVM Shutdown assertion processing, packagename and classname are used in the same way as-ea, and the JVM is turned off by default.
This parameter is typically used in scenarios where some classes in the same package do not require assertions, such as Com.wombat.fruitbat needs assertions, but com.wombat.fruitbat.Brickbat the class does not need to, you can run the following:
Java-ea:com.wombat.fruitbat...-da:com.wombat.fruitbat.brickbat <MainClass>.

-enablesystemassertions
-esa
Activates the assertion of the system class.

-disablesystemassertions
-DSA
Shuts down the assertion of the system class.

-jar
Specifies that an application be executed as a jar package.
To execute an application like this, you must have the manifest file in the JAR package declare the initial loaded Main-class, and of course that Main-class must have the public static void main (string[] args) method.

-javaagent:jarpath[=options]
Specifies that the JVM starts fashion into the Java language device proxy.
The Mainfest file in the Jarpath file must have the Agent-class attribute. The proxy class must also implement a common static public statics void Premain (String Agentargs, Instrumentation Inst) method (similar to the Main method). When the JVM initializes, the Premain method is called in the order in which the proxy class is described, as described in the Java.lang.instrument software package.

-verbose
-verbose:class
Outputs information about the JVM loading classes that can be diagnosed when the JVM reports that a class or class violation is not found.
-VERBOSE:GC
Outputs the correlation of each GC.
-verbose:jni
The output native method invocation is typically used to diagnose JNI invocation error messages.

-version
Output Java version information, such as JDK version, vendor, model.
-version:release
Specifies the JDK version information required for class or Jar runtime, and if the specified version is not found, executes in the default JDK version of the system that can be found; In general, for jar files, you can specify the required version information in the manifest file instead of the command line.
You can specify a single version in release, or you can specify a list, separated by spaces, and support complex combinations, such as:
-version: "1.5.0_04 1.5*&1.5.1_02+"
Specifying a class or jar requires a JDK version of 1.5.0_04 or any version higher than 1.5.1_02 in the 1.5 series.

-showversion
After outputting the Java version information (same as-version), continue to output the Java standard parameter list and its description.

-?
-help
Outputs a list of Java standard parameters and their descriptions.

- x
Outputs a non-standard parameter list and its description.

These parameters we often use multiple combinations in many cases, for example, when we use jprofiler for tracking monitoring, we need to add the following configuration to the monitored Java Boot parameters:
-agentlib:jprofilerti=port=8849-xbootclasspath/a:/usr/local/jprofiler5/bin/agent.jar
With two-agentlib and-x parameters, the details of the Bootclasspath parameter are described in detail in non-standard parameters.

Two Non-standard parameters

-xint
Set the JVM to run in interpreting mode, and all bytecode will be executed directly without compiling the cost code.

-xbatch
Turn off background Code compilation, force the foreground compile, compile after the completion of code execution;
By default, the JVM is compiled in the background, and if it is not compiled, the foreground runs in interpreted mode when the code is running.

-xbootclasspath:bootclasspath
Allows the JVM to load Bootclass from the specified path (which can be a semicolon-delimited directory, jar, or zip) to replace the JDK's Rt.jar;
-xbootclasspath/a:path
Appends all files of the specified path to the default bootstrap path;
-xbootclasspath/p:path
Having the JVM take precedence over the bootstrap default path to load all files of the specified path;

-xcheck:jni
Additional check of the JNI function, at which time the JVM officer passed to the validity of the JNI function parameter, when the illegal data is encountered in the local code, the JMV will terminate with a fatal error, and the performance will be degraded after using this parameter, please use caution.

-xfuture
Let the JVM perform a strict format check on the class file (the default JVM does not perform a strict format check) to conform to the class file format specification, which is recommended for developers.

-XNOCLASSGC
Turn off GC functionality for class, because it prevents memory recycling, so it may cause outofmemoryerror errors, use caution;

-XINCGC
Turn on incremental GC (which is off by default), which helps reduce application pauses during long GC, but because it is possible to execute concurrently with the application, it reduces the CPU's ability to handle the application.

-xloggc:file
Similar to the-VERBOSE:GC feature, just log the correlation of each GC event to a file, preferably locally, to avoid potential problems with the network.
If the verbose command appears on the command line at the same time, the-XLOGGC will prevail.

-xmsn
Specifies the initial size of the JVM heap, which defaults to 1/64 of physical memory, with a minimum of 1M, and can specify units, such as K, M, by default, if not specified.

-XMXN
Specifies the maximum value of the JVM heap, which defaults to 1/4 or 1G of physical memory, and the minimum is 2M; units are consistent with-XMS.

-xprof
Keep track of running programs and trace data in standard output, suitable for development environment debugging.

-xrs
Reduce the JVM's use of operating system signals (signals), which is valid from 1.3.1;
Starting with jdk1.3.0, the JVM allows the program to execute some code (such as closing the database's connection pool) before shutting down, even if the JVM is abruptly terminated;
The JVM shutdown tool satisfies the above functions by monitoring the events related to the console, or, more specifically, registering the control handler of the console before closing the tool, and then Ctrl_c_event, ctrl_close_event,ctrl_logoff_ event, and ctrl_shutdown_event these types of events directly return true.
However, if the JVM is running in the background as a service (such as a servlet engine), he can receive the Ctrl_logoff_event event, but it does not need to initialize the shutdown program at this time, in order to avoid the recurrence of similar conflicts, The-XRS parameter is provided starting from jdk1.3.1, and when this parameter is set, the JVM will not receive control handler of the console, that is, he does not monitor and process ctrl_c_event, ctrl_close_event, Ctrl_logoff_event, Orctrl_shutdown_event event.

-XSSN
Sets the size of a single line stacks, which is typically 512k by default.

Above these parameters, such as-xmsn,-XMXN ... are important parameters in our performance optimization;
-xprof,-xloggc:file, etc. are in the absence of professional tracking tools in the wrong position;
The configuration of the Jprofiler mentioned in the previous section is used in the-xbootclasspath/a:path

Three Non-stable parameters

We mentioned earlier that the list of parameters prefixed with-XX may not be robust in the JVM, Sun is not recommended, and may be canceled without notice, but because many of these parameters are useful to us, such as the-xx:permsize that we often see, Xx:maxpermsize and so on;

Below we will describe the list of configurable parameters for -xx: in the Java HotSpot VM;
These parameters can be loosely aggregated into three categories:
Behavioral Parameters (behavioral Options): Used to change some of the underlying behavior of the JVM;
Performance tuning (performance Tuning): Optimized for JVM performance;
Debug Parameters (Debugging Options): Typically used to open trace, print, output, and other JVM parameters, to display the JVM more detailed information;

Since there are very few descriptions of the parameters in the Sun's official documentation (mostly only a single word), and most of the OS-level stuff is difficult to describe, here are some of the more configurable items that we might use in our development, and if you need to see all the parameter lists, click the Hotspot VM Specific Options. View original text;

First, let's introduce the behavior parameters :

Parameters and their default values	Describe
-xx:-disableexplicitgc	Disable calling System.GC (), but the JVM's GC is still valid
-xx:+maxfdlimit	Limit the number of file descriptors to maximize
-xx:+scavengebeforefullgc	The new generation GC takes precedence over full GC execution
-xx:+usegcoverheadlimit	Limit the amount of time the JVM spends on GC before throwing an Oom
-xx:-useconcmarksweepgc	Using concurrent tag switching algorithm for GC in Laosheng generation
-xx:-useparallelgc	Enable parallel GC
-xx:-useparalleloldgc	Enable parallelism on the full GC, which is automatically enabled when-XX:-USEPARALLELGC is enabled
-xx:-useserialgc	Enable serial GC
-xx:+usethreadpriorities	Enable local thread Priority

The three parameters of the blackbody in the table above represent three ways that the GC executes in the JVM, namely serial, parallel, concurrency ;
Serial (SERIALGC) is the default GC mode of the JVM, which is generally suitable for small applications and single processors, the algorithm is simple and the GC is more efficient, but it may bring pause to the application.
Parallel (PARALLELGC) refers to the GC runtime, no impact on the application run, GC and app both threads are executing concurrently, so as to minimize the impact of the app operation;
Concurrency (CONCMARKSWEEPGC) is a multi-thread concurrent execution GC, generally applicable to multiprocessor systems, can improve the efficiency of GC, but the algorithm is complex, the system consumes large;

Performance Tuning parameter list:

Parameters and their default values	Describe
-xx:largepagesizeinbytes=4m	Set a large page size for the Java heap
-xx:maxheapfreeratio=70	Maximum percentage of idle amount in the Java heap after GC
-xx:maxnewsize=size	The maximum amount of memory that a new build object can occupy
-xx:maxpermsize=64m	The maximum amount of memory that a Laosheng object can occupy
-xx:minheapfreeratio=40	Minimum percentage of idle amount in the Java heap after GC
-xx:newratio=2	The ratio of the new generation memory capacity to the Laosheng memory capacity
-xx:newsize=2.125m	Default value of memory used by Cenozoic object generation
-xx:reservedcodecachesize=32m	Reserve the amount of memory your code consumes
-xx:threadstacksize=512	Set the thread stack size to use the system default value if 0
-xx:+uselargepages	Use large page memory

In the daily performance tuning we will basically use the above properties of the blackbody;

Debug Parameter list:

Parameters and their default values	Describe
-xx:-citime	When the print consumption is JIT-compiled
-xx:errorfile=./hs_err_pid<pid>.log	Save the error log or data to a file
-xx:-extendeddtraceprobes	To open a Solaris-specific dtrace probe
-xx:heapdumppath=./java_pid<pid>.hprof	Specifies the path or file name when the heap information is exported
-xx:-heapdumponoutofmemoryerror	Export the information in this heap when an oom is first encountered
-xx:onerror= "<cmd args>;<cmd args>"	Run the custom command after a fatal error occurs
-xx:onoutofmemoryerror= "<cmd args>;<cmd args>"	Execute a custom command when an oom is first encountered
-xx:-P Rintclasshistogram	Print the column information of the class instance after encountering Ctrl-break, same as the Jmap-histo function
-xx:-P Rintconcurrentlocks	Print concurrency lock information after encountering Ctrl-break, same as jstack-l function
-xx:-P Rintcommandlineflags	Print markup that appears on the command line
-xx:-P rintcompilation	When a method is compiled, the relevant information is printed
-xx:-P RINTGC	Print related information each time the GC
-xx:-P RINTGC Details	Print Details per GC
-xx:-P Rintgctimestamps	Print timestamp for each GC
-xx:-traceclassloading	Tracking load information for a class
-xx:-traceclassloadingpreorder	Trace load information for all classes referenced to
-xx:-traceclassresolution	TRACE Constant Pool
-xx:-traceclassunloading	Tracking uninstall information for a class
-xx:-traceloaderconstraints	Tracking information about class loader constraints

When there is a problem with the system, you cannot use an external tracking tool (such as Jprofiler ...). ), the above parameters will play a significant role, such as dump heap information, print concurrency lock ...

Java Startup parameter collation