JVM常用概念之线程本地分配缓冲区（ThreadLocal Allocation Buffer，TLAB）

当实例化一个Java类时，运行时环境必须为相关实例分配存储空间，在JRE中此存储空间分配操作是由内存管理器实现的（其实是JVM的垃圾回收器），由于内存管理器通常使用与运行时目标语言不同的语言编写（例如，Java 以 JVM 为目标，而 HotSpot JVM 是用 C++ 编写的），因此接口会变得更加模糊。而这种操作成本是相当高的，并且内存管理器也必须应对多线程场景下进行内存请求的压力。为了使Java程序的运行效率尽可能接近C++等语言的运行效率，针对JVM的内存管理器的执行效率需要进行优化。

1.优化方法

优化方法如允许线程分配整个内存块以满足其需求，并且只传输到 VM 以获取新块。在 Hotspot 中，这些块称为线程本地分配缓冲区 (TLAB)，并且有一个复杂的机制来支持它们。请注意，TLAB 在时间意义上是线程本地的，这意味着它们像缓冲区一样接受当前分配。它们仍然是 Java 堆的一部分，线程仍然可以将对新分配对象的引用写入 TLAB 之外的字段等等。

所有已知的 OpenJDK GC 都支持 TLAB 分配。VM 代码的这一部分在它们之间基本是共享的。所有 Hotspot 编译器都支持 TLAB 分配，因此您通常会看到如下所示的对象分配生成代码：

0x00007f3e6bb617cc: mov    0x60(%r15),%rax        ; TLAB "current"
0x00007f3e6bb617d0: mov    %rax,%r10              ; tmp = current
0x00007f3e6bb617d3: add    $0x10,%r10             ; tmp += 16 (object size)
0x00007f3e6bb617d7: cmp    0x70(%r15),%r10        ; tmp > tlab_size?
0x00007f3e6bb617db: jae    0x00007f3e6bb61807     ; TLAB is done, jump and request another one
0x00007f3e6bb617dd: mov    %r10,0x60(%r15)        ; current = tmp (TLAB is fine, alloc!)
0x00007f3e6bb617e1: prefetchnta 0xc0(%r10)        ; ...
0x00007f3e6bb617e9: movq   $0x1,(%rax)            ; store header to (obj+0)
0x00007f3e6bb617f0: movl   $0xf80001dd,0x8(%rax)  ; store klass to (obj+8)
0x00007f3e6bb617f7: mov    %r12d,0xc(%rax)        ; zero out the rest of the object

2.指针碰撞分配

分配路径内联在生成的代码中，因此不需要调用 GC 来分配对象。如果我们请求分配耗尽了 TLAB 的对象，或者对象足够大而无法放入 TLAB，那么我们将采取“慢速路径”，要么在那里满足分配，要么返回新的 TLAB。请注意，最常见的“正常”路径只是将对象大小添加到 TLAB 当前光标，然后继续。

这就是为什么这种分配机制有时被称为“指针碰撞分配”。指针碰撞需要分配一块连续的内存，但这又带来了堆压缩的需要。请注意 CMS 如何在“老”代中进行空闲列表分配，从而实现并发清除，但它压缩了STW情况下堆中的“年轻代”集合，这受益于指针碰撞分配！年轻代集合中幸存下来的对象数量要少得多，这就是空闲列表分配的代价。

为了进行实验，我们可以使用 -XX:-UseTLAB 关闭 TLAB 功能。然后，所有分配都将进入本机方法，通常不建议这么做，如下所示：

-   17.12%     0.00%  org.openjdk.All  perf-31615.map
   - 0x7faaa3b2d125
      - 16.59% OptoRuntime::new_instance_C
         - 11.49% InstanceKlass::allocate_instance
              2.33% BlahBlahBlahCollectedHeap::mem_allocate