Go 101 总结了几个可能导致内存泄露的场景：
https://gfw.go101.org/article/memory-leaking.html
goroutine 阻塞在 channel，time.Ticker 不使用但未 stop，以及 for 循环里用 defer
导致泄露，这三个场景其实已经比较常见了，这里就不说了。
我们来看看子切片截取为什么会导致内存泄露。
因为 Go 是一门带 GC 的语言，虽然官方宣传 GC stw
metrics 上报在高并发时会带来性能问题，为了解决问题，有时反而又会带来别的问题。
举个例子，一般的 metrics 上报代码可能是下面这样：
// when request in
metrics.Req(caller, count, latency)
内部实现一般也就是个 UDP 调用，可能碰到的是 fd 锁的问题，在 这篇 [http://xargin.com/lock-contention-in-go/]
里已经写过了。
为了优化这个锁带来的阻塞问题，有些系统会把 metrics 上报改为非阻塞逻辑：
某系统中有类似下面这样的代码：
package main
import (
"sync"
"time"
)
type resp struct {
k string
v string
}
func main() {
res := fetchData()
log.Print(res)
}
func rpcwork() resp {
// do some rpc work
return resp{}
}
func fetchData() (map[string]
https://www.zhihu.com/question/364687707
在知乎上已经说了原因，不过只是讲官方的 spec，我们再来看看实现上具体为什么会是这样的。
package main
import "fmt"
func main() {
a := new(struct{})
b := new(struct{})
println(a, b, a == b)
c := new(struct{})
d := new(struct{
MQ 对于业务系统建模非常重要，是解决分离关注点、依赖反转、CQRS、最终一致等业务问题的重要法宝。
然而企业对于 MQ 中的数据管理却并不重视。从互联网企业发展的历程来看这个问题，最初 MQ 不是很可靠，大家不会把让特别重要的业务依赖 MQ，所以接入到 MQ
的业务事件并不多。总共也就两三个
topic，开发相应的系统对这些内容进行管理看起来没什么必要，甚至可能连详尽的业务信息都要从生产者的代码注释中去寻找。公司规模不大，这些都是可以接受的。
经历过 1Mb 小水管的朋友大概还记得当初火爆的 Flashget 的 Slogan：
> 下载的最大问题是什么——速度，其次是什么—
