JVM基础篇以及JVM内存泄漏诊断与分析

1 Java 中的四种引用类型及区别

在 Java 中，引用类型决定了对象如何被垃圾回收器（GC）回收，这对于管理内存、防止内存泄漏以及构建高性能应用至关重要。Java 提供了四种引用类型，按照从强到弱的顺序排列如下：

• 强引用 (Strong Reference)
• 软引用 (Soft Reference)
• 弱引用 (Weak Reference)
• 虚引用 (Phantom Reference)

它们的主要区别在于垃圾回收器对待它们的态度不同，即一个对象在何时可以被 GC 回收。

---

1.1 强引用 (Strong Reference)

这是我们平时最常用的、默认的引用类型。

• 定义：类似于 Object obj = new Object(); 这样的引用。只要强引用还存在，垃圾回收器就永远不会回收被引用的对象。
• 何时被回收：当没有任何强引用指向该对象时（即将 obj 设置为 null，或者 obj 离开了其作用域），该对象才变得可被回收。
• 用途：日常编程中绝大部分的对象引用都是强引用。
• 代码示例：

  // 创建一个强引用
  MyClass strongRef = new MyClass();
  // 取消强引用，对象变得可被回收
  strongRef = null;
  

---

1.2 软引用 (Soft Reference)

• 定义：用来描述一些还有用但并非必需的对象。
• 何时被回收：
  • 在内存充足的情况下，垃圾回收器不会回收被软引用关联的对象。
  • 在内存不足，即将发生 OutOfMemoryError 之前，垃圾回收器会把这些对象列入回收范围进行第二次回收。如果这次回收后还是没有足够的内存，才会抛出内存溢出异常。
• 用途：非常适合实现内存敏感的缓存（如图片、大文件等缓存）。
• 代码示例：

  import java.lang.ref.SoftReference;// 创建对象和软引用
  MyClass myObject = new MyClass();
  SoftReference<MyClass> softRef = new SoftReference<>(myObject);// 取消强引用，只剩下软引用
  myObject = null;// 使用缓存
  MyClass cachedObject = softRef.get();
  if (cachedObject == null) {// 对象已被回收，重新创建cachedObject = new MyClass();softRef = new SoftReference<>(cachedObject);
  }
  

---

1.3 弱引用 (Weak Reference)

• 定义：用来描述非必需的对象，它比软引用的生命周期更短。
• 何时被回收：无论当前内存是否充足，只要发生了垃圾回收，被弱引用关联的对象就会被回收。
• 用途：用于生命周期短的缓存或 WeakHashMap（防止内存泄漏）。
• 代码示例：

  import java.lang.ref.WeakReference;MyClass myObject = new MyClass();
  WeakReference<MyClass> weakRef = new WeakReference<>(myObject);// 取消强引用
  myObject = null;System.gc(); // 建议GC，不保证立即执行if (weakRef.get() == null) {System.out.println("对象已被GC回收");
  }
  

---

1.4 虚引用 (Phantom Reference)

• 定义：是最弱的一种引用关系。无法通过虚引用来获取一个对象实例。
• 何时被回收：在对象被垃圾回收器回收之后，会收到一个系统通知。
• 如何工作：必须和引用队列 (ReferenceQueue) 联合使用。用于在对象被 GC 之后，执行一些收尾工作。
• 用途：对象回收跟踪、堆外内存（Direct Buffer）清理等。
• 代码示例：

  import java.lang.ref.PhantomReference;
  import java.lang.ref.ReferenceQueue;ReferenceQueue<MyClass> queue = new ReferenceQueue<>();
  MyClass myObject = new MyClass();PhantomReference<MyClass> phantomRef = new PhantomReference<>(myObject, queue);myObject = null;// 监控 queue，如果有引用被加入，说明其引用的对象已经被GC完全回收了
  

---

1.5 总结对比表格

引用类型	被 GC 回收的时机	用途	获取对象 (get())	强度
强引用	永远不会被GC主动回收，除非没有任何强引用指向它	普通对象引用，Java默认行为	返回对象本身	最强
软引用	在内存不足，即将OOM时	实现内存敏感的缓存	内存不足前返回对象，不足后可能返回null	次强
弱引用	只要发生GC，就会被回收	实现易失性缓存、WeakHashMap防止内存泄漏	GC后很可能返回null	弱
虚引用	无法通过它获取对象，GC后会被放入引用队列以通知	对象回收跟踪、堆外内存清理等收尾工作	总是返回 null	最弱

