新生代java

A. 深入理解GC垃圾回收机制

在我们程序运行中会不断创建新的对象，这些对象会存储在内存中，如果没有一套机制来回收这些内存，那么被占用的内存会越来越多，可用内存会越来越少，直至内存被消耗完。于是就有了一套垃圾回收机制来做这件维持系统平衡的任务。

1.确保被引用对象的内存不被错误的回收
2.回收不再被引用的对象的内存空间

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时， 计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

优点：引用计数收集器可以很快地执行，交织在程序的运行之中。
缺点：很难处理循环引用，比如上图中相互引用的两个对象，计数器不为0，则无法释放，但是这样的对象存在是没有意义的，空占内存了。

引用计数法处理不了的相互引用的问题，那么就有了可达性分析来解决了这个问题。

从GC Roots作为起点，向下搜索它们引用的对象，可以生成一棵引用树，树的节点视为可达对象，反之最终不能与GC Roots有引用关系的视为不可达，不可达对象即为垃圾回收对象。

我自己的理解是，皇室家族每过一段时间，会进行皇室成员排查，从皇室第一代开始往下找血缘关系的后代，如果你跟第一代皇室没有关系，那么你就会被剔除皇室家族。

1.虚拟机栈中引用的对象（正在运行的方法使用到的变量、参数等）
2.方法区中类静态属性引用的对象（static关键字声明的字段）
3.方法区中常量引用的对象，(也就是final关键字声明的字段)
4.本地方法栈中引用的对象（native方法）

1.显示地赋予某个对象为null，切断可达性

在main方法中创建objectA、objectB两个局部变量，而且相互引用。相互引用直接调System.gc()是回收不了的。而将两者都置为null，切断相互引用，切断了可达性，与GCRoots无引用，那么这两个对象就会被回收调。

2.将对象的引用指向另一个对象

这里将one的引用也指向了two引用指向的对象，那么one原本指向的对象就失去了GCRoots引用，这里就判断该对象可被回收。

3.局部对象的使用

当方法执行完，局部变量object对象会被判定为可回收对象。

4.只有软、弱、虚引用与之关联
new出来的对象被强引用了，就需要去掉强引用，改为弱引用。被弱引用之后，需要置空来干掉强引用，达到随时可回收的效果。

只被软引用的对象在内存不足的情况，可能会被GC回收掉。

只被弱引用持有的对象，随时都可能被GC回收，该对象就为可回收对象。

是不是被判定为了可回收对象，就一定会被回收了呢。其实Ojbect类中还有一个finalize方法。这个方法是对象在被GC回收之前会被触发的方法。

该方法翻译过来就是：当垃圾回收确定不再有对该对象的引用时，由垃圾回收器在对象上调用。子类重写finalize方法以处置系统资源或执行其他清除。说人话就是对象死前会给你一个回光返照，让你清醒一下，想干什么就干什么，甚至可以把自己救活。我们可以通过重写finalize方法，来让对象复活一下。

示例：

执行的结果：

这里我们重写FinalizeGC类的finalize方法， 使用FinalizeGC.instance = this语句，让对象又有了引用，不再被判定为可回收对象，这里就活了。然后再置空再回收一下，这个对象就死了，没有再被救活了。所以finalize方法只能被执行一次，没有再次被救活的机会。

在JDK1.8版本废弃了永久代，替代的是元空间（MetaSpace），元空间与永久代上类似，都是方法区的实现，他们最大区别是：元空间并不在JVM中，而是使用本地内存。
元空间有注意有两个参数：

MetaspaceSize ：初始化元空间大小，控制发生GC阈值
MaxMetaspaceSize ： 限制元空间大小上限，防止异常占用过多物理内存
为什么移除永久代？
移除永久代原因：为融合HotSpot JVM与JRockit VM（新JVM技术）而做出的改变，因为JRockit没有永久代。
有了元空间就不再会出现永久代OOM问题了！

1.Generational Collection（分代收集）算法
分代收集算法是GC垃圾回收算法的总纲领。现在主流的Java虚拟机的垃圾收集器都采用分代收集算法。Java 堆区基于分代的概念，分为新生代（Young Generation）和老年代（Tenured Generation），其中新生代再细分为Eden空间、From Survivor空间和To Survivor空间。 (Survivor：幸存者)

