深入理解Java虚拟机JVM内存结构与垃圾回收机制详解

深入理解Java虚拟机：JVM内存结构与垃圾回收机制详解

JVM内存结构概览

Java虚拟机（JVM）在执行Java程序的过程中会将它所管理的内存划分为若干个不同的数据区域。这些区域有各自的用途，其创建和销毁的时间也各不相同。理解这些内存区域是深入掌握Java程序运行机制和性能调优的基础。总体上，JVM内存可以分为线程共享区域和线程私有区域两大类。线程共享区域随着虚拟机的启动而创建，随着虚拟机的退出而销毁；而线程私有区域则与单个线程的生命周期保持一致。

程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。此内存区域是线程私有的，每个线程都有自己独立的程序计数器。如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Native方法，这个计数器值则为空（Undefined）。此区域是唯一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。

Java虚拟机栈

Java虚拟机栈（Java Virtual Machine Stack）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。局部变量表存放了编译期可知的各种基本数据类型、对象引用和returnAddress类型。该区域可能抛出两种异常：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展，但在扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

本地方法栈

本地方法栈（Native Method Stack）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

Java堆

Java堆（Java Heap）是虚拟机所管理的内存中最大的一块，是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。Java堆是垃圾收集器管理的主要区域，因此很多时候也被称作“GC堆”。从内存回收的角度来看，由于现代收集器基本都采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然《Java虚拟机规范》把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做“非堆”（Non-Heap），目的应该是与Java堆区分开来。很多人愿意将方法区称为“永久代”（Permanent Generation），但这本质上并不等价。方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。运行时常量池是方法区的一部分，用于存放编译期生成的各种字面量和符号引用。

垃圾回收机制的必要性

在Java中，程序员不需要像C/C++那样手动释放对象占用的内存，因为JVM中的垃圾回收器（Garbage Collector, GC）会自动完成这项工作。当一个Java对象不再被任何引用变量所引用时，该对象就变成了垃圾，它占用的内存需要被回收以腾出空间供新的对象使用。如果不进行垃圾回收，内存迟早会被消耗殆尽。垃圾回收机制有效地防止了内存泄漏，简化了程序员的开发工作，是Java语言的重要特性之一。

判断对象是否可回收的算法

垃圾回收器需要解决的首要问题是：如何判断一个对象已经“死亡”，即不再被使用。主要有两种算法：

1. 引用计数算法： 给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。但主流Java虚拟机并未采用此算法，因为它很难解决对象之间相互循环引用的问题。

2. 可达性分析算法： 这是主流商用程序语言（如Java、C#）的管理系统所采用的算法。该算法的基本思路是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”。如果某个对象到GC Roots间没有任何引用链相连，则证明此对象是不可能再被使用的。在Java技术体系里，固定可作为GC Roots的对象包括：在虚拟机栈中引用的对象、在方法区中类静态属性引用的对象、在方法区中常量引用的对象、在本地方法栈中JNI引用的对象等。

垃圾收集算法

在确定了哪些垃圾需要回收之后，垃圾收集器需要采用特定的算法来执行回收操作。经典的垃圾收集算法主要有以下三种：

1. 标记-清除算法： 算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象。它的主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，导致以后在分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2. 复制算法： 该算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况。该算法的代价是将内存缩小为了原来的一半，代价较高。现代的商业虚拟机都采用这种收集算法来回收新生代。

3. 标记-整理算法： 标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。这种算法适用于对象存活率高的老年代。

4. 分代收集算法： 当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法根据对象存活周期的不同将内存划分为几块（一般是新生代和老年代），然后根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

常见的垃圾收集器

垃圾收集器是垃圾回收算法的具体实现。HotSpot虚拟机提供了多种不同的收集器，每种收集器都有各自的特点和适用场景。

Serial收集器： 是最基本、发展历史最悠久的收集器，它是一个单线程的收集器，在进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。简单而高效，对于运行在Client模式下的虚拟机来说是一个很好的选择。

ParNew收集器： 实质上是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器完全一样。它是许多运行在Server模式下的虚拟机中首选的新生代收集器。

Parallel Scavenge收集器： 也是一个新生代收集器，它使用复制算法，并且是并行的多线程收集器。它的特点是它的关注点与其他收集器不同，它的目标是达到一个可控制的吞吐量。

Serial Old收集器： 是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。

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

CMS收集器： 是一种以获取最短回收停顿时间为目标的收集器，基于“标记-清除”算法实现。它的运作过程相对于前面几种收集器来说更复杂，整个过程分为四个步骤，包括初始标记、并发标记、重新标记、并发清除。其中初始标记和重新标记仍然需要“Stop The World”。

G1收集器： 是当前收集器技术发展的最前沿成果之一，它是一款面向服务端应用的垃圾收集器。G1收集器将整个Java堆划分为多个大小相等的独立区域，它能够建立可预测的停顿时间模型，让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。