1.6 关键补充：引用队列 (ReferenceQueue)

软引用、弱引用和虚引用都可以在创建时与一个 ReferenceQueue 关联。当引用的对象被垃圾回收器回收后，这个引用对象本身会被加入到这个队列中。程序可以通过监控这个队列，来了解哪些对象已经被回收，从而执行一些后续的清理操作。

2 产线有遇到过内存泄漏吗？

2.1 先通过jstat命令确认是否存在内存泄漏

jstat -gc 这是一个非常强大的监控 JVM 内存和 GC 行为的工具

2.1.1 每2秒打印一次GC信息

使用命令：jstat -gc <pid> 2s

2.1.2 观察 FGC/FGCT (Full GC次数/耗时) 和 OU (老年代使用量)

假设你执行 jstat -gc 1 1s，会得到类似下面的输出（不同的 GC 收集器，列可能会略有不同，以下是基于 Parallel Scavenge + Parallel Old 的经典布局）：

各列含义详细解释如下：

2.1.2.1 新生代 (Young Generation) / 堆内存

S0C (Survivor 0 Capacity): Survivor 0区 的当前容量 (KB)。S1C (Survivor 1 Capacity): Survivor 1区 的当前容量 (KB)。S0U (Survivor 0 Utilization): Survivor 0区 已使用的空间 (KB)。S1U (Survivor 1 Utilization): Survivor 1区 已使用的空间 (KB)。观察技巧：在两次 Young GC 之间，S0U 和 S1U 总是一个为 0，另一个有数据，因为存活的对象会在两个 Survivor 区之间来回拷贝。EC (Eden Capacity): Eden区 的当前容量 (KB)。EU (Eden Utilization): Eden区 已使用的空间 (KB)。观察技巧：EU 会持续快速增长，直到接近 EC，然后触发 Young GC (YGC)，EU 会瞬间下降。OC (Old Capacity): 老年代 的当前容量 (KB)。OU (Old Utilization): 老年代 已使用的空间 (KB)。这是判断内存泄漏的关键指标！如果 OU 在每次 Full GC (FGC) 后持续上升，或者只升不降，很可能存在内存泄漏。

2.1.2.2 元空间 (Metaspace) / 非堆内存 (Java 8+)

在 Java 8 之前，这部分是永久代 PermGen，列名为 PC 和 PU

MC (Metaspace Capacity): Metaspace 的提交容量 (KB)。可以近似理解为当前分配的元空间大小。MU (Metaspace Utilization): Metaspace 已使用的空间 (KB)。观察技巧：如果 MU 不断接近 MC，并且 MC 不断增长，可能意味着类加载器泄漏或动态生成了大量类（如CGlib代理）。CCSC (Compressed Class Space Capacity): 压缩类空间 的提交容量 (KB)。这是 Metaspace 中专门用于存储类元信息的一部分。CCSU (Compressed Class Space Utilization): 压缩类空间 已使用的空间 (KB)。

2.1.2.3 垃圾收集统计 (最重要的监控指标)

• YGC (Young GC Count): 从应用启动至今，发生 Young GC 的总次数。
• YGCT (Young GC Time): 从应用启动至今，Young GC 消耗的总时间（秒）。
  计算平均耗时：YGCT / YGC。如果这个值突然变大，说明年轻代回收效率变低。
• FGC (Full GC Count): 从应用启动至今，发生 Full GC 的总次数。
• FGCT (Full GC Time): 从应用启动至今，Full GC 消耗的总时间（秒）。
  这是最重要的性能指标之一，频繁的 FGC (FGC 快速增长) 或长时间的 FGC (FGCT 很高) 会直接导致应用卡顿、响应变慢。
• CGC (Concurrent GC Cycles) 含义：从应用启动至今，完成的并发GC周期的总次数。
  解释：对于像ZGC这样的收集器，它的工作流程分为多个阶段，其中很多阶段（如标记、重定位、引用处理）是和应用线程一起并发执行的。每一次完整的垃圾收集循环被称为一个周期（Cycle），CGC 就是统计这个周期数。它类似于传统GC中的 YGC 或 FGC，但概念不同，因为ZGC等是不分代的。
