对象的创建流程与内存分配
对象创建流程如下:
Java 中新创建的对象如何分配空间呢?
- new 的对象先放 Eden 区(如果是大对象,直接放入老年代)
- 当 Eden 区满了之后,程序还需要创建对象,则垃圾回收器会对 Eden 区进行垃圾回收
- 在垃圾回收的时候,会将 Eden 区的幸存对象转移到 Survivor From 区
- 如果再次触发垃圾回收,此时将 Eden 区的幸存对象转移到 Survivor To 区中,并且将 Survivor From 区中的幸存对象也转移到 Survivor To 区
- 如果再次出发垃圾回收,此时将 Eden 区和 Survivor To 区中的幸存对象转移到 Survivor From 区中
- 当对象的生存年龄达到 15 时,会被放入老年代
在幸存对象每次转移的时候,对会将对象的生存年龄 + 1,达到 15 时会放入老年代中
Java 对象只会分配在堆中吗?
不是的,如果经过 逃逸分析
后发现,一个对象并没有逃逸出方法的话,就可能被优化为在栈上分配
,这是常见的堆外存储技术。
逃逸分析就是分析对象动态作用域:
- 对象在方法中被定义后,对象只在方法内部使用,则认为没有发生逃逸
- 对象在方法中被定义后,对象被外部方法所引用,则认为发生逃逸
在 HashMap 中就将变量声明在方法中,可以将变量存储在栈中,提升速度
什么情况下,对象会直接进入老年代?
- 对象存储年龄默认超过 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
对象的访问定位
有两种方式:
- 通过句柄访问:稳定,对象被移动只需要修改句柄中的地址
- 通过直接指针访问:访问速度快,节省了一次指针定位的开销
句柄访问如下图:
直接指针访问如下图: