Why the `list.Remove()` try to avoid memory leaks explicitly?

Question

The source code of container/list.Remove() tries to avoid memory leaks explicitly by assigning nil to specific variables, why should we do this? thanks!

The code is in the golang source code of version 1.12.

// remove removes e from its list, decrements l.len, and returns e.
func (l *List) remove(e *Element) *Element {
    e.prev.next = e.next
    e.next.prev = e.prev
    e.next = nil // avoid memory leaks
    e.prev = nil // avoid memory leaks
    e.list = nil
    l.len--
    return e
}

Can't GC handle this situation?

score 2 · Accepted Answer · answered May 20 '19 at 03:59

An element removed from a list cannot be pointing to other elements in the list after its removal.

Consider the list A -> B -> C -> D . And you remove the element B from the above list. Without the statement

e.next = nil

in the code snipped above, the memory layout will look like this.


A -> C > D
     ^
     |
     B

Now if the element B is still in use(say element B is used till the end of the progarm), It has a pointer to C. This means that C cannot be garbage collected even if C is removed from list later and is not required for anymore.

A similar case can occur for e.prev

Why the `list.Remove()` try to avoid memory leaks explicitly?

1 Answers1