分代收集算法会结合不同的收集算法来处理不同的空间，因此在学习分代收集算法之前我们首先要了解Java堆区的空间划分。Java堆区的空间划分在Java虚拟机中，各种对象的生命周期会有着较大的差别。因此，应该对不同生命周期的对象采取不同的收集策略，根据生命周期长短将它们分别放到不同的区域，并在不同的区域采用不同的收集算法，这就是分代的概念。

当执行一次GC Collection时，Eden空间的存活对象会被复制到To Survivor空间，并且之前经过一次GC Collection并在From Survivor空间存活的仍年轻的对象也会复制到To Survivor空间。

对象进入到From和To区之后，对象的GC分代年龄ege的属性，每经过GC回收存活下来，ege就会+1，当ege达到15了，对象就会晋级到老年代。

2.Mark-Sweep（标记-清除）算法
标记清除：标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。标记-清除算法主要是运用在Eden区，该区对象很容易被回收掉，回收率很高。

3.Copying（复制）算法
复制算法的使用在From区和To区，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。

缺点：可使用内存缩减为一半大小。

那么复制算法使可使用内存大小会减半，设计上是怎么解决这个问题的呢。就是给From和To区划分尽可能小的区域。经过大数据统计之后，对象在第一次使用过后，绝大多数都会被回收，所以能进入第一次复制算法的对象只占10%。那么设计上，Eden、From、To区的比例是8:1:1，绝大多数对象会分配到Eden区，这样就解决了复制算法缩减可用内存带来的问题。

4.Mark-Compact (标记—整理)算法
在新生代中可以使用复制算法，但是在老年代就不能选择复制算法了，因为老年代的对象存活率会较高，这样会有较多的复制操作，导致效率变低。标记—清除算法可以应用在老年代中，但是它效率不高，在内存回收后容易产生大量内存碎片。因此就出现了一种标记—整理算法，与标记—清除算法不同的是，在标记可回收的对象后将所有存活的对象压缩到内存的一端，使它们紧凑地排列在一起，然后对边界以外的内存进行回收，回收后，已用和未用的内存都各自一边。

垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现：
Serial 收集器（复制算法): 新生代单线程收集器，标记和清理都是单线程，
优点是简单高效；
Serial Old 收集器 (标记-整理算法): 老年代单线程收集器，Serial 收集器
的老年代版本；
ParNew 收集器 (复制算法): 新生代收并行集器，实际上是 Serial 收集器
的多线程版本，在多核 CPU 环境下有着比 Serial 更好的表现；
CMS(Concurrent Mark Sweep)收集器（标记-清除算法）： 老年代并行
收集器，以获取最短回收停顿时间为目标的收集器，具有高并发、低停顿
的特点，追求最短 GC 回收停顿时间。

B. Java垃圾回收：GC在什么时候对什么做了什么

GC在什么时候对什么做了什么？
要回答这个问题，先了解下GC的发展史、jvm运行时数据区的划分、jvm内存分配策略、jvm垃圾收集算法等知识。
先说下jvm运行时数据的划分，粗暴的分可以分为堆区(Heap)和栈区(Stack)，但jvm的分法实际上比这复杂得多，大概分为下面几块：
1、程序计数器(Program Conuter Register)
程序计数器是一块较小的内存空间，它是当前线程执行字节码的行号指示器，字节码解释工作器就是通过改变这个计数器的值来选取下一条需要执行的指令。它是线程私有的内存，也是唯一一个没有OOM异常的区域。
2、Java虚拟机栈区(Java Virtual Machine Stacks)
也就是通常所说的栈区，它描述的是Java方法执行的内存模型，每个方法被执行的时候都创建一个栈帧(Stack Frame)，用于存储局部变量表、操作数栈、动态链接、方法出口等。每个方法被调用到完成，相当于一个栈帧在虚拟机栈中从入栈到出栈的过程。此区域也是线程私有的内存，可能抛出两种异常：如果线程请求的栈深度大于虚拟机允许的深度将抛出StackOverflowError；如果虚拟机栈可以动态的扩展，扩展到无法动态的申请到足够的内存时会抛出OOM异常。
3、本地方法栈(Native Method Stacks)
本地方法栈与虚拟机栈发挥的作用非常相似，区别就是虚拟机栈为虚拟机执行Java方法，本地方法栈则是为虚拟机使用到的Native方法服务。
4、堆区(Heap)
所有对象实例和数组都在堆区上分配，堆区是GC主要管理的区域。堆区还可以细分为新生代、老年代，新生代还分为一个Eden区和两个Survivor区。此块内存为所有线程共享区域，当堆中没有足够内存完成实例分配时会抛出OOM异常。
5、方法区(Method Area)
方法区也是所有线程共享区，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。GC在这个区域很少出现，这个区域内存回收的目标主要是对常量池的回收和类型的卸载，回收的内存比较少，所以也有称这个区域为永久代(Permanent Generation)的。当方法区无法满足内存分配时抛出OOM异常。
6、运行时常量池(Runtime Constant Pool)
运行时常量池是方法区的一部分，用于存放编译期生成的各种字面量和符号引用。

