从new Class()入手浅看JVM的oop-klass模型

从new Class()入手浅看JVM的oop-klass模型

首先讲下Java中一个类创建实例如ClassX x = new ClassX()时在整个JVM（Hotspot）中的大致流程：

初始JVM会加载ClassX这个类到perm区，也叫方法区（以前在Hotspot存放于永久代，后来被移到Metaspace），解析完字节码文件以后JVM会创建一个与ClassX类相对应的类模板对象，这个所谓的类模板对象其实就是个C++类的实例（hotspot中就是klassOop的实例对象instanceKlass）。
即类加载的结果便是在jvm的方法区中创建了一个与java类对等的instanceKlass，instanceKlass中保存了ClassX这个Java类所定义的所有信息如：变量、方法、接口、构造函数、属性等等。
此时要注意，jvm在创造instanceKlass后，还会创造一个mirror镜像：这个镜像就是传说中的java.lang.Class，但是需要注意的是这个所谓的镜像类也就是java_lang_Class其实也是一个instanceKlass实例对象，是之前instanceKlass实例对象的镜像，instanceKlass是给jvm内部访问用的而java.lang.Class是暴露给java程序用的。

PS1:在openJDK8中instanceKlassHandle ClassFileParser::parseClassFile里面调用的了一个java_lang_Class::create_mirror，来创建了一个mirror镜像InstanceMirrorKlass，而class InstanceMirrorKlass是继承于 public InstanceKlass的 ，（甚至jdk6的create_mirror直接创建的就是InstanceKlass，在JDK 6及之前的HotSpot VM里，静态字段依附在InstanceKlass对象的末尾；而在JDK 7开始的HotSpot VM里，静态字段依附在java.lang.Class对象的末尾，所以7之后包装成了InstanceMirrorKlass，其实本质还是差不多的，详情请见永远的神R大的回答）。

PS2：在JDK7或之前的HotSpot里，InstanceKlass是被包装在由GC管理的klassOopDesc对象中，存放在GC堆中的所谓Permanent Generation（简称PermGen）中。从JDK 8开始的HotSpot VM则完全移除了PermGen，改为在native memory里存放这些元数据。新的用于存放元数据的内存空间叫做Metaspace，InstanceKlass对象就存在这里。至于java.lang.Class对象（mirror），它们从来都是“普通”Java对象，跟其它Java对象一样存在普通的Java堆（GC堆的一部分）里。

在加载处理完ClassX类的一系列逻辑之后，Hotspot会在堆中为其实例对象x开辟一块内存空间存放实例数据，即JVM在实例化ClassX时，又会创建一个instanceOop，这个instanceOop就是ClassX对象实例x在内存中的对等体，用来存储实例对象的成员变量。
让我们来看下instanceOop.hpp（位于OpenJDK\hotspot\src\share\vm\oops\目录下），发现instanceOop是继承自oopDesc的（class instanceOopDesc : public oopDesc），继续看下Oop的结构就会发现：

class oopDesc {
	//友元类
	friend class VMStructs;
	private:
		volatile markOop  _mark;
		union _metadata {
			Klass*      _klass;
			narrowKlass _compressed_klass;
		} _metadata;

	// Fast access to barrier set.  Must be initialized.
	//用于内存屏障
	static BarrierSet* _bs;
	........
}

_mark和_metadata加起来就是我们传说中的对象头了，其中markOop的变量_mark用来标识GC分代信息、线程状态、并发锁等信息。而_metadata的联合结构体则用来标识元数据（指向元数据的指针），什么是元数据呢，概念一点就是这个类包含的父类、方法、变量、接口等各种信息，通俗一点来说就是我们上文中所提到的instanceKlass。仔细看_metadata包含两个元素，根据名我们也可以轻易地看出来_klass是个正常的指针/或者说宽指针（OpenJDK7以前叫做wideKlassOop），而_compressed_klass则是被压缩过得指针。

OpenJDK8的oopDesc跟OpenJDK7里的是略有不同。不过主要的不同并不是在mark word上，而是在metadata部分：以前如klassOopDesc、methodOopDesc等元数据，虽然并非Java对象，但也由GC直接管理；到OpenJDK 8时，这些metadata都被移到GC掌管之外的native memory，于是oopDesc这个对象头里metadata的指针就不是一个oop，而是native直接指针（或者压缩的native直接指针了）。具体不做解释了，感兴趣请出门左拐yyds R大的回答。

由于是union类型，所以_metadata还是占用了8字节的空间，但是JVM会根据计算把合适的field字段放入闲置的4字节空间，当然如果不合适就保持一个4字节的padding填充来保持对齐（如果是数组对象则会用来存放描述长度的length，如typeArrayOop或objArrayOop）。关于内存对齐和字段重排，又是个可以写的话题，不如有时间单独写一篇文章（一般这么说就是没时间，摔）。

