我有一个用Go编写的应用程序正在进行消息处理，需要以20K /秒（可能更多）的速率从网络（UDP）接收消息，并且每条消息可以达到UDP数据包的最大长度（64KB-headersize） ，程序需要解码这个传入的数据包并编码成另一种格式并发送到另一个网络;
现在在24核+ 64GB RAM机器上运行正常，但偶尔会丢失一些数据包，编程模式已经跟随pipelines使用多个go-routines / channels并且需要10％的整机CPU负载;因此它有可能使用更多的CPU％或RAM来处理所有20K / s消息而不会丢失任何消息;然后我开始分析，在profiling我发现在cpu配置文件中runtime.mallocgc出现在顶部，那是垃圾收集器运行时，我怀疑这个GC可能是它挂起几毫秒（或几微秒）并丢失一些数据包的罪魁祸首，和一些最佳实践说切换到sync.Pool可能会有所帮助，但我切换到池似乎会导致更多的CPU争用并丢失更多的数据包更频繁
(pprof) top20 -cum (sync|runtime)
245.99s of 458.81s total (53.61%)
Dropped 487 nodes (cum <= 22.94s)
Showing top 20 nodes out of 22 (cum >= 30.46s)
flat flat% sum% cum cum%
0 0% 0% 440.88s 96.09% runtime.goexit
1.91s 0.42% 1.75% 244.87s 53.37% sync.(*Pool).Get
64.42s 14.04% 15.79% 221.57s 48.29% sync.(*Pool).getSlow
94.29s 20.55% 36.56% 125.53s 27.36% sync.(*Mutex).Lock
1.62s 0.35% 36.91% 72.85s 15.88% runtime.systemstack
22.43s 4.89% 41.80% 60.81s 13.25% runtime.mallocgc
22.88s 4.99% 46.79% 51.75s 11.28% runtime.scanobject
1.78s 0.39% 47.17% 49.15s 10.71% runtime.newobject
26.72s 5.82% 53.00% 39.09s 8.52% sync.(*Mutex).Unlock
0.76s 0.17% 53.16% 33.74s 7.35% runtime.gcDrain
0 0% 53.16% 33.70s 7.35% runtime.gcBgMarkWorker
0 0% 53.16% 33.69s 7.34% runtime.gcBgMarkWorker.func2
使用游泳池是标准
// create this one globally at program init
var rfpool = &sync.Pool{New: func() interface{} { return new(aPrivateStruct); }}
// get
rf := rfpool.Get().(*aPrivateStruct)
// put after done processing this message
rfpool.Put(rf)
不确定我做错了吗？或者想知道其他什么方法可以调整GC使用更少的CPU％？ go版本是1.8
该列表显示了pool.getSlow src to pool.go at golang.org中发生了很多锁争用
(pprof) list sync.*.getSlow
Total: 7.65mins
ROUTINE ======================== sync.(*Pool).getSlow in /opt/go1.8/src/sync/pool.go
1.07mins 3.69mins (flat, cum) 48.29% of Total
. . 144: x = p.New()
. . 145: }
. . 146: return x
. . 147:}
. . 148:
80ms 80ms 149:func (p *Pool) getSlow() (x interface{}) {
. . 150: // See the comment in pin regarding ordering of the loads.
30ms 30ms 151: size := atomic.LoadUintptr(&p.localSize) // load-acquire
180ms 180ms 152: local := p.local // load-consume
. . 153: // Try to steal one element from other procs.
30ms 130ms 154: pid := runtime_procPin()
20ms 20ms 155: runtime_procUnpin()
730ms 730ms 156: for i := 0; i < int(size); i++ {
51.55s 51.55s 157: l := indexLocal(local, (pid+i+1)%int(size))
580ms 2.01mins 158: l.Lock()
10.65s 10.65s 159: last := len(l.shared) - 1
40ms 40ms 160: if last >= 0 {
. . 161: x = l.shared[last]
. . 162: l.shared = l.shared[:last]
. 10ms 163: l.Unlock()
. . 164: break
. . 165: }
490ms 37.59s 166: l.Unlock()
. . 167: }
40ms 40ms 168: return x
. . 169:}
. . 170:
. . 171:// pin pins the current goroutine to P, disables preemption and returns poolLocal pool for the P.
. . 172:// Caller must call runtime_procUnpin() when done with the pool.
. . 173:func (p *Pool) pin() *poolLocal {
https://golang.org/pkg/sync/#Pool
作为短期对象的一部分而维护的空闲列表不适合用于池，因为在该场景中开销不能很好地摊销。使这些对象实现自己的空闲列表更有效
https://dave.cheney.net/2015/11/29/a-whirlwind-tour-of-gos-runtime-environment-variables
sync.Pool以高并发负载运行缓慢。尝试在启动期间分配所有结构并多次使用它。例如，您可以在开始时创建几个goroutine（worker），而不是在每个请求上运行新的goroutine。我建议阅读这篇文章：https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs。
去1.13（2019年第四季度）可能会改变：见CL 166961。
最初的问题是issue 22950：“同步：避免清除每个GC上的完整池”
在那里我发现令人惊讶的是每个周期再次有大约1000个分配。这似乎表明Pool正在清除每个GC上的全部内容。 一个peek at the implementation似乎表明这是如此。
结果：
sync：使用受害者缓存平滑GC上的池行为目前，每个GC在每个GC开始时都会被完全清除。 这对于池的大量用户来说是一个问题，因为它会在池清除后立即导致分配峰值，这会影响吞吐量和延迟。
此CL通过引入受害者缓存机制来解决此问题。
不会清除池，而是删除受害者缓存，并将主缓存移动到受害者缓存。
因此，在稳定状态下，（大致）没有新的分配，但如果池使用率下降，则仍将在两个GC（而不是一个）中收集对象。
此受害者缓存方法还可以提高Pool对GC动态的影响。 当前方法导致Pools中的所有对象都是短暂的。但是，如果应用程序处于稳定状态并且只是要重新填充其池，则这些对象会影响实时堆大小，就好像它们很长时间一样。 由于池化对象在计算GC触发器和目标时计为短寿命，但在活动堆中充当长寿命对象，这会导致GC过于频繁地触发。 如果池化对象是应用程序堆的非平凡部分，则会增加GC的CPU开销。受害者缓存使Pooled对象影响GC触发器和目标作为长期存在的对象。
这对
Get/Put表现没有影响，但substantially reduces the impact to the Pool user when a GC happens。PoolExpensiveNew证明了这一点，大大降低了“New”函数的调用率。