学习《深入理解Java虚拟机》时个人的理解笔记

1、为什么要去了解垃圾收集和内存回收技术？

当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节。

2、“哲学三问”内存收集

what？when？how？

1. 那些内存需要回收？
2. 什么时候回收？
3. 如何回收？

这是一个整体的问题，确定了什么状态的内存可以回收，才可以在内存“死”掉时及时地回收它们。只有了解了“死”掉内存的特性，才可以确定合理的回收方式。

3、如何确定内存已经“死”掉呢？

在Java的世界，内存承载的都是对象，内存的“死”去，代表着对象的“死”去，即对象不再被需要了（任何途径都再能使用到了）。

这里有两种方式去确定：

3.1、引用计数算法（Reference Counting）

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

然而：

在Java领域，至少主流的Java虚拟机里面都没有选用引用计数来管理内存，主要原因是，这个看似简单的算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。

3.1、可达性分析算法（Reachability Analysis）

基本思路：通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象时不可能再被使用的。

Java技术系统下，作为GC Roots的对象：

1. 在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
2. 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
3. 在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
4. 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
5. Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointException、OutOfMemoryError）等，还有系统类加载器。
6. 所有被同步锁（synchronized关键字）持有的对象。
7. 反映Java虚拟机内部情况的JMXBean、JVMTI中的注册的回调、本地代码缓存等。

4、那些内存需要回收呢？

根据Java虚拟机规范，当一个台Java虚拟机运行起来时，其主要内存区域有如下：

线程共享

• 方法区（Method Area）
• 堆（Heap）

线程隔离

• 虚拟机栈（VM Stack）
• 本地方法栈（Native Method）
• 程序计数器（Program Counter Register）

当然还有其他一些，但是这些并不直接和客户程序关联，暂时不关心。

线程隔离的区域，虚拟机栈、本地方法栈、程序计数器在线程产生时写入内存，在线程结束时自动回收，一般不需要太多管理。

线程共享的区域：

• 方法区

在Java虚拟机规范中没有要求必须实现垃圾收集，本身的回收率也不高。但是也可以进行回收的。其回收的主要内容为：废弃的常量和不再使用的类型。

• 堆（Heap）

这里才是Java世界中，回收的主要战场。

5、何如进行垃圾收集呢？

从如何判定对象的消亡角度，收集算法可以划分为“引用计数式来垃圾收集（Reference Counting GC）”和“追踪式垃圾收集（Trace Counting GC）”。同判定对象“死亡”一样。我们主要关注在后者。

遵循分代收集理论去设计垃圾收集器。
理论假说：

1. 弱分代假说（Weak Generational Hypothesis）：绝大部分对象都是朝生夕灭的。
2. 强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消灭。

扩展
3. 跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极少数。

基于分代收集理论的三种收集算法。

• 标记-清除算法
• 标记-复制算法
• 标记-整理算法

如下图：

6、一句理解垃圾收集

主要发生在堆中，不可达对象，通过收集算法进行回收。

参考

《深入理解Java虚拟机》第三版，周志明著。