画图理解JVM相关内容

1. JVM视角下，内存划分

tip: 额外补充

• 在以“分代设计”为主导的堆内存，其控件划分大致如上图所示。但G1垃圾回收期为分解，后续的内存设计并没有都参考分代理论，因此jdk8以后（G1大规模运用在jdk8之后），内存划分有待商榷
• 堆虽然是线程共享的，但他可以为线程划分缓冲区——Thread Local Allocation Buffer，TLAB。TLAB是线程私有的。但无论怎么划分，堆都是存储对象实例
• 直接内存：属于操作系统本地内存，不归JVM管理。因此GC对他无效

2. 类内存分布硬核详解

既然是硬核，不来点内存轰炸是对不起硬核两字。

下文主要讲述一个类在创建过程中，可能会涉及到的所有类在内存的分布情况。包括JVM层面的instanceKlass，Java层面的Test实例，Test.class

下文内容比较硬核，请读者酌情阅读。另外，底层指针分析可能存在纰漏，欢迎读者友善指出

让我们开始！

demo代码如下

package com.xhf.test;

// -XX:+UseSerialGC -Xmn10M -XX:-UseCompressedOops
public class TestDemo {
    public static void main(String[] args) {
        new Test();
        while (true) {}
    }
}

package com.xhf.test;

public class Test {
    private static Integer a;
    private Integer b;
    private int c;
    public int d;

    private void func() {}
    public void func2() {}
}

1. 获取堆内存参数

打开HSDB，扫描堆的整体内存范围 universe

Heap Parameters:
Gen 0:   eden [0x0000000080000000,0x00000000803845a8,0x0000000080800000) space capacity = 8388608, 43.96257400512695 used
  from [0x0000000080800000,0x0000000080800000,0x0000000080900000) space capacity = 1048576, 0.0 used
  to   [0x0000000080900000,0x0000000080900000,0x0000000080a00000) space capacity = 1048576, 0.0 usedInvocations: 0

Gen 1:   old  [0x0000000080a00000,0x0000000080a00000,0x000000008fe00000) space capacity = 255852544, 0.0 usedInvocations: 0

其它信息我们可以不用关注，只需要知道，eden区的范围是0x0000000080000000 0x0000000080800000，绝大多数情况下，对象的空间有限划分在eden区域。因此，我们想要探查Test示例相关内存地址，需要扫描eden区域

2. 扫描堆内存，定位实例

scanoops 0x0000000080000000 0x0000000080800000 com.xhf.test.Test

hsdb> scanoops 0x0000000080000000 0x0000000080800000 com.xhf.test.Test
0x000000008023e2d0 com/xhf/test/Test

主程序运行new Test();，他的实例对象被划分在0x000000008023e2d0地址

3. 查看实例所在地址的数据

inspect 0x000000008023e2d0

hsdb> inspect 0x000000008023e2d0
instance of Oop for com/xhf/test/Test @ 0x000000008023e2d0 @ 0x000000008023e2d0 (size = 32)
_mark: 1
_metadata._klass: InstanceKlass for com/xhf/test/Test
b: null null
c: 0
d: 0

在控制台上通过指令，查看不到最全面的信息，通过Tools->inspector创建可视化窗口，可以查看最全面的信息，具体如下

通过上述两幅图，我们可以返现很多有趣的细节

1. _mark字段，mark其实就是markword，对象头的意思。markword能够存储相当丰富的信息，比如分代年龄，gc次数，偏向锁，重锁等等信息。
2. _metadata._klass，类型指针，指向类型com.xhf.test.Test.class。该字段用于表示当前实例是哪个类的实例
3. b, c, d：3个字段属于oop，但a不属于oop，a属于Test.class，因为他是静态变量。此外，b这个Object被赋值null，c，d两个基本int类型赋值为0

4. 找到实例所指向的类信息的地址

我们找到Test oop，但没有找到存储Test类信息的数据地址。inspect无法直接看到_metadata._klass指向的地址，我们通过内存扫描，直接查看内存数据

mem 0x000000008023e2d0 2 ：查看0x000000008023e2d0地址，偏移2个单位（8bit）

hsdb> mem 0x000000008023e2d0 2
0x000000008023e2d0: 0x0000000000000001 
0x000000008023e2d8: 0x0000000013ff3400 

0x0000000013ff3400，就是oop指向的Test类信息所在地址

注意，笔者这里并没有说明0x0000000013ff3400是Test.class类对象的地址

5. 查看class信息

如下图所示，0x0000000013ff3400才是class真正的信息，这也被称为元信息，被JVM存储在meta space中

！！！需要注意的是，0x0000000013ff3400地址上的内容不是Java意义上的Test.class这个类

笔者为什么会这么说呢？原因是JVM内部采用C++的instanceKlass描述
Java类，并且会将instanceKlass分配到meta space

而instanceKlass有个叫做_java_mirror的字段，它指向的才是Java类的Class对象

本例中就是Test.class这个对象

我们监视这个地址inspect 0x000000008023e210

hsdb> inspect 0x000000008023e210
instance of Oop for java/lang/Class @ 0x000000008023e210 @ 0x000000008023e210 (size = 168)
a: null null