• CGCT (Concurrent GC Time) 含义：从应用启动至今，所有并发GC阶段所花费的总时间（秒）。
  解释：这是所有并发阶段消耗的CPU时间的总和。需要注意的是：因为这是并发执行的，所以这部分时间不一定都会转化为应用的暂停时间（Latency）。应用线程在并发阶段可以继续运行，只是可能会因为与GC线程竞争CPU资源而稍微变慢。
• GCT (GC Time): 从应用启动至今，垃圾收集的总时间（秒）。GCT = YGCT + FGCT + CGCT。

2.1.2.4 关键监控技巧

• 内存泄漏判断：重点关注 OU (老年代使用量) 和 FGC (Full GC 次数)。如果 FGC 频繁发生，但每次 GC 后 OU 下降很少甚至不降反升，基本可以断定有内存泄漏。

• GC 健康度：关注 YGCT/YGC (平均 Young GC 耗时) 和 FGCT/FGC (平均 Full GC 耗时)。如果平均耗时过长，需要调优。

• 实时观察：使用 jstat -gc 1s（每秒输出一次）来动态观察 EU 的快速增长和回收，以及 OU 的缓慢变化趋势。

2.1.3 疑似内存泄漏的现象

频繁进行 Full GC (FGC 快速上升)，但每次 GC 后老年代使用量 (OU) 居高不下，甚至持续增长，最终导致 java.lang.OutOfMemoryError: Java heap space。

确认是内存泄漏后，再使用 jmap进行堆内存信息分析。

2.2 使用jmap命令分析堆信息（推荐）

2.2.1 生成堆转储 (Heap Dump)

生成堆转储有两种常用方式：

• 使用 jmap 命令 (最直接的方式)

  jmap -dump:format=b,file=heapdump.hprof <pid>
  <pid>：目标 Java 进程的 ID。可以用 jps 或 ps -ef | grep java 查看。
  heapdump.hprof：输出的堆转储文件名。
  

• 在应用启动时添加 JVM 参数 (适合预生产环境或已发生 OOM 的场景)

  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump.hprof
  

  当发生 OOM 时，JVM 会自动生成堆转储文件，这是分析 OOM 问题的利器。

建议：为了获取最佳分析效果，最好在内存占用已经很高（例如达到 70%-90%）但还未发生 OOM 的时候手动执行 jmap 命令生成转储。

2.2.2 分析堆转储文件

上一步，我们使用jmap 生成了 .hprof 文件，但分析它需要借助图形化工具，不要尝试用文本编辑器打开！

2.2.2.1 推荐使用以下工具（任选其一即可）

• Eclipse MAT (Memory Analyzer Tool) - 最强力推荐

  功能极其强大，专门为分析内存泄漏设计， 官网下载：https://www.eclipse.org/mat/

2.2.2.2 VisualVM

JDK 自带的工具，也可以打开堆转储，功能比 MAT 弱一些，但简单易用

2.2.2.3 JProfiler, YourKit (商业软件)

功能全面，非常专业，但需要付费

2.2.3 在 MAT 中快速定位可疑类

这是最关键的一步，使用 Eclipse MAT 打开 heapdump.hprof 文件后，它会自动生成一个 Leak Suspects Report (泄漏嫌疑报告)。

核心操作流程如下：

2.2.3.1 查看自动分析报告

打开堆转储后，MAT 会首先提示你生成一个报告。选择 Leak Suspects Report。

在这个报告的 Overview 页面，直接看 Problem Suspect 1 部分。MAT 会基于对象保留集的大小，直接告诉你它怀疑哪个对象占用了大量内存，以及这个对象被谁引用着。

示例：它可能会说“com.example.LeakyClass 的实例通过 static 字段 java.util.HashMap$Node[] 被根对象持有，占据了 98% 的堆”。

2.2.3.2 使用直方图 (Histogram) 功能

如果自动分析报告不够清晰，可以点击工具栏上的 Histogram 图标。

这里会列出所有类的实例数量以及它们的 Shallow Heap (对象本身大小) 和 Retained Heap (这个对象被回收后能释放的总内存，包括它引用的其他对象)。

技巧：

点击表头Retained Heap 进行降序排序。排在最前面的类就是占用内存最多的“嫌疑犯”。

重点关注你自己编写的业务类、以及常用的集合类（如 HashMap, ArrayList, char[], String 等）。

