共计 4570 个字符，预计需要花费 12 分钟才能阅读完成。
前言
上一篇咱们剖析了 Java 虚拟机办法执行流程及办法重载和办法重写原理，并剖析了办法的调用过程及原理，Java 虚拟机栈是线程公有的，没有数据安全问题，而堆相比拟于 Java 虚拟机栈而言更为简单，因为堆是所有线程共享的一块内存空间，会呈现线程安全性问题，而垃圾回收也次要是回收堆内空间，所以堆内的布局咱们十分有必要深刻去理解一下。当初就让咱们持续来剖析一下堆内布局以及 Java 对象在内存中的布局把。
对象的指向
先来看一段代码：
`package com.zwx.jvm;
public class HeapMemory {private Object obj1 = new Object();
public static void main(String[] args) {Object obj2 = new Object();
}
}` 下面的代码中，obj1 和 obj2 在内存中有什么区别？
咱们先来回顾一下 JVM 系列 1 的文章中有提到，办法区存储每个类的构造，比方：运行时常量池、属性和办法数据，以及办法和构造函数等数据。所以咱们这个 obj1 是存在办法区的，而 new 会创立一个对象实例，对象实例是存储在堆内的，于是就有了上面这幅图 ( 办法区指向堆 )：
而 obj2 是属于办法内的局部变量，存储在 Java 虚拟机栈内的栈帧中的局部变量表内，这就是经典的 栈指向堆 ：
这里咱们再来思考一下，咱们一个变量指向了堆，而堆内只是存储了一个实例对象，那么堆内的示例对象是如何晓得本人属于哪个 Class，也就是说这个实例是如何晓得本人所对应的类元信息的呢？这就波及到了一个 Java 对象在内存中是如何布局的。
Java 内存模型
对象内存中能够分为三块区域：对象头 (Header)，实例数据(Instance Data) 和对齐填充 (Padding)， 以 64 位操作系统为例 (未开启指针压缩的状况) Java 对象布局如下图所示：
其中对象头中的 Mark Word 中的详细信息在文章 synchronized 锁降级原理中有具体介绍。
上图中的对齐填充不是肯定有的，如果对象头和实例数据加起来刚好是 8 字节的倍数，那么就不须要对齐填充。
晓得了 Java 内存布局，那么咱们来看一个面试问题
Object obj=new Object()占用字节
这是网上很多人都会提到的一个问题，那么联合下面的 Java 内存布局，咱们来剖析下，以 64 位操作系统为例，new Object()占用大小分为两种状况：
- 未开启指针压缩
占用大小为：8(Mark Word)+8(Class Pointer)=16 字节 - 开启了指针压缩 (默认是开启的)
开启指针压缩后，Class Pointer 会被压缩为 4 字节，最终大小为：
8(Mark Word)+4(Class Pointer)+4(对齐填充)=16 字节
后果到底是不是这个呢？咱们来验证一下。
首先引入一个 pom 依赖：
`<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.10</version>
</dependency>` 而后新建一个简略的 demo：
`package com.zwx.jvm;
import org.openjdk.jol.info.ClassLayout;
public class HeapMemory {public static void main(String[] args) {Object obj = new Object();
System.out.println(ClassLayout.parseInstance(obj).toPrintable());
}
}` 输入后果如下：
最初的后果是 16 字节，没有问题，这是因为默认开启了指针压缩，那咱们当初把指针压缩敞开之后再去试试。
`-XX:+UseCompressedOops 开启指针压缩
-XX:-UseCompressedOops 敞开指针压缩 `
再次运行，失去如下后果：
能够看到，这时候曾经没有了对齐填充局部了，然而占用大小还是 16 位。
上面咱们再来演示一下如果一个对象中带有属性之后的大小。
新建一个类，外部只有一个 byte 属性：
`package com.zwx.jvm;
public class MyItem {byte i = 0;}` 而后别离在开启指针压缩和敞开指针压缩的场景下别离输入这个类的大小。
`package com.zwx.jvm;
import org.openjdk.jol.info.ClassLayout;
public class HeapMemory {public static void main(String[] args) {MyItem myItem = new MyItem();
System.out.println(ClassLayout.parseInstance(myItem).toPrintable());
}
}`
开启指针压缩, 占用 16 字节：
敞开指针压缩，占用 24 字节：
这个时候就能看进去开启了指针压缩的劣势了，如果一直创立大量对象，指针压缩对性能还是有肯定优化的。
对象的拜访
创立好一个对象之后，当然须要去拜访它，那么当咱们须要拜访一个对象的时候，是如何定位到对象的呢？
目前最支流的拜访对象形式有两种：句柄拜访 和间接指针拜访。
- 句柄拜访
应用句柄拜访的话，Java 虚构机会在堆内划分出一块内存来存储句柄池，那么对象当中存储的就是句柄地址，而后句柄池中才会存储对象实例数据和对象类型数据地址。 - 间接指针拜访 (Hot Spot 虚拟机采纳的形式)
间接指针拜访的话对象中就会间接存储对象类型数据。
句柄拜访和间接指针拜访比照
下面图形中咱们很容易比照，就是如果应用句柄拜访的时候，会多了一次指针定位，然而他也有一个益处就是，如果一个对象被挪动(地址扭转了)，那么只须要扭转句柄池的指向就能够了，不须要批改 reference 对象内的指向，而如果应用间接指针拜访，就还须要到局部变量表内批改 reference 指向。
堆内存
下面咱们提到，在 Java 对象头当中的 Mark Word 存储了对象的分代年龄，那么什么是分代年龄呢？
一个对象的分代年龄能够了解为垃圾回收次数，当一个对象通过一次垃圾回收之后还存在，那么分代年龄就会加 1，在 64 位的虚拟机中，分代年龄占了 4 位，最大值为 15。分代年龄默认为 0000，随着垃圾回收次数，会逐步递增。
Java 堆内存中依照分代年龄来划分，分为 Young 区和 Old 区，对象调配首先会到 Young 区，达到肯定分代年龄 (-XX:MaxTenuringThreshold 能够设置大小，默认为 15) 就会进入 Old 区 ( 留神：如果一个对象太大，那么就会间接进入 Old 区)。
之所以会这么划分是因为如果整个堆只有一个区的话，那么垃圾回收的时候每次都须要把堆内所有对象都扫描一遍，节约性能。而其实大部分 Java 对象的生命周期都是很短的，一旦一个对象回收很屡次都回收不掉，能够认为下一次垃圾回收的时候可能也回收不掉，所以 Young 区和 Old 区的垃圾回收能够离开进行，只有当 Young 区在进行垃圾回收之后还是没有腾出空间，那么再去触发 Old 区的垃圾回收。
Young 区
当初拆分成了 Young 区，那咱们看上面一个场景，上面的 Young 是通过垃圾回收之后的一个概图：
如果说当初来了一个对象，要占用 2 个对象的大小，会发现放不上来了，这时候就会触发 GC(垃圾回收)，然而一旦触发了 GC(垃圾回收)，对用户线程是有影响的，因为 GC 过程中为了确保对象援用不会一直变动，须要进行所有用户线程，Sun 把这个事件称之为：Stop the World(STW)。这些在下一篇解说垃圾回收的时候会具体介绍，这里先不深刻。
所以说个别是越少 GC 越好，而实际上上图中能够看到至多还能够放入 3 个对象，只有依照对象都依照程序放好，那么是能够放得下的，所以这就产生了问题了，明明有空间，然而因为空间不间断，导致对象申请内存失败，导致触发 GC了，那么如何解决这种问题呢？
解决的思路就是把 Young 区的对象按程序放好，所以就产生了一个办法，把 Young 区再次划分一下，分为 2 个区：Eden 区 和Survivor 区 。
具体操作是：一个对象来了之后，先调配到 Eden 区，Eden 区满了之后，触发 GC，通过 GC 之后，为了避免空间不间断，把幸存下来的对象复制到 Survivor 区，而后 Eden 区就能够残缺清理掉了，当然这么做是有一个前提的，就是大部分对象都是生命周期极短的，根本一次垃圾回收就能够把 Eden 区大部分对象回收掉（这个前提是通过测试总结失去的）。
触发 GC 的时候 Survivor 区也会一起回收，并不是说独自只触发 Eden 区，然而这样问题又来了，Eden 区是保障空间根本间断了，然而 Survivor 区又可能产生空间碎片，导致不间断了，所以就又把 Survivor 区给一分为二了：
这个时候工作流程又变成这样了：
首先还是在 Eden 区调配空间，Eden 区满了之后触发 GC，GC 之后把幸存对象 复制到 S0 区 (S1 区是空的)，而后持续在 Eden 区调配对象，再次触发 GC 之后如果发现 S0 区放不下了(产生空间碎片，理论还有空间)，那么就把 S0 区对象复制到 S1 区，并把幸存对象也复制到 S1 区，这时候 S0 区是空的了，并顺次重复操作，如果说 S0 区或者 S1 区空间对象复制挪动了之后还是放不下，那就阐明这时候是真的满了，那就去老年区借点空间过去（这就是 担保机制，老年代须要提供这种空间调配担保），如果说老年区空间也不够了，那就会触发 Full GC，如果还是不够，那就会抛出 OutOfMemeoyError 异样了。
留神：为了确保 S0 和 S1 两个区域之间每次复制都能顺利进行，S0 和 S1 两个区的大小必须要保持一致，而且同一时间有一个区域肯定是空的。尽管说这种做法是会导致了一小部分空间的节约，然而综合其余性能的晋升来说，是值得的。
Old 区
当 Young 区的对象达到设置的分代年龄之后，对象会进入 Old 区，Old 区满了之后会触发 Full GC，如果还是清理不掉空间，那么就抛出 OutOfMemeoyError 异样。
名词扫盲
下面提到了很多新的名词，而实际上很多这种名词还有其余叫法，这个还是感觉有必要理解一下。
- 垃圾回收：简称 GC。
- Minor GC：针对新生代的 GC
- Major GC：针对老年代的 GC，个别老年代触发 GC 的同时也会触发 Minor GC，也就等于触发了 Full GC。
- Full GC：新生代 + 老年代同时产生 GC。
- Young 区：新生代
- Old 区：老年代
- Eden 区：临时没发现有什么中文翻译(伊甸园?)
- Surcivor 区：幸存区
- S0 和 S1：也称之为 from 区和 to 区，留神 from 和 to 两个区是一直调换身份的，且 S0 和 S1 肯定要相等，并且保障一块区域是空的
一个对象的人生轨迹图
从下面的介绍大家应该有一个大抵的印象，一个对象会在 Eden 区，S0 区，S1 区，Old 区一直流转（当然，一开始就会被回收的长寿对象除外），咱们能够失去上面的一个流程图：
总结
本文次要介绍了一个 Java 对象在堆内是如何存储的，并联合 Java 对象的内存布局示范了一个一般对象占用大小问题，而后还剖析了堆内的空间划分以及划分起因，本文中波及到了 GC 相干常识均没有深刻解说，对于 GC 及 GC 算法和 GC 收集器等相干常识将放在下一篇进行详细分析。