对象内存布局，生命周期
2018-07-04 本文已影响0人
peteLee
内存布局
布局
对象头：标记字（32位虚拟机4B，64位虚拟机8B） + 类型指针（32位虚拟机4B，64位虚拟机8B）+ [数组长（对于数组对象才需要此部分信息）]
实例数据
对齐填充：对于64位虚拟机来说，对象大小必须是8B的整数倍，不够的话需要占位填充
布局.png
- 对象头用于存储对象的元数据信息：
Mark Word 部分数据的长度在32位和64位虚拟机（未开启压缩指针）中分别为32bit和64bit，存储对象自身的运行时数据如哈希值等。Mark Word一般被设计为非固定的数据结构，以便存储更多的数据信息和复用自己的存储空间。
类型指针 指向它的类元数据的指针，用于判断对象属于哪个类的实例。 - 实例数据存储的是真正有效数据，如各种字段内容，各字段的分配策略为longs/doubles、ints、shorts/chars、bytes/boolean、oops(ordinary object pointers)，相同宽度的字段总是被分配到一起，便于之后取数据。父类定义的变量会出现在子类定义的变量的前面。
- 对齐填充部分仅仅起到占位符的作用，并非必须。
示例（以HashMap<Long,Long>为例）：
其只有Key和Value是有效数据，共28B=16B，包装成Long对象后分别具有了8B标记字和8B的类型指针，共24B2=48B；两个对象组成Map.Entry后多了16B对象头、一个8B的next字段、4B的int类型的hash字段，还必须添加4B的空白填充。共32B；最后还有对HashMap中对此Entry的8B的引用。所以空间利用率为 16B / (48B+32B+8B) ≈ 18%
对象的访问定位
对象的访问定位也取决于具体的虚拟机实现。当我们在堆上创建一个对象实例后，就要通过虚拟机栈中的reference类型数据来操作堆上的对象。现在主流的访问方式有两种（HotSpot虚拟机采用的是第二种）：
- 使用句柄访问对象。即reference中存储的是对象句柄的地址，而句柄中包含了对象实例数据与类型数据的具体地址信息，相当于二级指针。
- 直接指针访问对象。即reference中存储的就是对象地址，相当于一级指针。
两种方式有各自的优缺点。当垃圾回收移动对象时，对于方式一而言，reference中存储的地址是稳定的地址，不需要修改，仅需要修改对象句柄的地址；而对于方式二，则需要修改reference中存储的地址。从访问效率上看，方式二优于方式一，因为方式二只进行了一次指针定位，节省了时间开销，而这也是HotSpot采用的实现方式。下图是句柄访问与指针访问的示意图。
访问
生命周期
对象是否存活
- 引用计数器：给对象添加一个引用计数器，每当有一个地方引用他时，计数器值就加一，当引用失效时，计数器值就减一。任何时刻计数器为零的对象就是不可在被使用的。
分析：客观的说，引用计数器算法（Reference Counting）的实现简单，判定效率很高，在大部分情况下，都是一个不错的算法。但是，主流的Java 虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是他很难解决u对象之间相互循环引用的问题。例如：objA.instance = objB;及 objB.instance = objA;除此之外两个对象再无其他引用，实际上这两个对象已经不可能再被访问，但是他们因为互相引用着对方，导致他们的引用计数都不为零，于是引用计数算法无法通知GC收集器回收他们。 - 可达性分析算法
在主流的商用程序语言（Java ， C# 等）的主流实现中都是使用可达性分析（Reachability Analysis）来判定对象是否是存活的。
基本思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots 没有任何引用链相连（用图论的话来说就是从GC Roots 到这个对象不可达）时，则证明此对象是不可引用的。
在Java 语言中，可作为GC Roots的对象包括下面几种：
a.虚拟机栈（栈帧中的本地变量表）中引用的对象
b.方法区中类静态属性引用的对象
c.方法区中常量引用的对象
d.本地方法栈中JIT（即一般说的Native方法）引用的对象
