Go GC 似乎没有收集我用于图像加载的未引用指针？

大家好，今天本人给大家带来文章《Go GC 似乎没有收集我用于图像加载的未引用指针？》，文中内容主要涉及到，如果你对Golang方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

我正在使用 OpenGL 开发一个 Go 项目，并且有代码可以通过 go/image 库加载图像文件。该函数没有留下永久指针，然后我离开该函数的范围。我希望该内存在下一个 GC 周期中被清除，但似乎并没有。我希望更了解 go 的人可以帮助我了解为什么图像没有被清除。

代码要点：https://gist.github.com/gjh33/62a75ccde6a7d849311804d31d7ee9ff

不调用该方法时，内存占用为17mb，调用该方法时，内存占用为40mb。即使等待 5 分钟后，该内存也不会被 GC。

如果您没有在 go 中使用过 openGL，请记住一些事情：

• 到不安全指针的转换（第 41 行）通过以下方式进行：https://github.com/go-gl/gl/blob/master/v3.2-core/gl/conversions.go
• 我正在使用 go-gl v3.2-core
• 如果您需要更多信息或背景信息，请直接询问

解决方案

这是一个主要的误解：Go 是一种垃圾收集语言，这意味着内存仅在所谓的垃圾收集期间被释放，垃圾收集定期 并且不会以任何方式由正在执行的代码中超出范围的变量触发。

可以说，在 Go 实现的 GC 算法中，每次扫描都由两个连续的阶段组成：扫描和清除。 在扫描阶段，将遍历所有活动对象（通过它们相互维护的指针（如果有的话），并且通过正在运行的 goroutine 和全局变量的堆栈无法访问的对象被标记为在扫描阶段发生的释放。

Go 运行时实现了一个相当复杂的“估计器”，它试图推断启动下一个 GC 会话的目标堆大小，以便在堆使用率和支付的 CPU 成本之间取得平衡用于执行 GC 会话。

这意味着两件事：

• 在 Go 中，丢失对已分配内存块的所有引用这一事实对于运行时来说没有任何意义：这个事实只会在下一个 GC 周期中被考虑。
• 在不执行任何分配的空闲程序中，一块已分配的内存有可能根本不会被回收，因为永远不会执行 GC 循环。

附带说明一下，GC 的原始图像 您所持有的作品本身并不是不真实的 - 确实存在没有显式内存管理的编程语言，在您提到的情况下，它们实际上会取消分配内存。这对于脚本（至少最初）编程语言来说是典型的，例如 Python、Tcl、Perl（至少 5）等。这些语言对它们操作的值使用所谓的引用计数。逻辑基本上是，每次对变量进行赋值（包括将其作为函数的参数传递）都会增加为该变量记录的引用数量，并且当执行离开变量的范围时，保存在变量中的值的引用计数它被减少。当某个值的引用计数降至 0 时，该值将被释放。

这种方法有效，而且看起来很自然，但它有一些缺点，例如：

• 需要为每个值维护一个引用计数字段。
• 每次更新该字段时都需要花费 CPU 周期（此外还有 CPU 缓存抖动）。
• 该方案无法处理循环引用。

我还要补充一点，该方案不能很好地处理对变量的并发访问：如果您在混合中添加并发（如 Go 中），您最终将需要这些引用计数的所有更新字段是互斥的，并且会出现一些不有趣的问题，例如当一个执行线程取消引用一个值，注意到引用计数越过零并释放该值，然后另一个线程等待前者增加引用时，如何处理这种情况解除阻塞后发现它想要引用的值已经不存在了。

本篇关于《Go GC 似乎没有收集我用于图像加载的未引用指针？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！