CMS收集器：老年代收集器， 一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。 CMS收集器就非常符合这类应用的需求。 CMS收集器是基于标记-清除算法实现的，他的运作过程相对于其他收集器来说复杂一些： 包括： 1.初始标记 2.并发标记 3.重新标记 4.并发清除 其中初始标记、重新标记这两个步骤仍然需要“Stop The World”，初始标记仅仅知识标记以下GCRoots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾手机线程一起并发运行；而重新标记阶段是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，多以这个阶段也是可以与用户线程同时并发的。 由于整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。 CMS（并发低停顿收集器） CMS三个明显的缺点： 1.CMS收集器对处理器资源非常敏感 2.CMS收集器无法处理“浮动垃圾"，有可能出现”Concurrent Mobile failure"失败而导致另一次完全“Stop The World”的FullGC的产生。 3.CMS是一款基于“标记-清除”算法实现的收集器，会产生大量的空间碎片。
G1收集器： 收集器面向局部收集的设计四路和基于Region的内存布局形式， Java9发布之后，G1宣告取代Parallel Scavenge和ParallelOld组合，称为服务端模式下的默认垃圾收集器， G1垃圾回收时，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。 G1开创的基于Region的堆内存布局是他能够实现这个目标的关键。虽然G1也仍是遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域，每个Region都可以根据需要，扮演新生代的Eden空间，Survior空间或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间，熬过多次手机的就对象都能获取很好的手机效果。
G1之所以能建立可预测的停顿时间模型，是因为他将Region作为单词回收的最小单元，即每次收集到的内存空间都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾手机。 优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来 ， G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部（两个Region之间）上看又是基于“标记-复制”算法实现，运作期间不会产生内存空间碎片，垃圾收集完成之后能提供规整的可用内存。这种特性有利于程序长时间运行，在程序为大对象分配内存时不容易因无法找到连续内存空间而提前出发下一次收集 。 用户运行过程中，G1无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载都要比CMS要高。 小内存应用上，CMS的表现大概率优于G1 大内存应用上，G1则大多能发挥其优势
Java1.7之前运行时常量池逻辑包含字符串常量池，存放在方法区，从此hotspot虚拟机对方法区的实现为永久代 Java1.7中，字符串常量池被从方法去拿到了堆区，这里没有提到运行时常量区，也就是说字符串常量池被单独拿到堆，运行时常量池剩下的东西还在方法区，也就是hotspot中的永久代。 Java1.8中hostspot移除了永久代用原空间取而代之，这时候字符串常量池还在堆，运行时常量池还在方法去，只不过方法区的实现从永久代变成了元空间。
CMS收集器：老年代收集器， 一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。 CMS收集器就非常符合这类应用的需求。 CMS收集器是基于标记-清除算法实现的，他的运作过程相对于其他收集器来说复杂一些： 包括： 1.初始标记 2.并发标记 3.重新标记 4.并发清除 其中初始标记、重新标记这两个步骤仍然需要“Stop The World”，初始标记仅仅知识标记以下GCRoots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾手机线程一起并发运行；而重新标记阶段是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，多以这个阶段也是可以与用户线程同时并发的。 由于整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。 CMS（并发低停顿收集器） CMS三个明显的缺点： 1.CMS收集器对处理器资源非常敏感 2.CMS收集器无法处理“浮动垃圾"，有可能出现”Concurrent Mobile failure"失败而导致另一次完全“Stop The World”的FullGC的产生。 3.CMS是一款基于“标记-清除”算法实现的收集器，会产生大量的空间碎片。
G1收集器： 收集器面向局部收集的设计四路和基于Region的内存布局形式， Java9发布之后，G1宣告取代Parallel Scavenge和ParallelOld组合，称为服务端模式下的默认垃圾收集器， G1垃圾回收时，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。 G1开创的基于Region的堆内存布局是他能够实现这个目标的关键。虽然G1也仍是遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域，每个Region都可以根据需要，扮演新生代的Eden空间，Survior空间或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间，熬过多次手机的就对象都能获取很好的手机效果。
G1之所以能建立可预测的停顿时间模型，是因为他将Region作为单词回收的最小单元，即每次收集到的内存空间都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾手机。 优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来 ， G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部（两个Region之间）上看又是基于“标记-复制”算法实现，运作期间不会产生内存空间碎片，垃圾收集完成之后能提供规整的可用内存。这种特性有利于程序长时间运行，在程序为大对象分配内存时不容易因无法找到连续内存空间而提前出发下一次收集 。 用户运行过程中，G1无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载都要比CMS要高。 小内存应用上，CMS的表现大概率优于G1 大内存应用上，G1则大多能发挥其优势
Java1.7之前运行时常量池逻辑包含字符串常量池，存放在方法区，从此hotspot虚拟机对方法区的实现为永久代 Java1.7中，字符串常量池被从方法去拿到了堆区，这里没有提到运行时常量区，也就是说字符串常量池被单独拿到堆，运行时常量池剩下的东西还在方法区，也就是hotspot中的永久代。 Java1.8中hostspot移除了永久代用原空间取而代之，这时候字符串常量池还在堆，运行时常量池还在方法去，只不过方法区的实现从永久代变成了元空间。