2.2.3.3 分析支配树 (Dominator Tree)

在 Histogram 中右键点击一个可疑的类（例如 MyServlet），选择 Immediate Dominators。

支配树可以清晰地展示哪些对象在“支配”（即直接或间接持有）着这些大量的实例，内存泄漏的根源通常是这个支配者。

技巧：
在支配树中寻找那些本应被回收但却存活着的对象，例如：

被 static 字段引用的对象

被生命周期很长的线程局部变量 (ThreadLocal) 引用的对象

被缓存引用但未被及时清理的对象

2.2.3.4 查看对象引用链 (Path to GC Roots)

在 Histogram 或 Dominator Tree 中，右键点击一个可疑的对象实例，选择 Path To GC Roots -> with all references。

这个功能会显示这个对象到垃圾收集根节点（如静态变量、线程栈中的局部变量等）的完整引用链。

这是找到“为什么这个对象无法被回收”的终极方法。仔细查看这条链，找到那个本应断开却未断开的引用。
通常问题就出在：

一个全局的、不断增长的 静态HashMap 用作缓存但无淘汰策略。

一个未正确清理的 ThreadLocal。

监听器注册后未反注册。

对象被放入某个集合后，业务逻辑执行完毕却忘记移除。

2.2.3.5 总结与快速 checklist

• 确认问题：jstat 看 FGC 和 OU，确认老年代只增不减。
• 抓取快照：在内存高位时，用 jmap -dump:format=b,file=heapdump.hprof 生成堆转储。
• 工具分析：用 Eclipse MAT 打开 .hprof 文件。
• 寻找线索：首选看 Leak Suspects Report 的自动分析。不行就看 Histogram，按 Retained Heap 排序，找最大的和自己写的类。右键可疑类，用 Dominator Tree 和 Path to GC Roots 功能，定位持有这些对象的“根”引用。
• 定位根源：分析引用链，找到那个本应释放但未释放的引用（通常是静态集合、缓存、全局配置等）。

通过这个流程，你可以非常高效地利用 jmap 生成的堆转储，快速 pinpoint 到导致内存泄漏的那个问题类及其根源。

2.3 使用jmap快速诊断问题（推荐）

上面那种方案，在生成完整的堆转储（可能好几GB）会非常慢，在不生成庞大堆转储文件的情况下，有没有可以迅速窥探堆内存中哪些类的实例最多、哪些类占用的总内存最大的方法呢？答案是：有

2.3.1 命令jmap -histo:live 1 | head -n 200

使用命令jmap -histo:live 1 | head -n 200，命令含义解释：

• jmap -histo:live 1 含义如下

jmap：JDK 自带的命令行内存分析工具。
-histo：选项，表示输出堆内存的直方图（Histogram）。它会显示每个类的实例数量、内存占用等信息。
:live：这是一个非常重要的修饰符。它告诉 jmap，在生成直方图之前，先触发一次 Full GC。这样，直方图中统计的就只包含存活的对象。排除了即将被回收的垃圾对象，使得结果更能反映实际的内存使用情况，而不是历史分配情况。
1：这是目标 Java 进程的进程 ID (PID)。你需要将其替换为你实际要调查的 Java 进程的 PID。可以使用 jps 或 ps -ef | grep java 命令来查找 PID。警告：在生产环境使用 :live 选项会触发 STW (Stop-The-World) 的 Full GC，会导致所有应用线程暂停，可能引起服务短暂卡顿。请谨慎使用。

*| 含义

|
这是 Linux/Unix 系统中的“管道”符。它将前一个命令 (jmap) 的标准输出，作为后一个命令 (head) 的标准输入。

• head -n 200含义

head -n 200
head：一个用于显示文件开头部分内容的命令。-n 200：选项，告诉 head 只显示输入内容的前 200 行。为什么是 200？ jmap -histo 的输出可能非常长（尤其是对于大型应用），会列出 JVM 中加载的所有类。我们通常只关心最顶部的几十个占用内存最大的类。200 是一个经验值，确保能覆盖到所有重要的条目，同时又不会让终端输出刷屏。

2.3.2 输出结果解读

执行命令后，你会看到类似这样的输出（格式大致如下）：

各列的含义：
num：序号。

#instances：该类的存活实例的数量。

#bytes：所有存活实例总共占用的内存大小（字节）。这是我们最关注的列。

