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

前言

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

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

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 main

import (
	"fmt"
	"net"
	"runtime/pprof"
	"sync"
)

var threadProfile = pprof.Lookup("threadcreate")

func main() {

	fmt.Println("创建协程之前的线程数量：", threadProfile.Count())
	var wg sync.WaitGroup
	for 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 main

import (
	"fmt"
	"net"
	"runtime/debug"
	"runtime/pprof"
	"sync"
)

var threadProfile = pprof.Lookup("threadcreate")

func main() {
	debug.SetMaxThreads(10)
	fmt.Println("创建协程之前的线程数量：", threadProfile.Count())
	var wg sync.WaitGroup
	for 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()杀死线程，下面来介绍这个方法

1. 调用 LockOSThread 函数会把当前 G 绑定在当前的系统线程 M 上，这个 G 总是在这个 M 上执行，并且阻止其它 G 在该 M 执行

2. 只有当前 G 调用了与之前调用 LockOSThread 相同次数的 UnlockOSThread 函数之后，G 与 M 才会解绑

3. 如果当前 G 在退出时，没有调用 UnlockOSThread，这个线程会被终止

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

package main

import (
	"fmt"
	"net"
	"runtime"
	"runtime/pprof"
	"sync"
)

var threadProfile = pprof.Lookup("threadcreate")

func main() {
	fmt.Println("创建协程之前的线程数量：", threadProfile.Count())
	var wg sync.WaitGroup
	for 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 方法来处理。