Java虚拟机内存管理机制

整体结构

参考原文

程序计数器

• 当前线程所执行的字节码的行号指示器，字节码解释器工作时就是通过改变这个计数器的值来确定下一条要执行的字节码指令的位置
• 执行 Java 方法和 native 方法时的区别：
  • 执行 Java 方法时：记录虚拟机正在执行的字节码指令地址；
  • 执行 native 方法时：无定义；
• 是 5 个区域中唯一不会出现 OOM 的区域。

Java 虚拟机栈

• Java 方法执行的内存模型，每个方法执行的过程，就是它所对应的栈帧在虚拟机栈中入栈到出栈的过程；
• 服务于 Java 方法；
• 可能抛出的异常：
  • OutOfMemoryError（在虚拟机栈可以动态扩展的情况下，扩展时无法申请到足够的内存）；
  • StackOverflowError（线程请求的栈深度 > 虚拟机所允许的深度）；
• 虚拟机参数设置：-Xss.
  

本地方法栈

• 服务于 native 方法；
• 可能抛出的异常：与 Java 虚拟机栈一样。
  

Java堆

• 唯一的目的：存放对象实例；
• 垃圾收集器管理的主要区域；
• 可以处于物理上不连续的内存空间中；
• 可能抛出的异常：
  • OutOfMemoryError（堆中没有内存可以分配给新创建的实例，并且堆也无法再继续扩展了）。
• 虚拟机参数设置：
  • 最大值：-Xmx
  • 最小值：-Xms
  • 两个参数设置成相同的值可避免堆自动扩展。

现代的垃圾收集器基本都是采用分代收集算法，该算法的思想是针对不同的对象采取不同的垃圾回收算法，因此虚拟机把 Java 堆分成以下三块：

• 新生代（Young Generation）
• 老年代（Old Generation）
• 永久代（Permanent Generation）

方法区

• 存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；
  • 类信息：即 Class 类，如类名、访问修饰符、常量池、字段描述、方法描述等。
• 垃圾收集行为在此区域很少发生；
  • 不过也不能不清理，对于经常动态生成大量 Class 的应用，如 Spring 等，需要特别注意类的回收状况。
• 运行时常量池也是方法区的一部分；
  • Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项是常量池，用于存放编译器生成的各种字面量（就是代码中定义的 static final 常量）和符号引用，这部分信息就存储在运行时常量池中。
• 可能抛出的异常：
  • OutOfMemoryError（方法区无法满足内存分配需求时）。

直接内存

• JDK 1.4 的 NIO 类可以使用 native 函数库直接分配堆外内存，这是一种基于通道与缓冲区的 I/O 方式，它在 Java 堆中存储一个 DirectByteBuffer 对象作为堆外内存的引用，这样就可以对堆外内存进行操作了。因为可以避免 Java 堆和 Native 堆之间来回复制数据，在一些场景可以带来显著的性能提高。
• 虚拟机参数设置：-XX:MaxDirectMemorySize
  • 默认等于 Java 堆最大值，即 -Xmx 指定的值。
• 将直接内存放在这里讲解的原因是它也可能会出现 OutOfMemoryError；
  • 服务器管理员在配置 JVM 参数时，会根据机器的实际内存设置 -Xmx 等信息，但经常会忽略直接内存（默认等于 -Xmx 设置值），这可能会使得各个内存区域的总和大于物理内存限制，从而导致动态扩展时出现 OOM。

Java内存模型中堆和栈的区别



元空间metaspace和永久代permgen

JMM(java memory model) java内存模型

在多线程环境下，线程之间的要通信,就不得不提JMM(java内存模型)
在JVM内部使用的java内存模型(JMM)将线程堆栈和堆之间的内存分开

线程堆栈(thread stack):

• 运行在java虚拟机上的每个线程都有自己的线程堆栈(thread stack)
• 线程堆栈还包含正在执行的每个方法的所有局部变量,一个线程只能访问它自己的线程堆栈。由线程创建的局部变量对于除创建它的线程之外的所有其他线程都是不可见的。
• 即使两个线程正在执行完全相同的代码，两个线程仍然会在每个线程堆栈中创建该代码的局部变量,一个线程可能会将一个有限变量的副本传递给另一个线程，但它不能共享原始局部变量本身

堆:

