其他分享
首页 > 其他分享> > TLAB 与堆可解析性

TLAB 与堆可解析性

作者:互联网

1. 写在前面


“[JVM 解剖公园][1]”是一个持续更新的系列迷你博客,阅读每篇文章一般需要5到10分钟。限于篇幅,仅对某个主题按照问题、测试、基准程序、观察结果深入讲解。因此,这里的数据和讨论可以当轶事看,不做写作风格、句法和语义错误、重复或一致性检查。如果选择采信文中内容,风险自负。


Aleksey Shipilёv,JVM 性能极客   

推特 [@shipilev][2]   

问题、评论、建议发送到 [aleksey@shipilev.net][3]


[1]:https://shipilev.net/jvm-anatomy-park

[2]:http://twitter.com/shipilev

[3]:aleksey@shipilev.net


 2. 问题


你是否遇到过无法申请大数组 `int[]` 的情况?看起来没有分配到任何地方,但仍然占据堆空间,存储的内容像是垃圾数据?


3. 理论


按照 GC 理论,好的回收器具有一种非常重要的特性——堆可解析性,即无需复杂的元数据就可以解析对象、字段等。例如在 OpenJDK 中,许多内部任务采取下面这样的简单循环进行堆遍历:


```c
HeapWord* cur = heap_start;
while (cur < heap_used) {
 object o = (object)cur;
 do_object(o);
 cur = cur + o->size();
}
```


就像这样!如果堆具备可解析性,可以从头到尾分配一个连读的对象流。虽然不是必备特性,但是可解析性能够使 GC 实现、测试与调试变得更容易。


从 [TLAB 机制][4]中可以知道,每个线程都有自己的当前 TLAB 可分配对象。从 GC 的角度看,这意味着声明了整个 TLAB。GC 无法快速知道有哪些线程在那里,它们是否正在操作 TLAB 游标?当前 TLAB 游标的值是什么?线程可能把这些信息存储在寄存器中不向外部展示( OpenJDK 并没有这么做)。因此,这里的问题在于外部无法了解 TLAB 中到底发生了什么。


[4]:https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/


为了验证当前是否正在遍历 TLAB 中的一部分,希望最好能够停止线程以避免 TLAB 发生变化,从而可以实现精确的堆遍历。但这里还有一个更便捷的技巧:为什么不向堆中插入填充对象?这样就可以让堆变得可解析。也就是说,如果 TLAB 像下面这样:


```shell
...........|===================           ]............
           ^                  ^           ^
       TLAB start        TLAB used   TLAB end
```


我们可以停止线程,让它们在 TLAB 剩余空间分配一个 dummy 对象,这样就可以使它们的堆变得可解析:


```shell
...........|===================!!!!!!!!!!!]............
           ^                  ^           ^
       TLAB start        TLAB used   TLAB end
```


有什么比 dummy 对象更好的选择?当然,可以用 `int[]` 数组。请注意,这种“放置”方法只分配了 array header,堆处理机制会跳过数组内容继续完成接下来的工作。一旦线程恢复在 TLAB 中分配对象,会像什么都没有发生一样覆盖之分配的填充的内容。


顺便说一下,在移除对象的时候,堆遍历程序也可以很好地处理填充对象,简化堆清扫工作。


4. 实验


能看到上面方案的执行效果吗?当然可以。我们可以启动很多线程,声明各自的 TLAB。然后启动单独的线程耗尽 Java 堆,抛出 `OutOfMemoryException` 并触发 heap dump。


例如下面这样的代码:


```java
import java.util.*;
import java.util.concurrent.*;


public class Fillers {
 public static void main(String... args) throws Exception {
   final int TRAKTORISTOV = 300;
   CountDownLatch cdl = new CountDownLatch(TRAKTORISTOV);
   for (int t = 0 ; t < TRAKTORISTOV; t++) {
     new Thread(() -> allocateAndWait(cdl)).start();
   }
   cdl.await();
   List<Object> l = new ArrayList<>();
   new Thread(() -> allocateAndDie(l)).start();
 }


 public static void allocateAndWait(CountDownLatch cdl) {
   Object o = new Object();  // 请求一个 TLAB 对象
   cdl.countDown();
   while (true) {
     try {
       Thread.sleep(1000);
     } catch (Exception e) {
       break;
     }
   }
   System.out.println(o); // 使用对象
 }


 public static void allocateAndDie(Collection<Object> c) {
   while (true) {
     c.add(new Object());
   }
 }
}
```


为了精确得到 TLAB 大小,可以使用 Epsilon GC 设置 `-Xmx1G -Xms1G -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -XX:+HeapDumpOnOutOfMemoryError` 参数运行。这样可以迅速失败并生成 heap dump 文件。


用 [Eclipse Memory Analyzer (MAT)][5] 打开 heap dump 文件,可以看到下图:


[5]:http://www.eclipse.org/mat/


```shell
Class Name                                 |   Objects | Shallow Heap |
-----------------------------------------------------------------------
                                          |           |              |
int[]                                      |     1,099 |  814,643,272 |
java.lang.Object                           | 9,181,912 |  146,910,592 |
java.lang.Object[]                         |     1,521 |  110,855,376 |
byte[]                                     |     6,928 |      348,896 |
java.lang.String                           |     5,840 |      140,160 |
java.util.HashMap$Node                     |     1,696 |       54,272 |
java.util.concurrent.ConcurrentHashMap$Node|     1,331 |       42,592 |
java.util.HashMap$Node[]                   |       413 |       42,032 |
char[]                                     |        50 |       37,432 |
-----------------------------------------------------------------------
```


从上面可以看到,`int[]` 占据了绝大多数的堆空间,这些是我们分配的填充对象。当然,这个实验也有需要注意的地方。


首先,配置 Epsilon TLAB 为固定大小。相反,高性能回收器会自己调整 TLAB 大小,尽可能减小由线程分配对象占据 TLAB 空间造成的堆空间松弛情况。这也是为什么在 TLAB 中分配大空间要三思而行。尽管如此,当一个主动分配线程有较大空间的 TLAB 时,由于真实分配的数据只占一半空间,仍然可以观察到填充对象。


其次,我们通过 MAT 展示无法访问的对象。根据定义,这些填充对象是无法访问的。它们出现在 heap dump 文件中是因为在转储过程利用堆的可解析性进行了遍历。这些对象实际上并不存在,好的分析器会把它们过滤出来。这样就可以解释为什么1G heap dump 实际上只存储了900MB对象。


5. 观察


TLAB 很有趣,堆的可解析性一样有趣。把二者结合有助了解一些内部工作机制,这是极好的。如果在运行中发现一些奇怪的结果,那么你很可能正在探索更有趣的技巧!


标签:java,对象,解析性,线程,TLAB,heap
来源: https://blog.51cto.com/u_15127686/2832750