内存区域划分,从高地址到低地址依次是
- 栈区:内存由系统控制开辟、释放。当系统的栈区大小不够分配时, 系统会提示栈溢出。存放时按照先入先出原则,从高地址向低地址扩展。
- 堆区:内存由程序控制开辟、释放。如果程序没有释放,在程序结束时,由系统释放。但是在程序运行时,会出现内存泄漏,内存溢出等问题。分配方式类似于链表。从低地址向高地址扩展。
- 全局静态区:全局变量、静态变量会存储在此区域。初始化的全局变量跟静态变量放在一片区域,未初始化的全局变量与静态变量放在相邻的另一片区域。程序结束后由系统释放。
- 文字常量区:在程序中使用的常量存储在此区域。程序结束后,由系统释放。
- 程序代码区: 存放函数体的二进制代码。
以上 全局静态区、文字常量区、程序代码区 在程序运行起来的时候就开辟好了
栈区由系统控制释放、开辟
垃圾回收机制主要就体现堆区的内存管理方面
基本概念
- GC:Garbage Collection。垃圾回收。
- Collector,用于进行垃圾回收的线程
- Mutators,应用程序的线程,可以修改 heap
- MS,mark-sweep 算法的简写
- MC,mark-compact 算法的简写
- RC,reference-counting 的简写
- liveness,一个对象的可到达性
- 引用关系图,由可到达对象引用形成的图结构
- locality,现代CPU在访问内存时,有多级缓存。缓存以 cache line (一般64字节)为最小操作单位,所以当访问内存中连续的数据时会比较高效,这称为 locality
- Roots,所有根对象,比如全局对象,stack 中的对象
一、手动垃圾回收
这个没什么好说的,c语言就需要手动垃圾回收
int *elements = malloc(10 * sizeof(int));
free(elements)
二、引用计数(Reference Counting)
- 为每个对象存储一个引用计数,新创建的对象,引用计数为1
- 当有一个新的指针指向这个对象时,引用计数加1
- 当某个指针不再指向这个对象时,引用计数减1
- 当引用计数为0时,将对象销毁,回收内存
优点
1.可以保证对象引用为0时立马得到清理,无不确定行
2.大多数操作具有增量特性(incremental),GC 可与应用交替运行,不需要暂停应用即可完成回收功能
3.可以用来优化运行时性能。比如函数式编程中所推崇的「 不可变数据结构 」的更新就能收益:运行时知道某个对象的引用为1,这时对这个对象进行修改,类似str <-str+"a"
,那么这个修改就可以在本地进行,而不必进行额外的 copy
缺点
1.无法解决循环引用。
2.实现一个高效率的引用计数 GC 比较困难。每个对象需要额外的空间来存储其引用次数。在增加/减少对象的引用时,需要修改引用次数。修改引用次数对于栈上的赋值,影响是非常大的。因为之前只需要简单修改寄存器里面的值,现在需要一个原子操作(这涉及到加锁,会浪费几百个 CPU cycles)
3.减少一个对象的引用计数时,会级联减少其引用对象的计数,这就可能造成同时删除过多的对象。在实现中一般会把要回收的对象放入一队列,当程序申请大小为 N 的内存时,从这个队列取出总体积不小于 N 的一个或多个对象将其回收。
采用这类 GC 的主流语言有:Python/PHP/ Perl /TCL/Objective-C。
三、追踪类(tracing)GC
3.1 MS算法:标记-清除(Mark-Sweep)
- mark,从 root 开始进行树遍历,每个访问的对象标注为「使用中」
- sweep,扫描整个内存区域,对于标注为「使用中」的对象去掉该标志,对于没有该标注的对象直接回收掉
优点
1.用以标注对象是否在使用中的flag 位一般放在引用变量里面,不需要额外的空间。
2.较引用计数(Reference Counting) 性能更高
缺点
1.在进行 GC 期间,整个系统会被挂起(暂停,Stop-the-world),所以在一些实现中,会采用各种措施来减少这个暂停时间
2.heap 容易出现碎片。实现中一般会进行 move 或 compact。(需要说明一点,所有 heap 回收机制都会这个问题)
3.回收时间与 heap 大小成正比
4.破坏引用本地性。其实还是因为碎片化导致的。(时间局部性是指,被引用一次的储存器位置,在接下来的时间会经常被引用,这样我们就说他有良好的时间局部性。空间局部性是指,被引用一次的储存器位置,在接下来的时间,他旁边的储存器位置也会被引用,这样我们就说他有良好的空间局部性)
3.2 优化MS算法 - 优化mark过程
在 mark 过程中,需要去标记(mark-bits)对象的 liveness,有两种方式来实现:
- 在每个对象的header部分(in-object mark-bit)
- 使用一个单独的 bitmap,每一位 bit 对应一个对象
两种方式各有利弊,需要结合具体场景进行分析。重点说一下bitmap:
对于 bitmap 来说,需要在 bit 位与 object 之间进行映射,这就要求 object 进行对齐,比如:heap 大小为 65536 字节,所有的对象以 16 字节对齐,那么堆内就有 4096 个地址可以作为对象的起始地址,与之对应需要 4096 个 bit 即 512 个字节。所以使sweep 操作更高效,这是由于 bitmap 结构紧凑,可以一次性加载到内存中,一次性进行多位的检测。
3.3 优化MS算法 - 优化sweep过程
MS 算法有以下两个特点:
- 某对象一旦被标为garbage,它永远都会是 garbage,不会被 mutator 再访问
- mutator 不能修改 mark-bit
基于以上两点,sweep 操作完全可以与 mutator 同时运行(parallel)的。
Lazy sweep 指的是把较为耗时(相对 mark 来说)的 sweep 操作放在 allocate 过程中,并且只在没有足够的空间时才去真正进行回收。
核心就是,把标记为待回收的内存块,放入一个队列中延迟回收。当需要开辟空间且内存不够时,根据需要开辟内存的空间大小,在待回收队列中释放内存。
Lazy Sweep 除了降低 sweep 阶段 mutator 的暂停时间外,还有以下优点:
- 更好的 locality。这是因为被回收的 block 会尽快地重新使用
- GC 复杂度只与可到达对象(即正在使用中的对象数)成正比
- 在大部分 heap 空间为空时效率最好
3.4 优化MS算法 - 碎片问题 - MC算法:标记-整理(Mark-Compact)
MC 算法与 MS 类似,先是一个 mark 过程标记可到达对象,这里取代 sweep 的是一个 compact,工作流程如下:
- 移动(relocate)可到达对象
- 更新指向可到达对象的指针
关于第一步中的安排策略,一般有如下三种选择:
- 任意(Arbitrary)。特点是快,但是空间局部性较差
- 线性(Linearising)。重新分配到附近有关系的(siblings/pointer/reference…)对象周边
- 滑动(Sliding)。所有活对象被滑动到 heap 的一端,保证原有顺序,这有利于改善 locality 的情况。这是现在采用较多的方案
对于采用 MC 的系统,allocate 过程就变得较为简单,只需要bump pointer 即可。
但是这类算法需要多次遍历对象,第一次遍历算出对象将要移动到的新位置,接下来的遍历来真正移动对象,并更新指针,所以MC相对MS要更耗时,这在 heap 较大时更为明显。
这里比较有名的是 Edward 的 Two-pointer 压缩算法。大致过程如下:
- 在 heap 两端各准备一指针,由外向内 scan 寻找可整理的对象
- 自顶向下的指针寻找可到达对象,自底向上的指针寻找 heap 中的“洞”来存放可到达对象
3.5 优化MC算法 - 效率问题 - Copying GC算法
MC 算法虽然能解决内存碎片问题,但是需要多次遍历heap空间,这会导致较大性能损耗,Copying GC 采用空间换时间的方式来提升性能。
这类 GC 并不会真正去“回收”不可到达对象,而是会把所有可到达对象移动到一个区域,heap 中剩余的空间就是可用的了(因为这里面都是垃圾)。这里并没有进行 sweep/compact,而是用 scavenging(净化) 来描述回收这一过程。
Copying GC 典型的代表半空间回收器(semispace collector)。其工作过程是这样的:
- heap 被分成2份相邻的空间(semispace):fromspace 与 tospace
- 在程序运行时,只有 fromspace 会被使用(分配新对象)
- 在 fromspace 没有足够空间容纳新对象时,程序会被挂起,然后把 fromspace 的可到达对象拷贝到 tospace
- 在拷贝完成时,之前的2个空间交换身份,tospace 成了新一轮的 fromspace
Cheney 算法是用来解决如何遍历引用关系图,将之移动到 tospace 的算法,其步骤如下:
- 所有可直接到达的对象组成一队列,作为宽度优先遍历的起点,同时有两个辅助指针:scan 指针指向起始位置,free 指针指向末尾
- 通过移动 scan 来依次遍历队列,当 scan 的对象存在指向 fromspace 中对象的指针时,把被指向的对象添加到队列末端,同时更新指针,使之指向新对象;
- 更新 free 使之始终指向初始时队列末尾所指的那个对象,重复步骤2
- 当 scan 移动到初始时队列末尾所指的那个对象时,即scan与free指向同一对象时,算法结束。
如果按照上述算法操作,会把被指向多次的对象复制多次(类似于引用计数为N,同一个可触达对象在队列中有多份),所以在拷贝对象到 tospace 时,会在原始版本的对象上记录一个重定向指针(forwarding pointer),来标明这个对象已经被复制过了,并且告知新对象的位置;后面 scan 对象时,如果发现具有重定向指针的对象时就会跳过复制操作,直接更新指针就可以了。
3.6 优化Copying算法 - 空间问题 - Non-Copying Implicit GC算法
通过上述描述,不难发现Copying GC 一最大缺点在于所需空间翻倍,不过现如今内存已经普遍较大,这个问题不是很严重。
其次,复制的效率与可到达对象成正比,如果每次 GC 时可到达对象占用的空间接近semispace空间,那么只能通过降低 GC 频率减少 GC 对程序的影响。如何降低 GC 频率呢?答案就是加大 semispace 空间,这样程序就需要更多的时间来填满它。
Non-Copying Implicit GC从 Copying GC 衍化而来,核心是,semispace 不必是物理上分割的空间,可以用两个用双向链表来表示,一般称为 :from-set 与 to-set。为了实现这种策略,需要在每个对象上多加以下两个信息:
- 两个指针,用来形成链表
- 一个flag,标明属于哪个集合
当 from-set 耗尽时,只需遍历 from-set,把其中的可到达对象插入到 to-set,然后改变flag即可,复制操作变成了链表指针操作。这类 GC 的优势除了不用进行真正的拷贝外,还有下面两处优点:
- 语言级别的指针不需要改变了(因为对象没动),这对编译器的要求更小了
- 如果一个对象不含有指针,那么就没必要 scan 了
缺点当然也比较明显: - 每个对象需要而外的空间
- 碎片问题又回来了
所以这类 GC 虽然是 Copying GC 的优化,但也只适用于某些特定的场景。
通过上面的介绍,觉得最重要的就是要分清一个算法的优势与劣势,软件工程里面没有「银弹」,都是有取舍的。
上面对 MS 算法的优化,基本都是在 sweep 阶段,mark 阶段没怎么改进。
但 mark 阶段会导致应用程序挂起,也就是常说的:stop-the-world(STW),这严重影响了 Tracing GC 的应用场景。
3.7 增量式 GC 思路(Incremental Collection)
增量式(incremental)GC 顾名思义,允许 collector 分多个小批次执行,每次造成的 mutator 停顿都很小,达到近似实时的效果。
引用计数类 GC 本身就具有增量式特性,但由于其算法自身的缺陷与效率问题,一般不会采用。而追踪类 GC 实现增量式的难点在于:
这是一个并发问题,collector 线程与 mutator 线程同时去读/写一些共享的数据结构(引用关系图),这就要求把它加锁保护起来。
在 GC 期间,对 mutator 改变「引用关系图」的保守度(conservatism)是增量式 GC 一大特性。如果 mutator 在 collector 遍历某对象后将其释放(floating garbage),那么这个对象在本次 GC 不会被回收,但在下一轮 GC 开始时会被回收。
这种弱一致性(relaxed consistency)是允许的,因为它不会对程序逻辑造成影响,只是延迟了垃圾对象的回收,而且一致性越弱,遍历算法的实现就可以更灵活。
三色标记(tricolor marking)抽象屏蔽了 GC 实现的算法(MS/Copying)、遍历策略(宽度优先/深度优先)等细节,具体来说是在 GC 遍历引用关系图时,对象会被标为三种颜色:
- 黑色black,表明对象被 collector 访问过,属于可到达对象
- 灰色gray,也表明对象被访问过,但是它的子节点还没有被 scan 到
- 白色white,表明没有被访问到,如果在本轮遍历结束时还是白色,那么就会被收回
对于 MS 来说,设置标记位就是着色的过程:有 mark-bit 的即为黑色。对 Copying GC 来说,把对象从 fromspace 移动到 tospace 就是着色过程:在 fromspace 中不可到达的对象为白色,被移动到 tospace 的对象为黑色。
对于增量式 GC 来说,需要在黑白之间有个中间状态来记录「那些之前被 collector 标记黑色,后来又被 mutator 改变的对象」,这就是灰色的作用。
对于 MS(3.2) 来说,灰色对象是用于协助遍历 queue 里面的对象,
对于 Copying GC 来说,灰色对象就是那些在 fromspace 中还没被 scan 的对象,
如果采用 Cheney 的宽度优先遍历算法,那么就是 scan 与 free 指针之间的对象。
增加的中间状态灰色要求 mutator 不会把黑色对象直接指向白色对象(这称为三色不变性 tri-color invariant),collector 就能够认为黑色对象不需要在 scan,只需要遍历灰色对象即可。但这可能存在违法三色不变性的情况。
违法三色不变性的情况简单来说,
就是有三层节点,第一层节点被scan过,且第二层节点全都可访问,此时第一层节点被着色为黑色,第二层节点被着色为灰色。
因为并发,mutator此时做了修改,把第一层节点直接指向第三层的节点,第二层的节点不再指向第三层节点
scan继续访问第二层节点,将第二层节点置位黑色,第三层节点因为此时不再连接第二层节点,故依旧为白色。第一层节点因为已经scan过为黑色,所以在此轮中不会再次被scan,第三层节点依旧为白色。
当遍历结束,虽然第三层节点依旧被第一层节点连接,可依旧会因为是白色而导致被释放。
为了解决上面的违法三色不变性的问题,一般有两类方式来协调 mutator 与 collector 的行为:
- 读屏障(read barrier),它会禁止 mutator 访问白色对象,当检测到 mutator 即将要访问白色对象时,collector 会立刻访问该对象并将之标为灰色。由于 mutator 不能访问指向白色对象的指针,也就无法使黑色对象指向它们了
- 写屏障(write barrier),它会记录下 mutator 新增的由黑色–>白色对象的指针,并把该对象标为灰色,这样 collector 就又能访问有问题的对象了
读/写屏障本质是一些同步操作——在 mutator 进行某些操作前,它必须激活 collector 进行一些操作。
如果没有特殊的硬件支持,写屏障一般来说效率要高于读屏障,因为heap 指针的读操作要多于写操作。
3.8 分代式 GC 思路(Generational Collection)
增量式 GC 是对 mark 阶段的一大优化,可以极大避免 STW 的影响。分代式 GC 根据对象生命周期(后面称为 age)的特点来优化 GC,降低其性能消耗。
虽然对象的生命周期因应用而异,但对于大多数应用来说,80% 的对象在创建不久即会成为垃圾。因此,针对不同 age 的对象「划分不同区域,采用不同的回收策略」也就不难理解了。
对于 Copying GC 来说,需要在两个 semispace 间移动对象,如果移动对象较大,就会对程序造成较大影响,而分代就能解决这个问题。简单情况下可以分为两个代:younger、older。
younger 用于分配新对象,在这里的对象经过几轮 GC 后会移动到 older。younger 与 older 相比空间要小,且 GC 发生更频繁。
分代算法的首要的问题是「如何在不回收 older 的同时安全的回收 younger 里面的对象」
由于引用关系图是全局的属性,older 里面的对象也必须考虑的。比如 younger 里面的一对象只被 older 里面的对象引用了,如何保证 GC 不会错误的回收这个对象呢?
避免上述问题的一个方法是采用写屏障(write barrier),在 mutator 进行指针存储时,进行一些额外的操作(bookkeeping)。写屏障的主要目的是保证所有由 older-->younger 的指针在进行 younger 内的 GC 时被考虑在内,并且作为 root set 进行 copy 遍历。需要注意的是,这里的写屏障与增量式 GC 同样具有一定的保守性。这是由于所有由 older-->younger 的指针都会被当作 root set,但在 older 内的对象是否存活在进行下一次 older GC 前是不可知的,这也就造成了一些 floating garbage,不过这在现实中并不是不能接受的。
第二个问题是「如何在不回收 younger 的同时安全的回收 older 里面的对象」。为了独立回收 older,通过记录所有由 younger-->older 的指针也是可行的,不过这会比较消耗性能。因为在大多数情况下,由 younger-->older 的指针数目要远大于 older-->younger 的,这是符合程序运行规律的——创建一个新对象,将至指向一个老对象。
即便不记录 younger-->older 的指针,也可以在不回收 younger 的前提下回收 older,只不过这时会把 younger 里面的所有对象作为 root set。尽管这样遍历的时间会与 younger 里面的对象数目成正比,但考虑到 younger 内对象数量一般都要小于 older 的,而且遍历操作的消耗要远小于 copying,所以这也是一种可以接受的方式。
除了上面交叉引用的问题,对于一个分代的 GC 来说,还需要考虑下面几个方面:
- 提升策略(advancement policy)。在一个代内的对象经过多少次 GC 会晋级到下一个代
- 堆组织(heap organization)。在代与代之间或者一个代内,heap 空间如何组织可以保证高的 locality 与 缓存命中率
- 代之间的交叉引用(intergenerational references)。采用哪种方式来记录这些指针最好?dirty bit or indirect table
提升策略
最简单的提升策略是在每次 GC 遍历时,把 live 的对象移动到下一代去。这样的优势有:
- 实现简单,不需要去区分一个代内不同对象的 age。对于 copying GC 来说,只需要用一块连续的区域表示即可,不需要 semispace,也不需要额外的 header 来保存 age 信息
- 可以尽快的把大对象提升到 GC 频率比较小的下一代中去
当然,这样做的问题也比较明显,可能会把一些 age 较小的对象移动到下一代中去,导致下一代被更快的填满,所以一般会让 younger 里面的对象停留一次,即第二次 GC 时才去提升,当然这时就需要记录对象的 age 了。
至于是不是需要停留两次,这个就不好说了,这个和应用也比较相关。一般来说,如果代分的少,比如2个,那么会倾向多停留几次,减慢 older 被填满的速度;如果代的数目大于2,那么就倾向于快速提升,因为这些对象很有可能在中间的某个代就会死亡,不会到达最终的 older。
堆组织
分代式 GC 需要对不同 age 的对象采取不同的处理方式,所以在 GC 遍历时,必须能够判断当前对象属于哪个代,写屏障也需要这个信息来识别 older-->younger 指针。
- 对于 copying GC 来说,一般是把不同 age 的对象放在不同的连续区域内,这样一个对象的代就能够从内存地址推断出来了。也有一些系统不采用连续地址,而是采用由 page number of object-->generation 的表来辅助判断。
- 对于 non-copying GC,一般是存放在 header 内
Subareas in Copying
分代式 copying GC 一般会把 generation 分为几个子区域,比如 semispace,通过来回的移动对象让它们一直处于当前代中。如果一个代内只有一个区域,那么每次 GC 时都需要把对象提升到下一代(没有可移动的地方)。
但是 semispace 的 locality 比较差,一个代的内存只有一半可以使用,且来回需要移动。
Ungar 在其论文《Generation Scavenging》 中提出一个解决方法:
一个代内除了两个 semispace 外,还有第三个区域,这里称为Third。在 Third 内分配新对象,在 GC 时,Third 内 live 对象与 semispace 中的一个对象会复制到 semispace 中的另一个去,GC 结束时 Third 会被清空,用于再次分配对象。这样就能够与只有一个区域的代类似的 locality 了。
(第三个区域即为java中的Eden,伊甸园区域。将新生代分为Eden,FromSpace,ToSpace等几个区域)
最后一个代(oldest generation,后面称为 oldest)在一些系统中有特殊处理。比如,在 Lisp Machine 中,每次 GC 后,大多数代都会被清空,并将其内对象拷贝到下一代去,但是 oldest 后面没有可用代了,因此 oldest 内会被分为 semispace。另一个优化是分配一个特殊的区域,称为 static space,用来分配 system data & compiled code 等这些基本不会变的数据,这个区域基本不会有 GC,即为永久代。
在一些基于 Ungar 的 Generation Scavenging 的系统中,把 oldest 分为一个区域,在这个区域使用 mark-compact 算法。使用一个区域可以提高内存利用率,MC 虽然比 copying 算法成本更高,但对于 oldest 来说减少换页(page fault)也是有价值的。
交叉引用
上面已经介绍的,older-->younger
的交叉引用是由写屏障来保障的。对于某些系统(如 Lisp,指针存储指令占全部指令的1%),这个写屏障的成本对分代式 GC 来说非常严重,因此写屏障的策略就十分重要了。
常见的策略的核心思路有两个
- 使用 entry table 或 Remembered Sets 记录交叉引用的指针对象,这种方式成本比较高
- 使用虚拟内存页保存交叉引用的对象,GC 时只需要对虚拟内存页进行扫描即可
3.9 实例:Java 的垃圾回收原理
java的垃圾回收分为三个区域
新生代 老年代 永久代
GC流程:
- 一个对象实例化时 先去看伊甸园有没有足够的空间
- 如果有 不进行垃圾回收 ,对象直接在伊甸园存储.
- 如果伊甸园内存已满,会进行一次minor gc
- 然后再进行判断伊甸园中的内存是否足够
- 如果不足 则去看存活区的内存是否足够.
- 如果内存足够,把伊甸园部分活跃对象保存在存活区,然后把对象保存在伊甸园.
- 如果内存不足,向老年代发送请求,查询老年代的内存是否足够
- 如果老年代内存足够,将部分存活区的活跃对象存入老年代.然后把伊甸园的活跃对象放入存活区,对象依旧保存在伊甸园.
- 如果老年代内存不足,会进行一次full gc,之后老年代会再进行判断 内存是否足够,如果足够 同上.
- 如果不足 会抛出OutOfMemoryError.
参考链接:
http://ju.outofmemory.cn/entry/358715
https://liujiacai.net/blog/2018/07/08/mark-sweep/