3.1 回收算法
由于网上已经拥有非常多的优秀博文来详细介绍关于回收算法这块，所以这块作者将引用其他博客的介绍并加上自己的一些描述:
3.1.1 标记清除算法(Mark-Sweep)
3.1.2复制算法(Coping)(绝大部分收集器的新生代使用的算法)
复制算法在JVM新生代垃圾回收中的运用:
Eden:From:TO =8:1:1
由于新生代中90%的对象都是"朝生夕死"，采用复制算法是比较合理的，首先只移动了存活下来的对象(比较少数),其次，内存在移动到To区域后是有顺序的，不存在内存碎片。
值得一提的是，假如在一次MinorGC时,Eden中存活的对象+From中存活的对象>To的剩余空间，则会通过担保机制将对象直接转移到Old gen ,如果Old gen的内存空间也不够，则进行一次Full gc .
当对象的年龄到达15岁时会转移到Old gen (可通过参数配置，一般不建议更改。)
3.1.3标记-整理算法(Mark-Compact):
由于Old gen 的大部分对象都是年龄很大的对象，所以存活率比较高，采用复制算法肯定是行不通的(较多的对象复制操作)，所以才大部分收集器的old gen采用 Mark-Compact算法，避免了空间碎片。
3.1.4三种算法比较：
稍微解释一下常见的关于GC时间的问题:
为什么FGC的时间比MinorGC长很多？
答:FGC进行了old gen的gc，由于算法上采用Mark-Sweep或者Mark-Compact，进行了很多对象(老年代存活率很低)的移动，当然很耗时了！其实就是空间换时间，时间换空间的问题。
3.2 HotSpot的具体实现-各种收
【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】 浏览器打开：qq.cn.hn/FTf 免费领取
集器
关于收集器这块，由于本人也是JVM初学者，加上很少有在生产环境做收集器参数调整，搭配使用的机会。所以可以说对于一些HotSpot收集器只是停留在
书籍与博文层次，所以这里就不卖弄了。下面给一个传送门大家自行看一看吧:
www.jianshu.com/p/50d5c88b2…
4 GC日志-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:/Users/zdy/Desktop/dump/gclog.txt
当服务器出现卡顿比较频繁时，尝试看下自己的GC日志，注意Full gc 频率。
最后，稍微说一下作者的心得:
-
如果是服务器一次卡顿时间比较长,一般是full gc时间过长，而应用最求的是卡顿(STW)时间短，可以接受多次卡顿，那么可以考虑调整加大young gen的比例，和提高进入老年代的年龄(默认15岁)来尽量避免FGC.
-
选择合适的收集器很重要。要根据应用的特点。是追求吞吐量，还是追求最小停顿。
-
经常对照gc日志观察现实的情况，如多长时间一卡顿，多久一卡顿，然后来调整自己的收集器或者相关的内存比例来达到自己想要的效果。
-
在有限的物理资源条件下，要避免让用户接受过多的STW，可以考虑在半夜自动进行gc(System.gc()),虽然不一定生效，但可以观察下效果。多数情况下是会触发full gc 的。
-
大多数应用是可以接受频繁的mgc，但却不能接受full gc 的长时间卡顿，所以在观察gc日志时一定要注意自己full gc的频率和触发条件(是由于内存担保，还是年龄到了，还是TO内存太小，导致每次都fgc.).
由于作者在gc这一块也不是特别厉害，并且缺少一定的实战经验，不敢妄自菲薄，所以给传送门供大家参考阅读:
www.jianshu.com/p/088d71f20…
www.cnblogs.com/mikevictor0…
www.cnblogs.com/mikevictor0…
我有一个微信公众号，经常会分享一些Java技术相关的干货；如果你喜欢我的分享，可以用微信搜索“Java团长”或者“javatuanzhang”关注。
ctor0…]( )
www.cnblogs.com/mikevictor0…
我有一个微信公众号，经常会分享一些Java技术相关的干货；如果你喜欢我的分享，可以用微信搜索“Java团长”或者“javatuanzhang”关注。
