A better jvm parameter configuration and jvm introduction, better jvm parameter Introduction
Jvm parameter configuration for a good web server:
-Server // server mode-Xmx2g // maximum heap memory that can be allocated by JVM, allocated as needed-Xms2g // heap memory initially allocated by JVM, generally, the configuration is the same as that of Xmx to avoid JVM re-allocating memory after each gc. -Xmn256m // The memory size of the young generation. The entire JVM memory is = Young Generation + Old Generation + persistent generation-XX: permSize = 128 m // persistent generation memory size-Xss256k // set the stack size of each thread-XX: + DisableExplicitGC // ignore Manual calls to GC, System. gc () calls will turn into an air conditioner, completely don't trigger GC-XX: + UseConcMarkSweepGC // concurrent mark clearing (CMS) Collector-XX: + CMSParallelRemarkEnabled // reduce mark pause-XX: + UseCMSCompactAtFullCollection // compression for the old generation during full gc-XX: LargePageSizeInBytes = 128 m // memory page size-XX: + UseFastAccessorMethods // rapid optimization of the original type-XX: + UseCMSInitiatingOccupancyOnly // use the manual definition of initialization definition to start CMS collection-XX: CMSInitiatingOccupancyFraction = 70 // use cms for garbage collection after 70%
Note:
-The ratio of Xmn to-Xmx is about. If the new generation memory is too large, the young gc takes a long time.
A good Web system should be able to recycle the memory for each http request in young gc. full gc will never happen. Of course, this is the ideal situation.
The xmn value should be set as small as possible on the premise that it is sufficient (enough for concurrent http requests ).
The configuration of web servers and game servers is not the same. The most important difference is that the xmn of the game server, that is, the configuration of the young generation, is relatively large and has a relationship with Xmx about, because the game server is generally a persistent connection, a large young heap memory is required after a certain amount of concurrency is maintained. If the size is set, young gc is often triggered.
We can see the classification of jvm heap memory. The JVM memory is divided into multiple independent parts.
Generally speaking, the JVM heap memory is divided into two parts: Young Generation and Old Generation ).
The young generation is where all new objects are generated. When the memory space of the young generation is used up, garbage collection is triggered. This garbage collection is called Minor GC. The young generation is divided into three parts: the Enden zone and two vor zones.
Highlights of the young generation space:
Most newly created objects are located in the Eden area.
When the Eden area is filled with objects, Minor GC is executed. And transfer all surviving objects to one of them.
Minor GC also checks the surviving objects and transfers them to another region. In this way, there will always be an empty region vor.
After multiple GC cycles, the surviving objects are transferred to the memory space of the older generation. Generally, this is done by setting the age threshold before the young generation is eligible to be promoted to the old generation.
The old generation memory contains long-lived objects and objects that remain alive after multiple Minor GC operations. Garbage collection is usually performed when the memory in the old age is full. In the old age, garbage collection is called Major GC. Major GC takes more time.
Stop the World event
All garbage collection events are "Stop the World" events, because all application threads Stop until the operation is completed (so it is called "Stop the World ").
Because the objects in the young generation are temporary (short-lived) objects, the execution of Minor GC is very fast, so the application will not be affected.
Because Major GC checks all surviving objects, it takes a longer time. Major GC should be minimized. Because the Major GC will slow your application response during garbage collection, if you have an application that requires rapid response to occur for multiple times, you will see a timeout error.
The garbage collection time depends on the garbage collection policy. This is why it is necessary to monitor and optimize garbage collection. This avoids timeout Errors for applications that require rapid response.
Permanent generation or "Perm Gen" contains the application metadata required by the JVM, which describes the classes and methods used in the application. Note that permanent generation is not part of the Java heap memory.
Permanently stores the classes used during JVM running. Permanent generation also contains classes and methods of the Java SE library. Permanent object garbage collection during full GC.
Method Area
The method area is a part of the permanent generation space and is used to store type information (runtime and static variables), method code, and constructor code.
Memory Pool
If JVM implementation is supported, JVM memory management creates a memory pool for the same object. String pool is a good example of the memory pool type. The memory pool can be a heap or permanent generation, depending on the Implementation of JVM memory management.
Runtime constant pool
The runtime constant pool is the running time table of each class constant pool. It contains the class runtime frequency and static method. The runtime constant pool is part of the method area.
Java stack memory
Java stack memory is used to run threads. They contain temporary data in the method and specific data referenced by other objects in the heap.
Java garbage collection
Java garbage collection will find useless objects, remove them from the memory, and release the memory for the objects created later. One of the biggest advantages of Java programming languages is automatic garbage collection. Unlike other programming languages, memory needs to be manually allocated and released, such as C language.
The garbage collector is a background running program. It manages all objects in the memory and finds objects that are not referenced. All unreferenced objects will be deleted, their space will be reclaimed and allocated to other objects.
A basic garbage collection process involves three steps:
MARK: This is the first step. In this step, the garbage collector will find out which objects are in use and which objects are not in use.
Normal cleanup: The Garbage Collector clears unused objects and recycles their space and assigns them to other objects.
Compression cleanup: to improve performance, compression cleanup will move all surviving objects together after useless objects are deleted. This improves the efficiency of allocating new objects.
Simple tag and clear methods have two problems:
Low efficiency. Because most newly created objects become "useless objects ".
Objects that have undergone multiple garbage collection cycles may survive in the future.
The problem with the above simple clearing method is that Java garbage collection is divided into generations, and there are two areas in the heap memory: the young and the old.
- Java garbage collection type
There are five types of garbage collection that can be used in applications.
You only need to use the JVM switch to enable the garbage collection policy in our application.
Serial GC (-XX: + UseSerialGC): The Serial GC uses simple marking, cleanup, and compression methods to recycle garbage from young and old generations, namely Minor GC and Major GC. Serial GC is useful in client mode (client mode), for example, in simple standalone applications and machines with low CPU configurations. This mode is useful for applications with a small amount of memory.
Parallel GC (-XX: + UseParallelGC): Apart from generating N threads to collect garbage from the young generation, Parallel GC is almost the same as Serial GC. Here N is the number of system CPU cores. We can use the-XX: ParallelGCThreads = n JVM option to control the number of threads. The parallel garbage collector is also called the throughput collector. Because it uses multiple CPUs to accelerate the garbage collection performance. Parallel GC uses a single thread for garbage collection in older generations.
Parallel Old GC (-XX: + UseParallelOldGC): Same as Parallel GC. The difference is that Parallel Old GC uses multiple threads to collect garbage from the young generation and the Old generation.
Concurrent mark clearing (CMS) Collector (-XX: + UseConcMarkSweepGC): CMS collectors are also known as transient pause concurrent collectors. It collects garbage from older generations. The CMS collector recycles garbage through multiple threads concurrently to minimize the pause caused by garbage collection. The CMS collector uses the same algorithm as the Parallel collector for garbage collection of young generations. This spam collector is suitable for applications that cannot tolerate long pauses and require rapid response. You can use the-XX: ParallelCMSThreads = n JVM option to limit the number of threads in the CMS collector.
G1 Garbage collector (-XX: + UseG1GC) G1 (Garbage First): The Garbage Collector is a feature that can be used only after Java 7. It replaces the CMS collector in the long term target era. The G1 collector is a parallel, concurrent, and incremental Garbage Collector that compresses transient pauses. The G1 collector runs differently from other collectors and does not distinguish between the young generation and the old generation. It divides the heap space into multiple equal-size regions. When Garbage collection is performed, it preferentially collects regions with fewer surviving objects, so it is called "Garbage First ".
Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.