运行时数据区域

1、程序计数器

程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。

2、Java虚拟机栈

1）与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期与线程相同。

2）虚拟机栈描述的是Java方法执行的内存模型，每个方法在执行同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。

3）每一个方法从调用直至执行完成的过程，对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

3、本地方法栈

与虚拟机栈的作用类似，之间的区别是：虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为虚拟机使用到的Native方法服务。

4、Java堆

1）Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。

2）Java堆被所有线程共享的一块内存区域。

3）此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

4）Java堆是垃圾收集器管理的主要区域，因此也被称为“GC堆”

从内存回收的角度看，现在收集器基本都采用分代收集算法，所以Java堆还可以细分为：新生代 和 老年代

新生代按照8:1:1的比例再划分为： Eden、Survivor0、Survivor1

5、方法区

方法区与Java堆一样，是各个线程共享的内存区域，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

方法区也被称为：永久代

二、java垃圾收集器

1、垃圾回收机制的意义

使用Java编写程序的时候，可以不考虑内存管理。由于垃圾回收机制，Java中的对象不在有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄漏，有效的使用空闲的内存。

内存泄漏（Memory Leak）：指该内存空间使用后未回收，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

内存溢出（out of memory）：内存不够，所需内存大于主机内安装的内存所承受大小。

2、Java对象存活判定

垃圾收集器确定对象是否可回收

2.1、引用计数算法

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

缺陷：很难解决对象之间相互循环引用的问题。

2.2、可达性分析算法

通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路劲称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，此时它们将会被判定为是可回收的对象。

Java中，可作为GC Roots的对象包括以下几种：

• 虚拟机栈中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（Java Native Implement）引用的对象

引用

强引用、软引用、弱引用、虚引用

3、垃圾收集器的算法

3.1、标记-清除算法

“标记-清除”（Mark-Sweep）算法是最基础的收集算法

算法分为“标记”和“清除”两个阶段；

首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

主要不足有两个：

• 效率问题，标记和清除两个过程的效率都不高
• 空间问题，标记清除后会产生大量不连续的内存碎片，内存碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
• 

 

3.2、复制算法

为了解决效率问题，出现了新的收集算法：“复制”算法

将可用的内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。

每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

缺点：将内存缩小为原来的一半，代价较高

 

3.3、标记-整理算法

复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。

根据老年代的特点，提出了另外一种算法：“标记-整理”算法（Mark-Compact）

让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

3.4、分代收集算法

根据各个年代的特点采用最适当的收集算法。

新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。

老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清除”或“标记-整理”算法进行回收。

4、垃圾收集器

4.1、Serial收集器

最基本、发展历史最悠久的收集器，JDK1.3.1之前是虚拟机新生代收集的唯一选择。

单线程的收集器，并且“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

因此会造成“Stop The World”（STW）。

优点：简单而高效（与其他收集器的单线程比），对于单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

4.2、ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:ServivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。

默认开启的收集线程数与CPU的数量相同。

4.3、Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。

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

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

4.4、Serial Old收集器

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

4.5、Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。JDK1.6才开始提供。

4.6、CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

CMS收集器是基于“标记-清除”算法实现的，整个过程分为4个步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。

初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

主要优点：并发收集、低停顿

但CMS还远达不到完美的程度，它有以下3个明显的缺点：

1.CMS收集器对CPU资源非常敏感，会占用部分线程，导致用户应用程序变慢，总吞吐量降低。CMS默认启动的回收线程数是：（CPU数量+3）/4

2.CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行并产生新的垃圾，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉，只能留待下一次GC再处理。这一部分垃圾就称为“浮动垃圾”。也是由于用户线程还在运行，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留足够的内存空间给用户线程使用。

在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活。

在JDK1.6中，CMS收集器的启动阈值已经提升至92%。

3.CMS是基于”标记-清除“算法实现的收集器，收集结束时会有大量空间碎片产生。空间碎片过多时，给大对象分配带来麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

4.7、G1收集器

4.7.1 G1收集器简介

G1是一款面向服务端应用的垃圾收集器

与其他GC收集器相比，G1具备如下特点：

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
• 分代收集：与其他收集器一样，分代概念在G1中仍然保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
• 空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
• 可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间上不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

4.7.2 G1收集器的划分

在G1之前，其他的收集器的收集范围都是整个新生代或者老年代，而G1不再是这样。G1收集器将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不再是连续）的集合。

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。

G1收集的运作大致可划分为以下几个步骤：

• 初始标记（Initail Marking）
• 并发标记（Concurrent Marking）
• 最终标记（Final Marking）
• 筛选回收（Live Data Counting and Evacuation）

5、内存分配和回收策略

5.1、对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。

Minor GC和Full GC的区别：

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较块。

老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。

5.2大对象直接进入老年代

所谓大对象是指，需要大量连续内存空间的Java对象。

大对象对虚拟机的内存分配来说是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。

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

虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1，当年龄增加到一定程度（默认为15），将会被晋升到老年代。

5.4、动态对象年龄判定

为了更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代。

5.5、空间分配担保

Minor GC之前，虚拟机一般会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，确保Minor GC是安全的。

三、虚拟机性能监控与故障处理工具

1、JDK的命令行工具

jps：虚拟机进程状况工具

jstat：虚拟机统计信息监视工具

jinfo：Java配置信息工具

jmap：Java内存映像工具

jhat：虚拟机堆转储快照分析工具

jstack：Java堆栈跟踪工具

HSDIS：JIT生成代码反编译

2、JDK的可视化工具

JDK自带的可视化工具：JConsole 和 VisualVM

外部工具：Eclipse Memory Analyzer、IBM HeapAnalyzer等

四、虚拟机类加载机制

1、类加载的时机

类加载的生命周期：

1）加载

2）验证

3）准备

4）解析

5）初始化

6）使用

7）卸载

验证、准备、解析3个部分统称为连接。

对于初始化阶段，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候

2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化

3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化

4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类

5）当使用JDK1.7的动态语言支持时，如果一个java.lang,invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化

2、类加载的过程

2.1加载

“加载”是“类加载”过程的一个阶段，在加载阶段，虚拟机需要完成以下3个过程：

1）通过一个类的全限定名来获取定义此类的二进制字节流

2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

2.2验证

验证是连接阶段的第一步，从整体上看，验证阶段大致上会完成4个阶段的校验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

2.3准备

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

2.4解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

2.5初始化

类初始化阶段是类加载过程的最后一步。

3、类加载器

从Java虚拟机的角度来讲，只存在两种不同的类加载器：

①启动类加载器，这个类加载由C++语言实现，是虚拟机自身的一部分

②所有其他的类加载器，由Java语言实现，都继承抽象类java.lang.ClassLoader

从Java开发人员的角度看，类加载器可以划分得更细致些：

①启动类加载器

②扩展类加载器

③应用程序类加载器

④自定义加载器

类加载器的双亲委派模型在JDK1.2期间被引入并广泛应用于之后几乎所有的Java程序中，但它并不是一个强制性的约束模型，而是Java设计者推荐给开发者的一种加载器实现方式。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。