class name：类的全限定名。

2.3.3 如何快速找到问题类？

• 按占用内存排序
  输出结果默认就是按 #bytes 降序排列的，所以排在第一位的，就是占用内存最多的类

• 重点关注前10-20行
  内存泄漏或消耗大户，通常就隐藏在最前面这些条目里

• 看懂类名

  [B：表示 byte[] 数组。这通常是存储内容数据（如图片、文件、序列化数据等）的主力，经常排第一。[C：表示 char[] 数组。这是 String 类内部用来存储字符的数据，所以大量的字符串操作会导致它排名靠前。[I：表示 int[] 数组。[L<some.class>;：表示某个类的对象数组。例如 [Ljava.util.HashMap$Node; 是 HashMap$Node[]。java.lang.String：字符串，无处不在。你自己的业务类：例如上面的 cn.smilehappiness.distribute.utils.PaddedAtomicLong 这是最可疑的（当然这里是正常的，这里只是举例内存占用比较靠前），如果你的一个业务类实例数不多，但占用内存巨大（Retained Heap大），或者实例数量多得离谱，它很可能就是内存泄漏的元凶。
  

2.3.4 总结与使用场景

• 这个命令的优势：
  速度快：相比生成完整的堆转储（可能好几GB），这个命令执行迅速，输出结果立即可见。

  开销相对小：虽然 :live 会触发 Full GC，但比生成堆转储对系统的影响要小。

  快速定位：能让你在几秒钟内就知道堆里是“谁”在占着内存。

• 这个命令的局限性：
  只能看“是什么”，不能看“为什么”：它告诉你 LeakyClass 有很多实例，但不会告诉你这些实例为什么无法被GC回收。要弄清引用链和根源，还是需要分析完整的堆转储（.hprof 文件）并使用 MAT 等工具。另外， :live 会触发 Full GC，不适合在要求极高可用性的场景下频繁使用。

• 最佳实践：
  将此命令作为 “初步侦察” 工具。当你通过监控发现老年代内存使用率持续升高时，用这个命令快速看一下是不是某个特定类的实例数或内存占用异常。如果发现可疑类，再决定是否在业务低峰期使用 jmap -dump 生成完整堆转储进行深度分析。

3 JVM调优

3.1 说一下 JVM 调优的工具？

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是jconsole 和 jvisualvm 这两款视图监控工具。

• jconsole：用于对 JVM 中的内存、线程和类等进行监控；
• jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等。

3.2 常用的 JVM 调优的参数都有哪些？

-Xms2g：初始化推大小为 2g
-Xmx2g：堆最大内存为 2g
-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4
-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2
–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合
-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合
-XX:+PrintGC：开启打印 gc 信息
-XX:+PrintGCDetails：打印 gc 详细信息

4 JVM类加载机制

4.1 JVM加载Class文件的原理机制

简述：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，解析和初始化，最终形成可以被虚拟机直接使用的java类型。

Java中的所有类，都需要由类加载器装载到JVM中才能运行。类加载器本身也是一个类，而它的工作就是把class文件从硬盘读取到内存中。在写程序的时候，我们几乎不需要关心类的加载，因为这些都是隐式装载的，除非我们有特殊的用法，像是反射，就需要显式的加载所需要的类。

类装载方式，有两种：

• 隐式装载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中
• 显式装载， 通过class.forname()等方法，显式加载需要的类Java类的加载是动态的，它并不会一次性将所有类全部加载后再运行，而是保证程序运行的基础类（像基类）完全加载到jvm中，至于其他类，则在需要的时候才加载，这当然就是为了节省内存开销。

4.2 什么是类加载器，类加载器有哪些?

定义：实现通过类的全限定名（包名+类名）获取该类的二进制字节流的代码块叫做类加载器。

类加载器，对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性，每一个类加载器，都有一个独立的类名称空间，类加载器就是根据指定全限定名称将 class 文件加载到JVM 内存，然后再转化为 class 对象。

主要有四种类加载器：

• 启动类加载器(Bootstrap ClassLoader)：用来加载java核心类库Java_HOME\lib目录中的，或者被 -Xbootclasspath 参数所指定的路径中并且被虚拟机识别的类库，无法被java程序直接引用。
• 扩展类加载器(extensions class loader)：它用来加载 Java 的扩展库\lib\ext目录或Java. ext.dirs系统变量指定的路径中的所有类库，该类加载器在此目录里面查找并加载 Java 类。
• 系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它，一般来说，如果我们没有自定义类加载器默认就是用这个加载器。
• 用户自定义类加载器，通过继承 java.lang.ClassLoader类的方式实现

4.3 说一下类装载的执行过程？

类装载分为以下 5 个步骤：

• 加载：根据查找路径找到相应的 class 文件然后导入
• 验证：检查加载的 class 文件的正确性
• 准备：给类中的静态变量分配内存空间
• 解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直接引用直接指向内存中的地址
• 初始化：对静态变量和静态代码块执行初始化工作

5 什么是双亲委派模型？

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

当一个类收到了类加载请求时，不会自己先去加载这个类，而是将其委派给父类，由父类去加载，如果此时父类不能加载，反馈给子类，由子类去完成类的加载。

6 说一下 JVM 的主要组成部分及其作用？

6.1 JVM作用

首先通过编译器把 Java 代码转换成字节码，类加载器（ClassLoader）再把字节码加载到内存中，将其放在运行时数据区（Runtime data area）的方法区内，而字节码文件只是 JVM 的一套指令集规范，并不能直接交给底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution Engine），将字节码翻译成底层系统指令，再交由 CPU 去执行，而这个过程中需要调用其他语言的本地库接口（Native Interface）来实现整个程序的功能。

以一句话来概括就是：类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。

6.2 JVM主要组成部分

JVM包含两个子系统和两个组件，两个子系统为Class loader(类装载子系统)、Execution engine（执行引擎系统）。两个组件为Runtime data area（运行时数据区）、Native Interface（本地接口）。

• Class loader(类装载)：根据给定的全限定名类名来装载class文件到Runtime data area中的method area
• Execution engine（执行引擎）：执行classes中的指令
• Native Interface(本地接口)：与native libraries交互，是其它编程语言交互的接口
• Runtime data area(运行时数据区域)：这就是我们常说的JVM的内存

6.3 JVM运行时数据区

Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存区域划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有些区域随着虚拟机进程的启动而存在，有些区域则是依赖线程的启动和结束而建立和销毁。不同虚拟机的运行时数据区可能略微有所不同，但都会遵从 Java 虚拟机规范，Java 虚拟机所管理的内存被划分为如下几个区域，Java 虚拟机规范规定的区域分为以下 5 个部分：

• 方法区（Methed Area）：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据
• Java 堆（Java Heap）：Java 虚拟机中内存最大的一块，是被所有线程共享的，几乎所有的对象实例都在这里分配内存
• Java 虚拟机栈（Java Virtual Machine Stacks）：用于存储局部变量表、操作数栈、动态链接、方法出口等信息
• 本地方法栈（Native Method Stack）：与虚拟机栈的作用是一样的，只不过虚拟机栈是服务 Java 方法的，而本地方法栈是为虚拟机调用 Native 方法服务的
• 程序计数器（Program Counter Register）：当前线程所执行的字节码的行号指示器，字节码解析器的工作是通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能，都需要依赖这个计数器来完成

6.4 深拷贝和浅拷贝有什么区别？

6.4.1 浅拷贝（shallowCopy）

浅拷贝指的是： 只是增加了一个指针，指向已存在的内存地址

6.4.2 深拷贝（deepCopy）

深拷贝指的是： 增加了一个指针并且申请了一个新的内存，使这个增加的指针，指向这个新的内存，使用深拷贝的情况下，释放内存的时候，不会因为出现浅拷贝时释放同一个内存的错误

6.4.3 浅复制

仅仅是指向被复制的内存地址，如果原地址发生改变，那么浅复制出来的对象也会相应的改变

6.4.4 深复制

在计算机中开辟一块新的内存地址用于存放复制的对象

6.5 说一下堆栈的区别？

6.5.1 物理地址

• 堆的物理地址分配对对象是不连续的，因此性能慢些。在GC的时候也要考虑到不连续的分配，所以有各种算法。比如，标记-清除，复制，标记-整理，分代（即新生代使用复制算法，老年代使用标记-整理）

• 栈使用的是数据结构中的栈，先进后出的原则，物理地址分配是连续的，所以性能快

6.5.2 内存分别

• 堆因为是不连续的，所以分配的内存是在运行期确认的，因此大小不固定，一般堆大小远远大于栈
• 栈是连续的，所以分配的内存大小要在编译期就确认，大小是固定的

6.5.3 存放的内容

• 堆存放的是对象的实例和数组，因此该区更关注的是数据的存储
• 栈存放的是局部变量，操作数栈，返回结果，该区更关注的是程序方法的执行
  静态变量放在方法区，静态的对象还是放在堆

6.5.4 程序的可见度

• 堆对于整个应用程序都是共享、可见的
• 栈只对于线程是可见的，所以也是线程私有，他的生命周期和线程相同

6.6 队列和栈是什么？有什么区别？

队列和栈都是被用来预存储数据的。

6.6.1 操作的名称不同

• 队列的插入称为入队，队列的删除称为出队
• 栈的插入称为进栈，栈的删除称为出栈

6.6.2 可操作的方式不同

• 队列是在队尾入队，队头出队，即两边都可操作
• 栈的进栈和出栈都是在栈顶进行的，无法对栈底直接进行操作

6.6.3 操作的方法不同

• 队列是先进先出（FIFO），即队列的修改是依先进先出的原则进行的。新来的成员总是加入队尾（不能从中间插入），每次离开的成员总是队列头上（不允许中途离队）
• 栈为后进先出（LIFO），即每次删除（出栈）的总是当前栈中最新的元素，即最后插入（进栈）的元素，而最先插入的被放在栈的底部，要到最后才能删除

7 垃圾回收

7.1 GC是什么？为什么要GC

GC 是垃圾收集的意思（Gabage Collection），内存处理是编程人员容易出现问题的地方，忘记或者错误的内存回收，会导致程序或系统的不稳定甚至崩溃，Java 提供的 GC 功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的，Java 语言没有提供释放已分配内存的显示操作方法。

7.2 简述Java垃圾回收机制

Java语言最显著的特点就是引入了垃圾回收机制，它使java程序员在编写程序时不再考虑内存管理的问题。由于有这个垃圾回收机制，java中的对象不再有“作用域”的概念，只有引用的对象才有“作用域”。

在java中，程序员是不需要显示的去释放一个对象的内存的，而是由JVM虚拟机自行执行。垃圾回收器通常作为一个单独的低级别的线程运行，在不可预知的情况下对内存堆中已经死亡的或很长时间没有用过的对象进行清除和回收。垃圾回收机制有效的防止了内存泄露，可以有效的使用可使用的内存。

在正常情况下是不会执行的，只有在虚拟机空闲或者当前堆内存不足时，才会触发执行，扫面那些没有被任何引用的对象，并将它们添加到要回收的集合中，进行回收。

7.3 垃圾回收器的基本原理是什么？垃圾回收器可以马上回收内存吗？有什么办法主动通知虚拟机进行垃圾回收？

• 对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。通常，GC采用有向图的方式记录和管理堆(heap)中的所有对象。通过这种方式确定哪些对象是"可达的"，哪些对象是"不可达的"。当GC确定一些对象为"不可达"时，GC就有责任回收这些内存空间。

• 可以

• 程序员可以手动执行System.gc()，通知GC运行，但是Java语言规范并不保证GC一定会执行。

7.4 怎么判断对象是否可以被回收？

垃圾收集器在做垃圾回收的时候，首先需要判定的就是哪些内存是需要被回收的，哪些对象是「存活」的，是不可以被回收的，哪些对象已经「死掉」了，需要被回收。

一般有两种方法来判断：

7.4.1 引用计数器法

为每个对象创建一个引用计数，有对象引用时计数器 +1，引用被释放时计数 -1，当计数器为 0 时就可以被回收。它有一个缺点：不能解决循环引用的问题

7.4.2 可达性分析算法

从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是可以被回收的。

当对象对当前使用这个对象的应用程序变得不可触及的时候，这个对象就可以被回收了。

7.5 JVM中的永久代中会发生垃圾回收吗

垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)，这就是为什么正确的永久代大小对避免Full GC是非常重要的原因

注：Java8中已经移除了永久代，新加了一个叫做元数据区的native内存区

7.6 JVM 有哪些垃圾回收算法？

7.6.1 标记-清除算法

标记无用对象，然后进行清除回收
缺点：效率不高，无法清除垃圾碎片

7.6.2 复制算法

按照容量划分二个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块上，然后再把已使用的内存空间一次清理掉 缺点：内存使用率不高，只有原来的一半

7.6.3 标记-整理算法

标记无用对象，让所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存

7.6.4 分代算法

根据对象存活周期的不同将内存划分为几块，一般是新生代和老年代，新生代基本采用复制算法，老年代采用标记整理算法

当前商业虚拟机都采用分代收集的垃圾收集算法。分代收集算法，顾名思义是根据对象的存活周期将内存划分为几块。一般包括年轻代、老年代 和 永久代（Java8中已经移除了永久代，新加了一个叫做元数据区的native内存区），如图所示：

7.7 JVM 有哪些垃圾回收器？

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器，其中用于回收新生代的收集器包括 Serial、PraNew、Parallel Scavenge，回收老年代的收集器包括SerialOld、Parallel Old、CMS，还有用于回收整个Java堆的G1收集器。不同收集器之间的连线表示它们可以搭配使用。

新生代回收器：Serial、ParNew、Parallel Scavenge
老年代回收器：Serial Old、Parallel Old、CMS
整堆回收器：G1

• Serial收集器（复制算法)：新生代单线程收集器，标记和清理都是单线程，优点是简单高效

• ParNew收集器 (复制算法)：新生代并行收集器，实际上是Serial收集器的多线程版本，在多核CPU环境下有着比Serial更好的表现

• Parallel Scavenge收集器 (复制算法): 新生代并行收集器，追求高吞吐量，高效利用 CPU。吞吐量 = 用户线程时间/(用户线程时间+GC线程时间)，高吞吐量可以高效率的利用CPU时间，尽快完成程序的运算任务，适合后台应用等对交互相应要求不高的场景

• Serial Old收集器 (标记-整理算法)：老年代单线程收集器，Serial收集器的老年代版本

• Parallel Old收集器 (标记-整理算法)： 老年代并行收集器，吞吐量优先，Parallel Scavenge收集器的老年代版本

• CMS(Concurrent Mark Sweep)收集器（标记-清除算法）： CMS 是英文 Concurrent Mark-Sweep 的简称，是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动 JVM 的参数加上- XX:+UseConcMarkSweepGC来指定使用 CMS 垃圾回收器。CMS 使用的是标记-清除的算法实现的，所以在 gc 的时候回产生大量的内存碎片，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent ModeFailure，临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低。
  CMS是老年代并行收集器，以获取最短回收停顿时间为目标的收集器，具有高并发、低停顿的特点，追求最短GC回收停顿时间。

• G1(Garbage First)收集器 (标记-整理算法)： Java堆并行收集器，G1收集器是JDK1.7提供的一个新收集器，G1收集器基于标记-整理算法实现，也就是说不会产生内存碎片。此外，G1收集器不同于之前的收集器的一个重要特点是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种收集器回收的范围仅限于新生代或老年代

7.8 简述分代垃圾回收器是怎么工作的？

分代回收器有两个分区： 新生代和老年代，新生代默认的空间占比总空间的1/3，老生代的默认占比是 2/3
新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、FromSurvivor，它们的默认占比是 8:1:1，它的执行流程如下：

• 把 Eden + From Survivor 存活的对象放入 To Survivor 区
• 清空 Eden 和 From Survivor 分区
• From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，ToSurvivor 变 From Survivor，S0U 和 S1U 总是一个为 0，另一个有数据，因为存活的对象会在两个 Survivor 区之间来回拷贝
  每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老年代（老生代）。大对象也会直接进入老生代。老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。

7.9 对象优先在 Eden 区分配

多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存。这里我们提到 Minor GC，如果你仔细观察过 GC 日常，通常我们还能从日志中发现 Major GC/Full GC。

• Minor GC 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所以 Minor GC 非常频繁，一般回收速度也非常快
• Major GC/Full GC 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC，Major GC 的速度通常会比 Minor GC 慢 10 倍以上

7.10 大对象直接进入老年代

所谓大对象是指需要大量连续内存空间的对象，频繁出现大对象是致命的，会导致在内存还有不少空间的情况下提前触发 GC 以获取足够的连续空间来安置新对象。前面我们介绍过新生代使用的是标记-清除算法来处理垃圾回收的，如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制，因此对于大对象都会直接在老年代进行分配。

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

虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区中每「熬过」一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15） 就会被晋升到老年代。