java中没创建对象的类怎么加载到内存,深入学习JVM: (3) 对象创建与内存分配

一. 前言

时隔多日, 我又来做知识总结了, 这次是Java对象的创建以及内存的分配机制. 本来说好的这篇文章打算写垃圾收集器, 但是想了想, 对象相关的东西作为前置知识, 还是得先说说.

二. 对象创建

一个对象的创建到底经历了哪些步骤? 看图说话:

创建对象流程图.png

加载类这一步, 在下就不多说了, 详细可以看在下的上...上篇文章. 不过, 涉及到对象创建的语句可不只是new, 比如说还有克隆, 或者反序列化等等. 好, 还是着重说说后边儿的步骤:

分配内存: 为即将要创建的对象分配合适的内存大小.

也没那么简单, Jvm一共设计了两种分配内存的策略, 分别是: 指针碰撞和空闲列表

先来说指针碰撞, 接着看图:

规整内存.png

假设这是一块非常规整的内存, 粉红色代表已使用, 白色表示未使用, 蓝色是一个指针; 当要给对象分配内存时, 蓝色的指针会根据对象的大小, 向后空闲的位置移动若干的格子. 比如这个对象计算后发现要占用3个格子, 则蓝色的指针就会移动到当前行的最后一个格子. 这个过程就叫做指针碰撞.

再来说空闲列表, 还是看图:

不规则内存.png

假设这是我们的内存, 由于选择了不恰当的垃圾收集算法, 就可能出现这种情况. 内存上分配的对象很凌乱, 完全不规则. 这种情况肯定就没有办法使用指针碰撞的方式来分配内存了. 这时候, Jvm会采用另外一种方式来给即将要创建的对象分配内存空间, 那就是空闲列表. 空闲列表是指Jvm维护在堆中的一个列表, 上面记录了所有空闲的可用的内存地址, 也就是上图中的白块儿.当计算完该对象需要多大空间的内存时, 则从列表选择出相应的连续的白块儿用于创建对象.

这时候, 新的问题产生了. 如果多个线程同时要创建对象, 到堆中分配内存怎么办?

Jvm提供了两种方式来解决这个问题, 分别是CAS以及TLAB.

①. CAS(compare and swap): 这是一种算法, 不知道的没关系, 可以先百度一下. 简而言之, 通过这种算法, 多个线程同时抢一块内存的时候, 只有一个会成功, 其余失败的会进行重试.

②. TLAB(Thread Local Allocation Buffer): 这是一种机制, Jvm事先给每个线程在堆中预先分配一小块儿内存空间, 每个线程要创建对象分配内存时, 先到自身线程分配到的内存中尝试分配. 如果分配失败, 再使用CAS的方式在Eden区中分配内存.

可以通过参数: -XX:+UseTLAB来开启TLAB(默认开启); 通过参数: ­XX:TLABSize指定TLAB的大小, 不过一般不用也不推荐去修改它.

以上是关于分配内存的所有内容, 下面来讲初始化:

初始化: 为对象所有成员变量赋零值

这也是为什么一个对象的成员变量不用赋值也可以使用的原因.

设置对象头: 一个对象分为三部分信息, 分别是对象头, 实例数据, 对齐填充

①. 对象头: 不知道你有没有想过为什么使用instanceof关键字可以判断一个对象的类型; 使用 对象.getClass() 可以取得该对象类对象; Jvm如何判断一个对象经历了15次垃圾回收, 从而将其放入老年代. 其实这些信息都存放在对象的对象头中.

对象头中也包含了三部分信息, 分别是:

(markword): 对象hash code值、gc分代年龄、锁状态标识(这也是对象可以作为锁的原因)

(klass pointer): 一个指针, 指向方法区中该对象对应的类元信息

(数组长度): 如果该对象是一个数组, 才会有该信息, 记录数组的长度

②. 实例数据: 这个就不多讲了, 就是对象的成员变量嘛.

