Go sync.Pool

Free retelling of documentation for sync.Pool

The garbage collector (hereinafter referred to as GC) does not constantly collect garbage, but at regular intervals. If your code allocates memory for some data structures, and then frees them - and so on a circle - this causes a certain pressure on the GC, including making the runtime turn to the OS for allocating new memory. Imagine: select a piece (for example []byte ), work with it, release it. It will take some time before the GC "wakes up from sleep" and collect this piece . If at this time we allocate one more such piece and the memory already allocated to the OS is not enough for it, then the application will have to ask the OS for more memory. By the time the application memory request from the OS lasts forever. And at this very time, somewhere gathering dust, the old "spent" piece is waiting for its time.
What to do?

• create pool
• reset the state of the piece
• pool the waste pieces
• take new pieces from the pool

Create pool

 import( "sync" ) var bytesPool = sync.Pool{ New: func() interface{} { return []byte{} }, } /*     `New`  .   ,  `New`  `nil` -        .      `interace{}` -    .   -    . */ 

Reset state

 //  ary   []byte     ary = ary[:0] //  len,  cap 

Put in pool

 /*          ,       (    ) -  ; :   2048        500-800 ,         -        */ const maxCap = 1024 if cap(ary) <= maxCap { //       bytesPool.Put(ary) } 

Take from the pool

 nextAry := bytesPool.Get().([]byte) 

Explanation about New

The New function creates an empty []byte{} , and even these conversions to interface{} and vice versa. In the case of []byte we are likely to increase it with the help of append , which in principle makes such an approach unprofitable:

• creating []byte zero capacity
• double conversion to interface{} and back
• append will still create a new piece.
• append can be fed nil , only of type [] byte (and not interface {})

It is much more convenient to make two functions that would deal with all the mess with the pool.
')

 //  func getBytes() (b []byte) { ifc := bytesPool.Get() if ifc != nil { b = ifc.([]byte) } return } //  func putBytes(b []byte) { if cap(b) <= maxCap { b = b[:0] //  bytesPool.Put(b) } } 

Remember

• sync.Pool not a panacea
• pool is gorutino-safe
• the pool will not necessarily release the data when the GC first wakes up, but it can free them at any time
• it is not possible to determine and set the size of the pool
• no need to worry about pool overflow
• There is no need to pool the pool anywhere, it was created as a shock absorber with multiple sharing of some common objects, not even just inside the package, but even more - in other packages.
• you probably have or will be situations where the need / opportunity to help the GC will be obvious
• a pool of limited size is made using a pipe with a buffer

A good example of using a pool is the fmt package. From the 109th to the 150th row.

---