【读书笔记】《深入理解Java虚拟机》

一、Java虚拟机运行时数据区

JVM会在执行Java程序的过程中把它管理的内存划分为若干个不同的数据区域。这些数据区域各有各的用处，各有各的创建与销毁时间，有的区域随着JVM进程的启动而存在，有的区域则依赖用户线程的启动和结束而创建与销毁。一般来说，JVM所管理的内存将会包含以下几个运行时数据区域：
线程私有区域:程序计数器、Java虚拟机栈、本地方法栈
线程共享区域:Java堆、方法区（包括运行时常量池）

1、程序计数器（线程私有）

程序计数器是一块比较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器。
如果当前线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是一个Native方法，这个计数器值为空。程序计数器内存区域是唯一一个在JVM规范中没有规定任何OOM情况的区域！

2、Java虚拟机栈（线程私有）

虚拟机栈描述的是Java方法执行的内存模型 : 每个方法执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应一个栈帧在虚拟机栈中入栈和出栈的过程。生命周期与线程相同。

此区域一共会产生以下两种异常:
1、如果线程请求的栈深度大于虚拟机所允许的深度(-Xss设置栈容量)，将会抛出StackOverFlowError异常。
2、虚拟机在动态扩展时无法申请到足够的内存，会抛出OOM(OutOfMemoryError)异常

3、本地方法栈（线程私有）

本地方法栈与虚拟机栈的作用完全一样，他俩的区别无非是本地方法栈为虚拟机使用的Native方法服务，而虚拟机栈为JVM执行的Java方法服务。 在HotSpot虚拟机中，本地方法栈与虚拟机栈是同一块内存区域。

4、Java堆（线程共享）

Java堆(Java Heap)是JVM所管理的大内存区域。Java堆是所有线程共享的一块区域，在JVM启动时创建。此内存区域存放的都是对象实例。JVM规范中说到:“所有的对象实例以及数组都要在堆上分配”。 Java堆是垃圾回收器管理的主要区域，因此很多时候可以称之为"GC堆"。根据JVM规范规定的内容，Java堆可以处于物理上不连续的内存空间中。Java堆在主流的虚拟机中都是可扩展的(-Xmx设置大值,-Xms设置小值)。
如果在堆中没有足够的内存完成实例分配并且堆也无法再拓展时，将会抛出OOM异常

5、方法区（线程共享）

方法区与Java堆一样，是各个线程共享的内存区域。它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。 在JDK8以前的HotSpot虚拟机中，方法区也被称为"永久代"(JDK8已经被元空间取代)。
永久代并不意味着数据进入方法区就永久存在，此区域的内存回收主要是针对常量池的回收以及对类型的卸载。
JVM规范规定：当方法区无法满足内存分配需求时，将抛出OOM异常。

6、运行时常量池（方法区的一部分）

运行时常量池是方法区的一部分，存放字面量与符号引用。
字面量 : 字符串(JDK1.7后移动到堆中) 、final常量、基本数据类型的值。
符号引用 : 类和结构的完全限定名、字段的名称和描述符、方法的名称和描述符。

二、OOM实例

1、Java堆溢出

Java堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免来GC清除这些对象，那么在对象数量达到大堆容量后就会产生内存溢出异常。

2、虚拟机栈和本地方法栈溢出

由于我们HotSpot虚拟机将虚拟机栈与本地方法栈合二为一，因此对于HotSpot来说，栈容量只需要由-Xss参数来设置。
关于虚拟机栈会产生的两种异常:

• 如果线程请求的栈深度大于虚拟机所允许的大深度，会抛出StackOverFlow异常
• 如果虚拟机在拓展栈时无法申请到足够的内存空间，则会抛出OOM异常

StackOverFlow异常：

OOM异常：

三、垃圾回收器与内存分配策略

1、如何判断对象已死？

引用计数法：

给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象已"死"。
在主流的JVM中没有选用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题

可达性分析算法（Java采用）：

通过一系列称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为"引用链"，当一个对象到GC Roots没有任何的引用链相连时(从GC Roots到这个对象不可达)时，证明此对象是不可用的。

在Java语言中，可作为GC Roots的对象包含下面几种：
1、虚拟机栈(栈帧中的本地变量表)中引用的对象
2、方法区中类静态属性引用的对象
3、方法区中常量引用的对象
4、本地方法栈中JNI(Native方法)引用的对象

2、方法区回收

方法区(永久代)的垃圾回收主要收集两部分内容 : 废弃常量和无用的类。
回收废弃常量和回收Java堆中的对象十分类似。以常量池中字面量(直接量)的回收为例，假如一个字符串"abc"已经进入了常量池中，但是当前系统没有任何一个String对象引用常量池的"abc"常量，也没有在其他地方引用这个字面量，如果此时发生GC并且有必要的话，这个"abc"常量会被系统清理出常量池。常量池中的其他类(接口)、方法、 字段的符号引用也与此类似。