③. 对齐填充: 我们的对象由于成员变量的数据类型不同, 都有不同的大小. 而Jvm会将这些对象大小都填充成8的倍数次方. 例如一个对象占用28字节, Jvm会填充4个字节, 使其变成32字节大小. 为什么要这样呢? 了解计算机底层的朋友应该知道, 对于8的倍数值, 计算机寻址的速度是最快的.

④. 还有一个指针压缩: 我们的对象头中有一个klass pointer, 它是一个指针, 也会占用相对应的内存, Jvm为了节省内存空间会对其进行压缩. 另外, 我们的对象中也可能包含其它对象, 这些个对象也会以指针的方式存放在内存中. 对其压缩后, 可以节省我们的内存空间, 降低指针移动时所耗费的带宽.

关于指针压缩, 不能在32G以上的内存中生效. 所以这也是为什么jvm内存配置小了不好, 配置大了也不好的原因之一.

三. 对象内存分配

上面说的对象分配内存是指对象创建时分配内存的规则, 下面要说的是对象分配的内存区域.

1. 栈上分配对象

看到这个的小伙伴儿可能有点儿奇怪, 哎, 你之前不是说对象在堆上分配, 然后栈内存上只存放对象的引用吗? 记住了, 我说的是大多数时候, 这里要扯到一个概念, 叫做对象逃逸分析, 请看伪代码:

public void test() {

User user = new User();

System.out.print("User对象能在test()方法外被使用吗?");

}

上述代码在test()方法内new了一个User对象, 这个对象仅在该方法内有效. 换句话说, 这个User对象已经逃不出test()方法的作用域了. 这个时候Jvm就有可能在栈上存放该对象.

可是, 存放对象需要一块儿连续的内存空间呀, 栈帧没有怎么办?

这就涉及到对象内存栈上分配的一种方式, 标量替换, 什么是标量? 其

实就是变量, Jvm会将该对象的成员属性拆分成一个一个的标量存放在栈

上.

使用参数: -XX:+DoEscapeAnalysis 开启逃逸分析(默认开启)

使用参数: -XX:+EliminateAllocations 开启标量替换(默认开启)

2. 大对象直接进入老年代

大对象直接进入老年代? 多大的对象算大对象嘞?

为了避免一些体积过大的对象频繁在年轻代参与gc占用I/O带宽, Jvm直接

将大对象放在老年代.

通过参数: -XX:PretenureSizeThreshold=1048576(字节) 设置大对象大小

3. 长期存活的对象进入老年代

这个之前提到过, 一个对象经历一次minor gc, 则将对象头中存储的gc年龄加1(最大15), Jvm默认当一个对象的gc年龄达到15时将其移入老年代(不同的垃圾回收器默认值不同).

这是为了避免一些本就应该永久存在, 或者说长期存活的的对象一直在年轻

代频繁经历minor gc却始终回收不掉, 消耗性能.

通过参数: -XX:MaxTenuringThreshold=5 可以设置移入老年代的年龄阈值

4. 对象动态年龄判断

这个就有意思了, 前一篇文章说过, 当年轻代的eden区满了之后, 会执行minor gc, 然后将存活的对象移动到survivor区. 前面还说过, 每个对象都有一个gc年龄. 还是结合图吧:

minor gc存活对象.png

当minor gc后如果移动到幸存区的对象总大小超过了幸存区大小的50%, 则

会进行对象动态年龄判断机制, 该机制会根据对象年龄进行排序, 然后相加并判断是否大于了幸存区的50% ,如果大于, 则将年龄n及以上对象全部移入老年代.

以上图举例:

对象1 + 对象2 + 对象3 + 对象4 + 对象5 + 对象6 = 600kb

600kb > (1mb * 0.5) = true

将对象6 ~ 对象9 移入老年代.

通过参数: -XX:TargetSurvivorRatio 指定判定阈值

