Golang 内存泄漏场景

虽然Golang 的runtime 会回收内存，但是本文列举的场景仍然会造成内存泄漏。

substrings 使用不当造成内存泄漏

TODO 此处需要了解下golang 的底层 memory block 分配知识

var s0 string // 包级别变量

// A demo purpose function.
func f(s1 string) {
	s0 = s1[:50]
	//s0 和 s1 共用相同的底层memory block
	// 尽管 s1 不再使用，但是 s0仍然存活状态
	// 所以s1 的内存不会被回收，尽管只有 50 byte内存
	// 被使用，但是其他内存都泄漏了。
}

func demo() {
	s := createStringWithLengthOnHeap(1 << 20) // 1M bytes
	f(s)
}

可以用如下方式来避免：

func f(s1 string) {
	s0 = string([]byte(s1[:50]))
}

这个方法的缺点是有50字节的重复了
可以继续优化为如下方式，当然它也有1byte内存的浪费

func f(s1 string) {
	s0 = (" " + s1[:50])[1:]
}

Not Resetting Pointers in Lost Slice Elements

func h() []*int {
	s := []*int{new(int), new(int), new(int), new(int)}
	// do something with s ...

	return s[1:3:3]
}

由于返回的slice 仍然存活状态，会阻止 s中元素被回收。

func h() []*int {
	s := []*int{new(int), new(int), new(int), new(int)}
	// do something with s ...

	// Reset pointer values.
	s[0], s[len(s)-1] = nil, nil
	return s[1:3:3]
}

被goroutinue hang住的内存泄漏

有时候，有些goroutinue 会永远都 hang住

为什么 go runtime 没有杀死hang住的goroutinue 一个原因是因为go routime 很难去判断一个goroutinue 是否是要永远被hang住。另外一个原因是可能是我们故意将goroutinue hang住，例如为了不面程序退出而hang住主要的goroutinue。

time.Ticker

time.Ticker 应该被stop，当不再使用时候

Finalizers

不恰当的使用了析构函数