1. JVM

1.1 Java内存区域划分

1.1.1 线程共享

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

它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。也被称为Non-Heap（非堆），永久代
- 方法区和永久代的关系
  
  方法区和永久代的关系很像Java中接口和类的关系，类实现了接口，而永久代就是HotSpot虚拟机对虚拟机规范中方法区的一种实现方式。
- 运行时常量池
  
  运行时常量池是方法区的一部分。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 (上)

JVM小结

1. JVM

1.1 Java内存区域划分

1.1.1 线程共享

1.1.2 线程私有

1.2 Java虚拟机对象

1.2.1 对象的创建

1.2.2 对象的内存布局

1.2.3 对象的访问定位

1.3 OOM异常及应对方法

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

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

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

1.3.4 本机直接内存溢出

1.4 虚拟机类加载机制

1.4.1 类加载的时机

1.4.2 类加载的过程

1.4.3 类加载器

1.4.4 双亲委派模型

1.5 Java内存模型

1.5.1 主内存和工作内存

1.5.2 内存交互操作

1.5.3 volatile变量的特殊规则

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

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

1.5.6 先行发生原则

2. GC

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

2.1.1 引用计数法

2.1.2 可达性分析

2.2 Java的四种引用

2.2.1 强引用

2.2.2 弱引用

2.2.3 软引用

2.2.4 虚引用

2.2.5 为什么要有不同的引用类型

2.3 垃圾收集算法

2.3.1 标记-清除

2.3.2 标记-复制

2.3.3 标记-整理

2.3.4 分代收集

2.4 垃圾收集器

2.4.1 Serial收集器

2.4.2 ParNew收集器

2.4.3 Parallel Scavenge收集器

2.4.4 Serial Old收集器

2.4.5 Parallel Old收集器

2.4.6 CMS收集器

2.4.7 G1收集器

2.5 内存分配与回收策略

2.6 Minor GC、Major GC和Full GC