JVM小结

时间 2019-11-07

标签 jvm 小结栏目 Java 繁體版

原文原文链接

1. JVM

1.1 Java内存区域划分

1.1.1 线程共享

堆
1. Java虚拟机所管理的内存中最大的一块，Java堆是全部线程共享的一块内存区域，在虚拟机启动时建立。此内存区域的惟一目的就是存放对象实例，几乎全部的对象实例以及数组都在这里分配内存。
2. 垃圾收集器管理的主要区域，亦称“GC堆”
方法区

它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。也被称为Non-Heap（非堆），永久代html
- 方法区和永久代的关系
  
  方法区和永久代的关系很像Java中接口和类的关系，类实现了接口，而永久代就是HotSpot虚拟机对虚拟机规范中方法区的一种实现方式。java
- 运行时常量池
  
  运行时常量池是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有常量池信息（用于存放编译期生成的各类字面量和符号引用）。 JDK1.7及以后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。程序员
直接内存
- 为何要将永久代(PermGen)替换为元空间(MetaSpace)呢?
  
  整个永久代有一个 JVM自己设置固定大小上限，没法进行调整，而元空间使用的是直接内存，受本机可用内存的限制。你可使用
  -XX：MaxMetaspaceSize标志设置最大元空间大小，默认值为unlimited，这意味着它只受系统内存的限制。
  -XX：MetaspaceSize调整标志定义元空间的初始大小若是未指定此标志，则Metaspace将根据运行时的应用程序需求动态地从新调整大小。面试

1.1.2 线程私有

程序计数器

程序计数器是一块较小的内存空间，能够看做是当前线程所执行的字节码的行号指示器。算法
- 做用
  1. 字节码解释器经过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
  2. 在多线程的状况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候可以知道该线程上次运行到哪儿了。
- 注意
  
  程序计数器是惟一一个不会出现 OutOfMemoryError 的内存区域。数组
虚拟机栈

虚拟机描述的是Java方法执行的内存模型，每次方法调用的数据都是经过栈传递的。缓存
- 栈帧
  
  用于存储局部变量表、操做数栈、动态连接、方法出口等信息。安全
- 局部变量表
  1. 基本数据类型；
  2. long和double会占用2个局部变量空间；
  3. 对象引用；
  4. returnAddress。
- 会抛出的两个异常
  1. Stack OverflowError 若Java虚拟机栈的内存大小不容许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度的时候，就抛出StackOverFlowError异常。
  2. OutOfMemoryError 若 Java 虚拟机栈的内存大小容许动态扩展，且当线程请求栈时内存用完了，没法再动态扩展了，此时抛出OutOfMemoryError异常。
本地方法栈

和虚拟机栈所发挥的做用很是类似，区别是：虚拟机栈为虚拟机执行 Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务服务器

1.2 Java虚拟机对象

1.2.1 对象的建立

对象的建立过程 数据结构
类加载检查

虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，而且检查这个符号引用表明的类是已被加载过、解析和初始化过。若是没有，那必须先执行相应的类加载过程。
分配内存
- 指针碰撞
  1. 原理用过的内存所有整合到一边，没有用过的内存放在另外一边，中间有一个分界值指着，只须要向着没用过的内存方向将指针移动对象内存大小位置便可
  2. 适合场景 堆内存规整（即没有内存碎片的状况下）
  3. GC收集器 Serial、ParNew等带compact过程的垃圾收集器
- 空闲列表
  1. 原理 JVM会维护一个列表，记录有哪些内存块是可用的，在分配的时候，找一块足够大的内存块来划分给对象实例，最后更新列表记录
  2. 适合场景 堆内存不规整的状况下
  3. GC收集器 CMS
- 注意选择以上两种方式中的哪种，取决于 Java 堆内存是否规整。而 Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，仍是"标记-整理"（也称做"标记-压缩"），值得注意的是，复制算法内存也是规整的.
- 分配内存过程当中的并发问题
  在建立对象的时候有一个很重要的问题，就是线程安全，由于在实际开发过程当中，建立对象是很频繁的事情，做为虚拟机来讲，必需要保证线程是安全的，一般来说，虚拟机采用两种方式来保证线程安全：
  1. CAS+失败重试 保证更新操做的原子性
  2. TLAB 为每个线程预先在Eden区分配一起内存，JVM在给线程中的对象分配内存时，首先在TLAB分配，当对象大于TLAB中的剩余内存或TLAB的内存已用尽时，再采用上述的CAS进行内存分配
