尚硅谷_11-删除CMS垃圾回收器

接着呢，咱们来给大家讲解这样一个新特性，也是呢，关于我们这个GC这块的一个变化，叫做删除CMS呢垃圾回收器。这个刚才呢，我们是不是还讲到这些叫CMS这个垃圾回收器了，就是CMS呢，是专门来处理我们老年代这个垃圾这个回收的问题的，也是咱们Java当中第一款，它这个不能叫Java中，应该是我们叫houseor的一个虚拟机当中第一款啊，真正意义上的叫并发的垃圾回收器。啊，这个他也实现了咱们叫垃圾回收的线程，和咱们这个用户线上可以同时工作，所以呢，我们叫并发对吧，那么很遗憾的是呢，在咱们JDK14这个版本当中。这个诶这个在这是吧，在我们这个JDK14这个版本当中啊，说他已经被干掉了，实际上呢，他在这个GDK9的时候呢，就被标识为叫deit了。啊，那么在我们这个十字当中啊，就彻底的给他拿掉了，经过这个两年多的这个时间啊，那为什么会这样呢？主要呢是现在基于这个g first，就我们说这个G啊，也可以叫垃圾回收器，都是呢，叫基于region分带的，这呢也是当前的一个主流。

那么G呢，自从作为这个默认的垃圾回收器出现之后呢，这个CMS呢，就很快的要被干掉。啊，就是这样一个情况，那为什么我们不选择使用这个CMS呢？这呢，我简单的写了三条原因。啊，第一个的话呢，叫会产生内存的碎片。嗯，说导致并发清除以后呢，用户线程可用的空间不足，这个内存碎片问题，就是因为CMS呢，它使用的叫这个叫标记清除算法啊，标记清除算法它就是会导致这个内存的碎片问题，那你想想，如果说我们这个内存中这个碎片过多，如果现在用户呢，想分配这个比较大的这个对象的时候呢，就有可能导致咱们这个内存空间呢，根本没有一个足够长的一个空间去分配这个大对象。可能就引发了for GC。啊就成这样问题，第二的话呢，就是既然呢强调了叫并发了，所以CMS呢，垃圾回收器对CPU的资源呢，就非常的敏感。那有可能他就需要更多的CPU资源来进行做运算，就导致呢，咱们这个整个这个吞吐量啊，就可能会降低。

OK，那下个问题呢，就是CMS的垃圾回收器，它无法处理浮动垃圾。那怎么叫浮动垃圾呢？啊，既然咱们说叫并发，那就说用户线程和我们这个垃圾回收的线程啊，它可以同时的去执行，那么就有可能咱们当前垃圾回收线程标记的垃圾，这个标记完以后呢，他就处理，那么用户现城是不是又会有新的垃圾出现啊，那么这个新的垃圾咱们当前这一次回收的时候呢，就没办法进行回收了，那么这个垃圾呢，咱们就称为叫浮动垃圾。啊，就跟咱们说呢，你一边打扫屋子一边呢，是不是又这个这个扔垃圾是吧，你打扫的只能是你当前这个，然后呢，你在打扫的过程当中又扔的这个垃圾呢，当前这一次清扫呢，就没办法解决了，那么这个呢，咱们就称为叫浮动垃圾，那CMS呢，咱搞定搞不定这样的事情是吧，这样就是它三个问题。这三个问题当中，最主要的问题呢，还是这个碎片化的问题。说他呢，给我们的这个GM呢，实力相当于就埋下了一颗叫定时炸弹。那说不定呢，哪一次当我们的业务呢，高峰期来临的时候呢，进行了一次for GC，那如果说很遗憾，你当前这个CMS呢，停止工作了啊，它停止工作以后呢，它还有一个后备方案，咱们在刚才呢，刚才呢，是不是也提到过，就是这个叫Siri old。

啊，那这里边又是一个很崩很崩溃的一个情况啊，这个Co呢，它可是一个串行的垃圾回收器，是咱们这个GM当中这个性能最差的一个垃圾回收器了，它需要呢，停停顿上这个十几秒上十秒都有可能啊，停顿上几秒或者十几秒都有可能，所以这块呢，如果对于我们后台处理这个业务来讲的话呢，那这是很难接受的。哎，所以这块呢，我们干脆直接呢，就把这个CS呢干掉了，因为呢，我们是不是有更好的叫g first去做选择呀。好，那么移除了这个CMS垃圾回收器之后呢，如果大家在JDK14当中，你再去通过这样的一个指令去使用的话呢，它就会报这个GMGM的一个警告，OK，这块咱们来演示一下。那比如在这块我把这个呢也添加过来是吧？嗯，我们在这个run这块呢，加入一个配置，把它呢干掉CTRLV，我们替换成呢叫CMS，这个呢，就是咱们Java虚拟的这个配置的这个参数，哎，大家在这块不清楚的话呢，还是可以在哔哩哔哩上去看这条视频就可以了啊好，我们这块点一下OK，这块呢做做执行。

