JVM系列之GC

JVM系列之GC

谈到JVM，你们都知道GC(Garbage Collection),GC这个话题说浅了就一句话--JVM自动垃圾收集，说深了就无止尽了，回收算法，各类收集器，gc类型,gc触发点....等等，做者也是略懂皮毛，这里给你们推荐一个知乎上比较活跃的JVM大牛，RednaxelaFX，是专门作JVM开发的，业界号称"R大"。放个传送门:R大
鉴于做者才学疏浅，这篇博文仍是准备用通熟易懂的话把做者本身对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收集器只是停留在
书籍与博文层次，因此这里就不卖弄了。下面给一个传送门你们自行看一看吧:
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…