我有一个用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
使用pool是标准的
// 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 {
答案 0 :(得分：1)
https://golang.org/pkg/sync/#Pool
作为短期对象的一部分维护的空闲列表不是 适用于资产池，因为间接费用不能很好地摊销 那个场景。实现这样的对象更有效 他们自己的免费清单
https://dave.cheney.net/2015/11/29/a-whirlwind-tour-of-gos-runtime-environment-variables
答案 1 :(得分：1)
sync.Pool以高并发负载运行缓慢。尝试在启动期间分配所有结构并多次使用它。例如，您可以在开始时创建几个goroutine（worker），而不是在每个请求上运行新的goroutine。我建议您阅读这篇文章：https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs。
答案 2 :(得分：0)
Go 1.13（2019年第四季度）可能会改变这一点：请参阅CL 166961。
最初的问题是issue 22950：“ 同步：避免清除每个GC上的完整池”
令我惊讶的是，每个周期又有大约1000个分配。这似乎表明Pool在每个GC上都将清除其全部内容。
peek at the implementation似乎表明确实如此。
结果：
sync：使用受害者缓存来消除GC上的Pool行为当前，每个池在每个GC的开始都被完全清除。
对于大量使用Pool的用户来说，这是一个问题，因为它会在清除Pools之后立即导致分配高峰，这会影响吞吐量和延迟。此CL通过引入受害者缓存机制来解决此问题。
代替清除池，将删除受害缓存，而将主缓存 移动到受害者缓存。
因此，在稳定状态下，（几乎）没有新分配，但是如果Pool使用率下降，对象仍将收集在两个GC中（而不是一个）。
这种受害者缓存方法还可以改善Pool对GC动态的影响。
当前方法导致Pools中的所有对象短暂存在。但是，如果应用程序处于稳定状态并打算重新填充其Pools，那么这些对象会影响实时堆大小 ，就像它们长期存在一样。
由于在计算GC触发器和目标时，池化对象算作短期对象，而在实时堆中却充当长期对象，因此导致GC触发过于频繁。
如果池化对象是应用程序堆的重要部分，则此 增加了GC的CPU开销。受害者缓存允许合并对象 会影响GC触发器和目标，使其成为长期存在的对象。这对
Get/Put的性能没有影响，但对substantially reduces the impact to the Pool user when a GC happens却有影响。
PoolExpensiveNew通过大幅降低 就会调用“New”功能。