当实例化一个Java类时，运行时环境必须为相关实例分配存储空间，在JRE中此存储空间分配操作是由内存管理器实现的（其实是JVM的垃圾回收器），由于内存管理器通常使用与运行时目标语言不同的语言编写（例如，Java 以 JVM 为目标，而 HotSpot JVM 是用 C++ 编写的），因此接口会变得更加模糊。而这种操作成本是相当高的，并且内存管理器也必须应对多线程场景下进行内存请求的压力。为了使Java程序的运行效率尽可能接近C++等语言的运行效率，针对JVM的内存管理器的执行效率需要进行优化。
1.优化方法
优化方法如允许线程分配整个内存块以满足其需求，并且只传输到 VM 以获取新块。在 Hotspot 中，这些块称为线程本地分配缓冲区 (TLAB)，并且有一个复杂的机制来支持它们。请注意，TLAB 在时间意义上是线程本地的，这意味着它们像缓冲区一样接受当前分配。它们仍然是 Java 堆的一部分，线程仍然可以将对新分配对象的引用写入 TLAB 之外的字段等等。
所有已知的 OpenJDK GC 都支持 TLAB 分配。VM 代码的这一部分在它们之间基本是共享的。所有 Hotspot 编译器都支持 TLAB 分配，因此您通常会看到如下所示的对象分配生成代码：
bash
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 object2.指针碰撞分配
分配路径内联在生成的代码中，因此不需要调用 GC 来分配对象。如果我们请求分配耗尽了 TLAB 的对象，或者对象足够大而无法放入 TLAB，那么我们将采取"慢速路径"，要么在那里满足分配，要么返回新的 TLAB。请注意，最常见的"正常"路径只是将对象大小添加到 TLAB 当前光标，然后继续。
这就是为什么这种分配机制有时被称为"指针碰撞分配"。指针碰撞需要分配一块连续的内存，但这又带来了堆压缩的需要。请注意 CMS 如何在"老"代中进行空闲列表分配，从而实现并发清除，但它压缩了STW情况下堆中的"年轻代"集合，这受益于指针碰撞分配！年轻代集合中幸存下来的对象数量要少得多，这就是空闲列表分配的代价。
为了进行实验，我们可以使用 -XX:-UseTLAB 关闭 TLAB 功能。然后，所有分配都将进入本机方法，通常不建议这么做，如下所示：
bash
- 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 <---- entry point to GC
0.35% AllocTracer::send_allocation_outside_tlab_event3.总结
TLAB 是内存分配机制的主力：它们消除了分配器的并发瓶颈，提供了廉价的分配路径，并全面提高了性能。有趣的是，使用 TLAB 会导致更频繁的 GC ，只是因为内存分配非常便宜！相反，在任何内存管理器实现中没有快速分配路径肯定会隐藏内存回收性能问题，从而严重的影响JVM的性能。