[TOC]
# 简介
* `sync.Pool是一个可以存或取的临时对象集合`
* `sync.Pool可以安全被多个线程同时使用，保证线程安全`
* `注意、注意、注意，sync.Pool中保存的任何项都可能随时不做通知的释放掉，所以不适合用于像socket长连接或数据库连接池。`
* `sync.Pool主要用途是增加临时对象的重用率，减少GC负担`
# 关于堆和栈
程序会从操作系统申请一块内存，而这块内存也会被分成堆和栈。栈可以简单得理解成一次函数调用内部申请到的内存，它们会随着函数的返回把内存还给系统。
~~~
func F() {
temp := make([]int, 0, 20)
...
}
~~~
类似于上面代码里面的temp变量，只是内函数内部申请的临时变量，并不会作为返回值返回，它就是被编译器申请到栈里面。**申请到栈内存好处：函数返回直接释放，不会引起垃圾回收，对性能没有影响。**
~~~
func F() []int{
a := make([]int, 0, 20)
return a
}
~~~
而上面这段代码，申请的代码一模一样，但是申请后作为返回值返回了，编译器会认为变量之后还会被使用，当函数返回之后并不会将其内存归还，那么它就会被申请到堆上面了。**申请到堆上面的内存才会引起垃圾回收。**
~~~
func F() {
a := make([]int, 0, 20)
b := make([]int, 0, 20000)
l := 20
c := make([]int, 0, l)
}
~~~
a和b代码一样，就是申请的空间不一样大，但是它们两个的命运是截然相反的。a前面已经介绍过，会申请到栈上面，而b，由于申请的内存较大，**编译器会把这种申请内存较大的变量转移到堆上面。即使是临时变量，申请过大也会在堆上面申请。**
而c，对我们而言其含义和a是一致的，**但是编译器对于这种不定长度的申请方式，也会在堆上面申请，即使申请的长度很短。**
实际项目基本都是通过c := make(\[\]int, 0, l)来申请内存，长度都是不确定的。自然而然这些变量都会申请到堆上面了
简单得说，就是程序要从操作系统申请一块比较大的内存，内存分成小块，通过链表链接。每次程序申请内存，就从链表上面遍历每一小块，找到符合的就返回其地址，没有合适的就从操作系统再申请。如果申请内存次数较多，而且申请的大小不固定，就会引起内存碎片化的问题。申请的堆内存并没有用完，但是用户申请的内存的时候却没有合适的空间提供。这样会遍历整个链表，还会继续向操作系统申请内存。这就能解释我一开始描述的问题，**申请一块内存变成了慢语句。**
**申请内存变成了慢语句，解决方法就是使用临时对象池**
# 临时对象池
如何解决这个问题，首先想到的就是对象池。Golang在`sync`里面提供了对象池`Pool`。一般大家都叫这个为对象池，而我喜欢叫它临时对象池。因为每次垃圾回收会把池子里面不被引用的对象回收掉。
> `func (p *Pool) Get() interface{}`
需要注意的是，`Get`方法会把返回的对象从池子里面删除。所以用完了的对象，还是得重新放回池子
~~~
package main
import (
"fmt"
"sync"
"time"
)
// 一个[]byte的对象池，每个对象为一个[]byte
var bytePool = sync.Pool{
New: func() interface{} {
b := make([]byte, 1024)
return &b
},
}
func main() {
a := time.Now().Unix()
// 不使用对象池
for i := 0; i < 1000000000; i++ {
obj := make([]byte, 1024)
_ = obj
}
b := time.Now().Unix()
// 使用对象池
for i := 0; i < 1000000000; i++ {
obj := bytePool.Get().(*[]byte)
bytePool.Put(obj)
}
c := time.Now().Unix()
fmt.Println("without pool ", b-a, "s")
fmt.Println("with pool ", c-b, "s")
}
~~~
输出
~~~
without pool 20 s
with pool 15 s
~~~
~~~
package main
import (
"fmt"
"sync"
)
// 一个[]byte的对象池，每个对象为一个[]byte
var bytePool = sync.Pool{
New: func() interface{} {
b := make([]byte, 8)
return &b
},
}
func main() {
fmt.Printf("%T\n", bytePool)
fmt.Printf("%+v\n", bytePool)
obj := bytePool.Get().(*[]byte)
fmt.Printf("%T\n", obj)
fmt.Printf("%v\n", obj)
}
~~~
输出
~~~
sync.Pool
{noCopy:{} local:<nil> localSize:0 New:0x1090180}
*[]uint8
&[0 0 0 0 0 0 0 0]
~~~
# 何时使用pool
**只有当每个对象占用内存较大时候，用pool才会改善性能**
对比1（起步阶段）:
~~~
package main
import (
"fmt"
"sync"
"time"
)
// 一个[]byte的对象池，每个对象为一个[]byte
var bytePool = sync.Pool{
New: func() interface{} {
b := make([]byte, 1)
return &b
},
}
func main() {
a := time.Now().Unix()
// 不使用对象池
for i := 0; i < 1000000000; i++ {
obj := make([]byte, 1)
_ = obj
}
b := time.Now().Unix()
// 使用对象池
for i := 0; i < 1000000000; i++ {
obj := bytePool.Get().(*[]byte)
bytePool.Put(obj)
}
c := time.Now().Unix()
fmt.Println("without pool ", b-a, "s")
fmt.Println("with pool ", c-b, "s")
}
~~~
输出
~~~
without pool 0 s
with pool 17 s
~~~
可以看到，当\[\]byte只有1个元素时候，用pool性能反而更差
对比2（追赶阶段）:
~~~
package main
import (
"fmt"
"sync"
"time"
)
// 一个[]byte的对象池，每个对象为一个[]byte
var bytePool = sync.Pool{
New: func() interface{} {
b := make([]byte, 800)
return &b
},
}
func main() {
a := time.Now().Unix()
// 不使用对象池
for i := 0; i < 1000000000; i++ {
obj := make([]byte, 800)
_ = obj
}
b := time.Now().Unix()
// 使用对象池
for i := 0; i < 1000000000; i++ {
obj := bytePool.Get().(*[]byte)
bytePool.Put(obj)
}
c := time.Now().Unix()
fmt.Println("without pool ", b-a, "s")
fmt.Println("with pool ", c-b, "s")
}
~~~
输出
~~~
without pool 16 s
with pool 17 s
~~~
可以看到，飞机快赶上跑车了
对比3（超越阶段）:
~~~
package main
import (
"fmt"
"sync"
"time"
)
// 一个[]byte的对象池，每个对象为一个[]byte
var bytePool = sync.Pool{
New: func() interface{} {
b := make([]byte, 8000)
return &b
},
}
func main() {
a := time.Now().Unix()
// 不使用对象池
for i := 0; i < 1000000000; i++ {
obj := make([]byte, 8000)
_ = obj
}
b := time.Now().Unix()
// 使用对象池
for i := 0; i < 1000000000; i++ {
obj := bytePool.Get().(*[]byte)
bytePool.Put(obj)
}
c := time.Now().Unix()
fmt.Println("without pool ", b-a, "s")
fmt.Println("with pool ", c-b, "s")
}
~~~
输出
~~~
without pool 128 s
with pool 17 s
~~~
可以看到2个特征
1. 当每个对象的内存小于一定量的时候，不使用pool的性能秒杀使用pool；当内存处于某个量的时候，不使用pool和使用pool性能相当；当内存大于某个量的时候，使用pool的优势就显现出来了
2. 不使用pool，那么对象占用内存越大，性能下降越厉害；使用pool，无论对象占用内存大还是小，性能都保持不变。可以看到pool有点像飞机，虽然起步比跑车慢，但后劲十足。
即：pool适合占用内存大且并发量大的场景。当内存小并发量少的时候，使用pool适得其反
# 知识点
~~~
package main
import (
"fmt"
"sync"
)
// 一个[]int的对象池，每个对象为一个[]int
var intPool = sync.Pool{
New: func() interface{} {
b := make([]int, 8)
return &b
},
}
func main() {
// 不使用对象池
for i := 1; i < 3; i++ {
obj := make([]int, 8)
obj[i] = i
fmt.Printf("obj%d: %T %+v\n", i, obj, obj)
}
fmt.Println("-----------")
// 使用对象池
for i := 1; i < 3; i++ {
obj := intPool.Get().(*[]int)
(*obj)[i] = i
fmt.Printf("obj%d: %T %+v\n", i, obj, obj)
intPool.Put(obj)
}
}
~~~
输出
~~~
obj1: []int [0 1 0 0 0 0 0 0]
obj2: []int [0 0 2 0 0 0 0 0]
-----------
obj1: *[]int &[0 1 0 0 0 0 0 0]
obj2: *[]int &[0 1 2 0 0 0 0 0]
~~~
可以看到，pool的Get和Put真的是从池里获得和放入池里，否则不会出现Get获得的变量是旧的变量（即之前通过Put放入的）
如果把上面代码中的`intPool.Put(obj)`这行删掉，那么输出就是
~~~
obj1: []int [0 1 0 0 0 0 0 0]
obj2: []int [0 0 2 0 0 0 0 0]
-----------
obj1: *[]int &[0 1 0 0 0 0 0 0]
obj2: *[]int &[0 0 2 0 0 0 0 0]
~~~
1. Pool的目的是缓存已分配但未使用的项目以备后用
2. 多协程并发安全
3. 缓存在Pool里的item会没有任何通知情况下随时被移除，以缓解GC压力
4. 池提供了一种方法来缓解跨多个客户端的分配开销。
5. 不是所有场景都适合用Pool，如果释放链表是某个对象的一部分，并由这个对象维护，而这个对象只由一个客户端使用，在这个客户端工作完成后释放链表，那么用Pool实现这个释放链表是不合适的。
官方对Pool的目的描述：
Pool设计用意是在全局变量里维护的释放链表，尤其是被多个 goroutine 同时访问的全局变量。使用Pool代替自己写的释放链表，可以让程序运行的时候，在恰当的场景下从池里重用某项值。sync.Pool一种合适的方法是，为临时缓冲区创建一个池，多个客户端使用这个缓冲区来共享全局资源。另一方面，如果释放链表是某个对象的一部分，并由这个对象维护，而这个对象只由一个客户端使用，在这个客户端工作完成后释放链表，那么用Pool实现这个释放链表是不合适的。
**Pool的正确用法**
在Put之前重置，在Get之后重置
- 基础
- 简介
- 主要特征
- 变量和常量
- 编码转换
- 数组
- byte与rune
- big
- sort接口
- 和mysql类型对应
- 函数
- 闭包
- 工作区
- 复合类型
- 指针
- 切片
- map
- 结构体
- sync.Map
- 随机数
- 面向对象
- 匿名组合
- 方法
- 接口
- 权限
- 类型查询
- 异常处理
- error
- panic
- recover
- 自定义错误
- 字符串处理
- 正则表达式
- json
- 文件操作
- os
- 文件读写
- 目录
- bufio
- ioutil
- gob
- 栈帧的内存布局
- shell
- 时间处理
- time详情
- time使用
- new和make的区别
- container
- list
- heap
- ring
- 测试
- 单元测试
- Mock依赖
- delve
- 命令
- TestMain
- path和filepath包
- log日志
- 反射
- 详解
- plugin包
- 信号
- goto
- 协程
- 简介
- 创建
- 协程退出
- runtime
- channel
- select
- 死锁
- 互斥锁
- 读写锁
- 条件变量
- 嵌套
- 计算单个协程占用内存
- 执行规则
- 原子操作
- WaitGroup
- 定时器
- 对象池
- sync.once
- 网络编程
- 分层模型
- socket
- tcp
- udp
- 服务端
- 客户端
- 并发服务器
- Http
- 简介
- http服务器
- http客户端
- 爬虫
- 平滑重启
- context
- httptest
- 优雅中止
- web服务平滑重启
- beego
- 安装
- 路由器
- orm
- 单表增删改查
- 多级表
- orm使用
- 高级查询
- 关系查询
- SQL查询
- 元数据二次定义
- 控制器
- 参数解析
- 过滤器
- 数据输出
- 表单数据验证
- 错误处理
- 日志
- 模块
- cache
- task
- 调试模块
- config
- 部署
- 一些包
- gjson
- goredis
- collection
- sjson
- redigo
- aliyunoss
- 密码
- 对称加密
- 非对称加密
- 单向散列函数
- 消息认证
- 数字签名
- mysql优化
- 常见错误
- go run的错误
- 新手常见错误
- 中级错误
- 高级错误
- 常用工具
- 协程-泄露
- go env
- gometalinter代码检查
- go build
- go clean
- go test
- 包管理器
- go mod
- gopm
- go fmt
- pprof
- 提高编译
- go get
- 代理
- 其他的知识
- go内存对齐
- 细节总结
- nginx路由匹配
- 一些博客
- redis为什么快
- cpu高速缓存
- 常用命令
- Go 永久阻塞的方法
- 常用技巧
- 密码加密解密
- for 循环迭代变量
- 备注
- 垃圾回收
- 协程和纤程
- tar-gz
- 红包算法
- 解决golang.org/x 下载失败
- 逃逸分析
- docker
- 镜像
- 容器
- 数据卷
- 网络管理
- 网络模式
- dockerfile
- docker-composer
- 微服务
- protoBuf
- GRPC
- tls
- consul
- micro
- crontab
- shell调用
- gorhill/cronexpr
- raft
- go操作etcd
- mongodb