发现_java_mirror指向的对象，是java/lang/Class类（Test.class），并且大小168bit

我们扫描0x000000008023e210往后的168bit（21个8bit）内存空间

mem 0x000000008023e210 21

hsdb> mem 0x000000008023e210 21
0x000000008023e210: 0x0000000000000001 
0x000000008023e218: 0x0000000013c03ed0 
0x000000008023e220: 0x0000000000000000 
0x000000008023e228: 0x0000000000000000 
0x000000008023e230: 0x0000000000000000 
0x000000008023e238: 0x00000000800dba38 
0x000000008023e240: 0x0000000000000000 
0x000000008023e248: 0x0000000000000000 
0x000000008023e250: 0x0000000000000000 
0x000000008023e258: 0x0000000000000000 
0x000000008023e260: 0x0000000000000000 
0x000000008023e268: 0x0000000000000000 
0x000000008023e270: 0x0000000000000000 
0x000000008023e278: 0x0000000080239560 
0x000000008023e280: 0x0000000000000000 
0x000000008023e288: 0x0000000000000000 
0x000000008023e290: 0x0000000013ff3400 
0x000000008023e298: 0x0000000000000000 
0x000000008023e2a0: 0x0000001500000000 
0x000000008023e2a8: 0x0000000000000001 
0x000000008023e2b0: 0x0000000000000000 

发现内存地址为0x000000008023e290时，存放的数据是：0x0000000013ff3400

而0x0000000013ff3400的内容，恰好是instanceKlass所在地址。

6. 结论

基于上述分析，我们得出如下结论：

Test实例 -> Test instanceKlass <-> Test.class

文字枯燥乏味，看图就好理解了

3. Java的对象创建流程

有了第2节的基础，第三节的分析自然就简单多了。

具体流程直接上图

这个流程中，具体的内存情况如下

tip:
严格来说，上图存在一定的问题。
由第2节可知，实例的指针指向的是instanceKlass，而非class对象。这里这么处理是为了方便画图。
而且，instanceKlass拥有class对象的指针，实例可以通过instanceKlass找到class对象，只是需要两次指针跳跃，所以上图绘制方式其实也并无太大问题

4. 垃圾判别算法

4.1 引用计数法

给对象增加计数器，当计数器为0，表示对象不再被引用。可以当作垃圾被垃圾清除器清理

这种算法的缺陷很明显，一方面开销大，JVM需要维护所有对象的引用计数器；另一方面，无法解决循环引用的问题

4.2 可达性分析算法

以GC Root根节点的集合，作为起始点。按照对象之间的引用关系向下遍历，如果某个对象无法和GC Root关联，那么我们认为该对象是不可达的，可以当作垃圾被回收

5. 垃圾收集算法

在讲解回收算法前，我们需要补充一些分代理论的基础知识

• 大部分对象都是朝生幕死，创建出来很快就被回收
• 如果一个对象经历了多次垃圾回收，那么该对象可以被认为是长时间存活的对象

曾经有个组织做过调查，98%的对象活不过一轮垃圾回收

考虑到对象存活时间长短存在差异，我们可以大致将堆内存划分为两块空间

• 新生代（Young Generation）
• 老年代（Old Generation）

新生代存放寿命短的对象；老年代存放长命的对象。这样在做垃圾回收时，可以根据不同区域对象存活特点做出不一样的垃圾回收策略，以此提高运行效率

5.1 标记-清除算法

标记清楚算法是最基础的垃圾回收算法，后续的算法基本都是在此基础上进行改进。

该算法的核心是

• 标记垃圾（可达性分析算法）
• 清除垃圾

标记-清除算法执行流程如上图所示

上述算法存在以下两个缺陷

• 算法效率不稳定：如果内存中存在大量需要清除的垃圾，JVM需要执行多次的清除操作；反之，如果垃圾数量较少，JVM执行清除操作次数就少
• 空间碎片：当JVM执行清除操作后，会存在大量内存碎片，内存中使用的空间不连续。这极大的降低了内存利用率，提高了内存申请的难度

5.2 标记-复制算法

标记-复制算法，将内存划分为等大的两个空间，一个空间用于存放对象，另一个空间用于预留。

当需要进行内存清除时，操作异常容易，因为两个区间在同一时刻只有一个区间存在使用的对象，因此只需要将存放对象的空间中，存活的对象复制到预留空间，然后清除原有空间的所有内容，即可完成垃圾回收

该算法让JVM只需要关注存活的对象，如果存活对象少，那么复制操作少，效率高，因此标记-复制算法一般用于Eden区域的垃圾回收。此外，该算法成功解决了内存碎片的问题

但显而易见，该算法带来了另一个问题

• 内存利用率低：该算法需要额外的空间进行存储，比标记清除算法大了1倍的空间

5.3 标记-整理算法

该算法就是在标记-清除的基础上，增加了整理的操作。对于清除后的内存空间，该算法会通过移动已使用的空间，让内存的使用再次连续

该算法解决了内存碎片问题，但移动存活对象这个操作引入了新的问题。就比如原先对象A引用了对象B，现在B的地址修改了，A如何感知到。此外，在移动过程中，需要暂停用户线程（Stop the world)，因此需要移动的对象数量要尽可能少，以此减少stop the world的时间