Java高级开发之走进JVM与GC

JVM简介

概念：JVM==Java Virtual Machin,意为Java虚拟机。
JVM是通过软件模拟Java字节码的指令集,JVM中只是主要保留了PC寄存器，其他的寄存器都进行了裁剪， JVM是一台被定制过的现实当中不存在的计算机。
.VMwave与VirtualBox是通过软件模拟物理CPU的指令集,物理系统中会有很多的寄存器

Java内存区域与内存溢出异常

JVM会在执行Java程序的过程中将他管理的内存分为若干个区域：

线程私有区域：程序计数器、Java虚拟机栈、本地方法栈
线程共享区域：Java堆、方法区、运行时常量池

线程私有区域详谈

程序计数器（pc）

是一块较小的内存空间，用来指示当前执行线程字节码执行的地址。若当前执行的是Native方法，则计数器值为空。

由于JVM的多线程是由CPU不断的分配CPU时间片段给不同的线程，因此一个处理器只会执行一条线程中的指令，因此切换线程后能恢复到正确的执行位置，每条线程都需要独立的程序计数器，各个线程间计数器互不影响，独立存储。

程序计数器内存区域是唯一一个在JVM规范中没有规定OOM(OutOfMemoryError）的区域。

Java虚拟机栈

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

虚拟机栈的局部变量表：存在了编译器可知的8种数据类型，对象引用。局部变量表所需的内存在编译期间完成分配，当进入一个方法时，这个方法在帧中分配局部变量空间的大小是完全确定的，不会改变。

Java虚拟机栈会产生的异常：

线程请求的栈（递归调用）的深度大于虚拟机能够允许的深度（1000-2000），会抛出StackOverFlowError异常
虚拟机在动态扩展时无法申请到足够的内存，会抛出OOM（OutOfMemoryError）

若是因为多线程导致的内存溢出问题，在不能减少线程数的情况下，只能减少最大堆（-Xmx参数设置）和减少栈容量（-Xss参数设置）的方式换取更多的线程。

本地方法栈

本地方法栈与虚拟机栈作用完全一样，区别在于本地方法栈为虚拟机使用native方法服务，而虚拟机栈为Java方法服务。

线程共享区域详谈

Java堆

Java堆是JVM所管理的最大的内存区域。Java堆是所有线程共享的一块区域，在Java启动时创建，存放的是对象实例(所有的对象实例和数组都要在堆上分配)。

Java堆是垃圾回收器管理的主要区域（GC堆），Java堆可以处于物理不连续的内存空间中，如果在堆中没有足够的内存完成实例分配并且也无法拓展时，将会抛出OOM

方法区（MateSpace）

用于存储已被Java虚拟机加载的类信息、常量、静态变量、即时编译i去编译后的代码等数据，在JDK8以前的HotSpot虚拟机中，方法区也被称为“永久代”，JDK8称为元空间。
此区域内存回收主要是针对常量池的回收以及对类型的卸载。
当方法区无法满足内存分配需求时，将抛出OOM

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

此区域是方法区的一部分，存放字面量（字符串、final常量、基本数据类型的值）与符号引用（类和结构的完全限定名、字段的名称和描述符、方法的名称和描述符）。

Java堆溢出

Java堆OOM异常是最常见的内存溢出，当异常信息提示"Java heap space"，则明确表示OOM发生在堆上。

内存泄漏：泄漏对象不能被GC
内存溢出：内存对象

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

程序计数器、虚拟机栈、本地方法栈的生命周期与相关线程有关，随线程生而生，死而死。这三个区域的内存分配与回收具有确定性，因为当线程结束，内存就跟着线程被回收了。

判断对象已死的三种方法

1.引用计数法：给对象增加一个引用计数器，每当有一个地方引用他时，计数器就加一，当引用失效就减一，任何时刻计数器为0的对象就是不能再被使用，判定对象已死。
python语言采用引用计数法进行内存管理。
但是引用计数法无法解决对象的循环引用问题。

2.可达性分析算法
Java（C#等语言）默认采用可达性分析算法判断对象是否已死。其核心思想是：通过一系列“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为"引用链"，当一个对象到GC Roots没有任何的引用链相连时，证明此对象是不可用的。

在Java中，可作为GC Roots的对象有：1.虚拟机栈中引用的对象2.方法区中类静态属性引用的对象3.方法区中常量引用的对象4.本地方法栈中native方法引用的方法

Java的引用分为四种：

1.强引用：类似于"Object obj = new Object()"，只要强引用存在，垃圾回收器就不会收掉被引用的对象实例。
2.软引用：对于软引用关联的对象，在系统将要发生内存溢出之前，会把这些对象列入回收范围之中进行第二次回收，如果这次回收还是没有足够的内存，才会抛出内存溢出异常。
3.弱引用：例如ThreadLocal中的key就是以弱引用的方式保存的。被弱引用的对象只能存活到下一次垃圾回收之前，当GC开始，无论当前内容是否够用，都会回收掉只被弱引用关联的对象。
4.虚引用：无法通过虚引用取得一个对象实例，因此一个对象是否有虚引用的存在不会对其生存时间构成影响。为一个对象设置虚引用的唯一目的就是能在对象回收前收到一个系统通知。

在可达性分析算法下的判定对象至少要经历两次标记过程：如果没有与GC Roots相连接的引用链将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否执行finalize()方法。当对象没有覆写或此方法已经被调用过了，那么此时的对象才是真正的“死”对象。
被判定要执行finalize()方法的对象会被放置在F-Queue的队列中，GC会对队列中的对象进行第二次标记，被标记上的对象被移除“即将回收”的集合。
任何一个对象的finalize()方法只会被调用一次

回收方法区

方法区（永久代）的垃圾回收主要收集两部分内容：废弃常量和无用的类

判定一个类是无用类的条件：
1.该类所有的实例都被回收
2.加载该类的ClassLoader已经被回收
3.该类对应的Class对象没有在任何地方被引用，无法通过反射访问该类的方法

垃圾回收算法

1.标记-清除算法
这是最基础的收集算法，需经历“标记”“清除”两个阶段的两次遍历。

算法缺点：1.效率不高2.产生大量不连续碎片，当需要一大片连续空间时就会出发另一次垃圾收集

2.复制算法（新生代回收算法）
他将可用内存划分为大小相等的两块，当其中一块需要垃圾回收时。会将此区域还或者的对象复制到另一块上，然后把已使用的内存一次性全清理。
此算法弥补了标记-清理算法的缺点，现在商用的虚拟机都采用此新生代回收算法来回收新生代，但是实际上并不是分为相等的两块空间，而是将新生代内存分为较大空间（Eden）和较小的两块空间（Survivor From，Survivor To)；Eden：Survivor From：Survivor To空间的大小比例大约为8：1：1.