判定一个类是否是"无用类"则相对复杂很多。类需要同时满足下面三个条件才会被算是"无用的类" :
1、该类所有实例都已经被回收(即在Java堆中不存在任何该类的实例)
2、加载该类的ClassLoader已经被回收
3、该类对应的Class对象没有在任何其他地方被引用，无法在任何地方通过反射访问该类的方法

3、什么时候进行回收？（对象的缓刑阶段-finalize()）

当一个对象被标记为不可达时，GC线程在回收时
1、若此对象所在的类没有覆写finalize方法，认为此对象不再存活
2、若此对象所在的类覆写finalize方法

• 2.1、且未被JVM调用，由JVM调用finalize方法
• 2.2、已被JVM调用，认为此对象不再存活

4、垃圾回收算法

标记-清除算法
"标记-清除"算法的不足主要有两个 :

1. 效率问题 : 标记和清除这两个过程的效率都不高
2. 空间问题 : 标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集。

复制算法（新生代回收算法）

新生代中98%的对象都是"朝生夕死"的，所以并不需要按照1 : 1的比例来划分内存空间，而是将内存(新生代内存) 分为一块较大的Eden(伊甸园)空间和两块较小的Survivor(幸存者)空间，每次使用Eden和其中一块Survivor（两个 Survivor区域一个称为From区，另一个称为To区域）。当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，后清理掉Eden和刚才用过的Survivor空间。 当Survivor空间不够用时，需要依赖其他内存(老年代)进行分配担保。

HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说Eden:Survivor From : Survivor To = 8:1:1。所以每次新生代可用内存空间为整个新生代容量的90%,而剩下的10%用来存放回收后存活的对象。 HotSpot实现的复制算法流程如下:

1. 当Eden区满的时候,会触发第一次Minor gc,把还活着的对象拷贝到Survivor From区；当Eden区再次触发Minor gc的时候,会扫描Eden区和From区域,对两个区域进行垃圾回收,经过这次回收后还存活的对象, 则直接复制到To区域,并将Eden和From区域清空。
2. 当后续Eden又发生Minor gc的时候,会对Eden和To区域进行垃圾回收,存活的对象复制到From区域,并将 Eden和To区域清空。
3. 部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这 个参数默认是15),终如果还是存活,就存入到老年代

标记-整理算法（老年代回收算法）
复制收集算法在对象存活率较高时会进行比较多的复制操作，效率会变低。因此在老年代一般不能使用复制算法。
针对老年代的特点，提出了一种称之为"标记-整理算法"。标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法
当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法并没有新思想，只是根据对象存活周期的不同将内存划分为几块。
一般是把Java堆分为新生代和老年代。在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采 用复制算法；而老年代中对象存活率高、没有额外空间对它进行分配担保，就必须采用"标记-清理"或者"标记-整 理"算法。

面试题 : 请问了解Minor GC和Full GC么，这两种GC有什么不一样吗

1. Minor GC又称为新生代GC : 指的是发生在新生代的垃圾收集。因为Java对象大多都具备朝生夕灭的特 性，因此Minor GC(采用复制算法)非常频繁，一般回收速度也比较快。
2. Full GC 又称为 老年代GC或者Major GC : 指发生在老年代的垃圾收集。出现了Major GC，经常会伴随 至少一次的Minor GC(并非绝对，在Parallel Scavenge收集器中就有直接进行Full GC的策略选择过程)。 Major GC的速度一般会比Minor GC慢10倍以上。

5、垃圾回收器

Serial收集器（新生代收集器,串行GC）
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程 去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束 (Stop The World)

ParNew收集器（新生代收集器,并行GC）
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收 集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样， 在实现上，这两种收集器也共用了相当多的代码。

Parallel Scavenge收集器（新生代收集器,并行GC）
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。

Serial Old收集器（老年代收集器，串行GC）
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记－整理算法。

Parallel Old收集器（老年代收集器，并行GC）
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。

CMS收集器（老年代收集器，并发GC）
CMS（Concurrent Mark Sweep）收集器是一种以获取短回收停顿时间为目标的收集器。目前很大 一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

G1收集器（唯一一款全区域的垃圾回收器）
G1是一款面向服务端应用的垃圾回收器，具备并发与并行、空间整合、分代收集、可预测的停顿的特点。

6、JDK内置的JVM工具

jps

查看当前操作系统下，所有的JVM进程，返回进程ID

jstack

一般使用：jstack pid -l
查看指定JVM进程的线程堆栈情况（一般多线程卡死使用此工具定位问题）

jmap

查看指定JVM的内存情况