当前位置：首页 > news >正文

JVM常用概念之移动GC和局部性

news 来源：原创 2025/8/26 7:43:46

问题

非移动GC一定比移动GC好吗？

基础知识

移动GC和非移动GC

移动GC

在进行垃圾回收时，为了减少碎片而移动对象来顺利完成垃圾回收的GC。

Serial GC

在单线程环境下，它在标记-清除（Mark-Sweep）算法的基础上进行，并且在执行垃圾收集时，会暂停所有应用线程。虽然它不是移动对象，但在某些情况下，它会移动对象以减少碎片。

Parallel GC

在多线程环境下，它通过多个线程并行执行大多数垃圾收集工作，以提高性能。在某些实现中，它可能包括对象移动以减少碎片。

非移动GC

在进行垃圾回收时，不移动对象，通过复制对象或者采用不同的策略来管理和回收内存。

G1 GC

G1将堆内存分割成多个区域，并优先处理垃圾最多的区域。G1不移动对象，而是通过复制存活对象到未使用的区域来处理内存回收。

CMS GC

在需要快速响应的应用场景下，CMS在应用程序运行的同时进行标记和清除工作，但不移动对象。

ZGC

采用多重映射和读屏障，指针染色，并发重映射，转发表，NUMA支持等技术来管理和回收内存。

Shenandoah

采用并发执行，大堆等技术支持来管理和回收内存。

GC的局部性

GC进行垃圾回收时，会保持内存的局部性，从而保证GC运行的效率。

时间局部性

如果一个信息项正在被访问，那么在近期它很可能还会被再次访问。程序循环、堆栈等是产生时间局部性的原因。

空间局部性

在最近的将来将用到的信息很可能与正在使用的信息在空间地址上是临近的。

顺序局部性

在典型程序中，除转移类指令外，大部分指令是顺序进行的。指令的顺序执行、数组的连续存放等是产生顺序局部性的原因‌。

GC局部性原理

调整数据的访问顺序

优化循环逻辑和数组访问顺序，减少缓存冲突，提高缓存命中率。

二进制文件中代码段对齐

优化代码段的排列，使得部分代码段能集中在一个缓存中，提高代码段的缓存命中率‌。

实验

测试用例源码

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.*;@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(value = 1, jvmArgsAppend = {"-Xms8g", "-Xmx8g", "-Xmn7g" })
public class ArrayWalkBench {@Param({"16", "256", "4096", "65536", "1048576", "16777216"})int size;@Param({"false", "true"})boolean shuffle;@Param({"false", "true"})boolean gc;String[] arr;@Setuppublic void setup() throws IOException, InterruptedException {arr = new String[size];for (int c = 0; c < size; c++) {arr[c] = "Value" + c;}if (shuffle) {Collections.shuffle(Arrays.asList(arr), new Random(0xBAD_BEE));}if (gc) {for (int c = 0; c < 5; c++) {System.gc();TimeUnit.SECONDS.sleep(1);}}}@Benchmarkpublic void walk(Blackhole bh) {for (String val : arr) {bh.consume(val.hashCode());}}
}

数组的大小。不同规模的数组大小更能凸显差异。
打乱顺序。表示我们是否在遍历数组之前对其进行打乱。启用打乱可模拟插入不按顺序和/或随时间推移发生在不同索引上的情况。
垃圾回收。表示在准备好数据集后强制执行 GC。由于工作负载未在有效负载代码中分配，因此我们需要明确强制执行 GC，否则它将永远不会运行。

运行结果

Benchmark             (gc)  (shuffle)    (size)  Mode  Cnt       Score      Error  UnitsArrayWalkBench.walk  false      false        16  avgt    5       0.051 ±    0.001  us/op
ArrayWalkBench.walk  false      false       256  avgt    5       0.821 ±    0.001  us/op
ArrayWalkBench.walk  false      false      4096  avgt    5      14.516 ±    0.026  us/op
ArrayWalkBench.walk  false      false     65536  avgt    5     307.210 ±    4.789  us/op
ArrayWalkBench.walk  false      false   1048576  avgt    5    4306.660 ±    7.950  us/op
ArrayWalkBench.walk  false      false  16777216  avgt    5   60561.476 ±  925.685  us/opArrayWalkBench.walk  false       true        16  avgt    5       0.051 ±    0.001  us/op
ArrayWalkBench.walk  false       true       256  avgt    5       0.823 ±    0.003  us/op
ArrayWalkBench.walk  false       true      4096  avgt    5      18.646 ±    0.044  us/op
ArrayWalkBench.walk  false       true     65536  avgt    5     461.187 ±   31.183  us/op
ArrayWalkBench.walk  false       true   1048576  avgt    5   16350.706 ±   75.757  us/op
ArrayWalkBench.walk  false       true  16777216  avgt    5  312296.960 ±  632.552  us/opArrayWalkBench.walk   true      false        16  avgt    5       0.051 ±    0.001  us/op
ArrayWalkBench.walk   true      false       256  avgt    5       0.820 ±    0.004  us/op
ArrayWalkBench.walk   true      false      4096  avgt    5      13.639 ±    0.063  us/op
ArrayWalkBench.walk   true      false     65536  avgt    5     174.475 ±    0.771  us/op
ArrayWalkBench.walk   true      false   1048576  avgt    5    4345.980 ±   15.230  us/op
ArrayWalkBench.walk   true      false  16777216  avgt    5   68687.192 ± 1375.171  us/opArrayWalkBench.walk   true       true        16  avgt    5       0.051 ±    0.001  us/op
ArrayWalkBench.walk   true       true       256  avgt    5       0.828 ±    0.010  us/op
ArrayWalkBench.walk   true       true      4096  avgt    5      13.749 ±    0.088  us/op
ArrayWalkBench.walk   true       true     65536  avgt    5     174.230 ±    0.655  us/op
ArrayWalkBench.walk   true       true   1048576  avgt    5    4365.162 ±   88.927  us/op
ArrayWalkBench.walk   true       true  16777216  avgt    5   70631.288 ± 1144.980  us/op