初始化零值

内存分配完成后，虚拟机须要将分配到的内存空间都初始化为零值（不包括对象头），这一步操做保证了对象的实例字段在 Java 代码中能够不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
设置对象头

初始化零值完成以后，虚拟机要对对象进行必要的设置，例如这个对象是哪一个类的实例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC 分代年龄等信息。这些信息存放在对象头中。另外，根据虚拟机当前运行状态的不一样，如是否启用偏向锁等，对象头会有不一样的设置方式。
执行init方法

在上面工做都完成以后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象建立才刚开始，方法尚未执行，全部的字段都还为零。因此通常来讲，执行 new 指令以后会接着执行方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算彻底产生出来。

1.2.2 对象的内存布局

对象在内存中存储的布局能够分为3块区域
1. 对象头
  - Mark Word 用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等
  - 类型指针 即对象指向它的类元数据的指针，虚拟机经过这个指针来肯定这个对象是哪一个类的实例。
  - 数组长度（若是该对象是一个数组）
2. 实例数据 对象真正存储的有效信息
3. 对象对齐 对象对齐并非必然存在的，也没有特别的含义，它仅仅起着占位符的做用

1.2.3 对象的访问定位

创建对象就是为了使用对象，咱们的Java程序经过栈上的 reference 数据来操做堆上的具体对象。对象的访问方式有虚拟机实现而定，目前主流的访问方式有①使用句柄和②直接指针两种：

句柄

若是使用句柄的话，那么Java堆中将会划分出一块内存来做为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息；

直接指针

若是使用直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference 中存储的直接就是对象的地址。

这两种对象访问方式各有优点。使用句柄来访问的最大好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而 reference 自己不须要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。

1.3 OOM异常及应对方法

1.3.1 Java堆内存溢出（Java heap space）

解决办法：可经过调整堆参数（-Xmx，-Xms）或经过内存映象分析工具

1.3.2 虚拟机栈和本地方法栈溢出

关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常
- 若是线程请求的栈深度大于虚拟机所容许的最大深度，将抛出StackOverflowError异常
- 若是虚拟机在扩展栈时没法申请到足够的内存空间，则抛出OutOfMemoryError异常
若是是创建过多线程致使的内存溢出，在不能减小线程数或者更换64位虚拟机的状况下，就只能经过减小最大堆（-Xmx）和减小栈容量（-Xss）来换取更多的线程。

1.3.3 方法区和运行时常量池溢出（PermGen space）

动态生成大量Class的场景
- CGLib字节码加强和动态语言
- 大量JSP或动态产生JSP文件的应用（JSP第一次运行时须要编译为Java类）
- 基于OSGi的应用（即便是同一个类文件，被不一样的加载器加载也会视为不一样的类）

1.3.4 本机直接内存溢出

DirectMemory容量可经过-XX：MaxDirectMemorySize指定，若是不指定，则默认与Java堆最大值相同

1.4 虚拟机类加载机制

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析、链接和初始化，最终造成能够被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

1.4.1 类加载的时机

类的生命周期
加载、验证、准备、初始化和卸载这5个阶段的顺序是肯定的，类的加载过程必须按照这种顺序循序渐进的开始，而解析过程则不必定：它在某些状况下能够在初始化阶段以后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或者晚期绑定）。
有且仅有5种状况必须当即对类进行初始化（而加载、验证、准备天然须要在此以前开始）
- 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，若是类没有进行过初始化，则须要先触发其初始化。对应的场景：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
- 使用java.lang.reflect包的方法对类进行反射调用的时候
- 当初始化一个类的时候，若是发现其父类尚未进行过初始化，则须要先触发其父类的初始化
- 当虚拟机启动时，用户须要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类
- 当使用jdk1.7的动态语言支持时，若是一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，而且这个方法句柄所对应的的类没有进行过初始化，则须要先触发其初始化
这5种场景中的行为成为对一个类进行主动引用。除此以外全部引用类的方法都不会触发初始化，成为被动引用。

1.4.2 类加载的过程

加载
- 加载阶段，虚拟机须要完成如下3件事
  1. 经过全类名获取定义此类的二进制字节流
  2. 将字节流所表明的静态存储结构转换为方法区的运行时数据结构
  3. 在内存中生成一个表明该类的 Class 对象,做为方法区这些数据的访问入口
- 一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动做）是可控性最强的阶段，这一步咱们能够去完成还能够自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不经过类加载器建立，它由 Java 虚拟机直接建立。
验证

