Java 对象分配流程
我们这里不考虑栈上分配,这些会在 JIT 的章节详细分析,我们这里考虑的是无法栈上分配需要共享的对象。
对于 HotSpot JVM 实现,所有的 GC 算法的实现都是一种对于堆内存的管理,也就是都实现了一种堆的抽象,它们都实现了接口 CollectedHeap。当分配一个对象堆内存空间时,在 CollectedHeap 上首先都会检查是否启用了 TLAB,如果启用了,则会尝试 TLAB 分配;如果当前线程的 TLAB 大小足够,那么从线程当前的 TLAB 中分配;如果不够,但是当前 TLAB 剩余空间小于最大浪费空间限制,则从堆上(一般是 Eden 区) 重新申请一个新的 TLAB 进行分配。否则,直接在 TLAB 外进行分配。TLAB 外的分配策略,不同的 GC 算法不同。例如G1:
- 如果是 Humongous 对象(对象在超过 Region 一半大小的时候),直接在 Humongous 区域分配(老年代的连续区域)。
- 根据 Mutator 状况在当前分配下标的 Region 内分配
TLAB 慢分配与 TLAB 外分配
重新申请一个 TLAB 进行分配,是 TLAB 慢分配,不在 TLAB 分配被称为 TLAB 外分配。我们可以通过 JFR 来监控 TLAB 慢分配或者 TLAB 外分配事件。也就是jdk.ObjectAllocationOutsideTLAB
与jdk.ObjectAllocationInNewTLAB
这两个事件。
jdk.ObjectAllocationOutsideTLAB
和 jdk.ObjectAllocationInNewTLAB
这两个事件在default.jfc
中( JFR 默认事件采集配置)是没有开启采集的:
<event name="jdk.ObjectAllocationInNewTLAB">
<setting name="enabled">false</setting>
<setting name="stackTrace">true</setting>
</event>
<event name="jdk.ObjectAllocationOutsideTLAB">
<setting name="enabled">false</setting>
<setting name="stackTrace">true</setting>
</event>
一般的,采集这两个事件,是需要连着堆栈一起采集,但是无法通过持续时间(因为这个事件没有持续时间这一概念)限制采集哪些,也就是只要开启就是全部采集,所以不建议长期开启这个采集。而是通过一些其他的监控项,按照需要,动态开启这个采集一段时间,之后关闭并 dump 出 JFR 文件用于分析。
每日一刷,轻松提升技术,斩获各种offer: