高性能Golang之临时对象池

内存分配问题

Slice扩充机制

初始化一个slice,初学者会用:

make([]int64, 0)

高级一些的程序员都会知道,这样第一次分配内存相当于没有分配,如果要后续append元素,会引起slice以指数形式扩充,可以参考下面的代码,追加了3个元素,slice扩容了3次。

a := make([]int64, 0)
fmt.Println(cap(a), len(a))

for i := 0; i < 3; i++ {
	a = append(a, 1)
	fmt.Println(cap(a), len(a))
}

0 0
1 1
2 2
4 3

每一次扩容空间,都是会重新申请一块区域,把就空间里面的元素复制进来,把新的追加进来。那旧空间里面的元素怎么办?等着垃圾回收呗。

简单的优化方式,就是给自己要用的slice提前申请好空间。

make([]int64, 0, len(ids))

这样做避免了slice多次扩容申请内存,但还是有问题的。

程序的内存分配、栈内存和堆内存

程序的内存分为以下几个部分:
1、栈区(stack)—由编译器自动分配释放 ,存放函数的参数值,局部变量的值等。其操作方式类似于数据结构中的栈
2、堆区(heap)— 一般由程序员分配释放,若程序员不释放,程序结束时可能由OS回收。注意它与数据结构中的堆是两回事,分配方式倒是类似于链表
3、全局区(静态区)(static)—,全局变量和静态变量的存储是放在一块的,初始化的全局变量和静态变量在一块区域,未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。-程序结束后有系统释放
4、文字常量区—常量字符串就是放在这里的。 程序结束后由系统释放
5、程序代码区—存放函数体的二进制代码。


如下定义的临时变量,将分配到栈区,函数执行之后会自动释放。

func F() {
	temp := make([]int, 0, 20)
	...
}

好处:函数返回直接释放,不会引起垃圾回收,对性能没有影响


如下定义的三个变量,都将分配到堆区。

func F() []int{
	a := make([]int, 0, 20)
	b := make([]int, 0, 20000)
	l := 20
	c := make([]int, 0, l)
	return a
}

变量a因为是返回值,系统默认其还将在接下来的程序中起作用,因此不分配到栈区。
变量b虽然是临时变量,但申请的内存很大,也将分配到堆区。
变量c因为分配的长度不定,也将分配到堆内存。

内存碎片化

实际项目基本都是通过 c := make([]int, 0, l) 来申请内存,长度都是不确定的。自然而然这些变量都会申请到堆上面了。Golang使用的垃圾回收算法是『标记——清除』。简单得说,就是程序要从操作系统申请一块比较大的内存,内存分成小块,通过链表链接。每次程序申请内存,就从链表上面遍历每一小块,找到符合的就返回其地址,没有合适的就从操作系统再申请。如果申请内存次数较多,而且申请的大小不固定,就会引起内存碎片化的问题。申请的堆内存并没有用完,但是用户申请的内存的时候却没有合适的空间提供。这样会遍历整个链表,还会继续向操作系统申请内存,申请一块内存变成了慢语句。

slice长度不定—> 分配到堆内存 —> 分页式内存分配导致内存碎片化 —> 申请内存语句速度急剧下降

用临时对象池构建本地缓存

什么是临时对象池

sync.Pool — 临时对象池是一些可以分别存储和取出的临时对象。池中的对象会在没有任何通知的情况下被移出。实际上,这个清理过程是在每次垃圾回收之前做的。垃圾回收是固定两分钟触发一次。而且每次清理会将Pool中的所有对象都清理掉!

Pool 结构体的定义为:

type Pool struct {
   noCopy noCopy

   local     unsafe.Pointer // 本地P缓存池指针
   localSize uintptr        // 本地P缓存池大小

   // 当池中没有可能对象时
   // 会调用 New 函数构造构造一个对象
   New func() interface{}
}

Pool 中有两个定义的公共方法,分别是 Put - 向池中添加元素;Get - 从池中获取元素,如果没有,则调用 New 生成元素,如果 New 未设置,则返回 nil。

临时对象池是协程安全的。

临时对象池的使用

代码实现:

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

临时对象池的局限性

这里的例子来自 https://cyent.github.io/golang/goroutine/sync_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

临时内存池终于发挥了作用!

总结:pool适合占用内存大且并发量大的场景。当内存小并发量少的时候,使用pool适得其反

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值