golang gc介绍

何为GC？GC全称为Garbage Collection，中文翻译为垃圾回收。它是一种自动发现与释放内存中不再使用的内存区域的过程。这些不再使用的内存区域被称为垃圾，自动垃圾回收机制可以有效避免程序中内存泄漏的问题，提升程序性能。常见的垃圾回收机制包括：引用计数、标记-清除、分代收集等。引用计数机制通过维护每个对象的引用计数，当引用该对象的引用被销毁时，引用计数减一。当计数为零时，表示该对象已被释放。标记-清除机制通过从根对象开始遍历所有引用的对象，标记为“被引用”。没有被标记的对象会被回收。分代收集机制将对象按照生命周期长短划分不同的代空间，长生命周期的对象放在老年代，短生命周期的对象放在新生代，采用不同的回收算法和回收频率。为什么要有GC？程序运行时会申请大量内存空间，但内存资源有限。如果不对不再使用的内存空间进行及时清理，会导致内存溢出，造成程序崩溃。垃圾回收机制可以管理内存重复使用，减轻开发者对内存管理的负担，减少内存相关问题

golang 垃圾回收、三色标记法、写屏障

垃圾回收简称GC，其核心是自动释放程序中不再使用的内存资源。常见的垃圾回收算法包括引用计数、标记-清除以及分代收集。引用计数通过跟踪每个对象的引用计数来决定是否释放；标记-清除算法从根节点开始遍历引用链，标记所有引用的对象，未被标记的对象将被回收；分代收集则根据对象生命周期的长短将其划分到不同的代空间中，采用不同的回收算法和频率。 在Go语言早期版本中，使用的是标记-清除算法，但在执行过程中需要暂停用户程序（STW），这严重降低了程序执行效率。为了解决这一问题，Go语言从1.5版本开始引入了三色标记法，并结合屏障技术，大幅缩短了STW时间，实现了用户程序与垃圾回收过程并行。 三色标记法通过将对象抽象为三种颜色：白色、灰色、黑色，以标记和清除过程。初始所有对象为白色状态，从根节点开始遍历，将访问到的对象标记为灰色并放入待处理队列，然后遍历所有灰色对象，将其变黑，并将所引用的对象变灰加入队列。这一过程循环执行直至队列为空

如何缓解Golang大型游戏服务器的GC压力

背景：Golang的垃圾回收器采用并行三色标记回收算法，该算法在处理老年代和新生代对象时存在局限，导致在对象数量过多时，新生代对象的回收效率降低，进而影响程序性能，对大型游戏服务器造成压力。分析：减少对象分配和提高回收效率是缓解压力的两个主要方向。减少分配可以通过合并对象、使用值代替指针等方式，但这只在微观层面有效，且效果有限。对象池可以重用对象，但对对象类型和关系复杂性有较高要求，且没有GC兜底时容易出现对象泄露问题。CGO提供了一种在C层面上绕过GC的方法，但因C语言的限制，使用复杂度高，不适合大型项目。因此，探索一个GC透明的内存分配器成为了解决方案。思路：考虑到直接使用CGO或现有成熟方案的局限性，决定通过Golang实现一个GC透明的分配器。该分配器将内存视为字节数组，使用unsafe指针和reflect.NewAt来实现内存分配，并将分配器本身作为全局数据，实现对象的永久存储，减少GC压力

[Go三关-典藏版]Golang垃圾回收+混合写屏障GC全分析

文章总结：Golang的垃圾回收机制历经多代优化，从最初的标记-清除方式，到引入三色并发标记法，再到混合写屏障GC，不断减少STW停机时间，提升效率。本文详细剖析了这些版本的GC策略，包括G0到V1.8的演进过程和其背后的关键技术，如STW、屏障机制等，以及它们对程序性能的影响。从V1.3的显著停机，到V1.5的三色并发标记减少停机，再到V1.8的混合写屏障几乎无STW，展示了Go团队在优化GC性能上的持续努力。1. V1.3之前的标记-清除算法存在明显的STW问题，程序暂停执行，效率低下。2. V1.5引入三色并发标记法，通过三个阶段标记对象，虽不完全避免STW，但有所优化，但仍需在标记结束时对栈进行重新扫描。3. V1.8的混合写屏障机制则结合了删除和插入屏障的优点，仅在开始时扫描栈并保持黑色，大大减少STW时间，提高整体效率。通过这些版本的变迁，Go的垃圾回收机制不断向着低停机、高效能的方向发展

golang 版本升级1.16 -> 1.19

随着Go语言的持续发展，其最新稳定版已升级至1.20，期间引入了诸多新特性。在版本迭代中，1.16至1.19之间的改进尤为显著，特别是在性能优化方面。在本地的性能分析中，我们观察到了trace日志的显著变化。通过对比1.16和1.19.4的STW（stop the world）时间，可以明显看出，1.19.4在垃圾收集（GC）效率上有了显著提升。进一步解析，GODEBUG中的"gctrace"数据揭示了这种改进背后的机制。在1.19版本之后，强制GC的触发变得更加频繁，大约每两分钟执行一次，这可能是由于内存管理策略的调整，确保内存增长在可接受范围内。在灰度部署阶段，我们进行了更为细致的验证。在14:05开始，我们分步骤将30%、50%和100%的系统升级到1.19版本，同时跟踪了性能指标。观察拉长时间线后，一个清晰的结论浮出水面：升级到1.19版本后，系统的p99响应时间明显下降，这证明了新版本在实际应用中的优越性能