【垃圾回收器】JDK的垃圾回收器

JDK不同版本的默认垃圾回收器

JDK1.7: PS + PO
JDK1.8: PS + PO
JDK1.9: G1

另，要注意的是：
（1）CMS从来不是某个版本默认的垃圾回收器；
（2）CMS是划时代的，从1.4开始出现，开启了并发回收。但它的缺点也很明显，并不是默认的垃圾回收。
（3）G1 是从jdk1.7开始，但到1.8才比较稳定，所以G1基本从1.8 就开始用了
（4）CMS 有两个比较致命的缺点，浮动垃圾和碎片化
其中：如果在清理过程中预留给用户线程的内存不足就会出现‘Concurrent Mode Failure’,一旦出现此错误时便会切换到SerialOld收集方式，而切换到 SerialOld收集方式，那STW时间可能就非常长了。所以现在都更宁愿使用G1。

2、查看GC详情
-XX:+PrintGCDetails 加这个参数。
其中 + 表示使用， - 表示不使用，比如 ： -XX:-PrintGCDetails 就表示不打印（当然不会有种写法，因为不打印详情是默认选项，只是举个例子）

参考： https://blog.csdn.net/calm_encode/article/details/106621152

---

关于CMS和G1物理内存的回收

在JDK8+CMS的配置下，JVM并不是立马归还内存给到操作系统，而是随着FullGC次数的增多逐渐归还，最终会全部归还
在JDK11+CMS的配置下和JDK8+CMS的情况相同（JVM并不是立马归还内存给到操作系统，而是随着FullGC次数的增多逐渐归还，最终会全部归还）

在JDK8+G1的配置下，JVM都是在每一次FullGC后全部归还物理内存
JDK11下的G1和JDK8下的G1对内存的响应是不一样的。 从堆内存变化来看， JDK11下G1更加倾向于尽可能的利用内存，不着急回收。 而JDK8下G1则是倾向于尽可能的先回收内存。 从图中看，JDK8下G1的实际使用的堆内存大小基本是JDK11下G1的一半

参考： https://blog.csdn.net/qq_40378034/article/details/110677269 (关于CMS和G1物理内存的回收)