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 文件用于分析。