• 堆包含在Java应用程序中创建的所有对象，而不管是不是由线程创建的该对象。
• 堆中的对象可以被具有对象引用的所有线程访问。当一个线程访问一个对象时，它也可以访问该对象的成员变量。
• 如果两个线程同时调用同一个对象上的一个方法，它们都可以访问该对象的成员变量，但每个线程都有自己的局部变量副本
• 堆中的数据是共享的,线程不安全的

主内存和工作内存

　　Java内存模型的主要目标是定义程序中各个变量的访问规则，即在JVM中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量与Java编程里面的变量有所不同步，它包含了实例字段、静态字段和构成数组对象的元素，但不包含局部变量和方法参数，因为后者是线程私有的，不会共享，当然不存在数据竞争问题（如果局部变量是一个reference引用类型，它引用的对象在Java堆中可被各个线程共享，但是reference引用本身在Java栈的局部变量表中，是线程私有的）。为了获得较高的执行效能，Java内存模型并没有限制执行引起使用处理器的特定寄存器或者缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。

　　JMM规定了所有的变量都存储在主内存（Main Memory）中。每个线程还有自己的工作内存（Working Memory）,线程的工作内存中保存了该线程使用到的变量的主内存的副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量（volatile变量仍然有工作内存的拷贝，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般）。不同的线程之间也无法直接访问对方工作内存中的变量，线程之间值的传递都需要通过主内存来完成。

线程1和线程2要想进行数据的交换一般要经历下面的步骤：

1. 线程1把工作内存1中的更新过的共享变量刷新到主内存中去。
2. 线程2到主内存中去读取线程1刷新过的共享变量，然后copy一份到工作内存2中去。

原子性、可见性、有序性

Java内存模型是围绕着并发编程中原子性、可见性、有序性这三个特征来建立的。

• 原子性（Atomicity）：一个操作不能被打断，要么全部执行完毕，要么不执行。在这点上有点类似于事务操作，要么全部执行成功，要么回退到执行该操作之前的状态。
• 可见性：一个线程对共享变量做了修改之后，其他的线程立即能够看到（感知到）该变量这种修改（变化）。Java内存模型是通过将在工作内存中的变量修改后的值同步到主内存，在读取变量前从主内存刷新最新值到工作内存中，这种依赖主内存的方式来实现可见性的。
  无论是普通变量还是volatile变量都是如此，区别在于：
  • volatile：的特殊规则保证了volatile变量值修改后的新值立刻同步到主内存，每次使用volatile变量前立即从主内存中刷新，因此volatile保证了多线程之间的操作变量的可见性，而普通变量则不能保证这一点。
  • 使用synchronized关键字：在同步方法/同步块开始时（Monitor Enter）,使用共享变量时会从主内存中刷新变量值到工作内存中（即从主内存中读取最新值到线程私有的工作内存中），在同步方法/同步块结束时(Monitor Exit),会将工作内存中的变量值同步到主内存中去（即将线程私有的工作内存中的值写入到主内存进行同步）。
  • 使用Lock接口：的最常用的实现ReentrantLock(重入锁)来实现可见性：当我们在方法的开始位置执行lock.lock()方法，这和synchronized开始位置（Monitor Enter）有相同的语义，即使用共享变量时会从主内存中刷新变量值到工作内存中（即从主内存中读取最新值到线程私有的工作内存中），在方法的最后finally块里执行lock.unlock()方法，和synchronized结束位置（Monitor Exit）有相同的语义,即会将工作内存中的变量值同步到主内存中去（即将线程私有的工作内存中的值写入到主内存进行同步）。
  • final关键字：被final修饰的变量，在构造函数一旦初始化完成，并且在构造函数中并没有把“this”的引用传递出去（“this”引用逃逸是很危险的，其他的线程很可能通过该引用访问到只“初始化一半”的对象），那么其他线程就可以看到final变量的值。
• 有序性：对于一个线程的代码而言，我们总是以为代码的执行是从前往后的，依次执行的。这么说不能说完全不对，在单线程程序里，确实会这样执行；但是在多线程并发时，程序的执行就有可能出现乱序。用一句话可以总结为：在本线程内观察，操作都是有序的；如果在一个线程中观察另外一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行语义（WithIn Thread As-if-Serial Semantics）”,后半句是指“指令重排”现象和“工作内存和主内存同步延迟”现象。
  Java提供了两个关键字volatile和synchronized来保证多线程之间操作的有序性
  • volatile关键字本身通过加入内存屏障来禁止指令的重排序
  • synchronized关键字通过一个变量在同一时间只允许有一个线程对其进行加锁的规则来实现，在单线程程序中，不会发生“指令重排”和“工作内存和主内存同步延迟”现象，只在多线程程序中出现。

