之前写过一篇 go 语言并发机制 goroutine 初探，后来对 go 如何跟踪 syscall 调用返回产生了兴趣，研究后发现，之前的一些看法是错误的。

问题是这么发现的。

// par.go
package main

import (
"fmt";
"runtime"
"strconv"
"time"
)

func main() {
        runtime.GOMAXPROCS(2)
        ch := make(chan int)
        n := 1000
        for i := 0; i < n; i++ {
                task(strconv.Itoa(i), ch, 100)
        }
        fmt.Printf("begin\n")
        for i := 0; i < n; i++ {
                <-ch
        }
}

func task(name string, ch chan int, max int) {
        go func() {
                i:= 1
                for i <= max {
                        fmt.Printf("%s %d\n", name, i)
                        i++
                }
                ch <- 1
        }();
}

这么一个程序，运行 ./par | less ，然后查看 /proc/<pid>/tasks，或者用类似的 pstree -p <pid> 。原来指望只有很少的线程数。结果却是 1002 个。看起来似乎是实实在在地为每个 goroutine 启动了一个线程。然后又用 strace -f ./par 2>&1 | less 跟踪，也发现了大量的 clone 系统调用。也就是说，goroutine 并不是像我之前认为的，在 cgocall 或者 syscall 的时候进行自动切换，而是使用了线程。同时，这个线程数和 runtime.GOMAXPROCS 也没有直接关联。在这个情况下，虽然 runtime.GOMAXPROCS 设为了 2 ，但是最后照样用了 1000 多个线程。但是 strace -f ./par 直接运行，此时跟踪线程数，最多就只有几十个。看来和 less 也有关系。

在 golang 的邮件列表里提问了解到，goroutine 在遇到阻塞性的系统调用，比如 Read ，或者 cgo 调用，会启用一个线程来处理这些调用。想想也和结果对应上了。因为使用了 less ，在显示完一屏幕，并且管道缓冲也被填满后，fmt.Printf 底层对应的 Write 系统调用全部被阻塞。而由于每一个系统调用都需要一个线程来处理，于是就有了 1000 多个线程。由此看来，goroutine 也并不是之前想象中的那么神奇。同时邮件列表里也提到，对于 net 包，还是使用了异步 io 系统调用，因此在网络应用中并不会由于网络 io 速度慢造成阻塞而产生大量线程。看了 net 包的源代码下的 netfd（net/fd*.go） ，确实如此。

go 语言要避免大量线程产生的切换开销，用类似 coroutine 的方式，还是得结合异步 io 。但是目前只在网络 io 上实现了这点。对于其他的 io，比如文件系统，仍然会由于阻塞而产生线程。如果应用中需要使用文件 io，就得使用生产者消费者模式来减少线程数量，或者可以考虑利用 netfd 的代码来实现一个其他类型 io 的异步包装（当然功能上会有一些限制）。