垃圾收集(Garbage Collection)并不是Java独有的，最早是出现在Lisp语言中，它做的事就是自动管理内存，也就是下面三个问题：
1、什么时候回收
2、哪些内存需要回收
3、如何回收

1、什么时候回收？
上面说到GC经常发生的区域是堆区，堆区还可以细分为新生代、老年代，新生代还分为一个Eden区和两个Survivor区。
1.1 对象优先在Eden中分配，当Eden中没有足够空间时，虚拟机将发生一次Minor GC，因为Java大多数对象都是朝生夕灭，所以Minor GC非常频繁，而且速度也很快；
1.2 Full GC，发生在老年代的GC，当老年代没有足够的空间时即发生Full GC，发生Full GC一般都会有一次Minor GC。大对象直接进入老年代，如很长的字符串数组，虚拟机提供一个-XX:PretenureSizeThreadhold参数，令大于这个参数值的对象直接在老年代中分配，避免在Eden区和两个Survivor区发生大量的内存拷贝；
1.3 发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则进行一次Full GC，如果小于，则查看HandlePromotionFailure设置是否允许担保失败，如果允许，那只会进行一次Minor GC，如果不允许，则改为进行一次Full GC。

2、哪些内存需要回收
jvm对不可用的对象进行回收，哪些对象是可用的，哪些是不可用的？Java并不是采用引用计数算法来判定对象是否可用，而是采用根搜索算法(GC Root Tracing)，当一个对象到GC Roots没有任何引用相连接，用图论的来说就是从GC Roots到这个对象不可达，则证明此对象是不可用的，说明此对象可以被GC。对于这些不可达对象，也不是一下子就被GC，而是至少要经历两次标记过程：如果对象在进行根搜索算法后发现没有与GC Roots相连接的引用链，那它将会第一次标记并且进行一次筛选，筛选条件是此对象有没有必要执行finalize()方法，当对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用执行过一次，这两种情况都被视为没有必要执行finalize()方法，对于没有必要执行finalize()方法的将会被GC，对于有必要有必要执行的，对象在finalize()方法中可能会自救，也就是重新与引用链上的任何一个对象建立关联即可。

3、如何回收
选择不同的垃圾收集器，所使用的收集算法也不同。
在新生代中，每次垃圾收集都发现有大批对象死去，只有少量存活，则使用复制算法，新生代内存被分为一个较大的Eden区和两个较小的Survivor区，每次只使用Eden区和一个Survivor区，当回收时将Eden区和Survivor还存活着的对象一次性的拷贝到另一个Survivor区上，最后清理掉Eden区和刚才使用过的Survivor区，Eden和Survivor的默认比例是8：1，可以使用-XX:SurvivorRatio来设置该比例。
而老年代中对象存活率高，没有额外的空间对它进行分配担保，必须使用“标记-清理”或“标记-整理”算法。

C. majorgc触发条件

Major GC通常是跟full GC是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是old gen。

最简单的分代式GC策略，按HotSpot VM的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 mp带GC，默认也是触发full GC。
HotSpot VM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。
当然也总有例外。Parallel Scavenge（-XX:+UseParallelGC）框架下，默认是在要触发full GC前先执行一次young GC，并且两次GC之间能让应用程序稍微运行一小下，以期降低full GC的暂停时间（因为young GC会尽量清理了young gen的死对象，减少了full GC的工作量）。这是HotSpot VM里的奇葩嗯。

并发GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查old gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对old gen做并发收集。