In Java application performance optimization, we can tune software performance from a design perspective, code level, JVM parameters, database optimization and so on. Due to the convenient adjustment of JVM parameters and the low cost of optimization, it is favored by performance test engineers. However, JVM optimization requires a deep understanding of the working mechanism and principle of JVM
After reviewing the relevant JVM information, combined with some OF my experience in the work of JVM tuning, I summarized some key parameters of the JVM. Some of these parameters have not been practiced, and I will do performance comparison when I have the opportunity in the future, so that I can have a clearer understanding of the impact of these parameters on performance
To ensure the integrity of this article, some of the parameters listed in the JVM garbage collection mechanism are also listed in this article for your reference
Heap Heap
In G1, when the new generation is unable to store new objects, an increase in the size of MinHeapDeltaBytes is performed. If there are not enough MinHeapDeltaBytes, GC is performed
- Specifies that the JVM heap shrinks if the usage is less than n, and not if Xmx==Xms
- Default size 40/70 PS collector adaptive mode 0/100
- These two values apply to the G1 collector, while the other collectors apply only to the old age
- Cms-gc If you do not specify a threshold for the CMS GC to be triggered by the fixed usage of the older generation, MinHeapFreeSize will use the CMSTriggerRatio parameter to calculate the threshold (92%) for the CMS GC to be triggered.
NewSize young generation
Tip:
- Each time the size of the new generation effective memory is adjusted, several components of the new generation will also be repositioned, including the starting and ending positions of the three memory blocks Eden, From and To
- If the available memory of the new generation can be adjusted after it is reclaimed, it will calculate the change value of the available memory of the new generation according to the available memory of the old generation and NewRatio and other conditions to expand or shrink the capacity. It is not recommended to set these parameters for the Cenozoic generation under G1-GC, and try to adapt to it, which is also officially recommended
SurvivorRatio Eden/ Survivor ratio. Default is 8 and minimum is 1. Under CMS-GC, if MaxTenuringThreshold is set to 0, it means that GC is directly promoted to the old generation each time. In this case, if SurvivorRatio is not set, the default SurvivorRatio is set to 1024. -xx :SurvivorRatio=___
Perm Size (JDK1.7 or earlier)
Tip:
- If PermSize is larger than MaxPermSize, MaxPermSize is set to PermSize
- PermSize is aligned at 64K, while MaxPermSize is aligned at 2M
- Class object is by default in the Heap, if we set up – XX: XX + UnlockDiagnosticVMOptions – : + JavaObjectsInPerm these two parameters, that will be allocated in a Perm
Metaspace (JDK1.7 or later, instead of Perm Size)
MetaspaceSize Specifies the initial size of the metadata area. Use the following method: -xx :MetaspaceSize=___
CompressedClassSpaceSize JVM startup will be specially assigned a block of memory, normal circumstances would like Perm next to Heap allocation, dedicated to the memory storage class klass part of metadata (UseCompressedClassPointers did not open, The CompressedClassSpaceSize parameter has no effect and needs to be used in conjunction). Method of use: – XX: CompressedClassSpaceSize = ___
InitialBootClassLoaderMetaspaceSize BootClassLoader specified storage not klass the main part of the data. Method of use: – XX: InitialBootClassLoaderMetaspaceSize = ___
Thread Size
There are roughly two types of threads in the JVM, Java threads and non-Java threads, such as GC threads, which are non-Java threads. There is also a VMThread in the JVM, which is also non-Java thread
Xss JAVA ThreadStackSize Xss is equivalent to ThreadStackSize (-xss100k is equivalent to -xx :ThreadStackSize=100) the value of ThreadStackSize is 1M by default on 64-bit OS
VMThreadStackSize Size of the JVM thread stack The default value is 4M in a 64-bit OS and 2M in a 32-bit OS
Garbage collector
G1 collector
Use the G1 garbage collector: -xx :+UseG1GC
-xx :MaxGCPauseMillis Target (GC) maximum pause time, after which G1 will automatically adjust related parameters to try to achieve this target. Usage: -xx :MaxGCPauseMillis=___ (default: 200ms). Xmn will be invalid.
-xx :ParallelGCThreads The number of worker threads in the GC during parallel collection. The default is 2, and 8+((CPU-8)*5)/8. -xx :ParallelGCThreads=___
– XX: InitiatingHeapOccupancyPercent * * to specify when and how the whole heap usage trigger concurrent marking cycles (45) by default. Method of use: – XX: InitiatingHeapOccupancyPercent = ___ * *
CMS collector
Enable the CMS collector -xx :+UseConcMarkSweepGC
-xx :ConcGCThreads Number of concurrent threads. By default ConcGCThreads = (ParallelGCThreads + 3)/4. Usage: -xx :ConcGCThreads=___
– XX: GC CMSInitiatingOccupancyFraction trigger the old s percentage. The slow growth in the old age can be adjusted to reduce the trigger frequency of CMS; Old age growth can be turned down to avoid frequent triggering of old age serial collector. If appear when the default 68 (CMS recovery of memory, then the CMS recycling failure, forced to trigger the old s serial collector), if you want to use must add * * – XX: + UseCMSInitiatingOccupancyOnly * *. Method of use: – XX: CMSInitiatingOccupancyFraction = ___
– XX: CMSFullGCsBEforeCompaction set how many CMS recovery after a memory compression. Method of use: – XX: CMSFullGCsBeforeCompaction = ___
PS collector
-xx :GCTimeRatio Throughput. If the value is n, garbage collection takes no more than 1/(1+n) time (99 by default). Usage: -xx :GCTimeRatio=___
Codecache
UseCodeCacheFlushing Used to clean up part of the code cache to avoid code buffer overflow, use method:-XX:+UseCodeCacheFlushing
To learn more about Codecache, read codecache for **JVM **.
For other JVM GCS, please read the full explanation of garbage collection mechanisms for the **JVM. **