happens-before原则：

　　Java内存模型中定义的两项操作之间的次序关系，如果说操作A先行发生于操作B，操作A产生的影响能被操作B观察到，“影响”包含了修改了内存中共享变量的值、发送了消息、调用了方法等。

　　下面是Java内存模型下一些”天然的“happens-before关系，这些happens-before关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随意地重排序。

• 程序次序规则(Pragram Order Rule)：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环结构。
• 管程锁定规则(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()方法检测是否有中断发生。
• 对象终结规则(Finalizer Rule)：一个对象初始化完成(构造方法执行完成)先行发生于它的finalize()方法的开始。
• 传递性(Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

　　一个操作”时间上的先发生“不代表这个操作会是”先行发生“，那如果一个操作”先行发生“是否就能推导出这个操作必定是”时间上的先发生 “呢？也是不成立的，一个典型的例子就是指令重排序。所以时间上的先后顺序与happens-before原则之间基本没有什么关系，所以衡量并发安全问题一切必须以happens-before 原则为准。

HotSpot 虚拟机堆中的对象

对象的创建（遇到一条 new 指令时）

1. 检查这个指令的参数能否在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，先把这个类加载进内存；
2. 类加载检查通过后，虚拟机将为新对象分配内存，此时已经可以确定存储这个对象所需的内存大小；
3. 在堆中为新对象分配可用内存；
4. 将分配到的内存初始化；
5. 设置对象头中的数据；
6. 此时，从虚拟机的角度看，对象已经创建好了，但从 Java 程序的角度看，对象创建才刚刚开始，构造函数还没有执行。

第 3 步，在堆中为新对象分配可用内存时，会涉及到以下两个问题：

如何在堆中为新对象划分可用的内存？

• 指针碰撞（内存分配规整）
  • 用过的内存放一边，没用过的内存放一边，中间用一个指针分隔；
  • 分配内存的过程就是将指针向没用过的内存那边移动所需的长度；
• 空闲列表（内存分配不规整）
  • 维护一个列表，记录哪些内存块是可用的；
  • 分配内存时，从列表上选取一块足够大的空间分给对象，并更新列表上的记录；

如何处理多线程创建对象时，划分内存的指针的同步问题？

• 对分配内存空间的动作进行同步处理（CAS）；
• 把内存分配动作按照线程划分在不同的空间之中进行；
  • 每个线程在 Java 堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB）；
  • 哪个线程要分配内存就在哪个线程的 TLAB 上分配，TLAB 用完需要分配新的 TLAB 时，才需要同步锁定；
  • 通过 -XX:+/-UseTLAB 参数设定是否使用 TLAB。

对象的内存布局

• 对象头：
  • 第一部分：存储对象自身运行时的数据，HashCode、GC分代年龄等（Mark Word）；
  • 第二部分：类型指针，指向它的类元数据的指针，虚拟机通过这个指针来判断这个对象是哪个类的实例（HotSpot 采用的是直接指针的方式访问对象的）；
  • 如果是个数组对象，对象头中还有一块用于记录数组长度的数据。
• 实例数据：
  • 默认分配顺序：longs/doubles、ints、shorts/chars、bytes/booleans、oops (Ordinary Object Pointers)，相同宽度的字段会被分配在一起，除了 oops，其他的长度由长到短；
  • 默认分配顺序下，父类字段会被分配在子类字段前面。
    注：HotSpot VM要求对象的起始地址必须是8字节的整数倍，所以不够要补齐。

对象的访问

Java 程序需要通过虚拟机栈上的 reference 数据来操作堆上的具体对象，reference 数据是一个指向对象的引用，不过如何通过这个引用定位到具体的对象，目前主要有以下两种访问方式：句柄访问和直接指针访问。

句柄访问

句柄访问会在 Java 堆中划分一块内存作为句柄池，每一个句柄存放着到对象实例数据和对象类型数据的指针。
优势：对象移动的时候（这在垃圾回收时十分常见）只需改变句柄池中对象实例数据的指针，不需要修改reference本身。

直接指针访问

直接指针访问方式在 Java 堆对象的实例数据中存放了一个指向对象类型数据的指针，在 HotSpot 中，这个指针会被存放在对象头中。
优势：减少了一次指针定位对象实例数据的开销，速度更快。

OOM 异常 (OutOfMemoryError)

Java 堆溢出

• 出现标志：java.lang.OutOfMemoryError: Java heap space
• 解决方法：
  • 先通过内存映像分析工具分析 Dump 出来的堆转储快照，确认内存中的对象是否是必要的，即分清楚是出现了内存泄漏还是内存溢出；
  • 如果是内存泄漏，通过工具查看泄漏对象到 GC Root 的引用链，定位出泄漏的位置；
  • 如果不存在泄漏，检查虚拟机堆参数（-Xmx 和 -Xms）是否可以调大，检查代码中是否有哪些对象的生命周期过长，尝试减少程序运行期的内存消耗。
• 虚拟机参数：
  • -XX:HeapDumpOnOutOfMemoryError：让虚拟机在出现内存泄漏异常时 Dump 出当前的内存堆转储快照用于事后分析。

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

• 单线程下，栈帧过大、虚拟机容量过小都不会导致 OutOfMemoryError，只会导致 StackOverflowError（栈会比内存先爆掉），一般多线程才会出现 OutOfMemoryError，因为线程本身要占用内存；
• 如果是多线程导致的 OutOfMemoryError，在不能减少线程数或更换 64 位虚拟机的情况，只能通过减少最大堆和减少栈容量来换取更多的线程；
  • 这个调节思路和 Java 堆出现 OOM 正好相反，Java 堆出现 OOM 要调大堆内存的设置值，而栈出现 OOM 反而要调小。

方法区和运行时常量池溢出

• 测试思路：产生大量的类去填满方法区，直到溢出；
• 在经常动态生成大量 Class 的应用中，如 Spring 框架（使用 CGLib 字节码技术），方法区溢出是一种常见的内存溢出，要特别注意类的回收状况。

直接内存溢出

• 出现特征：Heap Dump 文件中看不见明显异常，程序中直接或间接用了 NIO；
• 虚拟机参数：-XX:MaxDirectMemorySize，如果不指定，则和 -Xmx 一样。

内存溢出与内存泄露

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

memory leak会最终会导致out of memory！

垃圾收集 (GC)

垃圾收集（Garbage Collection，GC），它的任务是解决以下 3 件问题：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？
  其中第一个问题很好回答，在 Java 中，GC 主要发生在 Java 堆和方法区中，对于后两个问题，我们将在之后的内容中进行讨论，并介绍 HotSpot 的 7 个垃圾收集器。

判断对象的生死

判断对象是否可用的算法

引用计数算法

• 算法描述：
  • 给对象添加一个引用计数器；
  • 每有一个地方引用它，计数器加 1；
  • 引用失效时，计数器减 1；
  • 计数器值为 0 的对象不再可用。
• 缺点：
  • 很难解决循环引用的问题。即 objA.instance = objB; objB.instance = objA;，objA 和 objB 都不会再被访问后，它们仍然相互引用着对方，所以它们的引用计数器不为 0，将永远不能被判为不可用。

可达性分析算法（主流）

• 算法描述：
  • 从 “GC Root” 对象作为起点开始向下搜索，走过的路径称为引用链（Reference Chain）；
  • 从 “GC Root” 开始，不可达的对象被判为不可用。
• Java 中可作为 “GC Root” 的对象：
  • 栈中（本地变量表中的reference）
    • 虚拟机栈中，栈帧中的本地变量表引用的对象；（a = new Obj()，a销毁之前，obj就是gc root）
    • 本地方法栈中，JNI 引用的对象（native方法）；
  • 方法区中
    • 类的静态属性引用的对象；
    • 常量引用的对象；（常量保存的是某个对象的地址）
  • 活跃线程引用的对象
    即便如此，一个对象也不是一旦被判为不可达，就立即死去的，宣告一个的死亡需要经过两次标记过程。

四种引用类型

JDK 1.2 后，Java 中才有了后 3 种引用的实现。

• 强引用： 像 Object obj = new Object() 这种，只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象。

• 软引用： 被软引用关联的对象，只有在内存不够的情况下才会被回收。对于软引用对象，在 OOM 前，虚拟机会把这些对象列入回收范围中进行第二次回收，如果这次回收后，内存还是不够用，就 OOM。

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null; // 使对象只被软引用关联

• 弱引用： 被弱引用引用的对象只能生存到下一次垃圾收集前，一旦发生垃圾收集，被弱引用所引用的对象就会被清掉。实现类：WeakReference。Tomcat 中的 ConcurrentCache 就使用了 WeakHashMap 来实现缓存功能。

• 虚引用： 又称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象实例。它唯一的用途就是：当被一个虚引用引用的对象被回收时，系统会收到这个对象被回收了的通知。实现类：PhantomReference。

宣告对象死亡的两次标记过程

finalize的执行过程(生命周期)
当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。否则，若对象未执行过finalize方法，将其放入F-Queue队列，由一低优先级线程执行该队列中对象的finalize方法。执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活

• finalize()是Object的protected方法，子类可以覆盖该方法以实现资源清理工作，GC在回收对象之前调用该方法。
• finalize()与C中的析构函数不是对应的。C中的析构函数调用的时机是确定的（对象离开作用域或delete掉），但Java中的finalize的调用具有不确定性
• 不建议用finalize方法完成“非内存资源”的清理工作，但建议用于：
  • 清理本地对象(通过JNI创建的对象)；
  • 作为确保某些非内存资源(如Socket、文件等)释放的一个补充：在finalize方法中显式调用其他资源释放方法。

方法区的回收

因为方法区主要存放永久代对象，而永久代对象的回收率比新生代差很多，因此在方法区上进行回收性价比不高。主要是对常量池的回收和对类的卸载。
永久代的 GC 主要回收：废弃常量 和 无用的类。

• 废弃常量：例如一个字符串 “abc”，当没有任何引用指向 “abc” 时，它就是废弃常量了。
• 无用的类：同时满足以下 3 个条件的类。
  • 该类的所有实例已被回收，Java 堆中不存在该类的任何实例；
  • 加载该类的 Classloader 已被回收；
  • 该类的 Class 对象没有被任何地方引用，即无法在任何地方通过反射访问该类的方法。

垃圾收集算法

基础：标记 - 清除算法

• 算法描述：
  • 先标记出所有需要回收的对象（图中深色区域）；
  • 标记完后，统一回收所有被标记对象（留下狗啃似的可用内存区域……）。
• 不足：
  • 效率问题：标记和清理两个过程的效率都不高。
  • 空间碎片问题：标记清除后会产生大量不连续的内存碎片，导致以后为较大的对象分配内存时找不到足够的连续内存，会提前触发另一次 GC。

解决效率问题：复制算法

• 算法描述：

  • 将可用内存分为大小相等的两块，每次只使用其中一块；
  • 当一块内存用完时，将这块内存上还存活的对象复制到另一块内存上去，将这一块内存全部清理掉。
• 不足： 可用内存缩小为原来的一半，适合GC过后只有少量对象存活的新生代。
• 节省内存的方法：
  • 新生代中的对象 98% 都是朝生夕死的，所以不需要按照 1:1 的比例对内存进行划分；
  • 把内存划分为：
    • 1 块比较大的 Eden 区；
    • 2 块较小的 Survivor 区；
  • 每次使用 Eden 区和 1 块 Survivor 区；
  • 回收时，将以上 2 部分区域中的存活对象复制到另一块 Survivor 区中，然后将以上两部分区域清空；
  • JVM 参数设置：-XX:SurvivorRatio=8 表示 Eden 区大小 / 1 块 Survivor 区大小 = 8。
    

解决空间碎片问题：标记 - 整理算法

• 算法描述：
  • 标记方法与 “标记 - 清除算法” 一样；
  • 标记完后，将所有存活对象向一端移动，然后直接清理掉边界以外的内存。
• 不足： 存在效率问题，适合老年代。
  

进化：分代收集算法

• 新生代： GC 过后只有少量对象存活 —— 复制算法
• 老年代： GC 过后对象存活率高 —— 标记 - 整理算法

当系统创建一个对象的时候，总是在Eden区操作，当这个区满了，那么就会触发一次Minor GC，也就是年轻代的垃圾回收。一般来说这时候不是所有的对象都没用了，所以就会把还能用的对象复制到From区。

这样整个Eden区就被清理干净了，可以继续创建新的对象，当Eden区再次被用完，就再触发一次Minor GC，然后呢，注意，这个时候跟刚才稍稍有点区别。这次触发Minor GC后，会将Eden区与From区还在被使用的对象复制到To区，

再下一次Minor GC的时候，则是将Eden区与To区中的还在被使用的对象复制到From区。

经过若干次Minor GC后，有些对象在From与To之间来回游荡，这时候From区与To区亮出了底线（阈值），这些家伙要是到现在还没挂掉，对不起，一起滚到（复制）老年代吧。

1. 经历一定minor次数依然存活的对象
2. survivor区放不下的对象
3. 新生成的大对象（-XX:+PretenuerSizeThreshold）
   
   老年代经过这么几次折腾，也就扛不住了（空间被用完），好，那就来次集体大扫除（Full GC），也就是全量回收，一起滚蛋吧。全量回收就好比我们刚才比作的大扫除，毕竟动做比较大，成本高，不能跟平时的小型值日（Minor GC）相比，所以如果Full GC使用太频繁的话，无疑会对系统性能产生很大的影响。所以要合理设置年轻代与老年代的大小，尽量减少Full GC的操作

Minor GC触发机制：

• 当年轻代满时就会触发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC。

Full GC触发机制：

• 调用System.gc()时，系统建议执行Full GC，但是不必然执行
• 老年代空间不足
• 永久代空间不足
• 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
• 由Eden区、survivor space1（From Space）区向survivor space2（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
• 使用RMI来进行RPC或管理的JDK应用，每小时执行一次Full GC
• CMS GC时出现promotion failed, concurrent mode failure

常用调优参数
-XX:SurvivorRatio:Eden和Survivor比值，默认8
-XX:NewRatio:老年代和年轻代内存大小比例
-XX:MaxTenuringThreshold:对象从年轻代晋升到老年代经过gc次数的最大阈值

HotSpot 中 GC 算法的实现

通过前两小节对于判断对象生死和垃圾收集算法的介绍，我们已经对虚拟机进行 GC 的流程有了一个大致的了解。但是，在 HotSpot 虚拟机中，高效的实现这些算法也是一个需要考虑的问题。所以，接下来，我们将研究一下 HotSpot 虚拟机到底是如何高效的实现这些算法的，以及在实现中有哪些需要注意的问题。

通过之前的分析，GC 算法的实现流程简单的来说分为以下两步：

1. 找到死掉的对象；
2. 把它清了。

想要找到死掉的对象，我们就要进行可达性分析，也就是从 GC Root 找到引用链的这个操作。

也就是说，进行可达性分析的第一步，就是要枚举 GC Roots，这就需要虚拟机知道哪些地方存放着对象应用。如果每一次枚举 GC Roots 都需要把整个栈上位置都遍历一遍，那可就费时间了，毕竟并不是所有位置都存放在引用呀。所以为了提高 GC 的效率，HotSpot 使用了一种 OopMap 的数据结构，OopMap 记录了栈上本地变量到堆上对象的引用关系，也就是说，GC 的时候就不用遍历整个栈只遍历每个栈的 OopMap 就行了。

在 OopMap 的帮助下，HotSpot 可以快速准确的完成 GC 枚举了，不过，OopMap 也不是万年不变的，它也是需要被更新的，当内存中的对象间的引用关系发生变化时，就需要改变 OopMap 中的相应内容。可是能导致引用关系发生变化的指令非常之多，如果我们执行完一条指令就改下 OopMap，这 GC 成本实在太高了。

因此，HotSpot 采用了一种在 “安全点” 更新 OopMap 的方法，安全点的选取既不能让 GC 等待的时间过长，也不能过于频繁增加运行负担，也就是说，我们既要让程序运行一段时间，又不能让这个时间太长。我们知道，JVM 中每条指令执行的是很快的，所以一个超级长的指令流也可能很快就执行完了，所以 真正会出现 “长时间执行” 的一般是指令的复用，例如：方法调用、循环跳转、异常跳转等，虚拟机一般会将这些地方设置为安全点更新 OopMap 并判断是否需要进行 GC 操作。

此外，在进行枚举根节点的这个操作时，为了保证准确性，我们需要在一段时间内 “冻结” 整个应用，即 Stop The World（传说中的 GC 停顿），因为如果在我们分析可达性的过程中，对象的引用关系还在变来变去，那是不可能得到正确的分析结果的。即便是在号称几乎不会发生停顿的 CMS 垃圾收集器中，枚举根节点时也是必须要停顿的。这里就涉及到了一个问题：

我们让所有线程跑到最近的安全点再停顿下来进行 GC 操作呢？

主要有以下两种方式：

• 抢先式中断：
  • 先中断所有线程；
  • 发现有线程没中断在安全点，恢复它，让它跑到安全点。
• 主动式中断： (主要使用)
  • 设置一个中断标记；
  • 每个线程到达安全点时，检查这个中断标记，选择是否中断自己。

除此安全点之外，还有一个叫做 “安全区域” 的东西，一个一直在执行的线程可以自己 “走” 到安全点去，可是一个处于 Sleep 或者 Blocked 状态的线程是没办法自己到达安全点中断自己的，我们总不能让 GC 操作一直等着这些个 ”不执行“ 的线程重新被分配资源吧。对于这种情况，我们要依靠安全区域来解决。

安全区域是指在一段代码片段之中，引用关系不会发生变化，因此在这个区域中的任意位置开始 GC 都是安全的。

当线程执行到安全区域时，它会把自己标识为 Safe Region，这样 JVM 发起 GC 时是不会理会这个线程的。当这个线程要离开安全区域时，它会检查系统是否在 GC 中，如果不在，它就继续执行，如果在，它就等 GC 结束再继续执行。

本小节我们主要讲述 HotSpot 虚拟机是如何发起内存回收的，也就是如何找到死掉的对象，至于如何清掉这些个对象，HotSpot 将其交给了一堆叫做 ”GC 收集器“ 的东西，这东西又有好多种，不同的 GC 收集器的处理方式不同，适用的场景也不同，我们将在下一小节进行详细讲述。

JVM 运行模式
Server
Client

7 个垃圾收集器

垃圾收集器就是内存回收操作的具体实现，HotSpot 里足足有 7 种，为啥要弄这么多，因为它们各有各的适用场景。有的属于新生代收集器，有的属于老年代收集器，所以一般是搭配使用的（除了万能的 G1）。关于它们的简单介绍以及分类请见下图。

Serial / ParNew 搭配 Serial Old 收集器

Serial 收集器是虚拟机在 Client 模式下的默认新生代收集器，它的优势是简单高效，在单 CPU 模式下很牛。
ParNew 收集器就是 Serial 收集器的多线程版本，虽然除此之外没什么创新之处，但它却是许多运行在 Server 模式下的虚拟机中的首选新生代收集器，因为除了 Serial 收集器外，只有它能和 CMS 收集器搭配使用。

Parallel 搭配 Parallel Scavenge 收集器

首先，这俩货肯定是要搭配使用的，不仅仅如此，它俩还贼特别，它们的关注点与其他收集器不同，其他收集器关注于尽可能缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目的是达到一个可控的吞吐量。

吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )

因此，Parallel Scavenge 收集器不管是新生代还是老年代都是多个线程同时进行垃圾收集，十分适合于应用在注重吞吐量以及 CPU 资源敏感的场合。
可调节的虚拟机参数：

• -XX:+UserParallelGC
• -XX:MaxGCPauseMillis：最大 GC 停顿的秒数；
• -XX:GCTimeRatio：吞吐量大小，一个 0 ~ 100 的数，最大 GC 时间占总时间的比率 = 1 / (GCTimeRatio + 1)；
• -XX:+UseAdaptiveSizePolicy：一个开关参数，打开后就无需手工指定 -Xmn，-XX:SurvivorRatio 等参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，自行调整。

CMS 收集器

参数设置：

• -XX:+UseCMSCompactAtFullCollection：在 CMS 要进行 Full GC 时进行内存碎片整理（默认开启）
• -XX:CMSFullGCsBeforeCompaction：在多少次 Full GC 后进行一次空间整理（默认是 0，即每一次 Full GC 后都进行一次空间整理）

G1 收集器

-XX：UserG1GC 复制+标记-整理算法

GC 日志解读

Java 内存分配策略

优先在 Eden 区分配

• Eden 空间不够将会触发一次 Minor GC；
• 虚拟机参数：
  • -Xmx：Java 堆的最大值；
  • -Xms：Java 堆的最小值；
  • -Xmn：新生代大小；
  • -XX:SurvivorRatio=8：Eden 区 / Survivor 区 = 8 : 1

大对象直接进入老年代

• 大对象定义： 需要大量连续内存空间的 Java 对象。例如那种很长的字符串或者数组。
• 设置对象直接进入老年代大小限制：
  • -XX:PretenureSizeThreshold：单位是字节；
    • 只对 Serial 和 ParNew 两款收集器有效。
  • 目的： 因为新生代采用的是复制算法收集垃圾，大对象直接进入老年代可以避免在 Eden 区和 Survivor 区发生大量的内存复制。

长期存活的对象将进入老年代

• 固定对象年龄判定： 虚拟机给每个对象定义一个年龄计数器，对象每在 Survivor 中熬过一次 Minor GC，年龄 +1，达到 -XX:MaxTenuringThreshold 设定值后，会被晋升到老年代，-XX:MaxTenuringThreshold 默认为 15；
• 动态对象年龄判定： Survivor 中有相同年龄的对象的空间总和大于 Survivor 空间的一半，那么，年龄大于或等于该年龄的对象直接
  晋升到老年代。

空间分配担保

我们知道，新生代采用的是复制算法清理内存，每一次 Minor GC，虚拟机会将 Eden 区和其中一块 Survivor 区的存活对象复制到另一块 Survivor 区，但当出现大量对象在一次 Minor GC 后仍然存活的情况时，Survivor 区可能容纳不下这么多对象，此时，就需要老年代进行分配担保，即将 Survivor 无法容纳的对象直接进入老年代。

这么做有一个前提，就是老年代得装得下这么多对象。可是在一次 GC 操作前，虚拟机并不知道到底会有多少对象存活，所以空间分配担保有这样一个判断流程：

• 发生 Minor GC 前，虚拟机先检查老年代的最大可用连续空间是否大于新生代所有对象的总空间；
  • 如果大于，Minor GC 一定是安全的；
  • 如果小于，虚拟机会查看 HandlePromotionFailure 参数，看看是否允许担保失败；
    • 允许失败：尝试着进行一次 Minor GC；
    • 不允许失败：进行一次 Full GC；
• 不过 JDK 6 Update 24 后，HandlePromotionFailure 参数就没有用了，规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行 Minor GC，否则将进行 Full GC。

Metaspace 元空间与 PermGem 永久代

元空间是方法区的在HotSpot jvm 中的实现，方法区主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。，理论上取决于32位/64位系统可虚拟的内存大小。可见也不是无限制的，需要配置参数。

==元空间和永久代都是方法区的实现==

Java 8 彻底将永久代 (PermGen) 移除出了 HotSpot JVM，将其原有的数据迁移至 Java Heap 或 Metaspace。

移除 PermGem 的原因：

• PermGen 内存经常会溢出，引发恼人的 java.lang.OutOfMemoryError: PermGen，因此 JVM 的开发者希望这一块内存可以更灵活地被管理，不要再经常出现这样的 OOM；
• 移除 PermGen 可以促进 HotSpot JVM 与 JRockit VM 的融合，因为 JRockit 没有永久代。
  移除 PermGem 后，方法区和字符串常量的位置：
• 方法区：移至 Metaspace；
• 字符串常量：移至 Java Heap。
  Metaspace 的位置： 本地堆内存(native heap)。
  Metaspace 的优点： 永久代 OOM 问题将不复存在，因为默认的类的元数据分配只受本地内存大小的限制，也就是说本地内存剩余多少，理论上 Metaspace 就可以有多大；
  JVM参数：
• -XX:MetaspaceSize：分配给类元数据空间（以字节计）的初始大小，为估计值。MetaspaceSize的值设置的过大会延长垃圾回收时间。垃圾回收过后，引起下一次垃圾回收的类元数据空间的大小可能会变大。
• -XX:MaxMetaspaceSize：分配给类元数据空间的最大值，超过此值就会触发Full GC，取决于系统内存的大小。JVM会动态地改变此值。
• -XX:MinMetaspaceFreeRatio：一次GC以后，为了避免增加元数据空间的大小，空闲的类元数据的容量的最小比例，不够就会导致垃圾回收。
• -XX:MaxMetaspaceFreeRatio：一次GC以后，为了避免增加元数据空间的大小，空闲的类元数据的容量的最大比例，不够就会导致垃圾回收。