Continue to create, accelerate growth! This is the 28th day of my participation in the "Nuggets Daily New Plan · June Update Challenge", click to view the details of the event
In this article, let's take a look at how to choose the right garbage collector. Each garbage collector has its own algorithm implementation and steps. Below we briefly describe the algorithm process of the four common garbage collectors. Interested students should read the following two articles to increase their understanding. . It introduces some basic concepts of garbage collection and the process of various garbage collectors. The content is repeated, and this chapter will not explain it separately. So this chapter makes some conclusions.
# Introduction to JVM GC garbage collection
# To learn java, you must understand the garbage collector
Common Garbage Collectors and Algorithms
I believe that you can learn a lot about garbage collectors through the other two articles I provided. And the garbage collectors we really need to pay attention to, and maybe even use, are the following four:
serial serial garbage collector
This garbage collector will become the default garbage collector if it is on clienta virtual machine or a server. 单核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 types are divided into client and server, and the jvm will compile the code into the bytecode recognized by the jvm through the client compiler (single thread).
This can be represented by the following flags:
-XX:+UseSerialGC
Parallel multithreaded garbage collector
On a server-type virtual machine or a multithreaded server, the default garbage collector type used by jdk8.
Both Minor GC and Full GC use multi-threaded methods to collect garbage, both of which will cause application thread suspension. But it has more throughput and is the most suitable garbage collector when response time is not too demanding.
Its status can be checked with the following flags:
- young generation
-XX:+UseParallelGC - old age
-XX:+UseParallelOldGC
CMS collector
The original intention of its design is to reduce the long-term system freeze caused by serial and parallel collectors during recycling.
它在发生Minor GC时同样会暂停所有的应用线程，不同之处在于，年轻代使用的不是parallel或者serial，而是使用一款专门适用于CMS的年轻代收集器ParNew。
可以通过下面的标志查看：
-XX:+UseParNewGC
CMS在发生Full GC时不再暂停全部应用线程，使用多线程的方式，和应用线程同时运行，清理不在使用的对象。这事得CMS垃圾收集器的停顿时间得到大大的降低。与Parellel收集器相比，极其明显。
缺点：
-
CMS需要占用较多的CPU资源，确保在应用线程运行时，gc线程不断地扫描堆空间。
-
不会对内存进行压缩整理，导致内存碎片化。
如果没有足够的CPU资源，或者内存碎片化达到极限，将会退化成serial收集器。
可以通过下面的标志查看：
-XX:+UseConcMarkSweepGC
G1 收集器
也可以称作垃圾优先收集器(garbage first)。
设计初衷是为了尽量减少处理超大堆（4gb）时发生的卡顿。G1仍然属于分代收集器，但是不同之处是它是逻辑分代。G1将堆空间划分成若干个区域（Region），新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这样就解决了CMS中的内存碎片问题。
与CMS相同，G1也属于concurrent收集器，在老年代发生Full GC时，由后台线程完成回收工作，不需要暂停应用线程。
通过下面的标志查看：
-XX:+UseG1GC
其实上面的内容都是简单描述，真正的实现细节请看开篇提供的文章。
显式垃圾收集
这里说的显式的垃圾收集，其实指的是手动触发的垃圾回收，如下所示：
System.gc;
这是一种可以认为控制，让jvm发生强制gc的方式。无论什么时候，都是不建议使用这种方式进行垃圾回收。
When you use this specification, no matter what kind of garbage collector, even CMS or G1 will have Full GC and stop all application threads at the same time, it will freeze for a long time.
Exceptions:
- Performance analysis and testing
- heap analysis
In the above situation, calling System.gc will better help us analyze the problems existing in the current application.