程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间。是线程私有的。它可以看作是当前线程所执行的字节码的行号指示器。什么意思呢？

白话版本：因为代码是在线程中运行的，线程有可能被挂起。即CPU一会执行线程A，线程A还没有执行完被挂起了，接着执行线程B，最后又来执行线程A了，CPU得知道执行线程A的哪一部分指令，线程计数器会告诉CPU。

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，CPU 只有把数据装载到寄存器才能够运行。寄存器存储指令相关的现场信息，由于CPU 时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。

因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储。每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器用来存放执行指令的偏移量和行号指示器等，线程执行或恢复都要依赖程序计数器。此区域也不会发生内存溢出异常。

直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现，所以我们放到这里一起讲解。

在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。如果内存区域总和大于物理内存的限制，也会出现OOM。

Code Cache

简而言之， JVM代码缓存是JVM将其字节码存储为本机代码的区域 。我们将可执行本机代码的每个块称为 nmethod 。该 nmethod可能是一个完整的或内联Java方法。

实时（JIT）编译器是代码缓存区域的最大消费者。这就是为什么一些开发人员将此内存称为JIT代码缓存的原因。

这部分代码所占用的内存空间成为CodeCache区域。一般情况下我们是不会关心这部分区域的且大部分开发人员对这块区域也不熟悉。如果这块区域OOM了，在日志里面就会看到 java.lang.OutOfMemoryError code cache。

诊断选项

JVM:常用的四种垃圾回收机制

CMS (Concurrent Mark Sweep)：

并行 标记清除 老年代垃圾回收机制

cms是一个基于标记-清除 算法的综合多种算法的老年代垃圾回收器

适用场景：重视服务器响应速度，要求系统停顿时间最短。

这里要说明下，这是一个老年代算法，年轻代怎么处理？不回收了嘛？这里其实年轻代是采用的其它算法，具体看策略，J ava 参数可以选择策略。这里下文也会涉及到

主要的pipeline如下

1、初始标记（CMS initial mark）

• “Stop The World”，仅仅只是标记一下 GC Roots 能直接关联到的对象，也就是根集合可直接到达的对象，但不会直接到叶子节点，还有遍历新生代对象，标记可达的老年代对象；速度很快。

  
  

  这些灰色的节点就是初始标记的节点 2.并发标记

• 再进行GC RootTracing的过程中，继续标记这些对象可以到达的对象，做可达性分析（可达性分析的思路就是通过引用链路判断对象是否可被触达，如果能触达说明该对象当前正在被使用，不可回收；反之，没有触达到的对象则认为是无使用的，可以回收。）

3、重新标记（CMS remark）

• “Stop The World”，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

这里有一个讨论：重新标记的意义在哪？主要是标记那些数据？

• remark阶段应该是以当前的gc roots开始再标记，但会跳过初始标记中已经被标记的数据，这样可以保证不会漏标。对于从存活到垃圾的这些对象来说，只能下次GC标记了。

4、并发清除（CMS concurrent sweep）

• 并行清理数据垃圾，回收内存。

优点：

• 并发收集

• 低停顿

缺点：

1. CPU 资源消耗过大 并发设计会对CPU敏感，CMS 默认启动的回收线程数：（CPU数量+3）/4，也就是当 CPU 在4个以上时，并发回收时垃圾收集线程不少于 25%。

2. CMS 收集器无法处理浮动垃圾 并发期间不用暂停，那么会导致这段期间产生的垃圾将不会被回收，只能下一次回收，这称作浮动垃圾。

3. 产生空间碎片 本质上是一个标记-清除 垃圾回收算法，意味着收集结束时会有大量空间碎片产生，给大对象分配空间带来麻烦，如果老年代无空间可存放大对象，得不提前触发一次 Full GC 。当然CMS也提供来一些Java 参数来帮助解决，比如顶不住压力时开启内存碎片的合并整理过程、多少次回收后使用该整理算法。

CMS（不带压缩）可以与Serial和ParNew进行组合，共2种组合垃圾回收算法。

Serial回收器：串行回收

• Serial收集器是最基本、历史最悠久的垃圾收集器了，JDK1.3之前回收新生代唯一的选择

• Serial收集器采用复制算法、串行回收，和"Stop一 the一World"机制的方式执行内存回收。

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

