Heap memory settings and garbage collection methods

Heap memory Setting principle JVM heap memory is divided into 2 blocks: Permanent space and heap space.

• Permanent is the persistent generation (Permanent Generation), which mainly holds Java class definition information, which is not related to the Java objects that the garbage collector collects.
• Heap = {old + new = {Eden, ' from ', to}},old is the older Generation, NEW is the young Generation (Generation). The division of old generations and younger generations has a greater impact on garbage collection.

Young generation

All newly generated objects are first placed in the young generation. The goal of the young generation is to collect as quickly as possible those objects with short life cycles. The young generation generally divided into 3 districts, 1 Eden Districts, 2 survivor districts (from and to).

Most objects are generated in the Eden area. When the Eden Zone is full, the surviving objects will be copied to the Survivor area (one of two), and when a survivor area is full, the surviving objects of this area will be copied to another survivor area, and when another survivor area is full, Objects that were copied from a former survivor area and survived at this time may be copied to the old generation.

2 survivor zones are symmetrical and have no succession, so the same survivor area may have objects copied from the Eden area and copied from the other survivor area, while the ones copied to the old quarter only come from another survivor area. also, at least one of the survivor areas is empty because of the need for Exchange . In special cases, depending on the program's needs, the survivor area can be configured to multiple (more than 2), which increases the age of the object in the younger generation and reduces the likelihood of being placed in the old generation.

Garbage collection for younger generations is the young GC.

Old generation

Objects that survived after N (configurable) garbage collection in the young generation are copied into the old generation. Therefore, it can be considered that older generations are storing objects with longer life cycles.

Garbage collection for older generations is the full GC.

Durable generation

Used to store static type data, such as Java Class, Method, and so on. Persistent generations have no significant impact on garbage collection. However, some applications may dynamically generate or invoke some classes, such as Hibernate CGLib, where it is often necessary to set a large, persistent generation space to store dynamically increasing types during these runs.

So, when a group of objects are generated, the memory request process is as follows:

1. The JVM tries to initialize an area of memory for the associated Java object in the young generation's Eden area.
2. When the Eden space is sufficient, the memory request ends. Otherwise, proceed to the next step.
3. The JVM tries to free all inactive objects in the Eden area (young GC). Once released, if Eden Space is still not enough to fit into the new object, the JVM attempts to put some of the active objects in the Eden area into the survivor area.
4. The survivor area is used as an intermediate swap area for the Eden area and the old generation. When the old generation of space is sufficient, the number of objects that have survived in the survivor area will be moved to the old generation.
5. When there is not enough space in the old generation, the JVM performs a complete garbage collection (full GC) in the older generation.
6. Full GC, if the survivor and older generations are still unable to store objects copied from the Eden Zone, the JVM will not be able to request memory for the newly generated object in the Eden area, i.e. "out of memory".

OOM ("Out of Memory") exceptions are generally mainly for the following 2 reasons :

1. Old generation overflow, performance: Java.lang.OutOfMemoryError:Javaheapspace This is the most common situation, which can be caused by the memory parameters set Xmx too small or the program memory leaks and improper use of the problem. For example, iterate over tens of thousands of string processing, create thousands of objects, and request hundreds of m or even upper g of memory within a piece of code. There are times when the memory overflow is not reported, but it will make the system uninterrupted garbage collection, and can not handle other requests. In this case, in addition to checking procedures, print heap memory and other methods to troubleshoot, but also with some memory analysis tools, such as Mat is very good.
2. Persistent overflow, the performance is: Java.lang.OutOfMemoryError:PermGenspace usually because the persistent generation set too small, dynamically loaded a large number of Java classes and caused overflow, the solution is only the parameter-xx:maxpermsize Large (256m can meet most application requirements). The way to load some Java classes into a container share (such as Tomcat share lib) is also a thought, but only if multiple applications are deployed in the container, and these applications have a large number of shared class libraries. Parameter description

