前言

在社区issues#14592可以看到，go中的空闲线程是不会自动回收的(注意是线程而不是协程，GMP模型中的M)，那么就衍生出了三个问题

为什么会产生空闲线程
如何限制最大线程数量
怎么回收空闲线程

CPU线程与OS线程

这个一级目录算是补充一下os的知识吧

CPU线程与OS线程有什么区别和联系呢？操作系统中的进程可以很多，进程中的线程就更多了，常常有几十个上百个。OS中的线程有自己的栈空间，和同一进程中的其他线程共享地址空间等等；CPU中的线程就那么固定几个(例如四核八线程)，是真正的计算资源。

两者都叫线程(Thread)是因为他们都是调度的基本单位。软件的调度基本单位是OS的线程，硬件的调度基本单位是CPU中的线程。操作系统负责把它产生的软线程调度到CPU中的硬线程中去进行计算。

GMP模型中的M皆是OS中的线程，所以后续所说的线程线程都是OS中的

为什么会产生空闲线程

如果不熟悉GMP模型请先弄明白了深入理解GMP模型再接着读后续

我们都知道GOMAXPROCS可以设置GMP中P的数量，那么GOMAXPROCS到底代表什么含义呢？

The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously.
There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit.
This package’s GOMAXPROCS function queries and changes the limit.

GOMAXPROCS 变量限制了可以同时执行用户级 Go 代码的操作系统线程数。
代表Go代码在系统调用中可以阻塞的线程数没有限制；这些不计入GOMAXPROCS 限制。
这个包的 GOMAXPROCS 函数查询和更改限制。

注意这里的重点在系统调用中可以阻塞的线程数没有限制；这些不计入GOMAXPROCS 限制，也就是说在系统调用中被阻塞的线程不在此限制之中。

那么问题就来了，在深入理解GMP模型的场景10中，我们说过，一旦这个G陷入系统调用了，那么与之对应的M和P就会解除绑定，而G和M绑定在一起，直到解除阻塞，
那么在陷入系统调用之后，因为在系统调用中可以阻塞的线程数没有限制；这些不计入GOMAXPROCS 限制的原因，就会有新的M与P绑定，那么解除阻塞后，G回到了全局队列中，这个M呢？因为它没有P，所以它得不到任务，此时M就是空闲线程了。

那么问题来了，如果短时间内，GO程序存在大量的系统调用，那线程数量不就暴涨了？
这也就是为什么在深入理解GMP模型的(1)GMP模型简介里面说，GO语言本身的原因，把M限制为10000的原因，这个值存在的主要目的是限制可以创建无限数量线程的GO程序，即在程序把操作系统干爆之前，干掉程序。

如何限制最大线程数量

GO提供了debug.SetMaxThreads()方法可以让我们限制最大线程数量

先来看不做限制的情况

package mainimport ("fmt""net""runtime/pprof""sync"
)var threadProfile = pprof.Lookup("threadcreate")func main() {fmt.Println("创建协程之前的线程数量：", threadProfile.Count())var wg sync.WaitGroupfor i := 0; i < 100; i++ {wg.Add(1)go func() {defer wg.Done()for j := 0; j < 100; j++ {net.LookupHost("www.baidu.com")}}()}wg.Wait()fmt.Println("创建协程之后的线程数量：", threadProfile.Count())
}

创建协程之前的线程数量： 6
创建协程之后的线程数量： 88

限制的情况

package mainimport ("fmt""net""runtime/debug""runtime/pprof""sync"
)var threadProfile = pprof.Lookup("threadcreate")func main() {debug.SetMaxThreads(10)fmt.Println("创建协程之前的线程数量：", threadProfile.Count())var wg sync.WaitGroupfor i := 0; i < 100; i++ {wg.Add(1)go func() {defer wg.Done()for j := 0; j < 100; j++ {net.LookupHost("www.baidu.com")}}()}wg.Wait()fmt.Println("创建协程之后的线程数量：", threadProfile.Count())
}

创建协程之前的线程数量： 6
runtime: program exceeds 10-thread limit
fatal error: thread exhaustion

当程序启动的线程M超过我们所设置的线程数量时，就会立马报错

怎么回收空闲线程

issues#14592提出的问题就是让空闲的 OS 线程退出，不过目前并没有一个完美的解决方案，有人提出用runtime.LockOSThread()杀死线程，下面来介绍这个方法

调用 LockOSThread 函数会把当前 G 绑定在当前的系统线程 M 上，这个 G 总是在这个 M 上执行，并且阻止其它 G 在该 M 执行
只有当前 G 调用了与之前调用 LockOSThread 相同次数的 UnlockOSThread 函数之后，G 与 M 才会解绑
如果当前 G 在退出时，没有调用 UnlockOSThread，这个线程会被终止

