会导致 goroutine 数量增加吗？
我们的应用程序在测试环境中运行。
我们所做的唯一改变是，将 Go 版本从 1.13 升级到 1.16，而不是直接将应用程序部署为容器，而是首次将其作为 pod 部署在私有 kubernetes 集群中。
goroutine 数量突然增加了将近 15 个（从 15 个上升到 30 个），保持稳定。
您可以提出的任何可能的原因可能是造成这种情况的原因吗？
【问题讨论】：
标签： go kubernetes goroutine
因为您在这个等式中至少有两个变量——Go 的升级和更改的部署方案——不可能进行有根据的猜测。
您应该从这样的想法开始，即 goroutine 不是由为您的应用程序提供支持的 Go 运行时创建的：虽然它确实自己使用了多个 goroutine，但它确实是“几个”——也就是说，它们的数量远低于 10，因此活动 goroutine 数量翻倍应该是由其他一些原因造成的。
此外，在用 Go 编写的典型软件中——网络服务器为客户端发出的并发请求提供服务——（你的软件看起来属于这一类）通常每个活动客户端请求至少有一个 goroutine（其中一个是“主要的”，而其他的可能会被创建来帮助主要的）因此增加的原因可能是新部署方案允许在持续负载下更好地并发客户端请求。
当然，可能还有许多其他原因。
例如，您的代码中可能存在错误，导致无法正确处理已终止的客户端请求，在新的部署方案中，由于网络的细微变化而暴露出来。
或者您可能已经升级了一些依赖项，这些依赖项开始为同一工作单元使用更多的 goroutine。
收集统计 goroutine 数量的指标可能存在错误或功能。
你看，我越想猜测我的猜测就越疯狂，但我仍然无法检查任何一个。
我要告诉你的是，与其问关于 SO 的没有实际意义的问题，你应该意识到自己是一名软件工程师（或 devops 人或其他人；我敢肯定你不是会计师或兽医），因此在发生此类问题时进行受过教育的研究基本上是你的工作。
一个好的分析方法是收集所有活动的 goroutine 的转储并分析它们的堆栈跟踪：这会让你了解每个活动的 goroutine 正在做什么。
有几种方法可以做到这一点：例如，使用SIGQUIT 终止进程将产生转储到进程'stdout;我不知道是否可以从 k8s pod 思想中收集这些信息。
另一种方法是使用 net/http/pprof 包，然后 pefrorm GET 到正在运行的进程的 /debug/pprof/goroutines?debug=1。
【讨论】：