这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。
- 验证阶段大体上会完成下面4个阶段的检验动做
  1. 文件格式验证 验证字节流是否符合Class文件格式的规范，而且能被当前版本的虚拟机处理
  2. 元数据验证 对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。
  3. 字节码验证 最复杂的一个阶段，主要目的是经过数据流和控制流分析，肯定程序语言是合法的、符合逻辑的。
  4. 符号引用验证 发生在虚拟机将符号引用转化为直接引用的时候，这个转化动做将在链接的第三阶段--解析阶段中产生。符号引用验证能够看作是对类自身之外（常量池中的各类符号引用）的信息进行匹配性检验
准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配
解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程
- 类或接口的解析
- 字段解析
- 类方法解析
- 接口方法解析
初始化

到了初始化阶段，才真正开始执行类中定义的Java程序代码

1.4.3 类加载器

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其余类加载器均由 Java 实现且所有继承自java.lang.ClassLoader：

BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由C++实现，负责加载 %JAVA_HOME%/lib目录下的jar包和类或者或被 -Xbootclasspath参数指定的路径中的全部类。
ExtensionClassLoader(扩展类加载器)：主要负责加载目录 %JRE_HOME%/lib/ext 目录下的jar包和类，或被 java.ext.dirs 系统变量所指定的路径下的jar包。
AppClassLoader(应用程序类加载器) :面向咱们用户的加载器，负责加载当前应用classpath下的全部jar包和类。

1.4.4 双亲委派模型

一个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工做的时候会默认使用 双亲委派模型 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，不然才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，所以全部的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器没法处理时，才由本身来处理。当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 做为父类加载器。

findClass和loadClass的不一样之处

findClass只是loadClass的其中一步，若是父加载器和根加载器都没有找到这个类，就会调用findClass方法，若是继承了findClass方法，那么双亲委派模型就不会被破坏，这其实就是一个模板方法模型。

1.5 Java内存模型

内存模型能够理解为在特定的操做协议下，对特定的内存或者高速缓存进行读写访问的过程抽象，不一样架构下的物理机拥有不同的内存模型，Java虚拟机也有本身的内存模型，即Java内存模型（Java Memory Model, JMM）。
在C/C++语言中直接使用物理硬件和操做系统内存模型，致使不一样平台下并发访问出错。
而JMM的出现，可以屏蔽掉各类硬件和操做系统的内存访问差别，实现平台一致性，是的Java程序可以“一次编写，处处运行”。

1.5.1 主内存和工做内存

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样底层细节。
Java内存模型中规定了全部的变量都存储在主内存中，每条线程还有本身的工做内存，线程的工做内存中保存了该线程使用到的变量到主内存副本拷贝，线程对变量的全部操做（读取、赋值）都必须在工做内存中进行，而不能直接读写主内存中的变量。不一样线程之间没法直接访问对方工做内存中的变量，线程间变量值的传递均须要在主内存来完成，线程、主内存和工做内存的交互关系以下图所示

注意：这里的主内存、工做内存与Java内存区域的Java堆、栈、方法区不是同一层次内存划分，这二者基本上没有关系。

1.5.2 内存交互操做

关于主内存与工做内存之间的具体交互协议，即一个变量如何从主内存拷贝到工做内存、如何从工做内存同步到主内存之间的实现细节，Java内存模型定义了如下八种操做来完成
- lock（锁定）：做用于主内存的变量，把一个变量标识为一条线程独占状态。
- unlock（解锁）：做用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才能够被其余线程锁定。
- read（读取）：做用于主内存变量，把一个变量值从主内存传输到线程的工做内存中，以便随后的load动做使用
- load（载入）：做用于工做内存的变量，它把read操做从主内存中获得的变量值放入工做内存的变量副本中。
- use（使用）：做用于工做内存的变量，把工做内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个须要使用变量的值的字节码指令时将会执行这个操做。
- assign（赋值）：做用于工做内存的变量，它把一个从执行引擎接收到的值赋值给工做内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操做。
- store（存储）：做用于工做内存的变量，把工做内存中的一个变量的值传送到主内存中，以便随后的write的操做。
- write（写入）：做用于主内存的变量，它把store操做从工做内存中一个变量的值传送到主内存的变量中。
若是要把一个变量从主内存中复制到工做内存，就须要按顺序地执行read和load操做，若是把变量从工做内存中同步回主内存中，就要按顺序地执行store和write操做。Java内存模型只要求上述两个操做必须按顺序执行，而没有保证必须是连续执行。
Java内存模型还规定了在执行上述八种基本操做时，必须知足以下规则：
- 不容许read和load、store和write操做之一单独出现
- 不容许一个线程丢弃它的最近assign的操做，即变量在工做内存中改变了以后必须同步到主内存中。
- 不容许一个线程无缘由地（没有发生过任何assign操做）把数据从工做内存同步回主内存中。
- 一个新的变量只能在主内存中诞生，不容许在工做内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操做以前，必须先执行过了assign和load操做。
- 一个变量在同一时刻只容许一条线程对其进行lock操做，lock和unlock必须成对出现
- 若是对一个变量执行lock操做，将会清空工做内存中此变量的值，在执行引擎使用这个变量前须要从新执行load或assign操做初始化变量的值
- 若是一个变量事先没有被lock操做锁定，则不容许对它执行unlock操做；也不容许去unlock一个被其余线程锁定的变量。
- 对一个变量执行unlock操做以前，必须先把此变量同步到主内存中（执行store和write操做）。
这8种内存访问操做很繁琐，后文会使用一个等效判断原则，即先行发生（happens-before）原则来肯定一个内存访问在并发环境下是否安全。

