为什么 Go 模块在下游服务抖动恢复后，CPU 占用无法恢复 about blog_comment HOT 9 OPEN

很有意思。似乎真正的元凶并非 checkdead。
checkdead 会在检查完 m 的数量后直接返回，很少能进入后续的 allgs 检查阶段，对其产生依赖的 sysmon 会保持相对轻量的性能；实际线程的状态也会在运行较为稳定的情况下不会发生太大变化。

相反真正会频繁对 allgs 进行扫描的只有 GC 的 gcResetMarkState。

from blog_comment.

我们去年就发现了，连着压测几次，压测结果一次不如一次…最后换fasthttp了，创建g逻辑动不了，只能在应用层加判断了

from blog_comment.

给 Go 官方提 issue 吧，应该会处理的

from blog_comment.

@tiancaiamao
给 Go 官方提 issue 吧，应该会处理的

提啦~
golang/go#34457

from blog_comment.

goroutine 池子大法好。我们基本上没有直接用裸的 go func(){} 了

from blog_comment.

@choleraehyq ，我们这外部服务基本都是 sdk，要是别人在 sdk 里干坏事，挡不住哎

from blog_comment.

@changkun ，确实实际看 pprof 也是 gc 的成本高了些~

from blog_comment.

这个在创建线程时不会checkdead吧，貌似是checkmcount

from blog_comment.

@contestjia ，这里说的确实不严谨，当时看是 templateThread 进来会有一个检查，我简单改一下

from blog_comment.