最近线上的一个项目遇到了内存泄露的问题，查了heap之后，发现 http包的 dialConn函数竟然占了内存使用的大头，这个有点懵逼了，后面在网上查询资料的时候无意间发现一句话
10次内存泄露，有9次是goroutine泄露。
结果发现，正是我认为的不可能的goroutine泄露导致了这次的内存泄露，而goroutine泄露的原因就是 没有调用 response.Body.Close()
深入理解Go-内存分配
Go语言内置运行时（就是runtime），抛弃了传统的内存分配方式，改为自主管理，最开始是基于tcmalloc，虽然后面改动相对已经很大了。使用自主管理可以实现更好的内存使用模式，比如内存池、预分配等等，从而避免了系统调用所带来的性能问题。
深入理解Go-逃逸分析
How do I know whether a variable is allocated on the heap or the stack?
From a correctness standpoint, you don’t need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.
The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function’s stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.
In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.
在Go里面定义了一个变量，到底是分配在堆上还是栈上，Go官方文档告诉我们，不需要管，他们会分析，其实这个分析就是逃逸分析
在编程语言的编译优化原理中，分析指针动态范围的方法称之为逃逸分析。通俗来讲，当一个对象的指针被多个方法或线程引用时，我们称这个指针发生了逃逸。
Go学习之Channel的一些模式
除了在goroutine之间安全的传递数据之外，在看了《Concurrency in Go》之后，感慨channel还有那么多模式可供使用，在个人的学习中总结了以下几种常用的模式
在centos7上安装V2ray 比shadowsock更科学的上网方式
近期ss的存活周期越来越短了，具体什么原因，咱也不知道，咱也不敢问，咱只能选择另一种更加科学的上网方式了，这里还是推荐一下 Vultr家的VPS ，换IP方便
Sync.Pool浅析
sync pool使用来存放临时变量的一个缓冲区，但是这个缓冲区并不可靠，每次gc的时候，都会首先清除缓冲区，所以，假如一个slice仅仅存放在 Pool 中，而没有其他地方引用，则会被当成垃圾清理掉。