1.5.3 volatile变量的特殊规则

关键字volatile是JVM中最轻量的同步机制。volatile变量具备2种特性：
1. 保证变量的可见性
2. 禁止指令重排序
因为volatile只能保证变量的可见性和屏蔽指令重排序，只有知足下面2条规则时，才能使用volatile来保证并发安全，不然就须要加锁（使用synchronized、lock或者java.util.concurrent中的Atomic原子类）来保证并发中的原子性。
1. 运算结果不存在数据依赖（重排序的数据依赖性），或者只有单一的线程修改变量的值（重排序的as-if-serial语义）
2. 变量不须要与其余的状态变量共同参与不变约束

DCL单例模式

public class Singleton {
    private volatile static Singleton instance = null;
    public static Singleton getInstance() {
        if(null == instance) {    
            synchronized (Singleton.class) {
                if(null == instance) {                    
                    instance = new Singleton();        
                }
            }
        }
        
        return instance;    
        
    }
}
复制代码

单例对象instance须要加上关键字volatile禁止指令重排序，保证可见性。（详情请点我）

1.5.4 long和double型变量的特殊规则

JMM要求lock、unlock、read、load、assign、use、store、write这8个操做都必须具备原子性，但对于64为的数据类型（long和double），具备非原子协定：容许虚拟机将没有被volatile修饰的64位数据的读写操做划分为2次32位操做进行。

若是多个线程共享一个没有声明为volatile的long或double变量，而且同时读取和修改，某些线程可能会读取到一个既非原值，也不是其余线程修改值的表明了“半个变量”的数值。不过这种状况十分罕见。由于非原子协议换句话说，一样容许long和double的读写操做实现为原子操做，而且目前绝大多数的虚拟机都是这样作的。

1.5.5 原子性、可见性与有序性

原子性

JMM保证的原子性变量操做包括read、load、assign、use、store、write，而long、double非原子协定致使的非原子性操做基本能够忽略。若是须要对更大范围的代码实行原子性操做，则须要JMM提供的lock、unlock、synchronized等来保证。
可见性

volatile、synchronized和final也能保证可见性
有序性
Java程序中自然的有序性能够总结为
1. 若是在本线程内观察，全部的操做都是有序的； ( 指“线程内表现为串行的语义”)
2. 若是在一个线程中观察另外一个线程，全部的操做都是无序的。 (“指令重排序”现象和“工做内存与主内存同步延迟”现象)。 Java程序提供了volatile和synchronized两个关键字来保证线程之间操做的有序性

1.5.6 先行发生原则

程序次序规则(Program OrderRule)：在同一个线程中，按照程序代码顺序，书写在前面的操做先行发生于书写在后面的操纵。准确的说是程序的控制流顺序，考虑分支和循环等。
管理锁定规则(Monitor Lock Rule)：一个unlock操做先行发生于后面（时间上的顺序）对同一个锁的lock操做。
volatile变量规则(Volatile Variable Rule)：对一个volatile变量的写操做先行发生于后面（时间上的顺序）对该变量的读操做。
线程启动规则(Thread Start Rule)：Thread对象的start()方法先行发生于此线程的每个动做。
线程终止规则(Thread Termination Rule)：线程的全部操做都先行发生于对此线程的终止检测，能够经过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。**
线程中断规则(Thread Interruption Rule)：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断时事件的发生。Thread.interrupted()能够检测是否有中断发生。
对象终结规则(Finilizer Rule)：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()的开始。
传递性(Transitivity)：若是操做A 先行发生于操做B，操做B 先行发生于操做C，那么能够得出A 先行发生于操做C。
注意：不一样操做时间前后顺序与先行发生原则之间没有关系，两者不能相互推断，衡量并发安全问题不能受到时间顺序的干扰，一切都要以happens-before原则为准