Serial回收器的优势

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

2. 运行在Client模式下的虛拟机是个不错的选择。 在用户的桌面应用场景中，可用内存一般不大（几十MB至一两百MB）， 可以在较短时间内完成垃圾收集（几十ms至一百多ms） ，只要不频繁发生，使用串行回收器是可以接受的。

3. 在HotSpot虛拟机中，使用-XX： +UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器。 等价于新生代用Serial GC，且老年代用Serial Old GC 控制台输出 -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC

Serial回收器总结：
这种垃圾收集器大家了解，现在已经不用串行的了。而且在限定单核cpu才可以用。现在都不是单核的了。
对于交互较强的应用而言，这种垃圾收集器是不能接受的。一般在Javaweb应用程序中是不会采用串行垃圾收集器的。

ParNew回收器:并行回收

Par是Parallel的缩写，New表示只能处理的是新生代

• ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、"Stop一 the一World"机制。

• ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器。

• 对于新生代，回收次数频繁，使用并行方式高效。

• 对于老年代，回收次数少，使用串行方式节省资源。（CPU并行 需要切换线程，串行可以省去切换线程的资源)

由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效？ ➢ParNew 收集器运行在多CPU的环境下，由于可以充分利用多CPU、 多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。 ➢但是在单个CPU的环境下，ParNew收 集器不比Serial收集器更高 效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。 除Serial Old外，目前ParNew GC还可以与CMS收集器配合工作

g1垃圾回收机制

所有的垃圾回收器的目的都是朝着减少STW的目的而前进，G1(Garbage First)回收器的出现颠覆了之前版本CMS、Parallel等垃圾回收器的分代收集方式，从2004年Sun发布第一篇关于G1的论文后，直到2012年JDK7发布更新版本，花了将近10年的时间G1才达到商用的程度，而到JDK9发布之后，G1成为了默认的垃圾回收器，CMS也变相地相当于被淘汰了。**

G1抛弃了之前的分代收集的方式，面向整个堆内存进行回收，把内存划分为多个大小相等的独立区域Region。 一共有4种Region：

• 自由分区Free Region

• 年轻代分区Young Region，年轻代还是会存在Eden和Survivor的区分

• 老年代分区Old Region

• 大对象分区Humongous Region

每个Region的大小通过-XX:G1HeapRegionSize来设置，大小为1~32MB，默认最多可以有2048个Region，那么按照默认值计算G1能管理的最大内存就是32MB*2048=64G。

对于大对象的存储，存在Humongous概念，对G1来说，超过一个Region一半大小的对象都被认为大对象，将会被放入Humongous Region，而对于超过整个Region的大对象，则用几个连续的Humongous来存储（如下图H区域）。

G1最大的优势就在于可预测的停顿时间模型，我们可以自己通过参数-XX:MaxGCPauseMillis来设置允许的停顿时间(默认200ms)，G1会收集每个Region的回收之后的空间大小、回收需要的时间，根据评估得到的价值，在后台维护一个优先级列表，然后基于我们设置的停顿时间优先回收价值收益最大的Region。

回收过程 G1的回收过程分为以下四个步骤：

1. 初始标记：标记GC ROOT能关联到的对象，需要STW

2. 并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，扫描完成后还会重新处理并发标记过程中产生变动的对象

3. 最终标记：短暂暂停用户线程，再处理一次，需要STW

4. 筛选回收：更新Region的统计数据，对每个Region的回收价值和成本排序，根据用户设置的停顿时间制定回收计划。再把需要回收的Region中存活对象复制到空的Region，同时清理旧的Region。需要STW。

相对于之前我们存在分代概念的GC来说，G1其实也是类似的过程，总体可以分为这两种：

• 年轻代GC，年轻代Region在超过我们默认设置的最大大小之后就会触发GC，还是用的我们熟悉的复制算法，Eden和Survivor来回倒腾，这里不再赘述。

• Mixed GC混合回收，混合回收类似于之前我们的Full GC概念，既会回收年轻代的Region，也会回收老年代的Region，还有我们新的Humongous大对象区域。触发规则根据参数-XX:InitiatingHeapOccupancyPercent(默认45%)值，也就是说老年代Region达到整个堆内存的45%时触发Mixed GC。