JVM学习笔记(二)

10.垃圾收集器与内存分配策略
为什么要学习GC和内存分配:
当要排查各种内存溢出，内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要堆这些"自动化"
的技术实施必要的监控和调节。
哪些内存需要回收:
因为程序计数器，虚拟机栈，本地方法栈3个区域随着线程而生，随线程而灭，栈和栈帧随方法进入和退出而有条不紊得
进行入栈和出栈，每一个栈帧中分配多少内存是在类结构确定下来的时候就已知的，因此这几个区域就不需要过多考虑
回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了，而Java堆和方法区不一样，一个接口的多个实现类所需的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有程序处于运行期间时才知道会创建
哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的就是这部分内存。
11.引用计数算法
给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1，当引用失效时，计数器值就减1，任何时刻计数器为0的对象就是不可能再被使用的。客观地说，引用技术算法的实现简单，判断效率也很高，在大部分情况下是一个不错的算法，在python语言，游戏脚本领域被广泛使用了该算法进行内存管理，但是主流的Java虚拟机并没有使用该算法来管理内存，其中主要原样是它很难解决对象之间相互循环引用的问题。
12.可达性分析算法
在主流的商用程序语言(Java,C#)的主流实现中，都是通过可达性分析来判定对象是否存活的，这个算法的基本思想
是通过一系列的称为"GC Roots"的对象作为起点，从这些节点开始向下搜索，搜索的路径称为引用链，当一个对象
到GC Roots没有任何引用链，从图论的角度上来说也就是不可达时，则证明此对象是不可用的。
在Java语言中，可作为GC Roots的对象包括下面几种:
(1)虚拟机栈(栈帧中的本地变量表)中引用的对象
(2)方法区中类静态属性引用的对象
(3)方法区中常量引用的对象
(4)本地方法栈中JNI(即一般说的Native方法)引用的对象
13.引用
在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用四种，这4中引用的强度
依次逐渐减弱。
强引用:程序中普遍存在的，类似"Object obj=new Object()"这类引用，只要强引用还在，垃圾收集器永远不
会回收掉被引用的对象。
软引用:是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会
把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
弱引用:也是用来描述非必需对象的，但是强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生
之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了
WeakReference类来实现弱引用。
虚引用:也称幽灵引用或者幻影引用，是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过一个虚引用来取得一个实例对象。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2后，提供了PhantomReference类来实现虚引用。
14.对象的生存与死亡
即使在可达性分析算法中不可达的对象，也并非是"非死不可"，至少要经过两次标记过程。如果对象在进行可达性分析或发现没有与GC Roots相连接的引用链，那他将会被第一次标记并进行第一次筛选，筛选的条件是此对象是否有必要
执行finalize()方法。当对象没有覆盖finalize()方法，或这finalize()方法已经被虚拟机调用过，虚拟机将这
两种情况都视为"没有必要执行"。如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个
叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立，低优先级的Finalizer线程区执行它。这里的执行指的是虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是如果一个对象在finalize()方法中执行缓慢，
或者发生了死循环，将会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize方法是对象逃脱死亡命运的最后一次机会，稍后GC将对整个F-Queue中的对象进行第二次小规模的标记，如果对象要在
finalize方法中成功拯救自己，只要重新与引用链上的任何对象建立关联即可，譬如把自己的this关键字赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出"即将回收"的集合，如果这个对象这时候没有逃脱，那就基本上真的被回收了。但是并不推荐用这种方法来拯救对象，相反，应该尽量避免使用它，因为它运行代价高昂，不确定性大，无法保证各个对象的调用顺序，finalize可以做的所有工作，使用try-finally或者其他方式都可以做的更好，更及时。
15.回收方法区
Java虚拟机规范中确实说过可用不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的"性价比"一般比较低，在堆中，尤其在新生代中，常规应用进行依次垃圾收集一般可用回收70%-95%，而永久代的垃圾收集效率远低于此。
永久代的垃圾收集主要回收两部分内容:废弃常量和无用的类。
回收废弃常量与回收Java堆中的对象非常相似，如果一个常量进入了常量池，但是当前系统没有一个地方引用了这个字面量，如果发生内存回收的话，这个常量就会被系统清理出常量池。常量池中的其他接口，方法，字段的符号引用也
如此。
判断一个常量是否是"废弃常量"比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多，要同时满足下面3个条件才能算是"无用的类":
(1)该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何实例
(2)加载该类的ClassLoader已经被回收
(3)该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类方法
虚拟机可以对满足上面3个条件的无用类进行回收，但是并不是必然会回收，还需看虚拟机参数的控制。在大量使用反射，动态代理，CGBLib等ByteCode框架，动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
16.垃圾收集算法
(1)标记-清除算法
最基础的收集算法，算法分为"标记"和"清除"两个阶段:首先标记除所有需要回收的对象，在标记完成后统一回收所有
被标记的对象，它的主要不足有2个:第一是效率问题，标记和清除两个过程的效率都不高，另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后程序运行中需要分配较大对象时，无法找到足够的
连续内存而不得不提前触发另一此垃圾收集动作
(2)复制算法
复制算法有着很高的效率，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区的内
存进行内存回收，内存分配就不用再考虑内存碎片等复杂的情况，实现简单，运行高效，只是这种算法的代价是将内存
缩小为了原来的一般，也高了点。现在的商业虚拟机都采用这种收集算法来回收新生代，IBM公司研究表面，新生代中
百分之98的对象都是"朝生夕死"的，所以不需要按照"1:1"的比例来划分内存空间，而是将内存划分为一块较大的Eden
空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活
着的对象一次性复制到另一块Survivor，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor空间大小比例是8:1，也就是只有10%的内存会被浪费，当然98%的对象只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够时，需要以来其他内存(老年代)进行分配担保。
(3)标记-整理算法
复制算法在复活率较高时就要进行较多的复制操作，效率将会变低，更关键的是，如果不想浪费百分之50的空间，就需要有额外的空间进行分配担保，以应对被使用内存中的所有对象存活率百分之百的极端情况，所以老年代一般不能直接
选用这种算法。根据老年代的特点，有人提出了另一种标记-整理算法，标记过程仍然与"标记-清除"算法一样，但是后续的步骤不是直接堆可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。
(4)分代收集算法
当前商业虚拟机的垃圾收集都采用"分代收集"算法，这种算法并没有什么新的思想，只是根据对象存活周期不同将内存划分为几块，一般是把Java堆划分为新生代和老年代，这样就可用根据各个年代的特点采用最恰当的收集算法。在新生代中，每次垃圾收集时发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本
就可用完成收集。而老年代因对象存活率高，没有额外空间对它进行分配担保，就必须使用"标记-清除"算法或者"标记-整理"算法来进行回收。
17.枚举根节点
从可达性分析中GC Roots节点找引用这个操作为例，可作为GC Roots的节点主要在全局引用(例如常量或类静态属性)
与执行上下文(例如线栈中的本地变量表)中，现在很多应用仅仅方法区就有数百兆，如果逐个检查这里面的引用，那么
必然会消耗很多的时间。另外，可达性分析中对时间的敏感性还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行，这个一致性指在整个分析期间，整个执行系统看起来就像是被冻结在某个时间点上，不可用出现分析过程中还在不断变化的情况，该点不满足的话分析结果的准确性就无法保证。这点是导致GC进行时必须停顿所有Java
执行线程的其中一个重要原因，即使是号称几乎不会停顿的CMS收集器中，枚举根节点时也是必须要停顿的。目前主流的Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏得检查完所有执行上下文和全局引用
位置，在HotSpot中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用，这样，GC在扫描时就可以直接得知这些信息了。
18.安全点
在OopMap的协助下，HotSpot可用快速且准确地完成GC Roots枚举，但是当OopMap内容变化非常多，如果为每一条
指令都生成对应的OopMap，那么将会需要大量的空间，这样GC的空间成本将会变得很高。实际上，HotSpot也没有为每条指令都生成OopMap，只是在特定位置记录了这些信息，这些位置被称为"安全点",即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。Safepoint的选定既不能太少以致于让GC等待时间太长，也不能过于频繁以致于过分增大运行的负荷。所以安全点的选定基本是以"是否具有能让程序长时间执行的特性"为标准选定的，因为每条指令的执行时间都非常短暂，程序不可能因为指令长度太这个原因过长时间运行，"长时间执行"的明显特征
就是指令序列的复用，例如方法调用，循环跳转，异常跳转等，所以具有这些功能的指令才会产生Safepoint。
对于Safepoint，另一个需要考虑的问题是如何在GC发生时让所有的线程都"跑"到最近的安全点上再停顿下来，这里有两种方案可用选择:
(1)抢先式中断:
抢先式中断不需要线程的执行代码主动取配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它"跑"到安全点，现在几乎没有虚拟机实现采用这种方式暂停线程从而响应GC事件。
(2)主动式中断:
当GC需要中断线程的时候，不直接对线程操作，仅仅简单得设置一个标志，各个线程执行时主动取轮询这个标志，发现中断标志为真就自己中断挂起。轮询的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。当需要暂停线程时，线程执行到轮询指令时就会产生一个自陷异常信号，在预先注册的异常处理器中暂停线程实现等待。