• -xmx3550m: Set JVM maximum heap memory to 3550M.
• -xms3550m: Set the JVM initial heap memory to 3550M. This value can be set to the same as-xmx to avoid the JVM reallocating memory after each garbage collection completes.
• -xss128k: Sets the stack size for each thread. After JDK5.0, each thread stack size is 1M, before each thread stack size is 256K. Adjustments should be made based on the size of memory required by the application's thread. In the same physical memory, reducing this value can generate more threads. However, the operating system of the number of threads within a process is still limited, can not be generated indefinitely, the empirical value of 3000~5000 around. It is important to note that when this value is set to a larger size (for example, >2MB), the performance of the system will be greatly reduced.
• -XMN2G: Set the young generation size to 2G. In the case where the entire heap memory size is determined, increasing the younger generation will reduce the age generation and vice versa. This value is related to JVM garbage collection, which has a large impact on system performance and is officially recommended to be 3/8 of the total heap size.
• -XX:NEWSIZE=1024M: Sets the initial value of the young generation to 1024M.
• -xx:maxnewsize=1024m: Sets the maximum value of the young generation to 1024M.
• -xx:permsize=256m: Set the persistent generation initial value to 256M.
• -xx:maxpermsize=256m: Sets the maximum value for the persistent generation to 256M.
• -xx:newratio=4: Set the ratio of the younger generation (including 1 Eden and 2 survivor) to the old generation. Says the younger generation is 1:4 more than old.
• -xx:survivorratio=4: Sets the ratio between Eden and survivor in the younger generation . Represents 2 survivor Zones (the default in the JVM heap memory for 2 equal-sized survivor areas) and 1 Eden areas is 2:4, or 1 survivor extents represent the entire young generation of 1/6.
• -xx:maxtenuringthreshold=7: Indicates an object that has not been recycled into the old generation if it has been moved 7 times in the Survivor area (salvage space). If set to 0, then the young generation object does not go through the survivor area, directly into the old generation, for applications that require a large number of resident memory, this can improve efficiency. If you set this value to a larger value, the younger generation objects will replicate multiple times in the Survivor area, which increases the chance that an object can survive in the younger generation, increase the probability that the object will be garbage collected in the younger generation, and reduce the frequency of the full GC, which can improve service stability to some extent.

Question Answer-xmn,-xx:newsize/-xx:maxnewsize,-xx:newratio 3 sets of parameters can affect the size of the young generation, mixed use of the case, what priority?
As follows:

1. High-priority:-xx:newsize/-xx:maxnewsize
2. Medium Priority:-xmn (default equivalent-xmn=-xx:newsize=-xx:maxnewsize=?)
3. Low-priority:-xx:newratio

The-XMN parameter is recommended because the parameter is concise, equivalent to setting the newsize/maxnewsize once, and the two are equal for the production environment. -xmn with-XMS/-XMX, you can complete the heap memory layout. The-XMN parameter is supported at the beginning of JDK 1.4. Garbage collector Selection

The JVM gives 3 choices: The serial collector, the parallel collector, and the concurrency collector. The serial collector is only suitable for small data volumes, so the choice of production environment is mainly the parallel collector and the concurrent collector.

By default JDK5.0 uses a serial collector before, and if you want to use a different collector, you need to add the appropriate parameters at startup. After JDK5.0, the JVM is intelligently judged based on the current system configuration.

Serial collector

• -XX:+USESERIALGC: Sets the serial collector.

Parallel collector (throughput first)

• -XX:+USEPARALLELGC: Set to parallel collector. This configuration is only valid for younger generations. That is, young generations use parallel collections, while older generations still use serial collections.
• -XX:PARALLELGCTHREADS=20: Configures the number of threads for a parallel collector, that is, how many threads are garbage collected together. This value is recommended to be configured equal to the number of CPUs.
• -XX:+USEPARALLELOLDGC: Configure the old Generation garbage collection method for parallel collection. JDK6.0 began supporting parallel collection of older generations.
• -XX:MAXGCPAUSEMILLIS=100: Sets the maximum time (in milliseconds) for each young generation of garbage collection. If this time is not met, the JVM automatically adjusts the young generation size to meet this time.
• -xx:+useadaptivesizepolicy: When this option is set, the parallel collector automatically adjusts the ratio of the size of the young generation Eden area to the size of the survivor area to achieve the minimum response time specified by the target system or the frequency of collection. This parameter is recommended to always open when using the parallel collector.

Concurrent Collector (Response time first)

