Memory leak in golang slice

后端 未结 1 718
面向向阳花
面向向阳花 2021-01-18 00:45

I just started learning go, while going through slice tricks, couple of points are very confusing. can any one help me to clarify.

To cut elements in slice its given

1条回答
  •  伪装坚强ぢ
    2021-01-18 01:25

    Simplest can be demonstrated by a simple slice expression.

    Let's start with a slice of *int pointers:

    s := []*int{new(int), new(int)}
    

    This slice has a backing array with a length of 2, and it contains 2 non-nil pointers, pointing to allocated integers (outside of the backing array).

    Now if we reslice this slice:

    s = s[:1]
    

    Length will become 1. The backing array (holding 2 pointers) is not touched, it sill holds 2 valid pointers. Even though we don't use the 2nd pointer now, since it is in memory (it is the backing array), the pointed object (which is a memory space for storing an int value) cannot be freed by the garbage collector.

    The same thing happens if you "cut" multiple elements from the middle. If the original slice (and its backing array) was filled with non-nil pointers, and if you don't zero them (with nil), they will be kept in memory.

    Why isn't this an issue with non-pointers?

    Actually, this is an issue with all pointer and "header" types (like slices and strings), not just pointers.

    If you would have a slice of type []int instead of []*int, then slicing it will just "hide" elements that are of int type which must stay in memory as part of the backing array regardless of if there's a slice that contains it or not. The elements are not references to objects stored outside of the array, while pointers refer to objects being outside of the array.

    If the slice contains pointers and you nil them before the slicing operation, if there are no other references to the pointed objects (if the array was the only one holding the pointers), they can be freed, they will not be kept due to still having a slice (and thus the backing array).

    Update:

    When you have a slice of structs:

    var bkSlice = []Books{Book1, Book2}
    

    If you slice it like:

    bkSlice = bkSlice[:1]
    

    Book2 will become unreachabe via bkSlice, but still will be in memory (as part of the backing array).

    You can't nil it because nil is not a valid value for structs. You can however assign its zero value to it like this:

    bkSlice[1] = Book{}
    bkSlice = bkSlice[:1]
    

    Note that a Books struct value will still be in memory, being the second element of the backing array, but that struct will be a zero value, and thus will not hold string references, thus the original book author and title strings can be garbage collected (if no one else references them; more precisely the byte slice referred from the string header).

    The general rule is "recursive": You only need to zero elements that refer to memory located outside of the backing array. So if you have a slice of structs that only have e.g. int fields, you do not need to zero it, in fact it's just unnecessary extra work. If the struct has fields that are pointers, or slices, or e.g. other struct type that have pointers or slices etc., then you should zero it in order to remove the reference to the memory outside of the backing array.

    0 讨论(0)
提交回复
热议问题