利用第三个特性，在启动 G 时，调用 LockOSThread 来独占一个 M。当 G 退出时，而不调用 UnlockOSThread，那这个 M 就会被终止杀死了

package mainimport ("fmt""net""runtime""runtime/pprof""sync"
)var threadProfile = pprof.Lookup("threadcreate")func main() {fmt.Println("创建协程之前的线程数量：", threadProfile.Count())var wg sync.WaitGroupfor i := 0; i < 100; i++ {wg.Add(1)go func() {runtime.LockOSThread()defer wg.Done()for j := 0; j < 100; j++ {net.LookupHost("www.baidu.com")}}()}wg.Wait()fmt.Println("创建协程之后的线程数量：", threadProfile.Count())
}

# 现在的
创建协程之前的线程数量： 6
创建协程之后的线程数量： 13# 之前的
创建协程之前的线程数量： 6
创建协程之后的线程数量： 88

由于调用了 runtime.LockOSThread 函数的 G 没有执行 UnlockOSThread 函数，在 G 执行完毕后，M 也被终止了，空闲线程大量减少了

不过这个方法其实是存在隐患的，具体看issues，下面是截取的片段

Hi @superajun-wsj Not sure that it is good solution. When the child process is created by one thread called A with PdeathSignal: SIGKILL and the thread A becomes idle, if the thread A exits, the child process will receive KILL signal. So I think UnLockOSThread might introduce other issues. just my two cents.

总结

在绝大多数情况下，我们的程序并不会遇到空闲线程数过多的问题。如果真的存在线程数暴涨的问题，那么你应该思考代码逻辑是否合理（为什么你能允许短时间内如此多的系统同步调用），是否可以做一些例如限流之类的处理。而不是想着通过 SetMaxThreads 方法来处理。

go-issues#14592 runtime: let idle OS threads exit 内核线程暴增与线程回收问题相关推荐

C11头文件threads.h声明了创建和管理线程,信号,条件变量的函数
作者Danny Kalev 是通过以色列系统分析师协会认证的系统分析师, 并且是专攻C++的软件工程师. Kalev 写了多本C++的书籍,同时给不同的软件开发者站点投搞C++文章. 他是C++标准委 ...
【Get 以太坊技能】遇到错误 issues#14633 runtime: out of memory:cannot allocate 1413480448-byte block (737902592
前言 geth version Geth Version: 1.9.7-stable Git Commit: a718daa674a2e23cb0c8a6789f7e5467e705bbbd Git ...
Runtime.exec 调用OS命令特例
1. 运行带有重定向的命令. String[] shellCommand = {"/bin/ksh", "-c", "/usr/lib/sendmai ...
Python的os模块常用文件夹的增删改查详解
python常用os模块增 os.makedirs("path\\目录") 用于递归创建目录删 os.remove("path")用于删除指定路径(path ...
OS / Linux / 主线程退出了，子线程会退出吗？
在 linux 世界中,主线程退出了,子线程是否退出是要看主线程的退出方式. 主线程以 return 的方式退出. 主线程以 pthread_exit() 函数的方式退出. 前者,main() 执行完 ...
如何有效控制 Go 线程数？
前阵子,在读者交流群中有人提到 Go 默认设置的最大线程数的问题:如果超过一万个 G (挂载于 M 上)阻塞于系统调用,那么程序就会被挂掉. 这是对的,因为 Go 对运行时创建的线程数量有一个限制,默 ...
tableau大屏bi_Excel，Tableau，Power BI ...您应该使用什么？
tableau大屏bi After publishing my previous article on data visualization with Power BI, I received qui ...
tomcat线程释放时间_聊下并发和Tomcat线程数（错误更正）
本文前半部分结论存在严重错误,请看最后2015-1-20更新部分. 最近一直在解决线上一个问题,表现是: Tomcat每到凌晨会有一个高峰,峰值的并发达到了3000以上,最后的结果是Tomcat线程池 ...
st(state-threads) coroutine和stack分析
st(state-threads) https://github.com/winlinvip/state-threads 以及基于st的RTMP/HLS服务器:https://github.com/w ...

go-issues#14592 runtime: let idle OS threads exit 内核线程暴增与线程回收问题

issues#14592

前言

CPU线程与OS线程

为什么会产生空闲线程

如何限制最大线程数量

怎么回收空闲线程

总结

go-issues#14592 runtime: let idle OS threads exit 内核线程暴增与线程回收问题相关推荐

最新文章

热门文章