在Golang中设置指针为nil以防止内存泄漏

18

我正在学习 Go,作为一个练习,我想实现一个链表。为了参考,我查看了官方 Go 代码 (https://golang.org/src/container/list/list.go)。有一点让我印象深刻的是这些行:

   108  // remove removes e from its list, decrements l.len, and returns e.
   109  func (l *List) remove(e *Element) *Element {
   110      e.prev.next = e.next
   111      e.next.prev = e.prev
   112      e.next = nil // avoid memory leaks
   113      e.prev = nil // avoid memory leaks
   114      e.list = nil
   115      l.len--
   116      return e
   117  } 

我很好奇在这种情况下将指针设置为nil如何防止内存泄漏?如果可能的话,我想构建一个有这个缺陷的程序,并使用pprof进行分析(我将使用未设置此nil指针的list.go的修改版本)。


为了回答更清晰:如果其中一个节点有一个外部指针指向它,则所有相邻的被移除的节点都将通过该指针具有活动引用,并且不会被删除。 enter image description here

  1. 我们创建一个指向Node2的外部指针
  2. 我们从列表中移除节点2-4
  3. 此时您只期望Node 1、2和5仍然存在,并且其余部分被垃圾回收。但是,由于Node2仍然指向Node3等等,整个链仍然未被回收。
2个回答

13

您的假设是正确的。如果有一组指针彼此指向,但没有任何成员的引用/指针指向此组,则垃圾回收器将检测到该组为无法访问,并将适当地释放。

但是,内存泄漏的解释很简单。我们可以从列表中获取 list.Element 包装器,其中包含未导出的 Element.nextElement.prev 指向列表中下一个和上一个元素的指针。

从列表中删除元素时,如果这些指针不被设置为 nil,则它们将保留对下一个和上一个元素包装器的引用,包括与那些元素相关联的值。

请参阅以下示例:

var e2 *list.Element

func main() {
    listTest()
    fmt.Println(e2.Value)
    // At this point we expect everything from the list to be
    // garbage collected at any time, we only have reference to e2.
    // If e2.prev and e2.next would not be set to nil,
    // e1 and e3 could not be freed!
}

func listTest() {
    l := list.New()
    e1 := l.PushBack(1)
    e2 = l.PushBack(2)
    e3 := l.PushBack(3)
    // List is now [1, 2, 3]
    fmt.Println(e1.Value, e2.Value, e3.Value)
    l.Remove(e2)
    // Now list is [1, 3], it does not contain e2
}
listTest()中,我们建立了一个包含3个元素的列表,并将第二个元素存储在全局变量e2中。然后我们移除了这个元素。现在我们期望在listTest()返回时,除了e2(和其中包含的值)之外的所有内容都会被垃圾回收,因为列表在listTest()函数外不可访问。是的,e2中有一个指向元素的指针,但是e2应该与列表无关了,因为我们已经将其移除了。
如果e2中的prevnext指针没有设置为nil,那么它们所指向的元素中包装的值永远无法被递归释放。但是,由于List.Remove()正确地将它们设置为nil,所以在上面的示例中,e1e3以及其中包含的值都将在下一次垃圾回收运行时被释放。

1
我已经根据您所描述的情况修改了问题,并附上了图片,请在有误的情况下纠正我。实际上,我已经尝试使用一个带有内存泄漏错误的修改版本列表进行了测试,我可以看到它没有释放内存。 - synepis

0

Golang的垃圾回收器基于三色标记-清除算法。简而言之,程序使用的每个内存都与一种颜色相关联。这种颜色决定了内存是否应该被垃圾回收。

如果某个内存没有被直接或间接引用,那么该算法将标记该内存以便释放。但是,如果我们看一下代码:

e.prev.next = e.next
e.next.prev = e.prev

这将指针从e.next复制到e.prev.next。现在,假设您想通过一个新的完全创建的元素来更新e.prev.next。

之前删除的元素不会被垃圾回收,因为它仍然被e.next引用。

这就是为什么存在这些行的原因:

e.next = nil // avoid memory leaks
e.prev = nil // avoid memory leaks

这可以防止留下旧的引用,从而防止内存泄漏。


我在上面添加了一条注释,解释了我认为会发生的事情。我不确定你所说的“已删除元素仍由e.next引用”是什么意思,难道e不是被删除的元素吗? - synepis

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接