---

若文章内容或图片失效，请留言反馈。部分素材来自网络，若不小心影响到您的利益，请联系博主删除。

---

总目录

---

• 学习笔记【Java 虚拟机快速入门①】内存结构
• 学习笔记【Java 虚拟机快速入门②】垃圾回收

---

前言

---

• 视频链接：https://www.bilibili.com/video/BV1yE411Z7AP
• 配套资料：https://pan.baidu.com/s/167mob33EfeD-on6dWrEWGQ（ 提取码：bqob）

• 参考书籍：《深入理解 JAVA 虚拟机 | JVM 高级特性与最佳实践》 周志明 著

参考文章

• jmap 命令详解：https://zhuanlan.zhihu.com/p/475571429
• JVM 垃圾回收 超详细学习笔记（二）：https://blog.csdn.net/weixin_53142722/article/details/125418216

---

（二）垃圾回收

---

8.如何判断对象可以回收

---

8.1.思考

---

参考书籍：《深入理解 JAVA 虚拟机 | JVM 高级特性与最佳实践》 周志明 著

---

下图为 Java 虚拟机运行时数据区

---

在 Java 内存运行时区中的三个区域：程序计数器、虚拟机栈、本地方法栈

• 这 3 个区域随线程而生，随线程而灭，
• 栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。

每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的

• （尽管在运行期会由即时编译器进行一些优化，但在基于概念模型的讨论里，大体上可以认为是编译期可知的）
• 因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑如何回收的问题
• 当方法结束或者线程结束时，内存自然就跟随着回收了。

---

而 Java 堆和方法区这两个区域则有着很显著的不确定性

• 一个接口的多个实现类需要的内存可能会不一样
• 一个方法所执行的不同条件分支所需要的内存也可能不一样

只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。

垃圾收集器所关注的正是这部分内存该如何管理，后续讨论中的 “内存” 分配与回收也仅仅特指这一部分内存。

---

在堆里面存放着 Java 世界中几乎所有的对象实例，

垃圾收集器在对堆进行回收前，

第一件事情就是要确定这些对象之中哪些还 “存活” 着，哪些已经“死去”（“死去” 即不可能再被任何途径使用的对象）了。

---

8.2.引用计数法

---

8.2.1.概念

---

---

参考书籍：《深入理解 JAVA 虚拟机 | JVM 高级特性与最佳实践》 周志明 著

---

很多教科书判断对象是否存活的算法是这样的：

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

---

客观地说，引用计数算法（Reference Counting） 虽然占用了一些额外的内存空间来进行计数。

但它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。

有一些比较著名的应用案例都使用到了引用计数算法进行内存管理

• 微软 COM（Component Object Model）技术
• 使用 ActionScript 3 的 FlashPlayer
• Python 语言
• 在游戏脚本领域得到许多应用的 Squirrel。

但是，在 Java 领域，至少主流的 Java 虚拟机里面都没有选用引用计数算法来管理内存。

主要原因是，这个看似简单的算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作。

譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。

---

8.2.2.举例分析

---

参考书籍：《深入理解 JAVA 虚拟机 | JVM 高级特性与最佳实践》 周志明 著

---

举个简单的例子：具体见下面的代码块中的 testGC() 方法

• 对象 objA 和 objB 都有字段 instance，赋值令 objA.instance=objB 及 objB.instance=objA。
• 除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问。
• 但是它们因为互相引用着对方，导致它们的引用计数都不为零，引用计数算法也就无法回收它们。

代码块：引用计数算法的缺陷

/**
 * testGC()方法执行后，objA 和 objB 会不会被 GC 呢？
 */
public class ReferenceCountingGC {
    public Object instance = null;
    private static final int _1MB = 1024 * 1024;
    /**
     * 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否有回收过
     */
    private byte[] bigSize = new byte[2 * _1MB];
    
