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