思考并回答以下问题:
Go是一个自动垃圾回收的编程语言,采用三色并发标记算法标记对象并回收。和其它没有自动垃圾回收的编程语言不同,使用Go语言创建对象的时候,我们没有回收/释放的心理负担,想用就用,想创建就创建。
但是,如果你想使用Go开发一个高性能的应用程序的话,就必须考虑垃圾回收给性能带来的影响,毕竟,Go的自动垃圾回收机制还是有一个STW(stop-the-world,程序暂停)的时间,而且,大量地创建在堆上的对象,也会影响垃圾回收标记的时间。
所以,一般我们做性能优化的时候,会采用对象池的方式,把不用的对象回收起来,避免被垃圾回收掉,这样使用的时候就不必在堆上重新创建了。
不止如此,像数据库连接、TCP的长连接,这些连接在创建的时候是一个非常耗时的操作。如果每次都创建一个新的连接对象,耗时较长,很可能整个业务的大部分耗时都花在了创建连接上。
所以,如果我们能把这些连接保存下来,避免每次使用的时候都重新创建,不仅可以大大减少业务的耗时,还能提高应用程序的整体性能。
Go标准库中提供了一个通用的Pool数据结构,也就是sync.Pool,我们使用它可以创建池化的对象。这节课我会详细给你介绍一下sync.Pool的使用方法、实现原理以及常见的坑,帮助你全方位地掌握标准库的Pool。
不过,这个类型也有一些使用起来不太方便的地方,就是它池化的对象可能会被垃圾回收掉,这对于数据库长连接等场景是不合适的。所以在这一讲中,我会专门介绍其它的一些Pool,包括TCP连接池、数据库连接池等等。
除此之外,我还会专门介绍一个池的应用场景:WorkerPool,或者叫做goroutinepool,这也是常用的一种并发模式,可以使用有限的goroutine资源去处理大量的业务数据。
sync.Pool
首先,我们来学习下标准库提供的sync.Pool数据类型。sync.Pool数据类型用来保存一组可独立访问的临时对象。请注意这里加粗的“临时”这两个字,它说明了sync.Pool这个数据类型的特点,也就是说,它池化的对象会在未来的某个时候被毫无预兆地移除掉。而且,如果没有别的对象引用这个被移除的对象的话,这个被移除的对象就会被垃圾回收掉。因为Pool可以有效地减少新对象的申请,从而提高程序性能,所以Go内部库也用到了sync.Pool,比如fmt包,它会使用一个动态大小的buffer池做输出缓存,当大量的goroutine并发输出的时候,就会创建比较多的buffer,并且在不需要的时候回收掉。有两个知识点你需要记住:sync.Pool本身就是线程安全的,多个goroutine可以并发地调用它的方法存取对象;sync.Pool不可在使用之后再复制使用。
sync.Pool的使用方法
知道了sync.Pool这个数据类型的特点,接下来,我们来学习下它的使用方法。其实,这个数据类型不难,它只提供了三个对外的方法:New、Get和Put。1.NewPoolstruct包含一个New字段,这个字段的类型是函数func()interface{}。当调用Pool的Get方法从池中获取元素,没有更多的空闲元素可返回时,就会调用这个New方法来创建新的元素。如果你没有设置New字段,没有更多的空闲元素可返回时,Get方法将返回nil,表明当前没有可用的元素。有趣的是,New是可变的字段。这就意味着,你可以在程序运行的时候改变创建元素的方法。当然,很少有人会这么做,因为一般我们创建元素的逻辑都是一致的,要创建的也是同一类的元素,所以你在使用Pool的时候也没必要玩一些“花活”,在程序运行时更改New的值。
2.Get如果调用这个方法,就会从Pool取走一个元素,这也就意味着,这个元素会从Pool中移除,返回给调用者。不过,除了返回值是正常实例化的元素,Get方法的返回值还可能会是一个nil(Pool.New字段没有设置,又没有空闲元素可以返回),所以你在使用的时候,可能需要判断。3.Put这个方法用于将一个元素返还给Pool,Pool会把这个元素保存到池中,并且可以复用。但如果Put一个nil值,Pool就会忽略这个值。好了,了解了这几个方法,下面我们看看sync.Pool最常用的一个场景:buffer池(缓冲池)。因为byteslice是经常被创建销毁的一类对象,使用buffer池可以缓存已经创建的byteslice,比如,著名的静态网站生成工具Hugo中,就包含这样的实现bufpool,你可以看一下下面这段代码:
除了Hugo,这段buffer池的代码非常常用。很可能你在阅读其它项目的代码的时候就碰到过,或者是你自己实现buffer池的时候也会这么去实现,但是请你注意了,这段代码是有问题的,你一定不要将上面的代码应用到实际的产品中。它可能会有内存泄漏的问题,下面我会重点讲这个问题。实现原理了解了sync.Pool的基本使用方法,下面我们就来重点学习下它的实现。Go1.13之前的sync.Pool的实现有2大问题:
1,每次GC都会回收创建的对象。如果缓存元素数量太多,就会导致STW耗时变长;缓存元素都被回收后,会导致Get命中率下降,Get方法不得不新创建很多对象。
2,底层实现使用了Mutex,对这个锁并发请求竞争激烈的时候,会导致性能的下降。在Go1.13中,sync.Pool做了大量的优化。前几讲中我提到过,提高并发程序性能的优化点是尽量不要使用锁,如果不得已使用了锁,就把锁Go的粒度降到最低。Go对Pool的优化就是避免使用锁,同时将加锁的queue改成lock-free的queue的实现,给即将移除的元素再多一次“复活”的机会。当前,sync.Pool的数据结构如下图所示:
Pool最重要的两个字段是local和victim,因为它们两个主要用来存储空闲的元素。弄清楚这两个字段的处理逻辑,你就能完全掌握sync.Pool的实现了。下面我们来看看这两个字段的关系。每次垃圾回收的时候,Pool会把victim中的对象移除,然后把local的数据给victim,这样的话,local就会被清空,而victim就像一个垃圾分拣站,里面的东西可能会被当做垃圾丢弃了,但是里面有用的东西也可能被捡回来重新使用。victim中的元素如果被Get取走,那么这个元素就很幸运,因为它又“活”过来了。但是,如果这个时候Get的并发不是很大,元素没有被Get取走,那么就会被移除掉,因为没有别人引用它的话,就会被垃圾回收掉。下面的代码是垃圾回收时sync.Pool的处理逻辑:
在这段代码中,你需要关注一下local字段,因为所有当前主要的空闲可用的元素都存放在local字段中,请求元素时也是优先从local字段中查找可用的元素。local字段包含一个poolLocalInternal字段,并提供CPU缓存对齐,从而避免falsesharing。而poolLocalInternal也包含两个字段:private和shared。private,代表一个缓存的元素,而且只能由相应的一个P存取。因为一个P同时只能执行一个goroutine,所以不会有并发的问题。shared,可以由任意的P访问,但是只有本地的P才能pushHead/popHead,其它P可以popTail,相当于只有一个本地的P作为生产者(Producer),多个P作为消费者(Consumer),它是使用一个local-free的queue列表实现的。Get方法我们来看看Get方法的具体实现原理。
我来给你解释下这段代码。首先,从本地的private字段中获取可用元素,因为没有锁,获取元素的过程会非常快,如果没有获取到,就尝试从本地的shared获取一个,如果还没有,会使用getSlow方法去其它的shared中“偷”一个。最后,如果没有获取到,就尝试使用New函数创建一个新的。这里的重点是getSlow方法,我们来分析下。看名字也就知道了,它的耗时可能比较长。它首先要遍历所有的local,尝试从它们的shared弹出一个元素。如果还没找到一个,那么,就开始对victim下手了。在vintim中查询可用元素的逻辑还是一样的,先从对应的victim的private查找,如果查不到,就再从其它victim的shared中查找。下面的代码是getSlow方法的主要逻辑:
这里我没列出pin代码的实现,你只需要知道,pin方法会将此goroutine固定在当前的P上,避免查找元素期间被其它的P执行。固定的好处就是查找元素期间直接得到跟这个P相关的local。有一点需要注意的是,pin方法在执行的时候,如果跟这个P相关的local还没有创建,或者运行时P的数量被修改了的话,就会新创建local。Put方法我们来看看Put方法的具体实现原理。
Put的逻辑相对简单,优先设置本地private,如果private字段已经有值了,那么就把此元素push到本地队列中。sync.Pool的坑到这里,我们就掌握了sync.Pool的使用方法和实现原理,接下来,我要再和你聊聊容易踩的两个坑,分别是内存泄漏和内存浪费。内存泄漏这节课刚开始的时候,我讲到,可以使用sync.Pool做buffer池,但是,如果用刚刚的那种方式做buffer池的话,可能会有内存泄漏的风险。为啥这么说呢?我们来分析一下。
取出来的bytes.Buffer在使用的时候,我们可以往这个元素中增加大量的byte数据,这会导致底层的byteslice的容量可能会变得很大。这个时候,即使Reset再放回到池子中,这些byteslice的容量不会改变,所占的空间依然很大。而且,因为Pool回收的机制,这些大的Buffer可能不被回收,而是会一直占用很大的空间,这属于内存泄漏的问题。即使是Go的标准库,在内存泄漏这个问题上也栽了几次坑,比如issue23199、@dsnet提供了一个简单的可重现的例子,演示了内存泄漏的问题。再比如encoding、json中类似的问题:将容量已经变得很大的Buffer再放回Pool中,导致内存泄漏。后来在元素放回时,增加了检查逻辑,改成放回的超过一定大小的buffer,就直接丢弃掉,不再放到池子中,如下所示:
packagefmt中也有这个问题,修改方法是一样的,超过一定大小的buffer,就直接丢弃了:
在使用sync.Pool回收buffer的时候,一定要检查回收的对象的大小。如果buffer太大,就不要回收了,否则就太浪费了。内存浪费除了内存泄漏以外,还有一种浪费的情况,就是池子中的buffer都比较大,但在实际使用的时候,很多时候只需要一个小的buffer,这也是一种浪费现象。接下来,我就讲解一下这种情况的处理方法。要做到物尽其用,尽可能不浪费的话,我们可以将buffer池分成几层。首先,小于512byte的元素的buffer占一个池子;其次,小于1Kbyte大小的元素占一个池子;再次,小于4Kbyte大小的元素占一个池子。这样分成几个池子以后,就可以根据需要,到所需大小的池子中获取buffer了。在标准库net/http/server.go中的代码中,就提供了2K和4K两个writer的池子。你可以看看下面这段代码:
YouTube开源的知名项目vitess中提供了bucketpool的实现,它提供了更加通用的多层buffer池。你在使用的时候,只需要指定池子的最大和最小尺寸,vitess就会自动计算出合适的池子数。而且,当你调用Get方法的时候,只需要传入你要获取的buffer的大小,就可以了。下面这段代码就描述了这个过程,你可以看看:第三方库除了这种分层的为了节省空间的buffer设计外,还有其它的一些第三方的库也会提供buffer池的功能。接下来我带你熟悉几个常用的第三方的库。
1.bytebufferpool这是fasthttp作者valyala提供的一个buffer池,基本功能和sync.Pool相同。它的底层也是使用sync.Pool实现的,包括会检测最大的buffer,超过最大尺寸的buffer,就会被丢弃。valyala一向很擅长挖掘系统的性能,这个库也不例外。它提供了校准(calibrate,用来动态调整创建元素的权重)的机制,可以“智能”地调整Pool的defaultSize和maxSize。一般来说,我们使用buffersize的场景比较固定,所用buffer的大小会集中在某个范围里。有了校准的特性,bytebufferpool就能够偏重于创建这个范围大小的buffer,从而节省空间。
2.oxtoacart/bpool这也是比较常用的buffer池,它提供了以下几种类型的buffer。bpool.BufferPool:提供一个固定元素数量的buffer池,元素类型是bytes.Buffer,如果超过这个数量,Put的时候就丢弃,如果池中的元素都被取光了,会新建一个返回。Put回去的时候,不会检测buffer的大小。bpool.BytesPool:提供一个固定元素数量的byteslice池,元素类型是byteslice。Put回去的时候不检测slice的大小。bpool.SizedBufferPool:提供一个固定元素数量的buffer池,如果超过这个数量,Put的时候就丢弃,如果池中的元素都被取光了,会新建一个返回。Put回去的时候,会检测buffer的大小,超过指定的大小的话,就会创建一个新的满足条件的buffer放回去。
bpool最大的特色就是能够保持池子中元素的数量,一旦Put的数量多于它的阈值,就会自动丢弃,而sync.Pool是一个没有限制的池子,只要Put就会收进去。bpool是基于Channel实现的,不像sync.Pool为了提高性能而做了很多优化,所以,在性能上比不过sync.Pool。不过,它提供了限制Pool容量的功能,所以,如果你想控制Pool的容量的话,可以考虑这个库。连接池Pool的另一个很常用的一个场景就是保持TCP的连接。一个TCP的连接创建,需要三次握手等过程,如果是TLS的,还会需要更多的步骤,如果加上身份认证等逻辑的话,耗时会更长。所以,为了避免每次通讯的时候都新创建连接,我们一般会建立一个连接的池子,预先把连接创建好,或者是逐步把连接放在池子中,减少连接创建的耗时,从而提高系统的性能。
事实上,我们很少会使用sync.Pool去池化连接对象,原因就在于,sync.Pool会无通知地在某个时候就把连接移除垃圾回收掉了,而我们的场景是需要长久保持这个连接,所以,我们一般会使用其它方法来池化连接,比如接下来我要讲到的几种需要保持长连接的Pool。标准库中的httpclient池标准库的http.Client是一个httpclient的库,可以用它来访问web服务器。为了提高性能,这个Client的实现也是通过池的方法来缓存一定数量的连接,以便后续重用这些连接。http.Client实现连接池的代码是在Transport类型中,它使用idleConn保存持久化的可重用的长连接:
TCP连接池最常用的一个TCP连接池是fatih开发的fatih/pool,虽然这个项目已经被fatih归档(Archived),不再维护了,但是因为它相当稳定了,我们可以开箱即用。即使你有一些特殊的需求,也可以fork它,然后自己再做修改。它的使用套路如下:
虽然我一直在说TCP,但是它管理的是更通用的net.Conn,不局限于TCP连接。它通过把net.Conn包装成PoolConn,实现了拦截net.Conn的Close方法,避免了真正地关闭底层连接,而是把这个连接放回到池中:
它的Pool是通过Channel实现的,空闲的连接放入到Channel中,这也是Channel的一个应用场景:
数据库连接池标准库sql.DB还提供了一个通用的数据库的连接池,通过MaxOpenConns和MaxIdleConns控制最大的连接数和最大的idle的连接数。默认的MaxIdleConns是2,这个数对于数据库相关的应用来说太小了,我们一般都会调整它。DB的freeConn保存了idle的连接,这样,当我们获取数据库连接的时候,它就会优先尝试从freeConn获取已有的连接(conn)。
MemcachedClient连接池BradFitzpatrick是知名缓存库Memcached的原作者,前Go团队成员。gomemcache是他使用Go开发的Memchaced的客户端,其中也用了连接池的方式池化Memcached的连接。接下来让我们看看它的连接池的实现。gomemcacheClient有一个freeconn的字段,用来保存空闲的连接。当一个请求使用完之后,它会调用putFreeConn放回到池子中,请求的时候,调用getFreeConn优先查询freeConn中是否有可用的连接。它采用Mutex+Slice实现Pool:
WorkerPool最后,我再讲一个Pool应用得非常广泛的场景。你已经知道,goroutine是一个很轻量级的“纤程”,在一个服务器上可以创建十几万甚至几十万的goroutine。但是“可以”和“合适”之间还是有区别的,你会在应用中让几十万的goroutine一直跑吗?基本上是不会的。一个goroutine初始的栈大小是2048个字节,并且在需要的时候可以扩展到1GB(具体的内容你可以课下看看代码中的配置:不同的架构最大数会不同),所以,大量的goroutine还是很耗资源的。同时,大量的goroutine对于调度和垃圾回收的耗时还是会有影响的,因此,goroutine并不是越多越好。有的时候,我们就会创建一个WorkerPool来减少goroutine的使用。比如,我们实现一个TCP服务器,如果每一个连接都要由一个独立的goroutine去处理的话,在大量连接的情况下,就会创建大量的goroutine,这个时候,我们就可以创建一个固定数量的goroutine(Worker),由这一组Worker去处理连接,比如fasthttp中的WorkerPool。
Worker的实现也是五花八门的:有些是在后台默默执行的,不需要等待返回结果;有些需要等待一批任务执行完;有些WorkerPool的生命周期和程序一样长;有些只是临时使用,执行完毕后,Pool就销毁了。大部分的WorkerPool都是通过Channel来缓存任务的,因为Channel能够比较方便地实现并发的保护,有的是多个Worker共享同一个任务Channel,有些是每个Worker都有一个独立的Channel。综合下来,精挑细选,我给你推荐三款易用的WorkerPool,这三个WorkerPool的API设计简单,也比较相似,易于和项目集成,而且提供的功能也是我们常用的功能。
gammazero/workerpool:gammazero/workerpool可以无限制地提交任务,提供了更便利的Submit和SubmitWait方法提交任务,还可以提供当前的worker数和任务数以及关闭Pool的功能。ivpusic/grpool:grpool创建Pool的时候需要提供Worker的数量和等待执行的任务的最大数量,任务的提交是直接往Channel放入任务。dpaks/goworkers:dpaks/goworkers提供了更便利的Submit方法提交任务以及Worker数、任务数等查询方法、关闭Pool的方法。它的任务的执行结果需要在ResultChan和ErrChan中去获取,没有提供阻塞的方法,但是它可以在初始化的时候设置Worker的数量和任务数。类似的WorkerPool的实现非常多,比如还有panjf2000/ants、Jeffail/tunny、benmanns/goworker、go-playground/pool、Sherifabdlnaby/gpool等第三方库。pond也是一个非常不错的WorkerPool,关注度目前不是很高,但是功能非常齐全。
其实,你也可以自己去开发自己的WorkerPool,但是,对于我这种“懒惰”的人来说,只要满足我的实际需求,我还是倾向于从这个几个常用的库中选择一个来使用。所以,我建议你也从常用的库中进行选择。总结Pool是一个通用的概念,也是解决对象重用和预先分配的一个常用的优化手段。即使你自己没在项目中直接使用过,但肯定在使用其它库的时候,就享受到应用Pool的好处了,比如数据库的访问、httpAPI的请求等等。我们一般不会在程序一开始的时候就开始考虑优化,而是等项目开发到一个阶段,或者快结束的时候,才全面地考虑程序中的优化点,而Pool就是常用的一个优化手段。如果你发现程序中有一种GC耗时特别高,有大量的相同类型的临时对象,不断地被创建销毁,这时,你就可以考虑看看,是不是可以通过池化的手段重用这些对象。另外,在分布式系统或者微服务框架中,可能会有大量的并发Client请求,如果Client的耗时占比很大,你也可以考虑池化Client,以便重用。
如果你发现系统中的goroutine数量非常多,程序的内存资源占用比较大,而且整体系统的耗时和GC也比较高,我建议你看看,是否能够通过WorkerPool解决大量goroutine的问题,从而降低这些指标。
思考题
在标准库net/rpc包中,Server端需要解析大量客户端的请求(Request),这些短暂使用的Request是可以重用的。请你检查相关的代码,看看Go开发者都使用了什么样的方式来重用这些对象。