    public static void testGC() {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();

        objA.instance = objB;
        objB.instance = objA;

        objA = null;
        objB = null;

        // 假设在这行发生GC，objA 和 objB 是否能被回收？
        System.gc();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

运行结果

[Full GC (System) 

	[Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), 
		[Perm : 2999K->2999K(21248K)],
	0.0150007 secs] 
	
	[Times: user=0.01 sys=0.00, real=0.02 secs] Heap
	def new generation total 9216K, used 82K [0x00000000055e0000, 0x0000000005fe0000, 0x0000000005fe0000)
	Eden space 8192K, 1% used [0x00000000055e0000, 0x00000000055f4850, 0x0000000005de0000)
	from space 1024K, 0% used [0x0000000005de0000, 0x0000000005de0000, 0x0000000005ee0000)
	to space 1024K, 0% used [0x0000000005ee0000, 0x0000000005ee0000, 0x0000000005fe0000)
	tenured generation total 10240K, used 210K [0x0000000005fe0000, 0x00000000069e0000, 0x00000000069e0000)
	the space 10240K, 2% used [0x0000000005fe0000, 0x0000000006014a18, 0x0000000006014c00, 0x00000000069e0000)
	compacting perm gen total 21248K, used 3016K [0x00000000069e0000, 0x0000000007ea0000, 0x000000000bde0000)
	the space 21248K, 14% used [0x00000000069e0000, 0x0000000006cd2398, 0x0000000006cd2400, 0x0000000007ea0000)
	No shared spaces configured.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

从运行结果中可以清楚看到内存回收日志中包含 “4603K->210K”

这意味着虚拟机并没有因为这两个对象互相引用就放弃回收它们

这也从侧面说明了 Java 虚拟机并不是通过引用计数算法来判断对象是否存活的。

---

8.3.可达性分析算法

---

8.3.1.概念

---

可达性分析（Reachability Analysis）

• Java 虚拟机中的垃圾回收器采用可达性分析来探索所有存活的对象。
• 扫描堆中的对象，看是否能够沿着 GC Root 对象为起点的引用链找到该对象。找不到，表示可以回收。

---

8.3.2.案例演示

---

• 哪些对象可以作为 GC Root 呢？这里作一下相关的演示来了解这些情况 （自己看视频吧） 。

---

/**
 * 演示 GC Roots
 */
public class Demo2_1 {
    public static void main(String[] args) throws InterruptedException, IOException {
        List<Object> list1 = new ArrayList<>();
        list1.add("a");
        list1.add("b");
        System.out.println(1);
        System.in.read();

        list1 = null;
        System.out.println(2);
        System.in.read();
        System.out.println("end...");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

---

1. 首先使用 jps 命令来查看进程 id

---

2. 之后再通过 jmap 工具来转存文件。

（之前介绍过其可以查看堆内存占用情况：jmap -heap 进程id）

• jmap 能够打印给定 Java 进程、核心文件或远程 DEBUG 服务器的共享对象内存映射或堆内存的详细信息。
• 如果给定的进程运行在 64 位虚拟机上，则必须指定 -J-d64 选项，例如 jmap -J-d64 -heap pid。
• jmap 可能在未来的 JDK 版本中删除。

jmap -dump:format=b,live,file=1.bin 进程id
1

-dump:[live,]format=b,file=

• 将 Java 堆以 hprof 二进制格式转储到 filename 文件中。
• live 是可选参数，如果指定，则只转储堆中的活动对象。
• 可以使用 MAT（Memory Analyzer） 工具来分析内容。

---

3. 打开 Eclipse Memory Analyzer（该工具可单独使用，无需下载 Eclipse）对使用 jmap 工具生成的文件来进行分析。

MAT 下载地址：https://www.eclipse.org/mat/downloads.php

• Eclipse Memory Analyzer

• gc roots

在上面的软件分析中出现了四个对象，这里先稍稍解释以下对象在软件中的情况。

• System Class
  • 系统类，由启动类加载器加载的类，即一些核心类，都是 java.lang.Class 类的实例对象
• JNI Global
  • 在本地方法栈中 JNI（即通常所说的 Native 方法）引用的对象。
• Thread
  • 一些活动线程。线程运行时都由一次次的方法调用组成，每一次调用都会产生一个栈帧
  • 即栈帧类所使用的一些东西，它们也是可以作为根对象的。
  • 其中线程中用到的局部变量引用的对象
• Busy Monitor
  • 被同步锁持有的对象

---

List