通过 JFR 与日志深入探索 JVM - TLAB 原理详解

什么是 TLAB？

TLAB（Thread Local Allocation Buffer）线程本地分配缓存区，这是一个线程专用的内存分配区域。既然是一个内存分配区域，我们就先要搞清楚 Java 内存大概是如何分配的。

我们一般认为 Java 中 new 的对象都是在堆上分配，这个说法不够准确，应该是大部分对象在堆上的 TLAB分配，还有一部分在 栈上分配 或者是 堆上直接分配，可能 Eden 区也可能年老代。同时，对于一些的 GC 算法，还可能直接在老年代上面分配，例如 G1 GC 中的 humongous allocations（大对象分配），就是对象在超过 Region 一半大小的时候，直接在老年代的连续空间分配。

这里，我们先只关心 TLAB 分配。 对于单线程应用，每次分配内存，会记录上次分配对象内存地址末尾的指针，之后分配对象会从这个指针开始检索分配。这个机制叫做 bump-the-pointer （撞针）。 对于多线程应用来说，内存分配需要考虑线程安全。最直接的想法就是通过全局锁，但是这个性能会很差。为了优化这个性能，我们考虑可以每个线程分配一个线程本地私有的内存池，然后采用 bump-the-pointer 机制进行内存分配。这个线程本地私有的内存池，就是 TLAB。只有 TLAB 满了，再去申请内存的时候，需要扩充 TLAB 或者使用新的 TLAB，这时候才需要锁。这样大大减少了锁使用。

TLAB 相关 JVM 参数详解

我们先来浏览下 TLAB 相关的 JVM 参数以及其含义，在下一小节会深入源码分析原理以及设计这个参数是为何。

以下参数与默认值均来自于 OpenJDK 11

1. UseTLAB

说明：是否启用 TLAB，默认是启用的。

默认：true

举例：如果想关闭：-XX:-UseTLAB

2. ResizeTLAB

说明：TLAB 是否是自适应可变的，默认为是。

默认：true

举例：如果想关闭：-XX:-ResizeTLAB

3. TLABSize

说明：初始 TLAB 大小。单位是字节

默认：0， 0 就是不主动设置 TLAB 初始大小，而是通过 JVM 自己计算每一个线程的初始大小

举例：-XX:TLABSize=65536

4. MinTLABSize

说明：最小 TLAB 大小。单位是字节

默认：2048

举例：-XX:TLABSize=4096

5. TLABWasteTargetPercent

说明：TLAB 的大小计算涉及到了 Eden 区的大小以及可以浪费的比率。TLAB 浪费占用 Eden 的百分比，这个参数的作用会在接下来的原理说明内详细说明

默认：1

举例：-XX:TLABWasteTargetPercent=10

6. TLABAllocationWeight

说明： TLAB 大小计算和线程数量有关，但是线程是动态创建销毁的。所以需要基于历史线程个数推测接下来的线程个数来计算 TLAB 大小。一般 JVM 内像这种预测函数都采用了 EMA （Exponential Moving Average 指数平均数）算法进行预测，会在接下来的原理说明内详细说明。这个参数代表权重，权重越高，最近的数据占比影响越大。

默认：35

举例：-XX:TLABAllocationWeight=70

7. TLABRefillWasteFraction

说明： 在一次 TLAB 再填充（refill）发生的时候，最大的 TLAB 浪费。至于什么是再填充（refill），什么是 TLAB 浪费，会在接下来的原理说明内详细说明

默认：64

举例：-XX:TLABRefillWasteFraction=32

8. TLABWasteIncrement

说明： TLAB 缓慢分配时允许的 TLAB 浪费增量，什么是 TLAB 浪费，什么是 TLAB 缓慢分配，会在接下来的原理说明内详细说明。单位不是字节，而是MarkWord个数，也就是 Java 堆的内存最小单元

默认：4

举例：-XX:TLABWasteIncrement=4