如上述运行结果可知，遍历打乱顺序的数组确实比初始的有序数组慢得多，这主要是有对象的内存布局决定的！并且发现在使用ParallelGC后，将内存的数组在内存进行重新排列，从而有利于提升局部性执行的效率。

Benchmark             (gc)  (shuffle)    (size)  Mode  Cnt       Score      Error  UnitsArrayWalkBench.walk  false      false        16  avgt    5       0.051 ±    0.001  us/op
ArrayWalkBench.walk  false      false       256  avgt    5       0.826 ±    0.006  us/op
ArrayWalkBench.walk  false      false      4096  avgt    5      14.556 ±    0.049  us/op
ArrayWalkBench.walk  false      false     65536  avgt    5     274.073 ±   37.163  us/op
ArrayWalkBench.walk  false      false   1048576  avgt    5    4383.223 ±  997.953  us/op
ArrayWalkBench.walk  false      false  16777216  avgt    5   60322.171 ±  266.683  us/opArrayWalkBench.walk  false       true        16  avgt    5       0.051 ±    0.001  us/op
ArrayWalkBench.walk  false       true       256  avgt    5       0.826 ±    0.007  us/op
ArrayWalkBench.walk  false       true      4096  avgt    5      18.169 ±    0.165  us/op
ArrayWalkBench.walk  false       true     65536  avgt    5     312.345 ±   26.149  us/op
ArrayWalkBench.walk  false       true   1048576  avgt    5   16445.739 ±   54.241  us/op
ArrayWalkBench.walk  false       true  16777216  avgt    5  311573.643 ± 3650.280  us/op

如上述运行结果可知，如果使用非移动的GC可能就没有这样的优势，从而导致非移动GC在这种情况下可能比移动GC进行垃圾回收的效率要低！

那出现这种结果的原因是什么呢?我们可以通过-prof perfnorm来进一步分析，执行结果如下：

Benchmark                    (gc)  (shuffle)   (size)  Mode  Cnt   Score    Error  Unitswalk                         true       true  1048576  avgt   25   4.247 ±  0.090  ns/op
walk:CPI                     true       true  1048576  avgt    5   0.498 ±  0.050   #/op
walk:L1-dcache-load-misses   true       true  1048576  avgt    5   0.955 ±  0.025   #/op
walk:L1-dcache-loads         true       true  1048576  avgt    5  12.149 ±  0.432   #/op
walk:L1-dcache-stores        true       true  1048576  avgt    5   7.027 ±  0.176   #/op
walk:LLC-load-misses         true       true  1048576  avgt    5   0.156 ±  0.029   #/op
walk:LLC-loads               true       true  1048576  avgt    5   0.514 ±  0.014   #/op
walk:cycles                  true       true  1048576  avgt    5  17.056 ±  1.673   #/op
walk:instructions            true       true  1048576  avgt    5  34.223 ±  0.860   #/opwalk                        false       true  1048576  avgt   25  16.155 ±  0.101  ns/op
walk:CPI                    false       true  1048576  avgt    5   1.885 ±  0.069   #/op
walk:L1-dcache-load-misses  false       true  1048576  avgt    5   1.922 ±  0.076   #/op
walk:L1-dcache-loads        false       true  1048576  avgt    5  12.128 ±  0.326   #/op
walk:L1-dcache-stores       false       true  1048576  avgt    5   7.032 ±  0.212   #/op
walk:LLC-load-misses        false       true  1048576  avgt    5   1.031 ±  0.032   #/op
walk:LLC-loads              false       true  1048576  avgt    5   1.365 ±  0.101   #/op
walk:cycles                 false       true  1048576  avgt    5  64.700 ±  2.613   #/op
walk:instructions           false       true  1048576  avgt    5  34.335 ±  1.564   #/op

如上述运行结果所示，由于使用的是随机版本，内存的随机游走会消耗大量的时间成本，所以导致每条指令大约需要 2 个时钟，并且几乎每个最后一级缓存加载都会失败。

总结

垃圾回收的局部性与对象图的布局有关，而对象图的布局伴随着程序的运行是动态变化的，因此GC需要一直动态的适应这种变化的对象图的布局，从而保证局部性的优势，这在现实应用场景下是很难实现的，而进一步讲，如果考虑NUMA特性,其对于垃圾回收的局部性更是灾难，所以所以不考虑垃圾回收局部性就一味的推崇非移动垃圾回收器的说法是错误的。

问题