我们都知道, 多线程程序并不是线程开越多性能就越好, 影响线程数规模一个主要的因素是 上下文切换时间, 即当某个并发线程承载的某些内容必须保存其状态以切换到其他线程时所发生的切换过程。如果我们有太多的并发进程，上下文切换可能花费所有的CPU时间，并且无法完成任何实际工作。在操作系统级别使用线程代价可能会非常高昂，操作系统线程必须保存寄存器值，查找表和内存映射等内容，才能在操作成功后切换回当前线程。 然后它必须为传入线程加载相同的信息。在golang中的上下文切换代价相对小得多，在golang调度程序下，运行时可以更具选择性地进行持久检索，例如如何持久化以及何时发生持久化。我们来看看操作系统线程和goroutines之间上下文切换的相对性能。

首先，我们将利用Linux内置的基准测试套件来测量在同一内核的两个线程之间发送消息需要多长时间：

 taskset -c 0 perf bench sched pipe -T  

这会输出:

 # Running 'sched/pipe' benchmark:
# Executed 1000000 pipe operations between two threads

     Total time: 4.793 [sec]

       4.793426 usecs/op
         208619 ops/sec  

这个基准测量实际上是衡量在一个线程上发送和接收消息所需的时间，所以我们将把结果分成两部分。 每个上下文切换2.396微秒。 这看起来不算太坏，但让我们先别急着下判断，再来比较下goroutine之间的上下文切换。

我们将使用Go构建一个类似的基准测试。下面的代码涉及到一些尚未讨论过的东西，所以如果有什么困惑的话，只需根据注释关注结果即可。 以下示例将创建两个goroutine并在它们之间发送消息：

 package main

import (
    "sync"
    "testing"
)

/**
1. 这里会被阻塞，直到接受到数据。我们不希望设置和启动goroutine影响上下文切换的度量。
2. 在这里向接收者发送数据。struct{}{}是空结构体且不占用内存；这样我们就可以做到只测量发送信息 所需要的时间。
3. 在这里，我们接收传递过来的数据，但不做任何事。
4. 开始启动计时器。
5. 在这里我们通知发送和接收的goroutine启动。
 */func BenchmarkContextSwitch(b *testing.B) {
    var wg sync.WaitGroup
    begin := make(chan struct{})
    c := make(chan struct{})
    var token struct{}
    sender := func() {
        defer wg.Done()
        <-begin //1
        for i := 0; i < b.N; i++ {
            c <- token //2
        }
    }
    receiver := func() {
        defer wg.Done()
        <-begin
        for i := 0; i < b.N; i++ {
            <-c //3
        }
    }
    wg.Add(2)
    go sender()
    go receiver()
    b.StartTimer() //4
    close(begin) //5
    wg.Wait()
}  

我们运行该基准测试，指定只使用一个CPU，以便与之前的Linux基准测试相比较，我们来看看结果：

 go test -bench=. -cpu=1 benchmark_context_switch_test.go  

测试结果:

 goos: linux
goarch: amd64
BenchmarkContextSwitch   6601460               180.9 ns/op
PASS
ok      command-line-arguments  1.381s  

每个上下文切换0.180us, 只有线程上下文的1/13,哇塞,这太惊艳了! 很难说有多少goroutines会导致过多的上下文切换，但我们可以很自然地说上限可能不会成为使用goroutines的障碍。