每次只使用Eden和Survivor中的一块，当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor中，最后全部清理刚才用过的Eden和Survivor空间。
当Survivor空间不够时，需依赖其他内存（老年代）进行分配担保

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),终如果还是存活,就存入到老年代

3.标记整理算法（老年代回收算法）
复制收集算法在对象存活率较高时经历多次复制效率会很低，因此在老年一代不使用复制算法。
在标记整理算法中清理对象时让所有存活的对象都向一端移动，然后直接清理边界以外的内存。
4.分代收集算法
当前JVM垃圾收集都是采用的分代收集算法。将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倍以上。

垃圾收集器

并发：在单CPU中，多条垃圾收集线程并行工作，用户仍处于等待状态。
并行：在多核CPU中，用户线程与垃圾线程同时执行（不一定并行，可能交替执行），用户程序继续运行，而垃圾收集器在另一个CPU上。
吞吐量：吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）
GC停顿时间的缩短是以牺牲吞吐量和新生代空间作为代价的

七种垃圾收集器

Serial收集器（新生代收集器，串行GC）

特性：是单线程收集器，在进行垃圾收集时必须暂停其他工作线程直到它收集结束。
应用场景：在Client模式下默认的新生代收集器
注：Client模式：可开发桌面程序，但在JDK1.8中已取消
Server模式：服务器运行，不加载桌面程序

优势：简单高效

ParNew收集器（新生代收集器，并行GC）

特性：Serial收集器的多线程版本，除了Serial收集器外，目前只有它能与CMS收集器配合工作
应用场景：在Server模式下的虚拟机中首选的新生代收集

Parallel Scavenge收集器(新生代收集器,并行GC）

特性： Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器,具有GC自适应的调节策略（监控JVM状态，调整新生代与Survivor区域的比例；调整合适的停顿时间和吞吐量）Parallel Scavenge收集器也经常称为“吞吐量优先”收集器
应用场景：停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用 CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务
Parallel Scavenge收集器 VS ParNew收集器： Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略

Serial Old收集器(老年代收集器，串行GC）

特性： Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记－整理算法。
应用场景：
Client模式使用。
Server模式下：一种用途是在JDK 1.5以及之前的版本中与 Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生 Concurrent Mode Failure时使用

Parallel Old收集器(老年代收集器，并行GC）

特性： Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。

CMS收集器（老年代收集器，并发GC）

特性：基于标记清理算法，是一种以获取最短停顿时间为目标的收集器（响应速度高）
缺点：
占用线程，对CPU资源敏感； CMS默认启动的回收线程数是（CPU数量+3）/ 4
CMS收集器无法处理浮动垃圾（与CMS并行运行的用户线程产生的垃圾）
CMS收集器会产生大量空间碎片

CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作

Parallel Scavenge收集器 VS CMS等收集器： Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。

G1收集器(唯一一款全区域的垃圾回收器

G1（Garbage First）垃圾回收器是用在heap memory很大的情况下，把heap划分为很多很多的region块，然后并行的对其进行垃圾回收。
G1垃圾回收器在清除实例所占用的内存空间后，还会做内存压缩
在G1垃圾收集器中，年轻代的垃圾回收过程使用复制算法
对于老年代上的垃圾收集，G1垃圾收集器也分为4个阶段，基本跟CMS垃圾收集器一样，但略有不同。

七种收集器的配合关系