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 分配,因此您通常会看到如下所示的对象分配生成代码:

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 object

2.指针碰撞分配

分配路径内联在生成的代码中,因此不需要调用 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_event

3.总结

TLAB 是内存分配机制的主力:它们消除了分配器的并发瓶颈,提供了廉价的分配路径,并全面提高了性能。有趣的是,使用 TLAB 会导致更频繁的 GC ,只是因为内存分配非常便宜!相反,在任何内存管理器实现中没有快速分配路径肯定会隐藏内存回收性能问题,从而严重的影响JVM的性能。

相关推荐
No8g攻城狮2 小时前
【异常解决】使用DateUtil.isSameDay()方法判断秒级时间戳是否属于同一天踩过的坑
java·jvm·spring boot·java-ee·springboot
天若有情6732 小时前
TFword:从字符到片段,解析一个“小而精”的字符串处理工具的设计智慧
java·jvm·算法
那我掉的头发算什么3 小时前
【数据结构】反射、枚举、lambda表达式以及补充知识
java·jvm·数据结构·intellij idea
沐浴露z18 小时前
【JVM】详解 Class类文件的结构
java·jvm·class
爬虫程序猿19 小时前
把“天猫”装进 JVM:Java 关键词商品爬虫从 0 到 1(含完整可运行代码)
java·jvm·爬虫
stillaliveQEJ21 小时前
【JVM】基础概念之为什么要使用JVM
jvm
维诺菌1 天前
k8s java应用pod内存占用过高问题排查
java·jvm·云原生·容器·性能优化·kubernetes
007php0071 天前
百度面试题解析:synchronized、volatile、JMM内存模型、JVM运行时区域及堆和方法区(三)
java·开发语言·jvm·缓存·面试·golang·php
智海观潮1 天前
JVM垃圾回收器、内存分配与回收策略
java·大数据·jvm
小杰帅气2 天前
内存管理C++
jvm