JVM虚拟机系统性学习-对象的创建流程及对象的访问定位
对象的创建流程与内存分配
对象创建流程如下：
Java 中新创建的对象如何分配空间呢？
- new 的对象先放 Eden 区（如果是大对象，直接放入老年代）
- 当 Eden 区满了之后，程序还需要创建对象，则垃圾回收器会对 Eden 区进行垃圾回收
- 在垃圾回收的时候，会将 Eden 区的幸存对象转移到 Survivor From 区
- 如果再次触发垃圾回收，此时将 Eden 区的幸存对象转移到 Survivor To 区中，并且将 Survivor From 区中的幸存对象也转移到 Survivor To 区
- 如果再次出发垃圾回收，此时将 Eden 区和 Survivor To 区中的幸存对象转移到 Survivor From 区中
- 当对象的生存年龄达到 15 时，会被放入老年代
在幸存对象每次转移的时候，对会将对象的生存年龄 + 1，达到 15 时会放入老年代中
Java 对象只会分配在堆中吗？
不是的，如果经过 逃逸分析 后发现，一个对象并没有逃逸出方法的话，就可能被优化为在栈上分配，这是常见的堆外存储技术。
逃逸分析就是分析对象动态作用域：
- 对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸
- 对象在方法中被定义后，对象被外部方法所引用，则认为发生逃逸
什么情况下，对象会直接进入老年代？
- 对象存储年龄默认超过 15 次（-XX:MaxTenuringThreshold）
- 动态年龄判断：Minor GC 之后，发现 Survivor 区中一批对象的总大小大于这块 Survivor 区的 50%，那么会将此时大于这批对象年龄最大值的所有对象放入老年代，如：一批对象年龄分别为3，4，5，这批对象的总和大于 Survivor 区的 50%，那么会将年龄大于 5 的对象放入老年代
- 大对象直接进入老年代：
前提是 Serial 和 ParNew 收集器 - MinorGC 后，存活对象太多无法放入 Survivor
空间担保机制： 空间担保是在 老年代 中进行空间分配担保
空间担保指的是在 MinorGC 前，会判断老年代可用内存是否大于新生代全部对象大小，如果大于，则此次 Minor GC 是安全的
如果小于，则会检查老年代最大连续可用空间是否大于 历次晋升到老年代对象的平均大小，如果大于，则尝试 Minor GC；如果小于，则进行 Full GC
老年代的空间担保如下图：
对象内存布局
对象存储在堆内存中主要分为三块区域：
- 对象头（Header）：Java 对象头占 8B，如果是数组则占 12 B，因为数组还需要 4B 存储数组大小，对象头又分为：
- 标记字段 MarkWord
- 存储对象自身运行时的数据，synchronized 实现的轻量级锁和偏向锁就在这里设置
- 默认存储：对象 HashCode、GC 分代年龄、锁状态等等
- 类型指针 KlassPoint
- KlassPoint 是对象指向它的类元数据的指针，来确定这个对象是哪个类的实例对象
- 开启指针压缩后存储空间为 4B，不开为 8B
- 数组长度：如果对象是数组，则记录，占 4B
- 对其填充：保证数组的大小永远是 8B 的整数倍
- 标记字段 MarkWord
- 示例数据（Instance Data）：生成对象时，对象的非静态成员变量也会在堆内存中存储
- 对齐填充（Padding）：JVM 内对象都采用 8B 对齐，不够 8B 的会自动补齐
对象头的信息并非是固定的，根据对象状态的不同，对象头存储的信息也是不同的，在 JDK1.8 中如下图：
打印对象的内存布局信息：
引入依赖：
<dependency><groupId>org.openjdk.jol</groupId><artifactId>jol-core</artifactId><version>0.9</version>
</dependency>
代码：
public class Test {public static void main(String[] args) {Object o = new Object();System.out.println(ClassLayout.parseInstance(o).toPrintable());}
}
控制台打印如下，对象头占 12B（MarkWord 8B + KlassPoint 4B），有 4B 的对齐填充，实例数据 0B，因此整个对象大小为 16B
对象的访问定位
有两种方式：
- 通过句柄访问：稳定，对象被移动只需要修改句柄中的地址
- 通过直接指针访问：访问速度快，节省了一次指针定位的开销
句柄访问如下图：
直接指针访问如下图：
