全网最硬核 JVM TLAB 分析 6. TLAB 相关热门Q&A汇总

末蓝、 2022-10-27 12:19 157阅读 0赞

> 今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。由于文章很长，每个人阅读习惯不同，所以特此拆成单篇版和多篇版

*  [全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）][JVM TLAB]
 *  [全网最硬核 JVM TLAB 分析 1. 内存分配思想引入][JVM TLAB _ 1.]
 *  [全网最硬核 JVM TLAB 分析 2. TLAB生命周期与带来的问题思考][JVM TLAB _ 2. TLAB]
 *  [全网最硬核 JVM TLAB 分析 3. JVM EMA期望算法与TLAB相关JVM启动参数][JVM TLAB _ 3. JVM EMA_TLAB_JVM]
 *  [全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析][JVM TLAB _ 4. TLAB]
 *  [全网最硬核 JVM TLAB 分析 5. TLAB 源代码全解析][JVM TLAB _ 5. TLAB]
 *  [全网最硬核 JVM TLAB 分析 6. TLAB 相关热门Q&A汇总][JVM TLAB _ 6. TLAB _Q_A]
 *  [全网最硬核 JVM TLAB 分析(额外加菜) 7. TLAB 相关 JVM 日志解析][JVM TLAB _ 7. TLAB _ JVM]
 *  [全网最硬核 JVM TLAB 分析(额外加菜) 8. 通过 JFR 监控 TLAB][JVM TLAB _ 8. _ JFR _ TLAB]

# 10. TLAB 流程常见问题 Q&A #

> 这里我会持续更新的，解决大家的各种疑问

## 10.1. 为何 TLAB 在退还给堆的时候需要填充 dummy object ##

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

## 10.2. 为何 TLAB 需要最大浪费空间限制 ##

当重新分配一个 TLAB 的时候，原有的 TLAB 可能还有空间剩余。原有的 TLAB 被退回堆之前，需要填充好 dummy object。这样导致这块内存无法分配对象，所示被称为“浪费”。如果不限制，遇到 TLAB 剩余空间不足的情况就会重新申请，导致分配效率降低，大部分空间被 dummy object 占满了，导致 GC 更加频繁。

## 10.3. 为何 **TLAB 重填次数配置** 等于 `100 / (2 * TLABWasteTargetPercent)` ##

TLABWasteTargetPercent 描述了**初始最大浪费空间配置占 TLAB 的比例**

首先，最理想的情况就是尽量让所有对象在 TLAB 内分配，也就是 TLAB 可能要占满 Eden。  
在下次 GC 扫描前，退回 Eden 的内存别的线程是不能用的，因为剩余空间已经填满了 **dummy object**。所以所有线程使用内存大小就是 **`下个 epcoh 内会分配对象期望线程个数 * 每个 epoch 内每个线程 refill 次数配置`**，对象一般都在 Eden 区由某个线程分配，也就所有线程使用内存大小就最好是整个 Eden。但是这种情况太过于理想，总会有内存被填充了 **dummy object**而造成了浪费，因为 GC 扫描随时可能发生。假设平均下来，GC 扫描的时候，每个线程当前的 TLAB 都有一半的内存被浪费，这个每个线程使用内存的浪费的百分比率（也就是 **TLABWasteTargetPercent**），也就是等于（注意，仅最新的那个 TLAB 有浪费，之前 **refill 退回的假设是没有浪费的**）：

`1/2 * (每个 epoch 内每个线程期望 refill 次数) * 100`

那么**每个 epoch 内每个线程 refill 次数配置**就等于 `50 / TLABWasteTargetPercent`， 默认也就是 50 次。

## 10.4. 为何考虑 ZeroTLAB ##

当分配出来 TLAB 之后，根据 ZeroTLAB 配置，决定是否将每个字节赋 0。在 TLAB 申请时，由于申请 TLAB 都发生在对象分配的时候，也就是这块内存会**立刻被使用**，并修改赋值。操作内存，涉及到 CPU 缓存行，如果是多核环境，还会涉及到 CPU 缓存行 false sharing，为了优化，JVM 在这里做了 Allocation Prefetch，简单理解就是分配 TLAB 的时候，会尽量加载这块内存到 CPU 缓存，也就是在**分配 TLAB 内存的时候，修改内存是最高效的**。

在创建对象的时候，本来也要对每个字段赋初始值，大部分字段初始值都是 0，并且，在 TLAB 返还到堆时，剩余空间填充的也是 int\[\] 数组，里面都是 0。

所以，TLAB 刚分配出来的时候，赋 0 避免了后续再赋 0。也能利用好 Allocation prefetch 的机制适应 CPU 缓存行（Allocation prefetch 的机制详情会在另一个系列说明）

## 10.5. 为何 JVM 需要预热，为什么 Java 代码越执行越快（这里只提 TLAB 相关的，JIT，MetaSpace，GC等等其他系列会说） ##

根据之前的分析，每个线程的 TLAB 的大小，会根据线程分配的特性，不断变化并趋于稳定，大小主要是由分配比例 EMA 决定，但是这个采集是需要一定运行次数的。并且 EMA 的前 100 次采集默认是不够稳定的，所以 TLAB 大小也在程序一开始的时候变化频繁。当程序线程趋于稳定，运行一段时间后， 每个线程 TLAB 大小也会趋于稳定并且调整到最适合这个线程对象分配特性的大小。这样，就更接近最理想的只有 Eden 区满了才会 GC，所有 Eden 区的对象都是通过 TLAB 分配的高效分配情况。这就是 Java 代码越执行越快在 TLAB 方面的原因。

[JVM TLAB]: https://zhanghaoxin.blog.csdn.net/article/details/113625536
[JVM TLAB _ 1.]: https://zhanghaoxin.blog.csdn.net/article/details/113625581
[JVM TLAB _ 2. TLAB]: https://zhanghaoxin.blog.csdn.net/article/details/113625597
[JVM TLAB _ 3. JVM EMA_TLAB_JVM]: https://zhanghaoxin.blog.csdn.net/article/details/113625614
[JVM TLAB _ 4. TLAB]: https://zhanghaoxin.blog.csdn.net/article/details/113625627
[JVM TLAB _ 5. TLAB]: https://zhanghaoxin.blog.csdn.net/article/details/113625645
[JVM TLAB _ 6. TLAB _Q_A]: https://zhanghaoxin.blog.csdn.net/article/details/113625667
[JVM TLAB _ 7. TLAB _ JVM]: https://zhanghaoxin.blog.csdn.net/article/details/113625714
[JVM TLAB _ 8. _ JFR _ TLAB]: https://zhanghaoxin.blog.csdn.net/article/details/113625743