2. GC

2.1 对象死亡判断(两种方法)

2.1.1 引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任什么时候候计数器为0的对象就是不可能再被使用的。

2.1.2 可达性分析

这个算法的基本思想就是经过一系列的称为 “GC Roots” 的对象做为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证实此对象是不可用的。

可做为GC Roots的对象
1. 虚拟机栈（栈帧中的本地变量表）中引用的对象
2. 方法区中类静态属性引用的对象
3. 方法区中经常使用的对象
4. 本地方法栈中JNI（即通常说的Native方法）引用的对象

2.2 Java的四种引用

2.2.1 强引用

若是一个对象具备强引用，它就不会被垃圾回收器回收。即便当前内存空间不足，JVM也不会回收它，而是抛出OutOfMemoryError 错误，使程序异常终止。若是想中断强引用和某个对象之间的关联，能够显式地将引用赋值为null，这样一来的话，JVM在合适的时间就会回收该对象

2.2.2 弱引用

使用软引用时，若是内存的空间足够，软引用就能继续被使用，而不会被垃圾回收器回收，只有在内存不足时，软引用才会被垃圾回收器回收。

2.2.3 软引用

具备弱引用的对象拥有的生命周期更短暂。由于当JVM进行垃圾回收，一旦发现弱引用对象，不管当前内存空间是否充足，都会将弱引用回收。不过因为垃圾回收器是一个优先级较低的线程，因此并不必定能迅速发现弱引用对象

2.2.4 虚引用

顾名思义，就是形同虚设，若是一个对象仅持有虚引用，那么它至关于没有引用，在任什么时候候均可能被垃圾回收器回收。

主要用来跟踪对象被垃圾收集器回收的活动
虚引用必须和引用队列（ReferenceQueue）联合使用。

当垃圾收集器准备回收一个对象时，就会在回收对象内存以前，把这个虚引用加入到与之相关的引用队列中，程序能够经过判断引用队列中是否加入了虚引用，来了解被引用的对象是否将要被垃圾回收，若是程序发现某个虚引用已经被加入到引用队列，那么就能够在引用的对象的内存被回收以前采起必要的行动

2.2.5 为何要有不一样的引用类型

不像C语言,咱们能够控制内存的申请和释放,在Java中有时候咱们须要适当的控制对象被回收的时机,所以就诞生了不一样的引用类型,能够说不一样的引用类型实则是对GC回收时机不可控的妥协.有如下几个使用场景能够充分的说明:

利用软引用和弱引用解决OOM问题：用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时，JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题.
经过软引用实现Java对象的高速缓存:好比咱们建立了一Person的类，若是每次须要查询一我的的信息,哪怕是几秒中以前刚刚查询过的，都要从新构建一个实例，这将引发大量Person对象的消耗,而且因为这些对象的生命周期相对较短,会引发屡次GC影响性能。此时,经过软引用和 HashMap 的结合能够构建高速缓存,提供性能.

2.3 垃圾收集算法

2.3.1 标记-清除

算法分为“标记”和“清除”阶段：首先标记出全部须要回收的对象，在标记完成后统一回收全部被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进获得。

带来的问题
1. 效率问题：标记和清除两个过程的效率都不高
2. 空间问题：标记清除后会产生大量不连续的内存碎片

2.3.2 标记-复制

它能够将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另外一块去，而后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。

带来的问题：空间浪费

2.3.3 标记-整理

根据老年代的特色提出的一种标记算法，标记过程仍然与“标记-清除”算法同样，但后续步骤不是直接对可回收对象回收，而是让全部存活的对象向一端移动，而后直接清理掉端边界之外的内存。

2.3.4 分代收集

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不一样将内存分为几块。通常将java堆分为新生代和老年代，这样咱们就能够根据各个年代的特色选择合适的垃圾收集算法。

好比在新生代中，每次收集都会有大量对象死去，因此能够选择复制算法，只须要付出少许对象的复制成本就能够完成每次垃圾收集。而老年代的对象存活概率是比较高的，并且没有额外的空间对它进行分配担保，因此咱们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

