文章目录
- 1. JVM视角下,内存划分
- 2. 类内存分布硬核详解
- 1. 获取堆内存参数
- 2. 扫描堆内存,定位实例
- 3. 查看实例所在地址的数据
- 4. 找到实例所指向的类信息的地址
- 5. 查看class信息
- 6. 结论
- 3. Java的对象创建流程
- 4. 垃圾判别算法
- 4.1 引用计数法
- 4.2 可达性分析算法
- 5. 垃圾收集算法
- 5.1 标记-清除算法
- 5.2 标记-复制算法
- 5.3 标记-整理算法
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创建可视化窗口,可以查看最全面的信息,具体如下
通过上述两幅图,我们可以返现很多有趣的细节
- _mark字段,mark其实就是markword,对象头的意思。markword能够存储相当丰富的信息,比如分代年龄,gc次数,偏向锁,重锁等等信息。
- _metadata._klass,类型指针,指向类型com.xhf.test.Test.class。该字段用于表示当前实例是哪个类的实例
- 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的时间