至此，JVM已经为ClassX类创建了对应的oop-klass模型，oop对应instanceOop对应类实例，klass对应instanceKlass对应java类。整个三者的关系大致是这样（偷得R大的图）：

Java object      InstanceKlass       Java mirror
 [ _mark  ]                          (java.lang.Class instance)
 [ _klass ] --> [ ...          ] <-\  
 [ fields ]     [ _java_mirror ] --+> [ _mark  ]
                [ ...          ]   |  [ _klass ]
                                   |  [ fields ]
                                    \ [ klass  ]
（在堆中）      （在prem区）       （在堆中）

我们来创建一个ClassX：

public class ClassX {
	boolean b;
	Object o1;
	int i;
	long l;
	Object o2;
	float f;
}

这个ClassX的实例的内存布局，我们可以使用JOL（Java Object Layout）来进行查看，使用方法及简介请移步。
64位下开启指针压缩：

Running 64-bit HotSpot VM.

Using compressed oop with 3-bit shift.

Using compressed klass with 3-bit shift.

Objects are 8 bytes aligned.

Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

ClassX object internals:
OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8     4                    (object header)                           05 c1 00 f8 (00000101 11000001 00000000 11111000) (-134168315)
12     4                int ClassX.i                                  0
16     8               long ClassX.l                                  0
24     4              float ClassX.f                                  0.0
28     1            boolean ClassX.b                                  false
29     3                    (alignment/padding gap)
32     4   java.lang.Object ClassX.o1                                 null
36     4   java.lang.Object ClassX.o2                                 null
Instance size: 40 bytes
Space losses: 3 bytes internal + 0 bytes external = 3 bytes total

ClassX@2ef1e4fad object externals:
ADDRESS       SIZE TYPE   PATH                           VALUE
76b5e9a98         40 ClassX                                (object)

64位下不开启指针压缩：

Running 64-bit HotSpot VM.

Objects are 8 bytes aligned.

Field sizes by type: 8, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

Array element sizes: 8, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

ClassX object internals:
OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8     4                    (object header)                           90 35 20 1c (10010000 00110101 00100000 00011100) (471872912)
12     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
16     8               long ClassX.l                                  0
24     4                int ClassX.i                                  0
28     4              float ClassX.f                                  0.0
32     1            boolean ClassX.b                                  false
33     7                    (alignment/padding gap)
40     8   java.lang.Object ClassX.o1                                 null
48     8   java.lang.Object ClassX.o2                                 null
Instance size: 56 bytes
Space losses: 7 bytes internal + 0 bytes external = 7 bytes total

ClassX@2ef1e4fad object externals:
ADDRESS       SIZE TYPE   PATH                           VALUE
129ed5378         56 ClassX                                (object)

我们可以清楚地看到，在未开启指针压缩时:

+0: [ _mark (8 bytes) ]
+8: [ _klass (8 bytes) ]
+16: [ field : long ClassX.l (8 bytes) ]
…
+40: [ field : java.lang.Object ClassX.o1 (8 bytes) ]
+48: [ field : java.lang.Object ClassX.o2 (8 bytes) ]

在开启指针压缩后：

+0: [ _mark (8 bytes) ]
+8: [ _narrow_klass (4 bytes) ]
+12: [ padding or first field (4 bytes) ] (此时为int ClassX.i 4bytes)
+16: [ field : long ClassX.l (8 bytes) ]
…
+32: [ field : java.lang.Object ClassX.o1 (4 bytes) ]
+36: [ field : java.lang.Object ClassX.o2 (4 bytes) ]

ps:关于指针压缩与8 bytes aligned的渊源，我们留到以后再嗦（又挖坑写完了，右转《字节对齐与Java的指针压缩》）。

当然整个oop-klass体系是很庞大的，不仅类是对象，方法是对象，字节码常量池也是对象，如果我们查看描述Hotspot中类型信息的oppsHierarchy.hpp就会发现oop分为很多：

typedef class oopDesc*                            oop;
typedef class   instanceOopDesc*            instanceOop;
typedef class   arrayOopDesc*                    arrayOop;
typedef class     objArrayOopDesc*            objArrayOop;
typedef class     typeArrayOopDesc*            typeArrayOop;
......

同理klass也有很多：

class Klass;
class   InstanceKlass;
class     InstanceMirrorKlass;
class     InstanceClassLoaderKlass;
class     InstanceRefKlass;
class   ArrayKlass;
class     ObjArrayKlass;
class     TypeArrayKlass;
......

JVM还是很博大精深的，这里只是浅谈一下oop-klass模型，毕竟源码…我自己也没看完哈哈哈啊。