2.4 垃圾收集器

若是说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

2.4.1 Serial收集器

串行单线程

“单线程” 的意义不只仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工做，更重要的是它在进行垃圾收集工做的时候必须暂停其余全部的工做线程（ "Stop The World" ），直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。

简单而高效（与其余收集器的单线程相比）
Serial收集器因为没有线程交互的开销，天然能够得到很高的单线程收集效率。Serial收集器对于运行在Client模式下的虚拟机来讲是个不错的选择。

2.4.2 ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本

它是许多运行在Server模式下的虚拟机的首要选择

除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到）配合工做。

并行并发
1. 并行（Parallel）：指多条垃圾收集线程并行工做，但此时用户线程仍然处于等待状态。
2. 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不必定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行在另外一个CPU上。

2.4.3 Parallel Scavenge收集器

Parallel Scavenge 收集器相似于ParNew 收集器。

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提升用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。

Parallel Scavenge收集器提供了不少参数供用户找到最合适的停顿时间或最大吞吐量，若是对于收集器运做不太了解的话，手工优化存在的话能够选择把内存管理优化交给虚拟机去完成也是一个不错的选择。

2.4.4 Serial Old收集器

Serial收集器的老年代版本

两大用途
- 在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用
- 在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用

2.4.5 Parallel Old收集器

Parallel Scavenge收集器的老年代版本

使用多线程和“标记-整理”算法

在注重吞吐量以及CPU资源的场合，均可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器。

2.4.6 CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而很是符合在注重用户体验的应用上使用。

基于“标记-清除”算法实现的
整个过程分为4个步骤
1. 初始标记：暂停全部的其余线程，并记录下直接与root相连的对象，速度很快；
2. 并发标记：同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前全部的可达对象。由于用户线程可能会不断的更新引用域，因此GC线程没法保证可达性分析的实时性。因此这个算法里会跟踪记录这些发生引用更新的地方。
3. 从新标记：从新标记阶段就是为了修正并发标记期间由于用户程序继续运行而致使标记产生变更的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
4. 并发清除：开启用户线程，同时GC线程开始对为标记的区域作清扫。
优势
1. 并发收集
2. 低停顿
缺点
1. 对CPU资源敏感；
2. 没法处理浮动垃圾；
3. 它使用的回收算法-“标记-清除”算法会致使收集结束时会有大量空间碎片产生。

2.4.7 G1收集器

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高几率知足GC停顿时间要求的同时,还具有高吞吐量性能特征.

优势
1. 并行与并发：G1能充分利用CPU、多核环境下的硬件优点，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其余收集器本来须要停顿Java线程执行的GC动做，G1收集器仍然能够经过并发的方式让java程序继续执行。
2. 分代收集：虽然G1能够不须要其余收集器配合就能独立管理整个GC堆，可是仍是保留了分代的概念。
3. 空间整合：与CMS的“标记--清理”算法不一样，G1从总体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
4. 可预测的停顿：这是G1相对于CMS的另外一个大优点，下降停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能创建可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片断内。
整个运行过程分为如下4个步骤
1. 初始标记
2. 并发标记
3. 最终标记
4. 筛选回收
G1收集器在后台维护了一个优先列表，每次根据容许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)。这种使用Region划份内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内能够尽量高的收集效率（把内存化整为零）。
- 垃圾收集器参数总结（jdk1.7）

2.5 内存分配与回收策略

对象优先在Eden分配
大对象直接进入老年代
长期存活的对象将进入老年代
动态对象年龄断定

为了能更好地适应不一样程度的内存情况，虚拟机并非永远地要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，若是在Survivor空间中相同年龄全部对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就能够直接进入老年代。
空间担保分配

2.6 Minor GC、Major GC和Full GC

MinorGC（新生代GC）发生在新生代的垃圾回收动做很是频繁，通常回收速度也很是快
Major GC（老年代GC）清理Tenured区，用于回收老年代一般会伴随至少一次的Minor GC
Full GC（全局范围）是针对整个新生代、老年代、元空间（metaspace Java8以上版本取代permGen）的群全局范围的GC。 Full GC不能等于Major GC，也不能等于Major GC+Minor GC，须要看使用了什么垃圾收集器组合，才能解释是什么样的垃圾回收

参考文献

《深刻理解Java虚拟机》第二版
剖析面试最多见问题之 JVM (上)