垃圾回收器与内存分配策略
1.1 起源
Lisp是第一门开始使用内存动态分配和垃圾收集技术的语言
作者John McCarthy思考过垃圾收集需要完成的哪三件事？
- 哪些内存需要回收？
- 什么时候回收？
- 如何回收？
程序计数器、虚拟机栈、本地方法区随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出，有条不紊的执行着出栈和进栈的操作，这几个内存分配具有确定性，不需要考虑内存回收的问题
堆和方法区这两个区域则由很多的不确定性：一个接口的多个实现类内存需要可能不一样…
只有处于运行期间，我们才能知道程序创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器关注的正是这部分内存该如何存储
1.2 对象已死？
在堆中存放Java的所有对象实例，垃圾收集器在对堆进行回收前，第一件事就是要确定哪些对象是死的，哪些对象是存活的。
1.2.1 引用计数算法
判断对象是否存活的条件：在对象中添加一个引用计数器，每当有一个地方引用时，引用计数器+1，当引用失效时，引用计数器-1，任何时刻引用计数为零的对象就是不可能再被使用的
在其他语言中，有的使用了引用计数算法，但在Java中，我们就没有使用该算法，原因是：这个看似简单的算法，必须要配合大量的处理才能合理的运行，比如：对象之间的循环引用，基本无法解决
public class YinYong { public Object instance = null; public static void main(String[] args) { YinYong test1 = new YinYong(); YinYong test2 = new YinYong(); test1.instance = test2; test2.instance = test1; test1 = null; test2 = null; System.gc(); } }
关于上面这个循环引用的算法，《深入理解Java虚拟机》并没有介绍特别清楚，这里详细介绍一下
线程私有区
- 程序计数器：记录正在执行的虚拟机字节码的地址
- 虚拟机栈：方法执行的内存区，每个方法执行时都会在虚拟机栈中创建栈帧
- 本地方法栈：虚拟机的Native方法执行的内存区
线程共享区
- Java堆：对象分配的区域，这是垃圾回收的主要区域
- 方法区：存放着类信息、常量、静态变量等数据、常量池
1.2.2 可达性算法
算法思路：通过一系列成为"GC Roots"的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程中的路径被称为"引用链"，如果某个对象到GC Roots之间没有引用链连接的话或者图论也就是不可达，那么这个对象就可以被回收了
GC Root的对象：
- 虚拟机栈中引用的对象
- 方法区中类静态属性引用的对象
- 常量池中引用的对象
- 本地方法栈JNI，也就是Native引用的对象
1.2.3 四大引用
无论是引用计数法还是可达性分析，都离不开引用这个词，在Java中引用主要有强引用、软引用、弱引用、虚引用。
- 强引用—不回收、 StrongReference
对于强引用来说，是我们经常使用的大部分都是强引用，如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器不会回收它。当我们的空间不足时，JVM宁愿抛出OutOfMemoryError也就是内存溢出，让程序终止，也不会靠随意的回收具有强引用的对象来解决内存不足的问题
StringBuffer buffer = new StringBuffer(); StringBuffer buffer1 = buffer;
- 对于一个普通的对象，如果没有其他引用的关系，只要超过了引用的作用域或者将强引用赋值为null，就是可以当做垃圾被收集了
- 软引用—有用但非需、内存不足既回收、 SoftReference
- 内存足够时，不会回收软引用的可达对象
- 当内存不够时，就会进行回收可达对象，如果回收完之后，内存还不够，就会报OOM
user u1 = new user( 1,"songhk"); softReference<User> userSoftRef = new SoftReference<User>(u1); ul = null;
- 软引用通常实现缓存。比如：图片缓存和网页缓存用到软引用
如果还有空间，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同 时，不会耗尽内存 - 弱引用----发现既回收、WeakReference
弱引用也是用来描述那些非必需对象，只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。
例子：存储可有可无的数据：
WeakHashMap：内存不足时就会被回收，内部的Entry继承类WeakReference - 虚引用——对象回收跟踪、Phantom Reference
一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收
它不能单独使用，必须和引用队列（ ReferenceQueue ），当垃圾回收器准备回收对象时，如果发现他还有虚引用，就会在回收对象的回收之前，把这个虚引用加入到引用队列中，从而可以查看当前JVM垃圾回收的情况
1.2.4 finalize()方法
如果一个对象经过我们可达性算法的计算，判定为不可达的对象，并不是直接将其进行杀死 ，而是进入到一个缓刑的阶段
真正宣告一个对象是否死亡要经历两次标记过程：
- 如果对象在进行可达性分析后，发现对象不可达，则将会进行第一次标记，随后进行一次筛选，条件为：是否有必要执行finalize方法，如果对象没有重写finalize方法或者finalize已经被调用一次，JVM判定没有必要执行，直接进行回收
- 如果JVM判定有必要执行finalize的话，会将其放在一个F-Quene的队列中，并执行对象的finalize方法，同样JVM对队列中的对象进行标记。如果这时候对象的finalize方法中，将自己与引用链上的任何一个对象建立了联系，那样，JVM就会在第二次标记的时候将它移出“即将回收”的集合
建议：因为finalize方法的出现具有一定的戏剧色彩，为了使C、C++的程序猿更容易接受而做出的妥协
1.2.5 回收方法区
方法区主要回收两部分内容：废弃的常量和不再使用的类型
而对于一个类型是否被回收就比较困难，需要满足三个条件：
- 所有的实例都被回收，也就是堆中不存在该类和派生子类
- 加载该类的加载器也被回收（基本不可能达成）
- 该类在java.lang.Class对象没有在任何地方引用
1.3 垃圾回收算法
垃圾收集算法可以划分为”引用计数式垃圾收集“和”追踪式垃圾收集“
1.3.1 分代收集理论
两个假说：
- 弱分代假说：绝大多数的对象都是朝生夕灭的
- 强分代假说：熬过越多次垃圾收集过程的对象就越难以消亡
设计原则：收集器应该将Java堆划分不同的区域，然后将回收对象依据其年龄分配到不同的区域进行存储
设计者将堆分为新生代和老年代两个区域，本来这种想法挺好的，但是出现了一个问题，也就是对象之间会存在跨代引用
我们要对新生代的对象进行垃圾的收集，但某个对象引用了老年代中的数据，不得不再去遍历老年代中的对象来确保可达性分析结果的准确性
所以，为这个理论增添了第三条经验法则：
- 跨代引用假说：跨代引用相对于同代引用来说，仅占少数
基于这条假说，我们对于那些隔代引用的对象，不再去单独的扫描他们，而是将他们放在一个新生代记忆集的数据结构中
部分收集—Partial GC
- 新生代收集：目标是新生代的
- 老年代收集：目标是老年代的 CMS收集器
- 混合收集：目标整个新生代和部分老年代 G1收集器
整堆收集----Full GC：收集整个Java堆和方法区的垃圾收集
1.3.2 标记-清除算法
这是最早出现的垃圾清除算法
算法分为两个阶段：先对要回收的对象进行标记，然后再进行回收
缺点：
- 执行效率不稳定：堆中有大量对象，会进行大量的标记和清除
- 内部的碎片化问题：标记和清除之后会产生大量的不连续的内存碎片
1.3.3 标记-复制算法
半区复制的垃圾收集算法
将可用内存按容量划分为大小相等的两块，每次使用其中的一块，当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把使用过的内存空间一次性清理掉。
在1989年，提出了一种更加优化的半区复制算法，将新生代分成了一块较大的伊甸园区和两块较小的幸存区
每次分配内存只使用伊甸园和一块幸存区，发生垃圾收集时，将伊甸园和幸存区存活的对象一次性复制到另外一个幸存区，然后直接清理掉伊甸园和已用过的幸存区。
在新生代中的对象存活比较少，所以可以一次性复制到幸存区，但是如果万一超过了内存，怎么办？
需要依赖其他内存区域，也就是老年代进行内存分配担保
优点：不会产生内存碎片
缺点：内存间赋值开销 只有一半空间可用 空间浪费太多
1.3.4 标记-整理算法
标记过程仍然使用标记-清除，后序步骤将所有存活的对象都向内存空间一端移动，然后清理掉边界以外的内存
缺点：在每次移动的过程中，尤其是对老年代这种存活对象多的区域，会导致效率的降低
优点：没有了内存碎片的产生