5. 老年代空间分配担保机制

该机制发生在minor gc前, 就是在执行minor gc之前, 会判断每一次minor gc移入老年代的对象的平均大小, 如果大于老年代剩余空间, 直接执行full gc.

举例说明: 年轻代gc完存活了一批对象要进入老年代, 而老年代放不下这么多的对象, 怎么办? 只能接着再执行一次full gc.

6. 对象在Eden区分配

除了上述规则, 一个对象创建时, 会被分配到Eden区.

四. 对象内存回收

1. 如何判定一个对象是可回收的对象?

有两种方式可以判断一个对象是不是一个无用的对象, 分别是: 引用计数器算法 和 可达性分析算法, 而且目前主流在用的只有可达性分析算法.

听上去很高大上? 听在下解释:

引用计数器算法: 给对象添加一个计数器, 每当有变量引用它时, +1, gc就判断这个对象的计数器是否为0即可. 十分简单, 不过问题也很明显, 比如:

A a = new A();

B b = new B();

a.b = b;

b.a = a;

只要对象相互引用一下, 好家伙, gg了...这两对象回收不掉了.

可达性分析算法: 将栈的 局部变量 以及方法区中的 静态变量 作为根, 沿着向下查找对象, 并将所有找到的对象标记为非垃圾对象. 然后回收掉所有未被标记的对象. 被作为根的对象也被称之为"gc roots". 如下图:

可达性分析算法.png

2. 听说Java中有好几种引用? 对于回收它们有什么区别?

Java中的引用一般分为 强, 软, 弱, 虚 四种引用, 在编码上区别如下:

强引用: 就是普通的变量直接引用, 只有在失去引用后才会被回收.

User user = new User();

软引用: 使用SoftReference软引用类型包裹一个对象, 即可将该对象转换为软引用. 该引用正常情况下不回被回收, 但如果gc之后仍没有足够的空间可以使用, 则会回收这类引用的对象

public static SoftReference user = newSoftReference<>(new User());

弱引用: 使用WeekSoftReference弱引用类型包裹, 即可转换引用类型为弱引用. 这类引用会在垃圾回收时直接被回收掉, 与无引用几乎无异.

public static WeakReference user = new WeakReference<>(new User());

虚引用: 在下没弄明白这个, 完全没有使用场景...前两种还可以用做缓存...如果有小伙伴儿知道这个虚引用的使用场景, 欢迎评论.

3. 垃圾回收调用finalize()干了啥?

我的理解, 这个finalize方法是Jvm的一个生命周期钩子, 在对象即将被回收之前调用.

其实在可达性分析算法结束后, 所有未被标记的"垃圾对象"在真正回收前会判断该对象是否重写了finalize()方法, 如果重写了, 则执行, 如果未重写, 直接回收.

也可以在finalize()方法中给对象重新建立引用, 这样做则可以挽救该对象被回收.

需要注意的是, 每个对象的finalize()方法仅会被调用一次.

4. 如何判断一个类是可回收的类呢?

我们的类在full gc时也可能被回收, 前面说过类的信息是存放在方法区的, 其实full gc回收方法区主要就是回收类.

而判断一个类是否可回收必须满足三个条件:

该类的所有实例对象被回收

该类的类对象已不存在任何引用, 也就是java.lang.class对象. 这意味着, 不能再通过反射创建该类的对象

加载该类的类加载器已被回收. 这一点很有意思, 因为这说明我们自己写的类, 也就是classpath路径下的类永远不会被回收. 因为它们都是AppClassLoader加载的. 这也是为啥热更新jsp需要tomcat自定义类加载器的原因之一(tomcat每次热更新jsp都会重新创建一个类加载器实例, 并重新加载产生变化的jsp).

好了, 今天的总结就到这里. 如果有错误的地方, 希望大家能不吝指教, 也欢迎大家向我提问, 一起讨论技术.