9. ZeroTLAB

说明： 是否将新创建的 TLAB 内的对象所有字段归零

默认：false

举例：-XX:+ZeroTLAB

TLAB 生命周期与原理详解

TLAB 是从堆上 Eden 区的分配的一块线程本地私有内存。线程初始化的时候，如果 JVM 启用了 TLAB（默认是启用的， 可以通过 -XX:-UseTLAB 关闭），则会创建并初始化 TLAB。同时，在 GC 扫描对象发生之后，线程第一次尝试分配对象的时候，也会创建并初始化 TLAB 。在 TLAB 已经满了或者接近于满了的时候，TLAB 可能会被释放回 Eden。GC 扫描对象发生时，TLAB 会被释放回 Eden。TLAB 的生命周期期望只存在于一个 GC 扫描周期内。在 JVM 中，一个 GC 扫描周期，就是一个epoch。那么，可以知道，TLAB 内分配内存一定是线性分配的。

TLAB 的最小大小：通过MinTLABSize指定

TLAB 的最大大小：不同的 GC 中不同，G1 GC 中为大对象（humongous object）大小，也就是 G1 region 大小的一半。因为开头提到过，在 G1 GC 中，大对象不能在 TLAB 分配，而是老年代。ZGC 中为页大小的 8 分之一，类似的在大部分情况下 Shenandoah GC 也是每个 Region 大小的 8 分之一。他们都是期望至少有 8 分之 7 的区域是不用退回的减少选择 Cset 的时候的扫描复杂度。对于其他的 GC，则是 int 数组的最大大小，这个和为了填充 dummy object 表示 TLAB 的空区域有关。

为何要填充 dummy object ？

由于 TLAB 仅线程内知道哪些被分配了，在 GC 扫描发生时返回 Eden 区，如果不填充的话，外部并不知道哪一部分被使用哪一部分没有，需要做额外的检查，如果填充已经确认会被回收的对象，也就是 dummy object， GC 会直接标记之后跳过这块内存，增加扫描效率。反正这块内存已经属于 TLAB，其他线程在下次扫描结束前是无法使用的。这个 dummy object 就是 int 数组。为了一定能有填充 dummy object 的空间，一般 TLAB 大小都会预留一个 dummy object 的 header 的空间，也是一个 int[] 的 header，所以 TLAB 的大小不能超过int 数组的最大大小，否则无法用 dummy object 填满未使用的空间。

TLAB 的大小： 如果指定了TLABSize，就用这个大小作为初始大小。如果没有指定，则按照如下的公式进行计算： Eden 区大小 / (当前 epcoh 内会分配对象期望线程个数 * 每个 epoch 内每个线程 refill 次数配置)

当前 epcoh 内会分配对象期望线程个数，也就是会创建并初始化 TLAB 的线程个数，这个从之前提到的 EMA （Exponential Moving Average 指数平均数）算法采集预测而来。算法是：

采样次数小于等于 100 时，每次采样：
1. 次数权重 = 100 / 次数
2. 计算权重 = 次数权重 与 TLABAllocationWeight 中大的那个
3. 新的平均值 = (100% - 计算权重%) * 之前的平均值 + 计算权重% * 当前采样值
采样次数大于 100 时，每次采样：
新的平均值 = (100% - TLABAllocationWeight %) * 之前的平均值 + TLABAllocationWeight % * 当前采样值
复制代码

可以看出 TLABAllocationWeight 越大，则最近的线程数量对于这个下个 epcoh 内会分配对象期望线程个数影响越大。

每个 epoch 内期望 refill 次数就是在每个 GC 扫描周期内，refill 的次数。那么什么是 refill 呢？

在 TLAB 内存充足的时候分配对象就是快分配，否则在 TLAB 内存不足的时候分配对象就是慢分配，慢分配可能会发生两种处理：

1.线程获取新的 TLAB。老的 TLAB 回归 Eden，之后线程获取