multithreading - golang 应用程序运行时保留了很多线程

Question

golang 应用程序是一个通过调用c 库接收文件，将其保存到磁盘并报告传输状态以使用http 协议(protocol)监控服务的工具。

经过几次传输，我发现大约有 70+ 个线程和几个 goroutines 存在。

我检查了 c 和 go 源代码，没有发现线程或 goroutine 泄漏。我使用“dlv”来调试应用程序，这是其中一个线程的堆栈:

(dlv) bt
0  0x000000000046df03 in runtime.futex
   at /home/vagrant/resource/go/src/runtime/sys_linux_amd64.s:388
1  0x0000000000437e92 in runtime.futexsleep
   at /home/vagrant/resource/go/src/runtime/os_linux.go:45
2  0x000000000041e042 in runtime.notesleep
   at /home/vagrant/resource/go/src/runtime/lock_futex.go:145
3  0x000000000044036d in runtime.stopm
   at /home/vagrant/resource/go/src/runtime/proc.go:1594
4  0x0000000000441178 in runtime.findrunnable
   at /home/vagrant/resource/go/src/runtime/proc.go:2021
5  0x0000000000441cec in runtime.schedule
   at /home/vagrant/resource/go/src/runtime/proc.go:2120
6  0x0000000000442063 in runtime.park_m
   at /home/vagrant/resource/go/src/runtime/proc.go:2183
7  0x0000000000469f1b in runtime.mcall
   at /home/vagrant/resource/go/src/runtime/asm_amd64.s:240

不知道这些线程是从哪里来的，有没有可能是golang运行时的线程池？

谁能看看这个，非常感谢!

Answer 1

问题

The golang application is a tool that receives file by invoking a c library, saves it to disk and report the transfer state to monitor service with http protocol.

After a few transferring, I found there are about 70+ threads existed with a few goroutines.

原因

对 C 的每次调用(通过 cgo，或 Windows 上的 syscall 等)都不是真的与执行 OS 系统调用不同，只要 Go 调度程序很关心。

这是怎么回事:

1. 当一个 goroutine 被执行时，它运行在一个 OS 线程上(这是显而易见的，我想)。

2. 当它执行系统调用或调用 C 时，goroutine 会阻塞(停止执行 Go 代码)。

3. Go 运行时调度程序监视被阻塞的 goroutine在至少一个“调度程序滴答”之后(目前——在Go 1.8 和 1.9 — 是 20 µs) 通过，goroutine 仍然被阻塞，还有其他可运行的 goroutines，调度器创建另一个 OS 线程来创建其他 goroutine继续执行。

这种行为乍一看似乎有悖常理但如果没有它，比如在一台双 CPU 机器上，你只需要调用并行的两个系统调用(例如读取或写入文件)任何两个 goroutines 来阻止其余的事件 goroutines从做他们的工作。换句话说，调度器试图跟上 Go 的 promise 总是有 GOMAXPROCS goroutines 运行如果有 goroutines 想要运行，并且 GOMAXPROCS设置为机器的CPU(核心)数。

因此，如果您有相当高的 C 调用流失率，而这些调用的完成速度比单个调度程序滴答慢，那么您将拥有不断增长的池分配的操作系统线程数。

请注意，这本身并不坏:当然，您将分配资源(在典型的商用操作系统上，每个线程分配了大约 8 MiB 的堆栈加上操作系统内部的一些簿记数据结构)但它们是不浪费:这些线程将在需要时立即重用。比如说，您的下一次此类 C 调用突发将重用分配的线程。

解决方案

不过，如果您想防止这种情况发生，常用的方法是是合理地序列化您的 C 调用。

一个典型的方法是有一个单一的“ worker ”goroutine它接收“任务”——通常以某种类型的值的形式您创建的自定义类型 - 通过 channel 发送结果他们通过另一个 channel 执行。

输入 channel 可能被缓冲——有效地将它变成一个队列。

如果您仍想并行化该工作，您可以拥有一个池worker goroutines——全部读取单个输入 channel 并写入单一输出 channel 。

但请注意，如果那些 C 调用将大部分时间用于磁盘 I/O和他们读/写的文件位于文件系统中由单一媒体支持，您通常不会获得太多并行化，除非该介质非常快——例如 SSD 或内存 (RAM) 磁盘。

因此请考虑所有选项并仔细考虑您的设计。