Golang的内存泄漏场景.pdfVIP

Golang的内存泄漏场景 看到个好⽂章，翻译⼀遍分享⼀下。 内存泄漏场景 当使⽤⽀持⾃动垃圾回收的语⾔进⾏编程时，通常我们不需要关⼼内存泄漏问题，因为运⾏时会定期⼿机⽆⽤的内存。但是我们确实需要了 解⼀些特殊场景，这些场景可能导致似(kind-of)/真内存泄漏。⽂章的后⾯部分会列出⼀些这样的场景。 ⼦字符串导致的似内存泄漏 Go语⾔规范没有指明⼀个⼦字符串表达式中的基字符串和结果字符串是否应该共⽤同个底层内存块来管理两个字符串的底层字节序列。标 准的Go编译器/运⾏时确实是让他们共享了同个底层内存块。这是⼀个很好的设计，不管是从内存还是CPU消化⾓度。但是有时它可能会导 致某种内存泄漏。 ⽐如，在下例中的 demo 函数被调⽤后，会有⼤约 1M字节的似内存，知道package级变量s0在其他地⽅被修改。 ⼀个 级变量 var s0 string // package ⼀个⽤作⽰例的函数 // func f(s1 string) { s0 = s1[:50] 现在， 与 共享了同个底层内存块。尽管 现在不存活了， // s0 s1 s1 仍然存活。所以尽管只⽤到了 个字节，其他字节访问不到， // s0 50 他们共享的内存块并不会被回收。 // } func demo() { 字节 s := createStringWithLengthOnHeap(1 20) // 1M f(s) } 为了避免这种似内存泄漏，我们可以转换底层字符串为⼀个[]byte ，然后把 []byte 转换回 string . func f(s1 string) { s0 = string([]byte(s1[:50])) } 上⾯这种避免这似内存泄漏的⽅法的缺点是，在会话处理过程中，会有两个50字节的副本，其中之⼀是没必要的。 我们可以利⽤标准Go编译器的其中⼀个优化来避免⾮必要的副本，只需要浪费⼀个字节的内存。 func f(s1 string) { s0 = ( + s1[:50])[1:] } 以上⽅法的缺点是，这个编译器优化在以后可能会被取消，并且这个优化可能在其他编译器中没有实现。 第三种避免这个似内存泄漏的⽅法是使⽤strings.Builder ，从Go 1.10开始有的。 import strings func f(s1 string) { var b strings.Builder b .Grow(50) b .WriteString(s1[:50]) s0 = b .String() } 第三种⽅式的缺点是相⽐前两种有些⿇烦。⼀个好消息是，从Go 1.12起，我们可以调⽤strings 标准包的 Repeat 函数，传递 count 参数 为 1 来克隆⼀个字符串。从Go 1.12起，string.Repeat 的底层实现会使⽤ strings.Builder 来避免不必要的复制。 从Go 1.17起， strings 标准包⾥加⼊了⼀个 Clone 函数。它成了做这个事的最好⽅法。 由⼦切⽚导致的似内存泄漏 与⼦字符串类似，⼦切⽚也可能导致似内存泄漏。在以下代码中，在g 函数被调⽤后，占据 s1 ⼤部分内存块的⼤量元素将会丢失(如果没有 更多值指向这个内存块)。 var s0 []int func g(s1 []int) { 假设 的长度远⼤于 // s1 30 s0 = s1[len(s1)-30:] } 如果我们想要避免这个似内存泄漏，我们必须为s0 复制30个元素，这样 s0 的存活就不会阻⽌ s1 的内存块被回收了。 func g(s1 []int) { s0 = make([]int, 30) copy(s0, s1[len(s1)-30:]) 现在，如果没有其他值引⽤着存着 的元素的内存块， // s1 它就可以被回收了。 // } 没有重置丢失的切⽚元素的指针导致的似内存泄漏 在以下代码中，在 h 函数被调⽤后，为 s 的第⼀个和最后⼀个元素分配的内存块将会丢失。 func