网站界面设计论文,wordpress伪静态 nginx,旧房翻新装修公司排名,网站建设奕网情深oop-klass模型
Hotspot 虚拟机在内部使用两组类来表示Java的对象和类。
oop(ordinary object pointer)#xff0c;用来描述对象实例信息。klass#xff0c;用来描述 Java 类#xff0c;是虚拟机内部Java类型结构的对等体 。
JVM内部定义了各种oop-klass#xff0c;在JV…oop-klass模型
Hotspot 虚拟机在内部使用两组类来表示Java的对象和类。
oop(ordinary object pointer)用来描述对象实例信息。klass用来描述 Java 类是虚拟机内部Java类型结构的对等体 。
JVM内部定义了各种oop-klass在JVM看来不仅Java类是对象Java 方法也是对象 字节码常量池也是对象一切皆是对象。JVM使用不同的oop-klass模型来表示各种不同的对象。 而在技术落地时这些不同的模型就使用不同的 oop 类instanceoop methodoop constmethodoop等等和 klass 类来表示 。由于JVM使用C/C编写因此这些 oop 和 klass 类便是各种不同的C类。对于Java类型与实例对象只叫使用 instanceOop 和 instanceKlass 这 2 个 C类来表示。
描述HotSpot中的oop 体系 也许是为了简化变量名JVM统一将最后的Desc去掉全部处理成以 Oop 结尾的类型名。 例如对于 Java 类中所定义的方法 只明使用 methodOop 去描述 Java 方法的全部信息对于 Java 类中所定义的引用对象变量 JVM则使用objArrayOop来保存这个引用变量的 “全息”信息。 纵观以上oop和 klass 体系的定义可以发现无论是 oop 还是 klass 基本都被划分为来分别描述 instance 、method 、constantMethod 、methodData 、array 、objArray 、typeArray 、constantPool 、 constantPoolCache 、klass 、compoiledICHolder这几种模型这几种模型中的每一种都有一个对应的 xxxOopDesc 和对应的 xxxKlass 。通俗而言这几种模型分别用于描述 Java 类类型和类型指针 、Java 方法类型和方法指针 、常量池类型及指针 、基本数据类型的数组类型及指针 、引用类型的数组类型及指针 、常量池缓存类型及指针、Java类实例对象类型及指针。Hotspot认为使用这几种模型 便足以勾画Java程序的全部 数据、方法 、类型 、数组和实例。
那么oop到底是啥其存在的意义究竟是什么其名称已经说得很清楚就是普通对象指 针。指针指向哪里指向 klass 类实例。直接这么说可能比较难以理解举个例子若 Java 程序中定义了一个类 ClassA 同时程序中有如下代码
Class a new ClassA ( );
当Hotspot执行到这里时会先将 ClassA 这个类型加载到 perm 区 也叫方法区 然后在 Hotspot 堆中为其实例对象a开辟一块内存空间存放实例数据。在 JVM加载ClassA到 perm 区时JVM就会创建一个instanceKlass,instanceKlass中保存了 ClassA 这个 Java 类中所定义的一切信息包括变量 、方法 、父类 、接 口、构造函数 、属性等所以 instanceKlass 就是 ClassA这个Java类类型结构的对等体。而 instanceOop 这个“普通对象指针”对象中包含了一个指针该指针就指向instanceKlass这个实例。在JVM实例化ClassA时JVM又会在堆中创建一个instanceOop , instanceOop便是 ClassA 对象实例 a 在内存中的对等体主要存储 ClassA 实例对象的成员变量。 其中instanceOop 中有一个指针指向 instanceKlass 通过这个指针JVM便可以在运行期获取这个类实例对象的类元信息。
oopDesc
既然讲到了oop就不得不提 JVM中所有oop对象的老祖宗oopDesc类。上述列表里的所有 oopDesc 诸如 instanceOopDesc 、constantPoolOopDesc 、klassOopDesc 等 在 C的继承体系中最终全都来自顶级的父类oopDesc ( JDK8中已经没有 oopDesc 换成了别的名字但是换汤不换药内部结构并没有什么太大的变化。 抛开友元类VMStructs以及用于内存屏障的_bs , oopDesc类中只剩下了2 个成员变量 友元类并不算成员变量 mark 和 metadata。其中 metadata 是联合结构体里面包含两个元素 分别是 wideKlassOop 与 narrowOop顾名思义前者是宽指针后者是压缩指针。关于宽指针与窄指针这里先简单提一句主要用于JVM是否对Java class进行压缩如果使用了压缩技术 自然可以节省出一定的宝贵内存空间。
oopDesc的这 2 个成员变量的作用很简单_mark顾名思义似乎是一种标记而事实上也的确如此Java 类在整个生命周期中会涉及到线程状态 、并发锁 、GC 分代信息等内部标识这些标识全都打在_mark变量上。而 _metadata顾名思义也很简单用于标识元数据。每一个 Java 类都会包含一定的变量 、方法 、父类 、所实现的接口等信息这些均可称为 Java 类的“元数据”其实可以更加通俗点所谓的元数据就是在前面反复讲的数据结构。Java类的结构信息在编译期被编译为字节码格式JVM则在运行期进一步解析字节码格式从字节码二进制流中还原出一个Java在源码期间所定义的全部数据结构信息JVM需要将解析出来结果保存到内存中以便在运行期进行各种操作例如反射而_metadata便起到指针的作用指向 Java 类的数据结构被解析后所保存的内存位置。
仍然以上一节所举的实例化ClassA这个自定义 Java 类的例子进行说明。当JVM完成ClassA类型的实例化之后会为该 Java 类创建对应的 oop-klass 模型 oop 对应的类是 instanceOop ,klass 对应的类是 instanceKlass 。上一节讲过 instanceOop 内部会有一个指针指向 instanceKlass 其实这个指针便是 oopDesc 中所定义的一_metadata。klass 是 Java类型的对等体 而 Java 类型 便是 Java 编程语言中用于描述客观事物的数据结构而数据结构包含一个客观事物的全部属性和行为 所以叫做 “类元”信息这便是_metadata的本意。
_metadata的作用可以参考下图所示。 两模型三维度
前文讲过JVM内部基于oop-klass模型描述一个 Java 类 将一个 Java 类一拆为二分别描述第一个模型是oop第二个模型是klass。所谓oop并不是object-oriented programming面向对象编程而是ordinary object pointer普通对象指针它用来表示对象的实例信息看起来像个指针而实际上对象实例数据都藏在指针所指向的内存首地址后面的一片内存区域中。 理解oop指向堆中实例对象所在内存区域的首地址
而klass则包含元数据和方法信息用来描述 Java 类而 klass 则包含元数据和方法信息用来描述 Java 类或者JVM内部自带的C类型信息。其实klass便是前文一直在讲的数据结构Java 类的继承信息、成员变量 、静态变量 、成员方法 、构造函数等信息都在 klass 中保存 JVM据此便可以在运行期反射出Java类的全部结构信息。当然JVM本身所定义的用于描述Java类的C类也使用klass去描述这相当于使用另一种面向对象的机制去描述C类这种本身便是面向对象的数据。
JVM使用 oop-klass 这种一分为二的模型描述一个 Java 类 虽然模型只有两种但是其实从 3 个不同的维度对一个 Java 类进行了描述。侧重于描述 Java 类的实例数据的第一种模型 oop 主要为 Java 类生成一张 “实例数据视图”从数据维度描述一个Java类实例对象中各个属性在运行期的值。而第二种模型 klass 则又分别从两个维度去描述一个 Java 类 第一个维度是 Java 类的“元信息视图”另一个维度则是虚函数列表或者叫作方法分发规则。元信息视图为JVM在运行期呈现Java类的“全息”数据结构信息这是JVM在运行期得以动态反射出类信息的基础。
下面的图描述了JVM内部对Java类的 “两模型三维度” 的映射。 体系总览
在JVM内部定义了3种结构去描述一种类型 oop 、klass 和 handle 类。注意这 3 种数据结构不仅能够描述外在的 Java 类 也能够描述 JVM内在的C类型对象。
前面讲过klass主要描述 Java 类和 JVM内部C类型的元信息和虚函数这些元信息的实际值就保存在oop里面。oop 中保存一个指针指向 klass 这样在运行期JVM便能够知道每一个实例的数据结构和实际类型。handle是对 oop 的行为的封装在访问 Java 类时一定是通过 handle 内部指针得到 oop 实例的再通过 oop 就能拿到 klass 如此 handle 最终便能操纵 oop 的行为了注意如果是调用JVM内部C类型所对应的oop的函数 则不需要通过 handle 来中转直接通过 oop 拿到指定的 klass便能实现。klass 不仅包含自己所固有的行为接口而且也能够操作 Java 类的函数。由于Java 函数在JVM内部都被表示成虚函数因此handle模型其实就是 Java 类行为的表达。
先上一张图说明这种三角关系。 可以看到Handle类内部只有一个成员变量一handle该变量类型是oop*因此该变量最终指向的就是一个oop的首地址。换言之只要能够拿到 Handle 对象便能据此得到其所指向的 oop 对象实例而通过oop 对象实例又能进一步获取其所关联的 klass 实例而获取到 klass 对象实例后便能实现对oop对象方法的调用。因此虽然从表面上看handle体系貌似是对 oop 的一种封装 但是实际上其醉翁之意在于最终的 klass 体系。
oop一般由对象头、对象专有属性和数据体这 3 部分构成。其一般结构如图所示。 oop体系
所谓oop就是ordinary object pointer 也即普通对象指针。但是究竟什么才是普通对象指针呢要搞清楚何谓 oop 要问2个问题
1 ) Hotspot里的 oop 指啥
Hotspot里的oop 其实就是 GC 所托管的指针每一个 oop 都是一种 xxxOopDesc*类型的指针。所有oopDesc及其子类 除神奇的 markOopDesc 外 的实例都由 GC 所管理这才是最最重要的是 oop 区分 Hotspot 里所使用的其他指针类型的地方。
2对象指针之前为何要冠以“普通”二字
对象指针从本质上而言就是一个指针指向xxxOopDesc的指针也是普通得不能再普通的 指针可是为何在 Hotspot 领域还要加一个“普通”来修饰要回答这个问题需要追溯到OOP 这里的OOP 是指面向对象编程 的鼻祖SmallTalk 语言。
SmallTalk语言里的对象也由 GC 来管理但是 SmallTalk 里面的一些简单的值类型对象都会使用所谓的 “直接对象”的机制来实现例如SmallTalk里面的整数类型。所谓 “直接对象”( immediate object 就是并不在 GC 堆上分配对象实例而是直接将实例内容存在对象指针里的对象。这样的指针也叫做 “带标记的指针”tagged pointer。
这一点倒是与markOopDesc类型如出一辙因为 markOopDesc 也是将整数值直接存储在指针里面 这个指针实际上并无“指向”内存的功能。
所以在SmallTalk的运行期 每当拿到一个对象指针时都得先校验这个对象指针是一个直接对象还是一个真的指针如果是真的指针它就是一个“普通”的对象指针了。这样对象指针就有了“普通”与“不普通”之分。
所以在Hotspot里面 oop 就是指一个真的指针而 markOop 则是一个看起来像指针但实际上是藏在指针里的对象数据。这也正是 markOop 实例不受 GC 托管的原因因为只要出了函数作用域指针变量就会直接被从堆枝上释放掉了不需要垃圾回收了。 klass体系
oop的讲述先告一段落 再来看看 klass 部分。按照JVM的官方解释klass主要提供下面2种能力
©klass提供一个与 Java 类对等的 C类型描述。©klass提供虚拟机内部的函数分发机制 。
其实这种说法与上文所说的2种维度的含义是相同的。klass 分别从类结构和类行为这两方面去描述一个 Java 类 当然也包含JVM内部非开放的C类。
与oop相同在JVM内部也不是klass一个人在战斗而是一个家族。klass 家族体系如下 handle体系
前面讲过handle封装了oop由于通过oop可以拿到 klass 而 klass 是对 Java 类数据结构和方法的描述 因此 handle 间接封装了 klass。JVM内部使用一个 table 来存储 oop 指针。
如果说oop是对普通对象的直接引用那么 handle 就是对普通对象的一种间接引用中间隔了一层。但是JVM内部为何要使用这种间接引用呢答案是这完全是为GC考虑。具体表现在2个地方
通过handle能够让 GC 知道其内部代码都有哪些地方持有 GC 所管理的对象的引用这只需要扫描 handle 所对应的 table 这样 JVM 便无须关注其内部到底哪些地方持有对普通对象的引用。
在GC过程中如果发生了对象移动例如从新生代移到了老年代那么JVM的内部引用无须跟着更改为被移动对象的新地址JVM 只需要更改 handle table 里对应的指针即可 。
当然实际的handle作为对 Java 类方法的访问的包装远不止上面所描述的这么简单。这里涉及 Java 类的类继承和接口继承的话题在 C领域类的继承和多态性最终通过vptr虚函数表来实现。在klass内部记录了每一个类的vptr信息具体而言分为两部分来描述。
1.vtable虚函数表
vtable中存放 Java 类中非静态和非 private 的方法入口JVM调用 Java 类的方法 非静态和非 private时最终会访问vtable找到对应的方法入口。
2.itable 接口函数表
itable中存放 Java 类所实现的接口的类方法。同样JVM调用接口方法时最终会访问itable,找到对应的接口方法入口。
不过要注意vtable和itable 里面存放的并不是Java类方法和接口方法的直接入口而是指向了 Method 对象入口JVM会通过Method最终拿到真正的 Java 类方法入口得到方法所对应的字节码二进制机器码并执行。当然对于被JIT进行动态编译后的方法JVM最终拿到的是其对应的被编译后的本地方法的入口。 这里有个问题前面不是一直在说handle是对 oop 的直接封装和对 klass 的间接封装吗为什么这里却分别给 oop 和 klass 定义了 2 套不同的 handle 体系呢这给人的感觉好像是封 装 oop 的 handle 和封装 klass 的 handle 并不是同一个 handle 既然不是同一个handle 那么通 过封装 oop 的handle 还怎么去得到所对应的 klass 信息呢
其实这正是只怕内部常常容易使人迷惑的地方。在JVM中使用oop-klass这种一分为二的模型去描述 Java 类以及 只叫内部的特殊类群体为此JVM内部特定义了各种oop和 klass类型。但是对于每一个oop其实都是一个 C类型也即 klass而对于每一个 klass 所对应的 class 在JVM内部又都会被封装成 oop。只怕在具体描述一个类型时会使用 oop 去存储这个类型的实例数据并使用 klass 去存储这个类型的元数据和虚方法表。而当一个类型完成其生命周期后JVM会触发 GC 去回收在回收时既要回收一个类实例所对应的实例数据 oop , 也要回收其所对应的元数据和虚方法表当然两者并不是同时回收一个是堆区的垃圾回收 一个是永久区的垃圾回收。为了让 GC 既能回收 oop 也能回收 klass因此 oop 本身被封装成了 oop 而 klass 也被封装成 oop。而只叫内部恰好将描述类实例的 oop 全都定义成类名以 oop 结尾的类并将描述类结构和方法信息的 klass 全都定义成类名以 klass 结尾的类 而只怕内部描述类信息的模型恰巧也叫作 oop-klass与类名存在重合这就导致了很多人的疑惑这些疑惑完全是因为叫法上的重合而产生。
因此为了进一步解开疑惑我们不妨换个叫法不再将JVM内部描述类信息的模型叫作
oop-klass而是叫作 data-meta 模型 瞎取的名字没啥特殊含义。然后将JVM内部的 oop 体系的类名全都改成以 Data结尾 例如methodData 、instanceData 、constantPoolData 等同时 将 klass 体系的类名也全都改成以 Meta 结尾例如methodMeta 、instanceMeta 、constantPoolMeta 等。JVM在进行 GC 时既要回收 Data 类实例也要回收 Meta 类实例为了让 GC 便于回收因此对于每一个 Data 类和每一个 Meta 类 JVM在内部都将其封装成了 oop 模型。对于 Data 类其内存布局是前面为 oop 对象头 后面紧跟实例数据而对 Meta 类 其内存布局是前面为 oop 对象头后面紧跟实例数据和虚方法表。封装成 oop 之后再进一步使用 handle 来封装 于是便有利于 GC 内存回收。
在这种新的模型中不管是Data类还是 Meta 类都是一种普通的 C类型只不过它们从不同的角度对 Java 类进行了描述。不管是 Data 类还是 Meta 类当其所在的JVM的内存区域爆满后都会触 GC为了方便回收因此就需要将其封装成 oop。
