JAVA heap memory management performance is one of the main factors.
Heap overflow is a very common fault JAVA project, before to solve this problem, you must first understand JAVA heap memory is how it works.
Look at how JAVA heap memory is divided, as shown:
- JVM heap memory is divided into memory and non-memory heap, heap memory is divided into the young generation (Young Generation), years old (Old Generation), a non-heap memory on a permanent-generation (Permanent Generation).
- The young generation is divided into Eden and Survivor areas. Survivor areas of FromSpace and ToSpace composition. Eden District, accounting for a large-capacity, Survivor region accounted for two small capacity, the default ratio is 8: 1: 1.
- Heap Memory Usage: is stored in the object, the garbage collector is to collect these objects, then recovered according to GC algorithm.
- Non-heap memory use: Generation of permanent, also called method area, long-term survival of the stored program runtime objects, such as metadata classes, methods, constants, and other properties.
In JDK1.8 version permanently abandoned generations. Instead of that element space (MetaSpace), Yuan permanent space on behalf of similar methods to achieve all areas, their biggest difference is: Yuan is not space in the JVM, but the use of local RAM.
Yuan space Note that there are two parameters:
- MetaspaceSize: Initialization membered space, the occurrence of GC control threshold value
- MaxMetaspaceSize: element space restrictions limit the size of physical memory to prevent the abnormal take up too much
Why remove permanent generations?
On behalf of the permanent removal of reasons: as a fusion HotSpot JVM and JRockit VM (JVM new technology) to make the change, because there is no permanent JRockit generations.
With the dollar will no longer be a permanent space on behalf of the OOM problem!
Generational concept
The new generation of the young generation into the first target area Eden, Eden when the space is full, triggering Minor GC, surviving move the object to Survivor0 area, after Survivor0 area full trigger the execution of Minor GC, Survivor0 area live objects move to Suvivor1 area, so ensures that there is always a survivor area is empty for some time. After the object repeatedly Minor GC still alive moved to the old era.
Old's long-term survival of stored objects, triggers Major GC = Full GC, GC will stop during all threads wait for the GC when filled, so the response to high demand applications to minimize the occurrence Major GC, avoid response timeout.
Minor GC: clean up the young generation
Major GC: cleaning up old's
Full GC: clean up the entire heap space, including the young generation and permanent generation of
all GC will stop all application threads.
Why generational?
The objects are classified according to the probability of survival, for the survival of long-time object into a fixed area, thus reducing the waste of time and scan GC frequency. Different garbage collection algorithms for classification, algorithm weaknesses.
Why survivor survivor space is divided into two equal-sized?
Mainly to solve fragmentation. If severe memory fragmentation, that is, the two objects occupy discrete memory, there is not enough contiguous memory to store a new object, it will trigger GC.
JVM heap memory commonly used parameters
| parameter | description |
|---|---|
| -Xms | The initial heap size, the unit m, g |
| -Xmx（MaxHeapSize） | The maximum allowable size of heap memory, physical memory is generally not more than 80% |
| -XX:PermSize | Non-heap memory initial size, the general application settings initialization 200m, 1024m maximum is enough |
| -XX:MaxPermSize | Non-heap memory maximum allowable size |
| -XX:NewSize（-Xns） | The initial size of the young generation of memory |
| -XX:MaxNewSize（-Xmn） | The maximum allowable size of the young generation of memory, you can also abbreviated |
| -XX:SurvivorRatio=8 | And the ratio of the capacity value of Eden region Survivor young generation region, the default is 8, i.e., 8: 1 |
| -Xss | Stack memory size |
Garbage collection algorithm (GC, Garbage Collection)
Red is marked inactive objects, green is the active object.
- Mark - Clear (Mark-Sweep)
the GC is divided into two stages, mark and sweep. First of all recyclable labeled objects, all objects are marked unified recovered after completion flag. And it will produce discrete memory fragmentation. When the need to allocate large objects can cause excessive debris after the program is running, you can not find enough contiguous memory, and forced to trigger GC again.
- Copy (the Copy)
memory capacity is divided into two by a time use only one. When this one runs out of memory, it will copy the surviving objects onto another piece of memory space has been used once and then clean out. So that every time the memory area for half recovery, they do not consider the problem of memory fragmentation, simple and efficient. The drawback of requiring twice as much memory space.
- Mark - finishing (Mark-Compact)
is also divided into two stages, first of all marking objects recyclable, then the surviving objects are moved to the end, then clean out the memory beyond the boundary. This method avoids the mark - to clear debris algorithms, but also to avoid space issues replication algorithm.
After performing GC generally younger generation, there will be a small amount of live objects, it will copy the selection algorithm, only to pay a small amount of live objects replication costs to complete the collection. The old era because of the high survival rate of the object, there is no extra space allocated too much memory, you need to use the mark - to clean up or mark - sorting algorithms to recover.
The garbage collector
- Serial collector (Serial)
older collectors, single-threaded. When collected, the worker thread must suspend the application until the end of the collection. - Parallel collector (Parallel)
multiple threads in parallel garbage collection work, higher efficiency in multi-core CPU, application threads still pending. - CMS collector (Concurrent Mark Sweep)
CMS collector is to shorten the time to suspend application designed for the target, based on mark - sweep algorithm, the whole process is divided into four steps, including:- Initial labels (Initial Mark)
- Concurrent mark (Concurrent Mark)
- Relabeled (Remark)
- Clear concurrent (Concurrent Sweep)
Among them, the initial marker, re-mark these two steps still need to pause the application thread. The initial mark just mark what objects can be linked directly to the GC Roots, very fast, concurrent mark phase is marked recyclable objects, and re-mark phase is to correct during the concurrent mark due to the operation of the user program continues to produce results in marked changes in that part of the mark record object, this stage pause a little longer than the initial mark phase, but far more concurrent mark time period.
Since the whole process of consuming the longest concurrent mark and clear process of collecting concurrent threads can work together with the user thread, so, CMS collector garbage collection with concurrent execution of the user, greatly reducing the pause time.
- G1 collector (Garbage First)
G1 stack will separate collector region (Region) memory is divided into a plurality of equal size, and can predict the pause time, it can predict the reason of avoiding the entire heap region collected. G1 track individual Region of garbage piled up in the value of size (obtained by space and time required for recovery), in the background to maintain a priority list, according to each collection time allowed, the biggest priority recovery value Region, thus ensuring longer limited time within a higher collection efficiency.
G1 collector work project is divided into four steps, including:- Initial labels (Initial Mark)
- Concurrent mark (Concurrent Mark)
- The final mark (Final Mark)
- Filter Recycling (Live Data Counting and Evacuation)
The initial mark with CMS, as it marks the object can be linked directly to the GC Roots of. Concurrent mark from GC Root mark the beginning of live objects, this phase takes longer, but can also be performed concurrently with application threads. The final mark also to amendments made during the concurrent mark due to the continued operation of the user program resulting from that part of the record mark mark produce change. Finally, sort the recycling value of each Region and cost recovery in the screening stage to recover the user to perform the desired GC pauses.
The garbage collector parameters
| parameter | description |
|---|---|
| -XX:+UseSerialGC | Serial collector |
| -XX:+UseParallelGC | Parallel collector |
| -XX:+UseParallelGCThreads=8 | The number of parallel threads collector, while the number of threads for garbage collection, generally equal to the number of CPU |
| -XX:+UseParallelOldGC | Specifies the parallel collector on behalf of the elderly |
| -XX:+UseConcMarkSweepGC | CMS collector (concurrent collector) |
| -XX:+UseCMSCompactAtFullCollection | Open space compression and memory consolidation, to prevent excessive memory fragmentation |
| -XX:CMSFullGCsBeforeCompaction=0 | Indicates the start of compression and how many times after finishing Full GC, 0 represents the compression is performed immediately after each Full GC and finishing |
| -XX:CMSInitiatingOccupancyFraction=80% | It indicates that the memory space using the old CMS's begin collecting 80%, to prevent too much of Full GC |
| -XX:+UseG1GC | G1 collector |
| -XX:MaxTenuringThreshold=0 | After several GC still alive in the young generation, to enter the old era, 0 means direct access to the old year |
Why would heap overflow?
In the younger generation still alive after GC after an object is copied to the old era. Years old when there is insufficient space, JVM years old will complete garbage collection (Full GC). If the GC, still can not store objects from Survivor areas over, there will be OOM (Out of Memory).
OOM (Out of Memory) abnormalities are common for several reasons:
1) the old year out of memory: java.lang.OutOfMemoryError: Javaheapspace
less than 2) permanent generation of memory: java.lang.OutOfMemoryError: PermGenspace
3) Code bug, can not take up memory timely recovery.
OOM are likely to occur in these memory areas, the actual encounter OOM, which can be located in memory overflow areas according to the abnormality information.
By adding a parameter -XX: + HeapDumpOnOutMemoryError, so that the virtual machine appears Dump the current snapshot of the heap dump memory overflow exception for post-mortem analysis.
Familiar with JAVA memory management and configuration parameters, the following is a JAVA application launch configuration tuning options:
-
JAVA_OPTS="-server -Xms512m -Xmx2g -XX:+UseG1GC -XX:SurvivorRatio=6 -XX:MaxGCPauseMillis=400 -XX:G1ReservePercent=15 -XX:ParallelGCThreads=4 -XX: -
ConcGCThreads=1 -XX:InitiatingHeapOccupancyPercent=40 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:../logs/gc.log"
- Set minimum and maximum heap memory, maximum utilization of historical reference set
- Setting up the GC garbage collector for the G1
- GC logging is enabled, to facilitate post analysis
summary
- Select efficient GC algorithm can effectively reduce the stopping time application threads.
- Full GC pauses frequently will increase the time and CPU utilization, it can increase the size of the old space Full GC's lower, but increases the recovery time, according to business appropriate choice.
