JVM parameter settings using tips (1)

Detailed JVM parameter settings
Jvmheap Area Distribution:
Javaheap are divided into 3 districts, Young,old and permanent. Young area to save most just instantiated objects, when the area is filled, triggering local GC, local GC will empty young area, still referenced objects will be moved to the old area. When the old area is stuffed again, it triggers the FULLGC and reclaims the last space that can be reclaimed. The full name of the permanent area is permanentgenerationspace, a permanent area for storing meta information such as class and method, such as class being put into the zone when it is load. It is also responsible for saving reflection objects because essentially the reflection object generates some metadata that cannot be reclaimed so that the next reflection is reused.
Generally, either local GC (garbagecollection) or FULLGC does not clean the permgenspace. But if your application will load a lot of class, it is likely that permgenspace overflow error
The JVM has 2 GC threads:
The first thread is responsible for reclaiming the young area of Jvmheap.
The second thread, when heap is insufficient, traverses the heap and upgrades young to the older area. The size of the older area equals-xmx minus-xmn, and the-XMS value cannot be set too large because the second thread is forced to run, which degrades the performance of the JVM.
The reasons that can cause frequent GC occurrences are:
1, the program calls the System.GC () or RUNTIME.GC ().
2. Some middleware software calls its own GC method, at which point you need to set parameters to prohibit these GC.
3, the Java heap is too small, the general default heap values are very small.
4, frequent instantiation of objects, release objects. At this point, try to save and reuse the objects, such as using StringBuffer () and string ().
If you find that after each GC, the remaining space of the heap will be 50% of the total space, which means that your heap is in a healthy state. Many server-side Java programs have a 65% of the remaining space after each GC.
It is recommended that the server-side JVM preferably set-XMS and-xmx to the same value. In order to optimize GC, it is best to have the-xmn value equal to about 1/3 of-XMX. A GUI program is best to run the GC once every 10-20 seconds, each time within half a second. Increasing the size of the heap may reduce the frequency of the GC, but it also increases the time of each GC run. And when the GC is running, all the user threads will be paused, i.e., during the GC, the Java application will not do any work, which can affect the user experience very much in GUI interface.
Stack's setting
1, each thread has his own stack.
2,-XSS specifies the stack size of each thread
3, the size of the stack limit the number of threads. Stack too large or too small can cause memory leaks
The hardware environment also affects the efficiency of the GC, such as the type of machine, memory, swap space, and number of CPUs. For example, if your program needs to create many transient objects frequently (cannot be serialized), it will cause the JVM to frequent GC. In this case you can increase the memory of the machine to reduce the use of swap space.
GC has 4 minutes altogether:
1. The first is a single-threaded GC and is also the default GC. , the GC applies to a single CPU machine.
2, the second is THROUGHPUTGC, is a multi-threaded GC, suitable for multiple CPUs, using a large number of threads of the program. The second GC is similar to the first GC, except that the GC is multi-threaded in the collection of young, but in the old and the first, it still takes a single thread. The-XX:+USEPARALLELGC parameter starts the THROUGHPUTGC.
3, the third is CONCURRENTLOWPAUSEGC, similar to the first, applicable to multiple CPUs, and to reduce the time due to the GC caused the program stagnation. This GC can run the application while the old zone is reclaimed. The-XX:+USECONCMARKSWEEPGC parameter starts the GC.
4. The fourth type is INCREMENTALLOWPAUSEGC, which is suitable for shortening the time when the procedure is stagnant due to GC. This GC can reclaim some old area objects while recovering from the young area. The-XINCGC parameter starts the GC.