今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。由于文章很长，每个人阅读习惯不同，所以特此拆成单篇版和多篇版
- 全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）
- 全网最硬核 JVM TLAB 分析 1. 内存分配思想引入
- 全网最硬核 JVM TLAB 分析 2. TLAB生命周期与带来的问题思考
- 全网最硬核 JVM TLAB 分析 3. JVM EMA期望算法与TLAB相关JVM启动参数
- 全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析
- 全网最硬核 JVM TLAB 分析 5. TLAB 源代码全解析
- 全网最硬核 JVM TLAB 分析 6. TLAB 相关热门Q&A汇总
- 全网最硬核 JVM TLAB 分析(额外加菜) 7. TLAB 相关 JVM 日志解析
- 全网最硬核 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 方面的原因。
