1# GC垃圾回收 2 3GC（全称 Garbage Collection），即垃圾回收。在计算机领域，GC是指识别并释放内存中的不再使用的对象，以回收内存空间。当前主流编程语言实现的GC算法主要分为两大类：引用计数和对象追踪（即Tracing GC）。 4 5## GC算法简述 6 7### GC的类型 8 9#### 引用计数 10 11当对象B指向对象A时，A的引用计数加1；当该指向断开时，A的引用计数减1。如果A的引用计数为0，回收对象A。 12 13- 优点：引用计数算法设计简单，内存回收及时，在对象成为垃圾时立即回收，因此无需引入单独的暂停业务代码（Stop The World，STW）阶段。 14- 缺点：对对象操作时插入计数环节，增加了内存分配和赋值的开销，影响程序性能。更严重的是存在循环引用问题。 15``` 16class Parent { 17 constructor() { 18 this.child = null; 19 } 20 child: Child | null = null; 21} 22 23class Child { 24 constructor() { 25 this.parent = null; 26 } 27 parent: Parent | null = null; 28} 29 30function main() { 31 let parent: Parent = new Parent(); 32 let child: Child = new Child(); 33 parent.child = child; 34 child.parent = parent; 35} 36``` 37在上述代码中，对象parent被对象child持有，parent的引用计数加1。同时，child也被parent持有，child的引用计数也加1。这导致了循环引用，直到main函数结束，parent和child仍无法释放，从而引发内存泄漏。 38#### 对象追踪 39 40 41 42根对象包括程序运行中的栈内对象和全局对象等当前时刻一定存活的对象。被根对象引用的对象也是存活状态。通过遍历可以找到所有存活的对象。如图所示，从根对象开始遍历对象及其域，所有可达的对象标记为蓝色，即为活对象；剩下的不可达对象标记为黄色，即为垃圾。 43- 优点：对象追踪算法可以解决循环引用的问题，且对内存的分配和赋值没有额外的开销。 44- 缺点：和引用计数算法相反，对象追踪算法较为复杂，且有短暂的STW阶段。此外，回收会有延迟，导致比较多的浮动垃圾。 45 46引用计数和对象追踪算法各有优劣。由于引用计数存在循环引用的性能问题，ArkTS运行时选择基于对象追踪（即Tracing GC）算法设计GC。 47 48### 对象追踪的三种类型 49 50对象追踪算法通过遍历对象图标记出垃圾，而根据垃圾回收方式的不同，对象追踪可以分为三种基本类型：标记-清扫回收、标记-复制回收、标记-整理回收。以下图示中蓝色标记为可达对象，黄色标记为不可达对象。 51 52#### 标记-清扫回收 53 54 55 56完成对象图遍历后，擦除不可达对象内容，并将其放入空闲队列，以便下次对象分配。 57该回收方式不搬移对象，因此效率高。但因回收对象内存地址不连续，会导致内存碎片化，降低分配效率。极端情况下，即使有大量空闲内存，也可能无法放入较大的对象。 58 59#### 标记-复制回收 60 61 62 63遍历对象图时，将可达对象复制到新内存空间。遍历完成后，一次回收旧内存空间。 64这种方式可以解决内存碎片问题，并通过一次遍历完成整个GC过程，效率较高。但在极端情况下，需要预留一半的内存空间以确保所有活动对象可以被拷贝，导致空间利用率较低。 65 66#### 标记-整理回收 67 68 69 70完成对象图遍历后，将可达对象（蓝色）往本区域（或指定区域）的头部空闲位置复制，然后将已经完成复制的对象回收整理到空闲队列中。 71这种回收方式既解决了“标记-清扫回收”导致的大量内存碎片问题，同时避免了“标记-复制回收”浪费一半内存空间的缺点，但性能开销比“标记-复制回收”高。 72### HPP GC 73 74HPP GC（High Performance Partial Garbage Collection），即高性能部分垃圾回收，其中“High Performance”主要体现在三方面，分代模型、混合算法和GC流程优化。在算法方面，HPP GC会根据不同对象区域、采取不同的回收方式。 75 76#### 分代模型 77 78ArkTS运行时采用传统的分代模型，将对象进行分类。考虑到大多数新分配的对象都会在一次GC之后被回收，而大多数经过多次GC之后依然存活的对象会继续存活，ArkTS运行时将对象划分为年轻代对象和老年代对象，并将对象分配到不同的空间。 79 80 81 82ArkTS运行时将新分配的对象直接分配到年轻代（Young Space）的From空间。经过一次GC后依然存活的对象，会移动到To空间，然后会交换from和to空间的类型。而经过再次GC后依然存活的对象，会被复制到老年代（Old Space）。 83 84#### 混合算法 85 86HPP GC是部分复制、部分整理和部分清扫的混合算法，根据年轻代和老年代对象特点采取不同的回收方式。 87 88- 部分复制 89考虑到年轻代对象生命周期短、回收频繁且大小有限，ArkTS运行时对年轻代对象采用“标记-复制回收”算法。 90- 部分整理+部分清扫 91根据老年代对象的特点，引入启发式Collection Set（简称CSet）选择算法。此选择算法的基本原理是：在标记阶段对每个区域的存活对象进行大小统计，然后在回收阶段优先选出存活对象少、回收代价小的区域进行对象整理回收，再对剩下的区域进行清扫回收。 92 93回收策略如下： 94 95- 根据设定的区域存活对象大小阈值，将满足条件的区域纳入初步的CSet队列，并根据存活率进行从低到高的排序（注：存活率=存活对象大小/区域大小）。 96 97- 根据设定的释放区域个数阈值，选出最终的CSet队列，进行整理回收。 98 99- 对未被选入CSet队列的区域进行清扫回收。 100 101启发式CSet选择算法结合了“标记-整理回收”和“标记-清扫回收”算法的优点，避免了内存碎片问题，同时提升了性能。 102 103#### 流程优化 104 105HPP GC流程中引入了大量的并发和并行优化，以减少对应用性能的影响。采用了并发+并行标记（Marking）、并发+并行清扫（Sweep）、并行复制/整理（Evacuation）、并行回改（Update）和并发清理（Clear）执行GC任务。 106 107## Heap结构及其配置参数 108 109### Heap结构 110 111 112 113- SemiSpace：年轻代（Young Generation），存放新创建出来的对象，存活率低，主要使用copying算法进行内存回收。 114- OldSpace：老年代（Old Generation），存放年轻代多次回收仍存活的对象会被复制到该空间，根据场景混合多种算法进行内存回收。 115- HugeObjectSpace：大对象空间，使用单独的Region存放一个大对象的空间。 116- ReadOnlySpace：只读空间，存放运行期间的只读数据。 117- NonMovableSpace：不可移动空间，存放不可移动的对象。 118- SnapshotSpace：快照空间，转储堆快照时使用的空间。 119- MachineCodeSpace：机器码空间，存放程序机器码。 120 121注：每个空间由一个或多个Region进行分区域管理，Region是空间向内存分配器申请的单位。 122 123### 相关参数 124 125> **注意：** 126> 127> 以下参数未提示可配置的均为不可配置项，由系统自行设定。 128 129根据系统分配堆空间总大小64MB-128MB/128MB-256MB/大于256MB的三个范围，以下参数系统会设置不同的大小。如果表格内范围仅有一个值，则表示该参数值不随堆空间总大小变化。手机设备堆空间总大小默认为大于256MB。 130开发者可以查阅[hidebug接口文档](../reference/apis-performance-analysis-kit/js-apis-hidebug.md)，使用相关接口查询内存信息。 131#### 堆大小相关参数 132 133| 参数名 | 范围 | 作用 | 134| --- | --- | --- | 135| HeapSize | 448MB | 主线程默认堆空间总大小，小内存设备会依据实际内存池大小修正。 | 136| SemiSpaceSize | 2MB-4MB/2MB-8MB/2MB-16MB | Semispace空间大小。 | 137| NonmovableSpaceSize | 2MB/6MB/64MB | nonmovableSpace空间大小。 | 138| SnapshotSpaceSize | 512KB | 快照空间大小。 | 139| MachineCodeSpaceSize | 2MB | 机器码空间大小。 | 140 141#### worker线程堆上限 142 143| 参数名 | 范围 | 作用 | 144| --- | --- | --- | 145| HeapSize | 768 MB | work类型线程堆空间大小。 | 146 147#### Semi Space 148heap中生成两个Semi Space供copying使用。 149| 参数名 | 范围 | 作用 | 150| --- | --- | --- | 151| semiSpaceSize | 2MB-4MB/2MB-8MB/2MB-16MB | Semispace空间大小，会根据堆总大小有不同的范围限制。 | 152| semiSpaceTriggerConcurrentMark | 1M/1.5M/1.5M| 首次单独触发Semi Space的并发mark的界限值，超过该值则触发。 | 153| semiSpaceStepOvershootSize| 2MB | 允许过冲最大大小。 | 154 155#### Old Space 和 Huge Object Space 156初始化时均设定为Heap剩余未分配空间的大小，默认手机设备主线程OldSpaceSize上限接近350MB。 157 158| 参数名 | 范围 | 作用 | 159| --- | --- | --- | 160| oldSpaceOvershootSize | 4MB/8MB/8MB | OldSpace允许过冲最大大小。 | 161 162#### 其他空间 163 164| 参数名 | 范围 | 作用 | 165| --- | --- | --- | 166| defaultReadOnlySpaceSize | 256 KB | ReadOnlySpace默认空间大小。 | 167| defaultNonMovableSpaceSize | 2 MB/6 MB/64 MB | NonMovableSpace默认空间大小。| 168| defaultSnapshotSpaceSize | 512 KB/512 KB/ 4 MB | SnapshotSpace默认空间大小。| 169| defaultMachineCodeSpaceSize | 2 MB/2 MB/8 MB | MachineCodeSpace默认空间大小。| 170 171#### 解释器栈大小 172 173| 参数名 | 范围 | 作用 | 174| --- | --- | --- | 175| maxStackSize | 128KB | 控制解释器栈帧大小。 | 176 177#### 并发参数 178 179| 参数名 | 值 | 作用 | 180| --- | --- | --- | 181| gcThreadNum | 7 | gc线程数量，默认为7。可通过`gc-thread-num`参数自行设定该参数值。 | 182| MIN_TASKPOOL_THREAD_NUM | 3 | 线程池最小线程数。 | 183| MAX_TASKPOOL_THREAD_NUM | 7 | 线程池最大线程数。 | 184 185注：该线程池主要用于执行GC流程中的并发任务。线程池初始化时，会综合参考gcThreadNum和线程上下限。如果gcThreadNum为负值，线程池的线程数将初始化为CPU核心数的一半。 186 187#### 其他参数 188 189| 参数名 | 值 | 作用 | 190| --- | --- | --- | 191| minAllocLimitGrowingStep | 2M/4M/8M | heap整体重新计算空间大小限制时，控制oldSpace、heapObject和globalNative的最小增长步长。 | 192| minGrowingStep | 4M/8M/16M | 调整oldSpace的最小增长步长。 | 193| longPauseTime | 40ms | 判断是否为超长GC界限，超长GC会触发完整GC日志信息打印，方便开发者定位分析。可通过`gc-long-paused-time`进行配置。 | 194 195### 其他：新增单VM内ArrayBuffer的native总内存上限为4GB 196 197## GC流程 198 199 200 201### HPP GC的类型 202 203#### Young GC 204 205- **触发机制**：年轻代GC触发阈值在2MB-16MB变化，根据分配速度和存活率等会变化。 206- **说明**：主要回收semi space新分配的年轻代对象。 207- **场景**：前台场景。 208- **日志关键词**：`[ HPP YoungGC ]` 209 210#### Old GC 211 212- **触发机制**：老年代GC触发阈值在20MB-300多MB变化，大部分情况，第一次Old GC的阈值在20M左右，之后会根据对象存活率，内存占用大小进行阈值调整。 213- **说明**：对年轻代和部分老年代空间做整理压缩，其他空间做sweep清理。触发频率比年轻代GC低很多，由于会做全量mark，因此GC时间会比年轻代GC长，单次耗时约5ms~10ms。 214- **场景**：前台场景。 215- **日志关键词**：`[ HPP OldGC ]` 216 217#### Full GC 218 219- **触发机制**：不会由内存阈值触发。应用切换后台之后，如果预测能回收的对象尺寸大于2M会触发一次Full GC。DumpHeapSnapshot 和 AllocationTracker 工具默认会触发Full GC。Native 接口和ArkTS 也有接口可以触发。 220- **说明**：会对年轻代和老年代做全量压缩，主要用于性能不敏感场景，最大限度回收内存空间。 221- **场景**：后台场景。 222- **日志关键词**：`[ CompressGC ]` 223 224此后的Smart GC或IDLE GC都会从上述三种GC中选择。 225 226### 触发策略 227 228#### 空间阈值触发GC 229 230- 函数方法：`AllocateYoungOrHugeObject`，`AllocateHugeObject`等分配函数。 231- 限制参数：对应的空间阈值。 232- 说明：对象申请空间到达对应空间阈值时触发GC。 233- 典型日志：日志可区分GCReason::ALLOCATION_LIMIT。 234 235#### native绑定大小达到阈值触发GC 236 237- 函数方法：`GlobalNativeSizeLargerThanLimit` 238- 限制参数：`globalSpaceNativeLimit`。 239- 说明：影响是否进行全量mark，以及是否开始并发mark。 240 241#### 切换后台触发GC 242 243- 函数方法：`ChangeGCParams` 244- 说明：切换后台后主动触发一次Full GC。 245- 典型日志：`app is inBackground` 和 `app is not inBackground`。 246 GC 日志中可区分GCReason::SWITCH_BACKGROUND。 247 248### 执行策略 249 250#### ConcurrentMark 251 252- 函数方法：`TryTriggerConcurrentMarking` 253- 说明：尝试触发并发mark，将遍历对象进行标记的任务交由线程池中并发运行，减少UI主线程挂起时间。 254- 典型日志：`fullMarkRequested`，`trigger full mark`，`Trigger the first full mark`，`Trigger full mark`，`Trigger the first semi mark`，`Trigger semi mark`。 255 256#### new space GC前后的阈值调整 257 258- 函数方法：`AdjustCapacity` 259- 说明：GC后调整SemiSpace的触发水线，优化空间结构。 260- 典型日志：无直接日志，可以通过GC统计日志看出，GC前young space的阈值有动态调整。 261 262#### 第一次OldGC后阈值的调整 263 264- 函数方法：`AdjustOldSpaceLimit` 265- 说明：根据最小增长步长以及平均存活率调整OldSpace阈值限制。 266- 日志关键词：`AdjustOldSpaceLimit`。 267 268#### 第二次及以后的OldGC对old Space/global space阈值调整，以及增长因子的调整 269 270- 函数方法：`RecomputeLimits` 271- 说明：根据当前GC统计的数据变化，重新计算并调整`newOldSpaceLimit`、`newGlobalSpaceLimit`、`globalSpaceNativeLimit`和增长因子。 272- 日志关键词：`RecomputeLimits`。 273 274#### PartialGC的Cset 选择策略 275 276- 函数方法：`OldSpace::SelectCSet()` 277- 说明：PartialGC执行时采用该策略，优先选择存活对象数量少、回收代价小的Region进行GC。 278- 典型日志： 279 - `Select CSet failure: number is too few` 280 - `Max evacuation size is 6_MB. The CSet Region number` 281 - `Select CSet success: number is` 282 283## SharedHeap 284 285### SharedHeap结构 286 287 288 289- SharedOldSpace：共享老年代空间（这里并不区分年轻代老年代），存放一般的共享对象。 290- SharedHugeObjectSpace：共享大对象空间，使用单独的Region存放一个大对象的空间。 291- SharedReadOnlySpace：共享只读空间，存放运行期间的只读数据。 292- SharedNonMovableSpace：共享不可移动空间，存放不可移动的对象。 293 294注：SharedHeap用于线程间共享对象，提高效率并节省内存。共享堆不单独属于任何线程，保存具有共享价值的对象，提高对象的存活率，去除了SemiSpace类型。 295 296## 特性 297 298### Smart GC 299 300#### 特性介绍 301 302在应用性能敏感场景，通过将线程（SmartGC对worker线程和taskpool线程不生效）GC触发水线临时调整到线程的堆最大值（主线程线程默认448MB），尽量避免触发GC导致应用掉帧。如果敏感场景持续时间过久，对象分配已经达到了堆最大值，则还是会触发GC，且这次GC由于积累的对象太多，GC时间会相对较久。 303 304#### 支持敏感场景 305 306- 应用冷启动（默认支持）。 307- 应用滑动。 308- 应用点击页面跳转。 309- 超长帧。 310 311当前该特性使能由系统侧进行管控，三方应用暂无接口直接调用。 312 313日志关键词: `SmartGC`。 314 315#### 交互流程 316 317 318 319标记性能敏感场景，在进入和退出性能敏感场景时，在堆上标记，避免不必要的GC，维持高性能表现。 320 321## 日志解释 322 323### 开启全量日志 324 325默认情况下，详细的GC日志仅在GC耗时超过40毫秒时才会打印。若需开启所有GC执行的日志，需使用命令在设备中开启。 326 327**使用样例：** 328 329```shell 330# 设置开启GC全量日志参数，开启参数为0x905d，关闭GC全量日志，设置为默认值为0x105c 331hdc shell param set persist.ark.properties 0x905d 332# 重启生效 333hdc shell reboot 334``` 335 336### 典型日志 337 338以下日志统计了GC完整执行后的信息，不同GC类型可能有所差异。开发者可以在导出的日志文件中搜索关键词`[gc]`查看GC相关日志，或搜索关键词`ArkCompiler`查看更全面的虚拟机相关日志。 339 340``` 341// GC前对象实际占用大小（Region实际占用大小）->GC后对象实际占用大小（Region实际占用大小），总耗时（+concurrentMark耗时），GC触发原因。 342C03F00/ArkCompiler: [gc] [ CompressGC ] 26.1164 (35) -> 7.10049 (10.5) MB, 160.626(+0)ms, Switch to background 343// GC运行时的各种状态以及应用名称 344C03F00/ArkCompiler: [gc] IsInBackground: 1; SensitiveStatus: 0; OnStartupEvent: 0; BundleName: com.example.demo; 345// GC运行时的各阶段耗时统计 346C03F00/ArkCompiler: [gc] /***************** GC Duration statistic: ****************/ 347C03F00/ArkCompiler: [gc] TotalGC: 160.626 ms 348C03F00/ArkCompiler: Initialize: 0.179 ms 349C03F00/ArkCompiler: Mark: 159.204 ms 350C03F00/ArkCompiler: MarkRoots: 6.925 ms 351C03F00/ArkCompiler: ProcessMarkStack: 158.99 ms 352C03F00/ArkCompiler: Sweep: 0.957 ms 353C03F00/ArkCompiler: Finish: 0.277 ms 354// GC后各个部分占用的内存大小 355C03F00/ArkCompiler: [gc] /****************** GC Memory statistic: *****************/ 356C03F00/ArkCompiler: [gc] AllSpaces used: 7270.9KB committed: 10752KB 357C03F00/ArkCompiler: ActiveSemiSpace used: 0KB committed: 256KB 358C03F00/ArkCompiler: OldSpace used: 4966.9KB committed: 5888KB 359C03F00/ArkCompiler: HugeObjectSpace used: 2304KB committed: 2304KB 360C03F00/ArkCompiler: NonMovableSpace used: 0KB committed: 2304KB 361C03F00/ArkCompiler: MachineCodeSpace used: 0KB committed: 0KB 362C03F00/ArkCompiler: HugeMachineCodeSpace used: 0KB committed: 0KB 363C03F00/ArkCompiler: SnapshotSpace used: 0KB committed: 0KB 364C03F00/ArkCompiler: AppSpawnSpace used: 4736.34KB committed: 4864KB 365C03F00/ArkCompiler: [gc] Anno memory usage size: 45 MB 366C03F00/ArkCompiler: Native memory usage size:2.99652 MB 367C03F00/ArkCompiler: NativeBindingSize: 0.577148KB 368C03F00/ArkCompiler: ArrayBufferNativeSize: 0.0117188KB 369C03F00/ArkCompiler: RegExpByteCodeNativeSize:0.280273KB 370C03F00/ArkCompiler: ChunkNativeSize: 19096 KB 371C03F00/ArkCompiler: [gc] Heap alive rate: 0.202871 372// 该虚拟机的此类型GC的整体统计 373C03F00/ArkCompiler: [gc] /***************** GC summary statistic: *****************/ 374C03F00/ArkCompiler: [gc] CompressGC occurs count 6 375C03F00/ArkCompiler: CompressGC max pause: 2672.33 ms 376C03F00/ArkCompiler: CompressGC min pause: 160.626 ms 377C03F00/ArkCompiler: CompressGC average pause:1076.06 ms 378C03F00/ArkCompiler: Heap average alive rate: 0.635325 379``` 380 381- gc类型：[HPP YoungGC]、[HPP OldGC]、[CompressGC]、[SharedGC]。 382- TotalGC：总耗时。其下相应为各个阶段对应的耗时，基本的包括`Initialize`、`Mark`、`MarkRoots`、`ProcessMarkStack`、`Sweep`、`Finish`，实际根据不同的GC流程不同会有不同的阶段。 383- IsInBackground：是否在后台场景，1：为后台场景，0：非后台场景。 384- SensitiveStatus：是否为敏感场景，1：为敏感场景，0：非敏感场景。 385- OnStartupEvent：是否为冷启动场景，1：为冷启动场景，0：非冷启动场景。 386- used：当前已分配的对象实际占用的内存空间大小。 387- committed：当前实际分配给heap内存空间的大小。由于各空间按Region分配，而Region通常不会被对象完全占满，因此committedSize大于等于usedSize。hugeSpace会完全相等，因为每个对象单独占用一个Region。 388- Anno memory usage size：当前进程所有堆申请的内存大小，包括heap与sharedHeap。 389- Native memory usage size：当前进程所申请的Native内存大小。 390- NativeBindingSize：当前进程堆内对象绑定的Native内存大小。 391- ArrayBufferNativeSize：当前进程申请的数组缓存Native内存大小。 392- RegExpByteCodeNativeSize：当前进程申请的正则表达式字节码Native内存大小。 393- ChunkNativeSize：当前进程申请的ChunkNative内存大小。 394- Heap alive rate：堆内对象的存活率。 395 396## GC开发者调试接口 397 398> **注意：** 399> 400> 以下接口仅供调试使用，非正式对外SDK接口，不应在应用正式版本中使用。 401 402### ArkTools.hintGC() 403 404- 调用方式：`ArkTools.hintGC()` 405- 接口类型：ArkTS接口。 406- 作用：调用后，VM主动判断是否适合进行full GC。如果后台场景中内存预期存活率低于设定值，则触发full GC；若判断为敏感状态，则不触发。 407- 使用场景：开发者提示系统进行GC。 408- 典型日志：无直接日志，仅可区分外部触发（`GCReason::TRIGGER_BY_JS`）。 409 410 411**使用参考：** 412 413```ts 414// 首先需要声明接口 415declare class ArkTools { 416 static hintGC(): void; 417} 418 419@Entry 420@Component 421struct Index { 422 @State message: string = 'Hello World'; 423 build() { 424 Row() { 425 Column() { 426 Text(this.message) 427 .fontSize(50) 428 .fontWeight(FontWeight.Bold) 429 Button("触发HintGC").onClick((event: ClickEvent) => { 430 ArkTools.hintGC(); //方法内直接调用 431 }) 432 } 433 .width('100%') 434 } 435 .height('100%') 436} 437} 438``` 439 440 441