行，这时候大家会看到我们标识出来，说你当前的这个，哎，我把它那先停一下啊。当前的话呢，我们使用的是这个CMS，他给我们的一个警告，而且呢，他说会忽略咱们当前的这个行为是吧，忽略是什么意思呢？就是说呃，他还是会选择默认的一个垃圾回收器做处理，那就是我们现在用的叫g first，因为呢，咱们在十字中移除了嘛，他不会说呢，虽然井号还会用，根本就没有了，所以呢就不会使用了。OK，这呢，就是我们说的这样一个新特性啊，咱把这个呢也可以。CTRLC来标识到咱们这块。这呢是相当于是第一个变化对吧。嗯，这是我们这个第二个变化。保存一下行，那么这个关于CMS垃圾回收器呢，咱们就说到这儿，大家知道呢，在实词当中把它干掉了，你在面试当中呢，就可以大胆的把这个CMS呢提出来，那为什么干掉这个弊端呢？是不是很自然而然的你也就表达出来了。

那么替换成什么呢？替换成谁了呢？毫无疑问呢，是不是g first？那么g first呢？难道就是一个最终方案吗？其实也不是好，这块呢，我们又引出了一个高级的内容，这也是在面试当中，大家呢一定要提出来的。就是说大家如果去网上你看一些这个GM的视频，通常你会发现呢，这些视频呢，可能都比较老，或者相关的这个书啊，一个在国内说呢比较少，其次呢，这个书啊，也都是翻译成国外的，翻译国外的时候呢，也有个时间的一个差，对吧，也比较老，所以说呢，并没有引入咱们在垃圾回收器方面的一些新的变化，那这块呢，我们给大家讲解一下。首先这个J垃圾回收器呢，是咱们目前的house虚拟机当中的默认的垃圾回收器，也用了好几年了，但是未来呢，这个j for一定不是最终方案，我们这块呢，看到两个新的垃圾回收器，一个呢叫做ZJC。

在JDK11当中就已经引入过这个ZJC了啊，另外一个呢，就这叫神圳斗网。这个单词呢，特别难念是吧，这个我还特意的查了查，还特意的这个这个念了好几遍啊，这个身子豆啊，这是这是这什么情况呢，是什么个鬼呢是吧。搜还搜不出来了，查询一下。哎哟，真出来了，跑一下。回车。把这个呢，我们改成一个小写的。诶，错了，不行，CTRLV一下。这样是吧。啊，圣豆瓦啊，这个圣豆是啥呢？实际上是美国的一条河，嗯，所以呢，就拿着一个河呢来做了一个命名叫S啊这个呢，其实我就想起来一首歌啊，这个我也不知道，我怎么我就想起来这首歌了啊这首歌的话呢，大家不知道听过没有，应该是很经典的一首歌啊，叫John duer的，这个叫take me home country road。

啊，非常好听的一首歌啊，这个推荐给大家可以听一听，在这里边就提到了一个叫深圳这一首，这个这个河流，这就是我们以这个河流来来命名的一个，呃，垃圾回收器。那这块呢，我们想说的是什么呀，这个神啊，还是挺孤独的，嗯，还是挺孤独的，为啥呢？这个神nado啊，它是这个Oracle这个团队是吧，它在houseor当中，这个开发的这么多的垃圾回收器，那么深圳do啊，它是第一款非Oracle官方发布的垃圾回收器。啊，这是其一是吧，那其二的话呢，这个非官方发布的这哥们儿啊，非常受排挤。啊怎么讲大家还记不记得咱们给大家说过这样一个图啊说啊从这个JDK11的时候，嗯，这个官方呢，就说说Oracle jdk和open jdk啊说代码呢，就没有任何的区别了，大家呢，可以认为就是同一套代码，说的非常好听是吧，那我们会发现呢，在这个JDK12这个版本当中，咱们不是说引入了这叫神内多瓦是吧，这个垃圾回收器，但是呢，你会发现这个垃圾回收器呢，它只出现在了出现在了叫open jdk12当中。

并没有出现在这个官方的Oracle jdk当中，所以呢，我们这块就看到一个非常奇怪的一个特性哈，说呢，一般咱们都说Oracle jdk它是不免费的，那它的东西按说要多一些，但是现在你会发现呢，正好相反，Open jdk当中反而东西呢更多了啊，Oracle jdk反而更少了，是吧？诶就会出现这样的一个比较尴尬的一个局面啊。好，我们这块再回来，那么Oracle官方呢，不引入这个室内豆网，那你有更好的选择吗？有，就是我们这块提到的叫ZJC。这个ZJC也是咱们下一个新德性呢，想给大家介绍的啊，这呢我们就稍微的来说一下这个神度啊，因为毕竟呢，它未来呢，应该看到就是这个命度多舛是吧？啊，应该呢很够呛啊，能够能够为大家去使用。这个深圳豆呢，跟我们这个CDC啊，它都是主打的叫低停低停顿，这也是咱们未来的这个垃圾回收器的一个主要的一个参考标准，低停顿或我们叫低延迟啊都可以。

这个深圳呢，这个开发团队呢，在实际这个测试当中，我们会发现呢，跟咱们现有的这些经典的垃圾回收器相比，这个性能是不是还是非常可以的。对吧，但是你看这个数据呢，是非常不错的。非常华丽的数据，但是很遗憾呢，是不是有一个ZJC啊？好，那么这类C就是我们未来的最终解决方案。啊，也不知道人家这个ZJC是不是这样起的名啊，Z呢，是不是26个英文字母呢，是不是最后一个呀，嗯，我我自己猜的啊，那他叫ZJC呢，可能就是说ZJC呢，就是一个最终方案看可能是这个意思啊行，咱们下个新的性呢，来给大家讲解一下，这叫ZJC。