preface
We’ve looked at the architecture of the JVM and the garbage collection algorithm, but today we’ll look at how the JVM’s most important heap memory uses garbage collectors for garbage collection, and how to configure the use of these garbage collectors using commands.
Heap memory details
I think you already know what this graph is. A house is divided into several rooms, each of which serves a different purpose. Some are for babies, some are for parents, and some are for grandparents
-
The heap memory is divided into two parts, one for the young generation and the other for the old generation.
-
The young generation is divided into Eden and Survivor. The default space ratio is 8:2,
-
The survival zone is subdivided into S0 and S1. These two Spaces are exactly the same size, they’re twins, and they’re 1:1
Heap memory garbage collection process
The first step
The newly generated objects are first placed in Eden, and the Minor GC is triggered when Eden is full.
The second step
In the first step, the surviving objects are moved to S0 in the survivor zone. When S0 is full, Minor GC is triggered. Surviving objects in S0 are moved to S1, and S0 is idle.
After S1 is full, the surviving ones move to S0 again, and S1 is idle, so that the object’s age increases one year with each GC, and reaches a certain value (15), and it enters the old age.
The third step
Depending on the garbage collector, a Major GC may occur in older generations after a Minor GC (a prerequisite).
Full GC trigger condition
-
A manual call to System.gc will continuously execute Full GC
-
There is not enough space in the old era
-
Method area space is insufficient/full
Pay attention to
You need to remember one word: stop-the-world. It can happen in any GC algorithm. Stop-the-world means that the JVM stops the execution of the application because it needs to perform GC.
When stop-the-world occurs, all threads except those required for GC go into a wait state until the GC task completes. A lot of GC optimization is about reducing stop-the-world.
Objects in which regions are reclaimed
Note that the JVM GC only reclaims objects in heap memory and method areas. Stack memory data is automatically released by the JVM when it is out of scope, so it is not managed by the JVM GC.
Configure common heap memory parameters
parameter | describe |
---|---|
-Xms | Initial size of heap memory, in m or g |
-Xmx | The maximum allowed size of heap memory should not be greater than 80% of physical memory |
-XX:PermSize | The initial size of non-heap memory is 200m, and the maximum size is 1024M |
-XX:MaxPermSize | Maximum allowed size of non-heap memory |
– XX: NewSize (- Xns) | Initial memory size of young generation |
– XX: MaxNewSize (- Xmn) | Maximum allowed memory size of young generation |
-XX:SurvivorRatio=8 | The ratio of the Eden zone to the Survivor zone in the young generation is 8 by default, that is, 8:1 |
-Xss | Stack memory size |
-xx :NewRatio= Old age/New age | Set the size ratio between old age and new age |
-XX:+PrintGC | When the JVM starts, it prints logs whenever GC is encountered |
-XX:+PrintGCDetails | View GC details, including extents |
-XX:MaxDirectMemorySize | You can access it directly in NIODirect memoryThe default is the maximum heap space -Xmx |
-XX:+DisableExplicitGC | Closure System. The gc () |
-XX:MaxTenuringThreshold | Garbage can enter old age |
-Xnoclassgc | Disable garbage collection |
-XX:TLABWasteTargetPercent | Percentage of TLAB in Eden area, default is 1% |
-XX:+CollectGen0First | FullGC specifies whether YGC comes first. The default value is false |
TLAB memory
TLAB (Thread Local Allocation Buffer) is a thread-specific memory Allocation area designed to speed up the Allocation of objects.
Each thread generates a TLAB, which is its own work area. The Java virtual machine uses this TLAB area to avoid multi-thread conflicts and improve the efficiency of object allocation.
TLAB space is generally not large, and when large objects cannot be allocated in TLAB, they are allocated directly to the heap.
parameter | describe |
---|---|
-Xx:+UseTLAB | Using TLAB |
-XX:+TLABSize | Set the TLAB size |
-XX:TLABRefillWasteFraction | Set the size of a single object that is maintained into the TLAB space. This is a scale value that defaults to 64, i.e. objects are created in the heap if they are larger than 1/64 of the total space |
-XX:+PrintTLAB | View TLAB information |
-Xx:ResizeTLAB | Self-adjust the TLABRefillWasteFraction threshold. |
Garbage collector overview
Next-generation configurable recyclers: Serial, ParNew, Parallel Insane
Collector configured in the Old era: CMS, Serial Old, Parallel Old
The link between the recyclers in the new generation and old age areas shows that they can be used together.
The next generation of garbage recyclers
Serial garbage collector
The Serial collector is the most basic and oldest in development. Commonly known as: serial collector, the use of replication algorithm for garbage collection
The characteristics of
A serial collector is a collector that uses a single thread for garbage collection. The serial collector has only one worker thread per collection.
For single-CPU computers with weak parallelism, the focus and exclusivity of the serial collector tend to perform better.
It has The Stop The World problem, and The garbage collection, to Stop The program running.
Use the -xx :+UseSerialGC parameter to set the new generation to use this serial collector
ParNew garbage collector
ParNew is a multithreaded version of Serial, with the same parameters as Serial except that it uses multiple threads. Commonly known as: parallel garbage collector, using the replication algorithm for garbage collection
The characteristics of
ParNew enables the same number of threads as the number of cpus by default. On machines with many CPU cores, you can set the number of threads by using -xx :ParallelGCThreads.
It is currently the garbage collector of choice for the new generation because, apart from ParNew, it is the only one that works with older CMS.
It also has The Stop The World problem
Use the -xx :+UseParNewGC parameter to set the new generation to use this parallel collector
ParallelGC collector
ParallelGC uses a replication algorithm for garbage collection and is also multithreaded.
The characteristics of
Throughput = code run time /(code run time + garbage collection time)
– XX: MaxGCPauseMillis: If you want to reduce the GC pause time, you can set MaxGCPauseMillis to be very small, but this will result in frequent GC, which increases the total GC time and reduces throughput. Therefore, set the value as required.
-xx :GCTimeRatio: Sets the throughput. It is an integer between 0 and 100. The default value is 99, so the system will spend no more than 1/(1+n) garbage collection time.
You can also specify -xx :+UseAdaptiveSizePolicy to turn on adaptive mode, in which the size of the new generation, Eden, from/to ratio, and age of objects promoted to the old generation are automatically adjusted to balance heap size, throughput, and pause time.
Use the -xx :+UseParallelGC parameter to set the new generation to use this parallel collector
Old age garbage collector
SerialOld garbage collector
SerialOld is an older collector version of Serial, which is also a single-threaded collector.
use
-
The one used in JDK1.5 and earlier with the Parallel Scavenge collector,
-
The other is to serve as a fallback for the CMS collector in the event of Concurrent Mode Failure.
Algorithm to use: mark-tidy algorithm
ParallelOldGC collector
ParallelOldGC collector is a multithreaded collector that, like the newer ParallelGC collector, is focused on throughput and is implemented using a mark-compression algorithm.
-xx :+UseParallelOldGc To set the old age to use the collector
-xx :+ParallelGCThreads can also set the number of threads for garbage collection.
CMS collector
CMS stands for Concurrent Mark Sweep, which uses a Mark Sweep method. Focus on system downtime.
Use -xx :+UseConcMarkSweepGC to set the old age to use the collector.
Use -xx :ConcGCThreads to set the number of concurrent threads.
The characteristics of
CMS is not an exclusive collector, that is, during CMS collection, the application is still working, and new garbage is constantly generated, so in the process of using CMS, you should ensure that the application memory is available.
The CMS does not wait until the application is saturated to collect garbage. Instead, it starts collecting garbage at a certain threshold, which can be configured with specified parameters: – XX: CMSInitiatingoccupancyFraction to specified, the default is 68, that is to say, when the old s space utilization rate reached 68%, will perform a CMS.
If the memory usage increases rapidly and the CMS is running out of memory, the CMS collection will fail and the VM will start the old serial collector. SerialOldGC does garbage collection, which causes the application to break until garbage collection is complete.
The process of GC pause time may be longer, so – XX: CMSInitiatingoccupancyFraction set according to the actual situation.
Before we said, when learning algorithm tag QingChuFa problems memory fragments of a weakness is, the CMS has a parameter set – XX: + UseCMSCompactAtFullCollecion can be carried out after completion of recycle CMS defragmenter at a time.
How many times – XX: CMSFullGCsBeforeCompaction parameter can be set to the CMS after recovery, a compression on memory.
G1 collector
The space is too long, we will explain next article!!
IT brother
A big factory to do advanced Java development program ape
Follow wechat public account: IT elder brother
Java actual combat project video tutorial: you can get 200G, 27 sets of actual combat project video tutorial
Reply: Java learning route, you can get the latest and most complete a learning roadmap
Re: Java ebooks, get 13 must-read books for top programmers
Java foundation, Java Web, JavaEE all tutorials, including Spring Boot, etc
Reply: Resume template, you can get 100 beautiful resumes