• -XX:+USECONCMARKSWEEPGC: That is, CMS collection, set old age on behalf of concurrent collection. CMS Collection is a new GC algorithm introduced by JDK1.4 later versions. Its main fit scenario is that the need for response time is greater than the demand for throughput, able to tolerate garbage collection threads and application threads sharing CPU resources, and there are more long life-cycle objects in the application. The goal of the CMS collection is to minimize the application's pause time, reduce the chance of full GC occurrence, and use the garbage collection threads that are associated with the application thread to clear older generations of memory.
• -XX:+USEPARNEWGC: Set Young on behalf of concurrent collection. Can be used concurrently with CMS collection. JDK5.0 above, the JVM will set itself according to the system configuration, so it is no longer necessary to set this parameter.
• -xx:cmsfullgcsbeforecompaction=0: Because the concurrent collector does not compress and defragment the memory space, running a period of time in parallel collection will result in memory fragmentation, and memory usage is less efficient. This parameter sets the memory space to compress and defragment after running 0 full GC, which is to start compressing and defragmenting the memory immediately after each full GC.
• -xx:+usecmscompactatfullcollection: Turns on compression and collation of memory space and executes after full GC. Performance may be affected, but memory fragmentation can be eliminated.
• -xx:+cmsincrementalmode: Set to incremental collection mode. Generally applies to single CPU situations.
• -XX:CMSINITIATINGOCCUPANCYFRACTION=70: Indicates that the old generation of memory space is used until 70% to start the CMS collection to ensure that older generations have enough space to accommodate objects from younger generations and avoid full GC occurrences.

Other garbage collection parameters

• -XX:+SCAVENGEBEFOREFULLGC: Younger generation GC is better than full GC execution.
• -XX:-DISABLEEXPLICITGC: does not respond to the System.GC () code.
• -xx:+usethreadpriorities: Enable the local thread priority API. java.lang.Thread.setPriority() not enabled is invalid even if it is in effect.
• -xx:softreflrupolicymspermb=0: A soft Reference object can survive the last 0 milliseconds (JVM defaults to 1000 milliseconds) after being accessed.
• -xx:targetsurvivorratio=90: Allow 90% of the survivor area to be occupied (JVM defaults to 50%). Increase the utilization rate for the survivor area.

Auxiliary Information parameter settings

• -xx:-citime: The time at which the print consumption is JIT-compiled.
• -xx:errorfile=./hs_err_pid.log: Saves the error log or data to the specified file.
• -xx:heapdumppath=./java_pid.hprof: Specifies the path to dump heap memory.
• -xx:-heapdumponoutofmemoryerror: Dumps the heap memory at this time when a memory overflow is first encountered.
• -xx:onerror= ";" : Run the custom command after a fatal error occurs.
• -xx:onoutofmemoryerror= ";" : Executes a custom command when a memory overflow is first encountered.
• -XX:-P Rintclasshistogram: Press Ctrl+break to print the column information of the class instance in the heap memory, with the JDK's Jmap-histo command.
• -XX:-P rintconcurrentlocks: Press Ctrl+break after the print line stacks concurrent lock related information, with the JDK jstack-l command.
• -xx:-P rintcompilation: Prints relevant information when a method is compiled.
• -xx:-P RINTGC: Prints relevant information each time the GC is printed.
• -xx:-P rintgcdetails: Print details Each time the GC is printed.
• -xx:-P rintgctimestamps: Prints the timestamp of each GC.
• -XX:-TRACECLASSLOADING: Tracking load information for a class.
• -xx:-traceclassloadingpreorder: Tracks the load information for all classes referenced to.
• -xx:-traceclassresolution: Tracks the constant pool.
• -xx:-traceclassunloading: The Unload information for the tracking class.

About parameter names, etc.

• Standard parameters (-), all JVMs must support the functionality of these parameters and are backwards compatible; for example:
  • -client--Set the JVM to use the client mode, characterized by a faster start-up speed, but run-time performance and memory management is not efficient, usually used for client applications or development debugging, in 32-bit environment directly run Java program by default enable the mode.
  • -server--Set the JVM to make the server mode, characterized by slow boot speed, but run-time performance and memory management is very efficient, suitable for the production environment. This mode is enabled by default in a JDK environment with 64-bit capability.
