I believe you can learn a lot about garbage collectors through the other two articles I provided. The garbage collectors that we really need to pay attention to and may even use are the following four types:
If it is a virtual type of client
machine or on a single-core
server, this garbage collector will become the default garbage collector. Whether it is Minor GC or Full GC, all application threads will be suspended. Serial Old is used in the old generation, which is also a single-threaded old generation version.
Client-type virtual machine, we mentioned earlier that the compilation type is divided into client and server. JVM will compile the code into bytecode recognized by JVM through the client compiler (single thread).
can be represented by the following flags:
-XX:+UseSerialGC
On server-type virtual machines or multi-threaded servers, jdk8 defaults The type of garbage collector to use.
Both Minor GC and Full GC use multi-threading to collect garbage. Both types of GC will cause the application thread to pause. But it has more throughput and is the most suitable garbage collector when there are no excessive requirements on response time.
You can check its status through the following flags:
Young generation:
-XX:+UseParallelGC
Old generation:
-XX:+UseParallelOldGC
Its original design is to reduce the long-term system lag caused by serial and parallel collectors during recycling.
It will also suspend all application threads when Minor GC occurs. The difference is that the young generation does not use parallel or serial, but uses a young generation collector specially adapted to CMSParNew
.
You can view it through the following signs:
-XX:+UseParNewGC
CMS no longer suspends all application threads when Full GC occurs, but uses multi-threading to run at the same time as the application threads. , clean up objects that are no longer in use. This greatly reduces the pause time of the CMS garbage collector. Extremely obvious compared to Parellel collector.
Disadvantages:
CMS needs to occupy more CPU resources to ensure that when the application thread is running, the gc thread continuously scans the heap space.
The memory will not be compressed and organized, resulting in memory fragmentation.
If there are not enough CPU resources, or memory fragmentation reaches the limit, it will degenerate into a serial
collector.
can be viewed through the following flags:
-XX:+UseConcMarkSweepGC
can also be called garbage priority collector
( garbage first).
The original design is to minimize the lag that occurs when processing extremely large heaps (4gb). G1 still belongs to the generational collector, but the difference is that it is logical generation
. G1 divides the heap space into several regions (Regions). Garbage collection in the new generation still uses the method of pausing all application threads to copy surviving objects to the old generation or Survivor space. The old generation is also divided into many areas, and the G1 collector completes the cleanup work by copying objects from one area to another. This solves the problem of memory fragmentation in CMS.
Same as CMS, G1 is also a concurrent collector. When Full GC occurs in the old generation, the background thread completes the recycling work without pausing the application thread.
View through the following logo:
-XX:+UseG1GC
In fact, the above content is a simple description. For the real implementation details, please see the article provided at the beginning.
The explicit garbage collection mentioned here actually refers to manually triggered garbage collection, as shown below:
System.gc;
This is a way to control and force the jvm to have gc. It is not recommended to use this method for garbage collection at any time.
When you use this specification, no matter what kind of garbage collector, even CMS or G1, Full GC will occur and all application threads will be stopped at the same time, which will cause lag for a long period of time.
Exceptions:
Performance analysis, testing
Heap analysis
In the above situation, calling System.gc will better help us analyze the problems of the current application.
The above is the detailed content of What are the common garbage collectors for java performance optimization?. For more information, please follow other related articles on the PHP Chinese website!