垃圾回收g1java_java垃圾回收-G1

为什么分代算法： 90%对象熬不过第一次回收；而老对象有98%的概率会一直存活下来

分代好处：把复杂的大问题，分成两类不同的小问题，针对不同的小问题，针对性的分而治之

--年轻代，对象来去频繁，执行时间一定要短、效率要高，采用标记-整理、copy算法，以空间换时间， 默认比例：8：1

--老年代，对象不多，次数不频繁，采用内存使用比较高效的算法

G1垃圾回收器， 是JDK7的特性， garbage first，即优先处理垃圾多的内存块

--G1将内存划分成很多小块，每个小块会被标记为E/S/O中的一个(共三大类，不在泾渭分明)

--垃圾回收过程：

---先短暂停止应用-stop the world 做初始标志

---继续应用，开始并行标记-concurrent mark

---再次停止应用，进行final mark 标记并发标记过程中产生的新垃圾

---根据G1原则，选择部分内存片进行回收-stop the world

G1的一个显著特点就是用户设置暂停时间，G1能够做到的原因：G1的第4步，是选择一些内存块，而不是整代内存回收(其他GC都是回收整个generation的内存，而回收内存所需的时间取决于内存的大小，以及实际的垃圾大小，所有回收时间是不可控的)，而G1每次不回收整代内存，到底回收多少依赖用户配置的时间，配置的时间短就少回收点，配置的时间长就多回收点，伸缩自如。

优点：内存分成多块，进行内存整理和压缩的代价比较小，可有效规避内存碎片的问题

缺点：如果内存吃紧，对内存的部分回收根本不够，仍需要整代回收，那么工作量一点没有减少，还有因为本身算法复杂，回收性能变差

-G1适合内存稍大一点的应用(一般来说至少4G以上)，小内存的应用还是用传统的垃圾回收器比如CMS比较合适

-G1最显著与CMS的，在于它对空间做了整理，减少了空间的碎片化

G1可以基本稳定在0.5S到1S左右的延迟

GC的一些建议：

1. 尽早释放无用对象的引用，大多是使用临时变量时，都是让引用变量退出活动域后，自动设置为null，如果程序运行，尽早将引用对象赋为null，加速gc工作；

2. 尽量少用finalize函数： 为支持finalize函数，GC额外做了大量工作；finalize后，对象仍有可能可达，使用finalize会降低GC运行性能；GC调用finalize的时间是不确定的，通过这种方式释放资源也是不确定的; (当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。否则，若对象未执行过finalize方法，将其放入F-Queue队列，由一低优先级线程执行该队列中对象的finalize方法。执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活”)

3. 如果经常使用图片，可以使用soft应用，能够尽可能将图片保持在内存中，供程序调用，而不引起OutOfMemory

4. 集合数据类型的回收更为复杂，还需要注意全局变量，以及一些静态变量，容易引起悬挂对象，造成资源浪费

5. 手动执行System.gc()，通知GC运行，但是java规范并不保证GC一定会执行，可使用增量式GC缩短暂停时间

(增量式GC就是通过一定的回收算法，把一个长时间的中断，划分为很多个小的中断，通过这种方式减少GC对用户程序的影响。虽然，增量式GC在整体性能上可能不如普通GC的效率高，但是它能够减少程序的最长停顿时间。 )

GC调优指标：

程序的吞吐量，GC对程序效率的影响，也就是花费在GC的时间和程序处理正常业务的时间比

GC吞吐量： 单位时间内垃圾回收梳理

暂停时间： Stop the world的时间， STW

GC常用算法

标记-清除：不需要挪动位置，但会产生碎片，效率也比较低-所有对象标记阶段遍历一遍，清除阶段扫描一遍

标记-压缩(整理)：是标记清除的改进版，对所有存活对象整理，剩余对象清除。 不会产生碎片，但是整理阶段较多复制操作，算法效率低

复制：内存分成两部分，素有存活队形复制到另一个内存中；不产生碎片，内存浪费

分代： 新生代和老年代， 见参考文献-【JAVA核心】Java GC机制详解