• Non-standard parameters (-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;
• Non-stable parameters (-XX), the various JVM implementations of such parameters will be different, may not be supported in the future, need to use cautiously;

JVM Service parameter tuning actual combat large Web server case

Dynamic Web applications that withstand massive access

Server configuration: 8 CPU, 8G MEM, JDK 1.6.X

Parameter scheme:

-SERVER-XMX3550M-XMS3550M-XMN1256M-XSS128K-XX:SURVIVORRATIO=6-XX:MAXPERMSIZE=256M-XX:PARALLELGCTHREADS=8-XX: Maxtenuringthreshold=0-xx:+useconcmarksweepgc

Tuning Instructions:

• The-XMX is the same as-XMS to prevent the JVM from repeatedly re-requesting memory. The size of the-XMX is about half the size of the system memory, that is, to make full use of system resources, and to give the system a safe running space.
• -xmn1256m set the young generation size to 1256MB. This value has a large impact on system performance, and Sun's official recommendation is to configure a young generation size of 3/8 for the entire heap.
• -xss128k sets a smaller line stacks to support the creation of more threads, supports massive access, and improves system performance.
• -xx:survivorratio=6 sets the ratio between Eden and survivor in the younger generation. The system defaults to 8, and according to experience set to 6, the ratio of 2 survivor zone to 1 Eden area is 2:6, and one survivor area represents 1/8 of the entire young generation.
• -xx:parallelgcthreads=8 configures the number of threads in the parallel collector, that is, 8 threads together for garbage collection. This value is typically configured to be equal to the number of CPUs.
• -xx:maxtenuringthreshold=0 set the maximum age of garbage (the number of survivors in younger generations). If set to 0, then the young generation object does not go through the survivor area directly into the old generation. For the older generation of more applications, can improve efficiency; If you set this value to a larger value, the younger generation object will replicate multiple times in the Survivor area, which increases the lifetime of the object's younger generations, increasing the probability of being recycled in the younger generation. Depending on the nature of the dynamic Web application that is accessed by the mass, its memory is either cached to reduce direct access to the DB, or is quickly recycled to support high concurrent mass requests, so its memory objects survive many times in the younger generation, and can go straight into the old generation, where this value is set to 0, depending on the actual application effect.
• -XX:+USECONCMARKSWEEPGC set old age on behalf of concurrent collection. The goal of the CMS (CONCMARKSWEEPGC) collection is to minimize the duration of application pauses, reduce the chance of full GC occurrences, and use garbage collection threads that are concurrent with the application thread to stamp out old-age memory for more long-life-cycle objects in your app.

Internal integration Build Server case application of high performance data processing tools

Server configuration: 1 CPU, 4G MEM, JDK 1.6.X

Parameter scheme:

-server-xx:permsize=196m-xx:maxpermsize=196m-xmn320m-xms768m-xmx1024m

Tuning Instructions:

• -xx:permsize=196m-xx:maxpermsize=196m based on the characteristics of the integration build, large-scale system compilation may require loading a large number of Java classes into memory, so it is efficient and necessary to allocate a large amount of persistent memory in advance.
• -xmn320m follows the 3/8 principle of the young generation size for the entire heap.
• The-xms768m-xmx1024m is set according to the heap memory size that the system can tolerate roughly.

When you run the application on a 64-bit server and build execution, observe the JVM heap memory status with the Jmap-heap 11540 command as follows:

Attaching to process ID 11540, please wait ...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.12-B01


Using Thread-local object allocation.
Parallel GC with 4 thread (s)


Heap Configuration:
Minheapfreeratio = 40
Maxheapfreeratio = 70
Maxheapsize = 1073741824 (1024.0MB)
NewSize = 335544320 (320.0MB)
Maxnewsize = 335544320 (320.0MB)
Oldsize = 5439488 (5.1875MB)
Newratio = 2
Survivorratio = 8
PermSize = 205520896 (196.0MB)
MaxPermSize = 205520896 (196.0MB)


Heap Usage:
PS Young Generation
Eden Space:
Capacity = 255852544 (244.0MB)
used = 101395504 (96.69828796386719MB)
Free = 154457040 (147.3017120361328MB)
39.63044588683081% used
From Space:
Capacity = 34144256 (32.5625MB)
used = 33993968 (32.41917419433594MB)
Free = 150288 (0.1433258056640625MB)
99.55984397492803% used
To Space:
Capacity = 39845888 (38.0MB)
Used = 0 (0.0MB)
Free = 39845888 (38.0MB)
0.0% used
PS Old Generation
Capacity = 469762048 (448.0MB)
used = 44347696 (42.29325866699219MB)
Free = 425414352 (405.7067413330078MB)
9.440459523882184% used
PS Perm Generation
Capacity = 205520896 (196.0MB)
used = 85169496 (81.22396087646484MB)
Free = 120351400 (114.77603912353516MB)
41.440796365543285% used

The results are relatively healthy.

Reprint: http://blog.csdn.net/sivyer123/article/details/17139443

Heap memory settings and garbage collection methods