JVM系列之GC

JVM系列之GC

谈到JVM，大家都知道GC(Garbage Collection),GC这个话题说浅了就一句话--JVM自动垃圾收集，说深了就无止尽了，回收算法，各种收集器，gc类型,gc触发点....等等
鉴于作者才学疏浅，这篇博文还是准备用通熟易懂的话把作者自己对GC这一块的理解做陈述，概要如下:

文章结构

1. 哪些内存需要回收(Which)
2. 各种GC的触发时机(When)
3. 如何回收(How)
   3.1 回收算法
   3.2 HotSpot的具体实现-各种收集器
4. GC日志

1. 哪些内存需要回收(Which)

大多数没干过C或者C++的Javaer是幸福的，因为没有体会过那种自己new delete内存的感觉，创建对象就是new,不管内存的回收问题。其实我们的内存是JVM的GC机制来帮我们回收的。那么问题来了。到底哪些内存需要回收呢？
答案:可达性分析算法,说白了，就是JVM预先确定一组GC roots引用变量，如Student stu =new Student();这个stu就可以作为GC roots,当进行垃圾回收时，JVM通过GC Roots找到能够引用到的所有活对象,然后把剩下的对象标记为"无用",即可回收状态！
能够作为GC roots的引用如下:

• 所有Java线程当前活跃的栈帧里指向GC堆里的对象的引用；换句话说，当前 所有正在被调用的方法的引用类型的参数/局部变量/临时值。
• VM的一些静态数据结构里指向GC堆里的对象的引用，例如说HotSpot VM里的Universe里有很多这样的引用。
• JNI handles，包括global handles和local handles（看情况）所有当前被加载的Java类（看情况）Java类的引用类型静态变量（看情况）Java类的运行时常量池里的引用类型常量（String或Class类型）（看情况）String常量池（StringTable）里的引用

2. 各种GC的触发时机(When)

2.1 GC类型

说到GC类型，就更有意思了，为什么呢，因为业界没有统一的严格意义上的界限，也没有严格意义上的GC类型，都是左边一个教授一套名字，右边一个作者一套名字。为什么会有这个情况呢，因为GC类型是和收集器有关的，不同的收集器会有自己独特的一些收集类型。所以作者在这里引用R大关于GC类型的介绍，作者觉得还是比较妥当准确的。如下:

• Partial GC：并不收集整个GC堆的模式
  • Young GC(Minor GC)：只收集young gen的GC
  • Old GC：只收集old gen的GC。只有CMS的concurrent collection是这个模式
  • Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式
• Full GC(Major GC)：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等所有部分的模式。

2.2 触发时机

上面大家也看到了，GC类型分分类是和收集器有关的，那么当然了，对于不同的收集器，GC触发时机也是不一样的，作者就针对默认的serial GC来说:

• young GC：当young gen中的eden区分配满的时候触发。注意young GC中有部分存活对象会晋升到old gen，所以young GC后old gen的占用量通常会有所升高。
• full GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（因为HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，所以不需要事先触发一次单独的young GC）；或者，如果有perm gen的话，要在perm gen分配空间但已经没有足够空间时，也要触发一次full GC；或者System.gc()、heap dump带GC，默认也是触发full GC。

3. 如何回收(How)

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的具体实现-各种收集器

关于收集器这块，由于本人也是JVM初学者，加上很少有在生产环境做收集器参数调整，搭配使用的机会。所以可以说对于一些HotSpot收集器只是停留在
书籍与博文层次

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.).

如果您觉得这篇文章对你有帮助，请点赞或者喜欢，让更多的人看到！祝你每天开心愉快！