Java/Python/Go不同开发语言基础数据结构和相关操作总结
- 1. 常见gc方式
- 1.1 gc判断对象是否存活
- 1.2 引用计数法
- 1.2 标记-清除算法
- 1.3 复制算法
- 1.4 标记-压缩算法
- 1.5 分代收集算法
- 2. java的gc方式以及垃圾回收器
- 2.1 gc方式
- 2.1 gc回收器
- 2.1.1 Serial收集器
- 2.1.2 ParNew收集器
- 2.1.3 Parallel Scavenge 收集器
- 2.1.4 Parallel Old 收集器
- 2.1.5 CMS收集器
- 2.1.6 G1收集器
- 3. python的gc方式以及垃圾回收器
- 3.1 gc方式
- 3.2 gc回收器
- 4. go的gc方式以及垃圾回收器
- 4.1 gc方式
- 4.1.1 三色标记法
- 4.1.2 gc工作原理
- 4.2 gc回收器
- 5. 疑问和思考
- 6. 参考文档
由于最近频繁在java、python、go三种开发语言中不断切换,有时候针对基础的数据结构和日常操作搞混了,因此本文进行相关梳理。文中涉及的相关数据结构和日常操作并不复杂,权当增强记忆和理解。通过整理常见的gc方法,进行内存回收,并梳理不同开发语言对于gc的使用方式,以及相关利弊。
1. 常见gc方式
垃圾收集(Garbage Collection) 通常被称为"GC",它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了。
jvm 中,程序计数器、虚拟机栈、本地方法栈都是随线程而生随线程而灭,栈帧随着方法的进入和退出做入栈和出栈操作,实现了自动的内存清理。
返回java常见gc方式
1.1 gc判断对象是否存活
gc需要判断对象是否存活,以判断是否能够进行回收。判断对象是否存活一般有两种方式:
-
引用计数
每个对象有一个引用计数属性,新增一个引用时计数加1,引用释放时计数减1,计数为0时可以回收。此方法简单,无法解决对象相互循环引用的问题。 -
可达性分析(Reachability Analysis)
从GC Roots开始向下搜索,搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的,是不可达对象。
1.2 引用计数法
通过对每个对象维护一个引用计数器来判断对象是否可回收。当引用计数器为0时,对象被认为是垃圾,可以被回收。
优点:实现简单,垃圾对象便于辨识;判定效率高,回收没有延迟性。
缺点:
- 需要单独的字段存储计数器,这样的做法增加了存储空间的开销。
- 每次赋值都需要更新计数器,伴随着加法和减法操作,这增加了时间开销。
- 引用计数器还有一个严重的问题,即无法处理循环引用的问题,这是一条致命的缺陷
1.2 标记-清除算法
“标记-清除”(Mark-Sweep)算法,如它的名字一样,算法分为"标记"和"清除"两个阶段:首先标记出所有需要回收的对象,在标记完成后统一回收掉所有被标记的对象。之所以说它是最基础的收集算法,是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的
它的主要缺点有两个:
- 一个是效率问题,标记和清除过程的效率都不高;
- 另外一个是空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致,当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作
1.3 复制算法
“复制”(Copying)的收集算法,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉
优点:
- 每次都是对其中的一块进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可,实现简单,运行高效。
缺点
- 将内存缩小为原来的一半,持续复制长生存期的对象则导致效率降低
1.4 标记-压缩算法
根据老年代的特点,有人提出了另外一种"标记-压缩"(Mark-Compact)算法,标记过程仍然与"标记-清除"算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存
1.5 分代收集算法
GC分代的基本假设:绝大部分对象的生命周期都非常短暂,存活时间短。
“分代收集”(Generational Collection)算法,把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。
- 在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集
- 老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用**“标记-清理"或"标记-压缩”**算法来进行回收
2. java的gc方式以及垃圾回收器
2.1 gc方式
常见gc方式 中介绍的gc方式java都在使用,相关的工作原理参考
2.1 gc回收器
如果说收集算法是内存回收的方法论,垃圾收集器就是内存回收的具体实现
2.1.1 Serial收集器
串行收集器是最古老,最稳定以及效率高的收集器,可能会产生较长的停顿,只使用一个线程去回收,新生代、老年代串行回收,新生代使用复制算法,老年代使用标记-压缩算法,垃圾收集的过程中会Stop The World(服务暂停)
参数控制:-XX:+UseSerialGC 指定收集器为Serial收集器
2.1.2 ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本,新生代使用"复制"算法并行收集,老年代使用"标记-压缩"算法串行收集
参数控制:
-XX:+UseParNewGC 指定收集器为ParNew收集器
-XX:ParallelGCThreads 限制线程数量
2.1.3 Parallel Scavenge 收集器
Parallel Scavenge收集器类似ParNew收集器,Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或最大的吞吐量;也可以通过参数控制GC的时间不大于多少毫秒或者比例;新生代使用"复制"算法,老年代使用"标记-压缩"
参数控制:-XX:+UseParallelGC 使用Parallel收集器+老年代串行
2.1.4 Parallel Old 收集器
Parallel Old是Parallel Scavenge收集器的老年代版本,使用多线程和"标记压缩"算法。这个收集器是在JDK 1.6中才开始提供
参数控制: -XX:+UseParallelOldGC 使用Parallel收集器+老年代并行
2.1.5 CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。
从名字(包含"Mark Sweep")上就可以看出CMS收集器是基于"标记-清除"算法实现的,它的运作过程相对于前面几种收集器来说要更复杂一些,
整个过程分为4个步骤,包括:
- 初始标记(CMS initial mark)
- 并发标记(CMS concurrent mark)
- 重新标记(CMS remark)
- 并发清除(CMS concurrent sweep)
其中初始标记、重新标记这两个步骤仍然需要"Stop The World"。初始标记仅仅只是标记一下GC Roots能直接关联到的对象,速度很快,并发标记阶段就是进行GC Roots Tracing的过程,而重新标记阶段则是为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段稍长一些,但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程中,收集器线程都可以与用户线程一起工作,所以总体上来说,CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器(新生代使用ParNew)
优点:并发收集、低停顿
缺点:产生大量空间碎片、并发阶段会降低吞吐量
参数控制:
-XX:+UseConcMarkSweepGC 使用CMS收集器
-XX:+UseCMSCompactAtFullCollection "Full GC"后,进行一次碎片整理,整理过程是独占的,会引起停顿时间变长
-XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后,进行一次碎片整理
-XX:ParallelCMSThreads 设定CMS的线程数量(一般情况约等于可用CPU数量)
2.1.6 G1收集器
G1是目前技术发展的最前沿成果之一,HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点:
空间整合,G1收集器采用"标记-压缩"算法,不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
可预测停顿,这是G1的另一大优势,降低停顿时间是G1和CMS的共同关注点,但G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为N毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒,这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。
上面提到的垃圾收集器,收集的范围都是整个新生代或者老年代,而G1不再是这样。使用G1收集器时,Java堆的内存布局与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔阂了,它们都是一部分(可以不连续)Region的集合。
收集步骤:
- 标记阶段,首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event),并且会触发一次普通Mintor GC,对应GC log:GC pause (young) (inital-mark)
- Root Region Scanning,程序运行过程中会回收survivor区(存活到老年代),这一过程必须在young GC之前完成。
- Concurrent Marking,在整个堆中进行并发标记(和应用程序并发执行),此过程可能被young GC中断。在并发标记阶段,若发现区域对象中的所有对象都是垃圾,那个这个区域会被立即回收(图中打X)。同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例)。
- Remark, 再标记,会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行);G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
- 清理阶段
-
Copy/Clean up,多线程清除失活对象,会有STW。G1将回收区域的存活对象拷贝到新区域,清除Remember Sets,并发清空回收区域并把它返回到空闲区域链表中。
-
复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。
3. python的gc方式以及垃圾回收器
3.1 gc方式
- 主要通过引用计数(Reference Counting)进行垃圾回收
- 通过标记清除解决循环对象的循环依赖问题
- 在循环引用对象的回收中,整个应用程序会被暂停,为了减少应用程序暂停的时间,Python 通过“分代回收”(Generational Collection)以空间换时间的方法提高垃圾回收效率。
3.2 gc回收器
python没有提供类似java复杂的gc回收器,而是可以通过gc模块提供垃圾回收器的接口进行gc的控制。
此模块提供可选的垃圾回收器的接口,提供的功能包括:关闭收集器、调整收集频率、设置调试选项。它同时提供对回收器找到但是无法释放的不可达对象的访问。由于 Python 使用了带有引用计数的回收器,如果你确定你的程序不会产生循环引用,你可以关闭回收器。可以通过调用 gc.disable() 关闭自动垃圾回收。若要调试一个存在内存泄漏的程序,调用 gc.set_debug(gc.DEBUG_LEAK) ;需要注意的是,它包含 gc.DEBUG_SAVEALL ,使得被垃圾回收的对象会被存放在 gc.garbage 中以待检查。
import gc
import pprint
class Graph:
def __init__(self, name):
self.name = name
self.next = None
def set_next(self, next):
print('Linking nodes {}.next = {}'.format(self, next))
self.next = next
def __repr__(self):
return '{}({})'.format(
self.__class__.__name__, self.name)
# 构造一个引用循环。
one = Graph('one')
two = Graph('two')
three = Graph('three')
one.set_next(two)
two.set_next(three)
three.set_next(one)
print()
print('three refers to:')
for r in gc.get_referents(three):
pprint.pprint(r)
4. go的gc方式以及垃圾回收器
当前Golang使用的垃圾回收机制是三色标记法配合写屏障和辅助GC,三色标记法是标记-清除法的一种增强版本。
4.1 gc方式
4.1.1 三色标记法
三色标记法是对标记阶段的改进,原理如下:
- 初始状态所有对象都是白色。
- 从root根出发扫描所有根对象(下图a,b),将他们引用的对象标记为灰色(图中A,B)
- 分析灰色对象是否引用了其他对象。如果没有引用其它对象则将该灰色对象标记为黑色(上图中A);如果有引用则将它变为黑色的同时将它引用的对象也变为灰色(上图中B引用了D)
- 重复步骤3,直到灰色对象队列为空。此时白色对象即为垃圾,进行回收。
4.1.2 gc工作原理
GC工作的完整流程:
- Mark: 包含两部分:
- Mark Prepare: 初始化GC任务,包括开启写屏障(write barrier)和辅助GC(mutator assist),统计root对象的任务数量等。这个过程需要STW
- GC Drains: 扫描所有root对象,包括全局指针和goroutine(G)栈上的指针(扫描对应G栈时需停止该G),将其加入标记队列(灰色队列),并循环处理灰色队列的对象,直到灰色队列为空。该过程后台并行执行
- Mark Termination: 完成标记工作,重新扫描(re-scan)全局指针和栈。因为Mark和用户程序是并行的,所以在Mark过程中可能会有新的对象分配和指针赋值,这个时候就需要通过写屏障(write barrier)记录下来,re-scan 再检查一下。这个过程也是会STW的。
- Sweep: 按照标记结果回收所有的白色对象,该过程后台并行执行
- Sweep Termination: 对未清扫的span进行清扫, 只有上一轮的GC的清扫工作完成才可以开始新一轮的GC。
写屏障(Write Barrier):
在每一轮GC开始时会初始化一个叫做“屏障”的东西,然后由它记录第一次scan时各个对象的状态,以便和第二次re-scan进行比对,引用状态变化的对象被标记为灰色以防止丢失,将屏障前后状态未变化对象继续处理。
辅助GC:
Go 语⾔如果发现扫描后回收的速度跟不上分配的速度它依然会把⽤户逻辑暂停,⽤户逻辑暂停了以后也就意味着不会有新的对象出现,同时会把⽤户线程抢过来加⼊到垃圾回收⾥⾯加快垃圾回收的速度。这样⼀来原来的并发还是变成了STW,还是得把⽤户线程暂停掉,要不然扫描和回收没完没了了停不下来,因为新分配对象⽐回收快,所以这种东⻄叫做辅助回收。
4.2 gc回收器
go没有提供类似java复杂的gc回收器
5. 疑问和思考
暂无
6. 参考文档
- 图解常见 GC 算法和垃圾收集器