Detailed description of startup parameters of Java virtual machines

Detailed description of startup parameters of Java virtual machines
Java startup parameters are divided into three types: standard parameters (-), which must be implemented by all JVM implementations and backward compatible; and non-standard parameters (-X ), by default, jvm implements the functions of these parameters, but does not ensure that all jvm implementations are satisfied, and backward compatibility is not guaranteed. The third is non-Stable parameter (-XX ), the implementation of these parameters varies by jvm, and may be canceled at any time in the future, so you need to use them with caution. 1. What is useful in standard parameters: verbose-verbose: class outputs information about the jvm loaded class. This can be diagnosed when the jvm report says no class or class conflict is found. -Verbose: gc output the related information of each GC. -Verbose: jni outputs native method call information, which is generally used to diagnose jni call errors. 2. Non-standard parameters, also known as extended parameters, are generally used most-Xms512m setting JVM to enable the memory to be 512 MB. This value can be set to the same as-Xmx to avoid JVM re-allocating memory after each garbage collection. -Xmx512m: Set the JVM maximum available memory to 512 MB. -Xmn200m: Set the young generation to 200 M. Total heap size = size of the young generation + size of the old generation + size of the persistent generation. The permanent generation usually has a fixed size of 64 m. Therefore, increasing the size of the young generation will reduce the size of the old generation. This value has a great impact on the system performance. Sun officially recommends 3/8 of the total heap configuration. -Xss128k: Set the stack size of each thread. After JDK 256, the size of each thread stack is 1 MB, and the size of each previous thread stack is K. The memory size required for more application threads is adjusted. Reduce this value to generate more threads in the same physical memory. However, the operating system still has a limit on the number of threads in a process. It cannot be generated infinitely. The experience is between 3000 and ~ About 5000. -The Xloggc: file function is similar to the-verbose: gc function. It only records the status of each GC event to a file. The file location is better to be local to avoid potential network problems. If the command and the verbose command appear in the command line at the same time, the-Xloggc prevails. -Xprof tracks running programs and outputs trace data in standard output. It is suitable for debugging in the development environment. The parameter list prefixed with-XX may not be robust in jvm, and SUN is not recommended. It may be canceled without notice in the future; however, many of these parameters are useful to us, such as-XX: PermSize,-XX: MaxPermSize, and so on. First, we will introduce the behavior parameters: description of the parameter and its default value-XX:-DisableExplicitGC prohibits the call of System. gc (); but the jvm gc is still effective-XX: + MaxFDLimit maximum number of file descriptors limit-XX: + ScavengeBeforeFullGC New Generation GC takes precedence over Full GC execution-XX: + UseGCOverheadLimit limit the time ratio of jvm consumption on GC before throwing out OOM-XX:-UseConcMarkSweepGC GC-XX for the old generation using the concurrent tag switching algorithm:-UseParallelGC enabling parallel GC-XX: -UseParallelOldGC enables parallelism for 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 in the above table represent three methods of GC execution in jvm, namely serial, parallel, and concurrent; SerialGC) it is the default GC method of jvm and is generally applicable to small applications and single processors. The algorithm is relatively simple and the GC efficiency is high, but it may bring a pause to the application. Parallel (ParallelGC) it means that the GC operation has no impact on the application program running, and the GC and app threads are concurrently executed, so that the operation of the app is not affected to the maximum extent; ConcMarkSweepGC) it refers to the concurrent execution of GC by multiple threads. It is generally applicable to multi-processor systems and can improve GC efficiency. However, the algorithm is complicated and the system consumes a lot. The list of performance tuning parameters: description of the parameter and its default value-XX: LargePageSizeInBytes = 4 m set the size of a large page for the Java heap-XX: MaxHeapFreeRatio = 70 percentage of free space in the java heap after GC-XX: maxNewSize = size the maximum number of pairs that can occupy memory-XX: MaxPermSize = maximum number of memory occupied by 64 m old generation objects-XX: minHeapFreeRatio = 40 minimum percentage of free space in the java heap after GC-XX: NewRatio = 2 ratio of new generation memory capacity to old generation memory capacity-XX: newSize = 2.125 m default value of memory used when new generation objects are generated-XX: ReservedCodeCacheSize = 32 m memory used by reserved code-XX: ThreadStackSize = 512 set the thread stack size, if the value is 0, the system default value-XX: + UseLargePages uses the large page memory. We basically use these attributes in the daily performance tuning. The debugging parameter list: description of parameters and their default values-XX:-CITime printing time consumed during JIT compilation-XX: ErrorFile =. /hs_err_pid <pid>. log to save the error log or data to the file-XX:-ExtendedDTraceProbes enable the solaris-specific dtrace probe-XX: HeapDumpPath =. /java_pid <pid>. hprof specifies the path or file name when the heap information is exported-XX:-HeapDumpOnOutOfMemoryError-XX: OnError = "<cmd args> when the first OOM error occurs; <cmd args> "run the custom command-XX: OnOutOfMemoryError =" <cmd args> after a fatal ERROR occurs; <cmd args> "when an OOM occurs for the first time, run the custom command-XX:-PrintClassHistogram to print the column information of the class instance after Ctrl-Break. The function is the same as that of jmap-histo-XX: -PrintConcurrentLocks prints the information about the concurrency lock after encountering Ctrl-Break, which is the same as that of jstack-l.-XX:-PrintCommandLineFlags: -PrintCompilation: prints related information when a method is compiled-XX:-PrintGC prints related information each time GC-XX:-PrintGC Details prints Details each GC-XX: -PrintGCTimeStamps: prints the timestamp of each GC-XX:-TraceClassLoading trace class loading information-XX:-TraceClassLoadingPreorder traces the loading information of all referenced classes-XX: -TraceClassResolution trace constant pool-XX:-TraceClassUnloading trace class unload information-XX:-TraceLoaderConstraints trace Class Loader constraints related information