Most computer programs are executed in the same order in which they are written. The first line executes, then the next, and so on. With synchronous programming, when a program encounters an operation that cannot be completed immediately, it will block until the operation completes. For example, establishing a TCP connection requires an exchange with a peer over the network, which can take a sizeable amount of time. During this time, the thread is blocked.
With asynchronous programming, operations that cannot complete immediately are suspended to the background. The thread is not blocked, and can continue running other things. Once the operation completes, the task is unsuspended and continues processing from where it left off. Our example from before only has one task, so nothing happens while it is suspended, but asynchronous programs typically have many such tasks.
Although asynchronous programming can result in faster applications, it often results in much more complicated programs. The programmer is required to track all the state necessary to resume work once the asynchronous operation completes. Historically, this is a tedious and error-prone task.
With asynchronous programming, operations that cannot complete immediately are suspended to the background，不能继续的任务，要被扔到后台。
The thread is not blocked, and can continue running other things，底层线程不因此而阻塞，继续运行其它任务。
Once the operation completes, the task is unsuspended and continues processing from where it left off，当被异步的操作完成后，被终止的任务恢复执行。
Rayon 默认只使用与 CPU 数量相同的线程来执行任务，执行效率反而比 Tokio 略好，Tokio 因为启动了大量的线程，导致我的电脑已无法正常响应键鼠了。
Object
区间
总耗时
平均
Go
676 s ~ 814 s
814 s
81.4 ms
Tokio
0.6 s ~ 564 s
564 s
56.4 ms
Rayon
0.00420079 s ~ 503 s
507 s
50 ms
由于例子的特殊性，在总的执行时间上，Go 没有任何优势可言，因为 Go 和 Rust 的定位不同，性能也有差距，所以比较总耗时并没有意义。我们这里主要观察每个任务的耗时区间。
这里有意思的是 Go 的所有任务耗时趋向于“平均”，而 Rust 的两个框架是在每个线程上串行执行任务，任务耗时如同信号图标📶，由低到高渐进式增长。
所以，如果计算任务之间没有依赖，更看重总的响应时间的话，使用与 CPU 核数相当的线程池进行并行计算能得到最佳效果；如果任务是并发的，更加注重单个任务的响应时间，类似于 Go 的并发模型可能是更好的选择。本文所举的示例，每个任务的计算量相当，并不能体现 Go 的这一优势，不过可以想象一下：并发途中，一个计算量很小的任务加入队列，上述两种任务处理方式会给出不同的结果。
Go 是为并发而生的语言，所以你会发现，在编写 Go 代码的时候，你根本不用去考虑并发任务是计算型还是 I/O 型的，在其并发模型下所有的任务都会尽可能得到及时的处理；而对于缺乏完善调度运行时的线程池来说，其注意事项就很多了，你要小心翼翼，不能在异步任务中写太多计算的代码。对此，甚至有博主指出：在进入.await之前，最好不要超过10 ~ 100 微秒。
道理不难理解，以 Tokio 为例，虽然可以运行 CPU 密集型任务，但是官方很明确的说你要新开实例去运行，不要饿死 I/O 任务，显然这是因为运行时缺乏调度能力的折中方案。CPU 密集型任务属于会阻塞 executor 线程的任务，容易霸占 CPU 而饿坏或者饿死其它任务，此时只能靠手动 yield 来让出 CPU，给其它任务以运行的机会；而网络 I/O 之所以适合，完全是因为有非阻塞特性和 Reactor 的存在，每个 I/O 读写点都是一次 yield 的机会！
Linux 内核也有原生的异步 I/O 支持，并冠以AIO之名，但限制很多，如只支持O_DIRECT访问、只支持特定设备、性能表现不佳等等，社区满意度极低，饱受诟病，我甚至找不到异步网络 I/O 的例子，因此可以说，当前 Linux 只支持有限的文件异步 I/O，不支持网络异步 I/O（至少没有应用场景）。
要知道，在异步 I/O 的概念出现之前，还有一种中间形态——IO 多路复用。
直到现在，IO 多路复用依然是 Linux 平台高并发网络的主流解决方案，以epoll为支点的事件循环结构铸就了当今互联网绝大多数网络程序的 Reactor模型。
I/O 多路复用
我们可以用非阻塞+单线程或多线程的网络模型来处理大量网络连接，但是由于需要浪费 CPU 来试探缓冲区是否就绪，所以效率难免会大打折扣。
// Wrapper around the accept system call that marks the returned file // descriptor as nonblocking and close-on-exec. funcaccept(s int) (int, syscall.Sockaddr, string, error) { ns, sa, err := Accept4Func(s, syscall.SOCK_NONBLOCK|syscall.SOCK_CLOEXEC) if err != nil { return-1, sa, "accept4", err } return ns, sa, "", nil }
// netpollready is called by the platform-specific netpoll function. // It declares that the fd associated with pd is ready for I/O. // The toRun argument is used to build a list of goroutines to return // from netpoll. The mode argument is 'r', 'w', or 'r'+'w' to indicate // whether the fd is ready for reading or writing or both. // // This may run while the world is stopped, so write barriers are not allowed. // //go:nowritebarrier funcnetpollready(toRun *gList, pd *pollDesc, mode int32) { var rg, wg *g if mode == 'r' || mode == 'r'+'w' { // 获取等待读操作的 g rg = netpollunblock(pd, 'r', true) } if mode == 'w' || mode == 'r'+'w' { // 获取等待写操作的 g wg = netpollunblock(pd, 'w', true) } if rg != nil { // 将等待读操作的 g 插入链表 toRun.push(rg) } if wg != nil { // 将等待写操作的 g 插入链表 toRun.push(wg) } }
type pollDesc struct { ... // rg, wg are accessed atomically and hold g pointers. // (Using atomic.Uintptr here is similar to using guintptr elsewhere.) rg atomic.Uintptr // pdReady, pdWait, G waiting for read or nil wg atomic.Uintptr // pdReady, pdWait, G waiting for write or nil ... }
rg 和 wg 都是原子类型，里面可能存放的内容为：pdReady, pdWait, G waiting for read or nil，G 就是 goroutine 的地址，我们继续沿着调用向下看：
for { old := gpp.Load() if old == pdReady { returnnil } if old == 0 && !ioready { // Only set pdReady for ioready. runtime_pollWait // will check for timeout/cancel before waiting. returnnil } varnewuintptr if ioready { new = pdReady } // 将 gpp 设置为 pdReady if gpp.CompareAndSwap(old, new) { if old == pdWait { // 如果设置为0，则 (*g)(unsafe.Pointer(old)) 为 nil old = 0 } // 将 old 的值转换为 *g 返回，old 通常就是发生等待的 goroutine 地址 return (*g)(unsafe.Pointer(old)) } } }
拿到 *g 之后，就可以插入toRun链表了：
runtime/proc.go
1 2 3 4 5 6 7 8 9 10 11
// A gList is a list of Gs linked through g.schedlink. A G can only be // on one gQueue or gList at a time. type gList struct { head guintptr }
// push adds gp to the head of l. func(l *gList) push(gp *g) { gp.schedlink = l.head l.head.set(gp) }
// The main goroutine. funcmain() { ... if GOARCH != "wasm" { // no threads on wasm yet, so no sysmon systemstack(func() { newm(sysmon, nil, -1) }) } ... }
// Always runs without a P, so write barriers are not allowed. // //go:nowritebarrierrec funcsysmon() { ... for { ... // poll network if not polled for more than 10ms lastpoll := int64(atomic.Load64(&sched.lastpoll)) if netpollinited() && lastpoll != 0 && lastpoll+10*1000*1000 < now { atomic.Cas64(&sched.lastpoll, uint64(lastpoll), uint64(now)) list := netpoll(0) // non-blocking - returns list of goroutines if !list.empty() { // Need to decrement number of idle locked M's // (pretending that one more is running) before injectglist. // Otherwise it can lead to the following situation: // injectglist grabs all P's but before it starts M's to run the P's, // another M returns from syscall, finishes running its G, // observes that there is no work to do and no other running M's // and reports deadlock. incidlelocked(-1) injectglist(&list) incidlelocked(1) } } ... } }
// returns true if IO is ready, or false if timedout or closed // waitio - wait only for completed IO, ignore errors // Concurrent calls to netpollblock in the same mode are forbidden, as pollDesc // can hold only a single waiting goroutine for each mode. funcnetpollblock(pd *pollDesc, mode int32, waitio bool)bool { gpp := &pd.rg if mode == 'w' { gpp = &pd.wg }
// set the gpp semaphore to pdWait for { // Consume notification if already ready. if gpp.CompareAndSwap(pdReady, 0) { returntrue } if gpp.CompareAndSwap(0, pdWait) { break }
// Double check that this isn't corrupt; otherwise we'd loop // forever. if v := gpp.Load(); v != pdReady && v != 0 { throw("runtime: double wait") } }
// need to recheck error states after setting gpp to pdWait // this is necessary because runtime_pollUnblock/runtime_pollSetDeadline/deadlineimpl // do the opposite: store to closing/rd/wd, publishInfo, load of rg/wg if waitio || netpollcheckerr(pd, mode) == pollNoError { // 开启 park 流程，休眠当前 goroutine gopark(netpollblockcommit, unsafe.Pointer(gpp), waitReasonIOWait, traceEvGoBlockNet, 5) } // be careful to not lose concurrent pdReady notification old := gpp.Swap(0) if old > pdWait { throw("runtime: corrupted polldesc") } return old == pdReady }
netpollblock会将pollDesc中的 rg 或 wg 设置为pdWait，然后调用gopark将当前 goroutine 休眠，进入schedule流程挑选新的 goroutine 来运行。
// Puts the current goroutine into a waiting state and calls unlockf on the // system stack. // // If unlockf returns false, the goroutine is resumed. // // unlockf must not access this G's stack, as it may be moved between // the call to gopark and the call to unlockf. // // Note that because unlockf is called after putting the G into a waiting // state, the G may have already been readied by the time unlockf is called // unless there is external synchronization preventing the G from being // readied. If unlockf returns false, it must guarantee that the G cannot be // externally readied. // // Reason explains why the goroutine has been parked. It is displayed in stack // traces and heap dumps. Reasons should be unique and descriptive. Do not // re-use reasons, add new ones. funcgopark(unlockf func(*g, unsafe.Pointer)bool, lock unsafe.Pointer, reason waitReason, traceEv byte, traceskip int) { if reason != waitReasonSleep { checkTimeouts() // timeouts may expire while two goroutines keep the scheduler busy } mp := acquirem() gp := mp.curg status := readgstatus(gp) if status != _Grunning && status != _Gscanrunning { throw("gopark: bad g status") } // 此时 lock 是 gpp(pollDesc 中的 rg) mp.waitlock = lock // 此时 unlockf 是 netpollblockcommit mp.waitunlockf = unlockf gp.waitreason = reason mp.waittraceev = traceEv mp.waittraceskip = traceskip releasem(mp) // can't do anything that might move the G between Ms here. mcall(park_m) }
// func mcall(fn func(*g)) // Switch to m->g0's stack, call fn(g). // Fn must never return. It should gogo(&g->sched) // to keep running g. TEXT runtime·mcall<ABIInternal>(SB), NOSPLIT, $0-8 MOVQ AX, DX // DX = fn
// save state in g->sched // 下面这 5 行指令是保存当前 goroutine 的状态到 g->sched MOVQ 0(SP), BX // caller's PC MOVQ BX, (g_sched+gobuf_pc)(R14) LEAQ fn+0(FP), BX // caller's SP MOVQ BX, (g_sched+gobuf_sp)(R14) MOVQ BP, (g_sched+gobuf_bp)(R14)
// switch to m->g0 & its stack, call fn // 准备切换到 g0 及其堆栈 MOVQ g_m(R14), BX // 通过 R14 拿到当前的 m MOVQ m_g0(BX), SI // SI = g.m.g0 通过 m 拿到 m 的 g0 CMPQ SI, R14 // if g == m->g0 call badmcall JNE goodm JMP runtime·badmcall(SB) goodm: MOVQ R14, AX // AX (and arg 0) = g 把当前 goroutine 地址放入 AX MOVQ SI, R14 // g = g.m.g0 SI 是 g.m.g0，这一句将 goroutine 切换到 g0 get_tls(CX) // Set G in TLS MOVQ R14, g(CX) // 设置 g0 到线程本地存储 MOVQ (g_sched+gobuf_sp)(R14), SP // sp = g0.sched.sp 切换到 g0 堆栈 PUSHQ AX // open up space for fn's arg spill slot MOVQ 0(DX), R12 CALL R12 // fn(g) POPQ AX JMP runtime·badmcall2(SB) RET
根据Go internal ABI specification的描述，amd64平台下整型参数传递依次使用如下寄存器：
不知道你有没有好奇，挂起的明明是当前的 goroutine，为什么函数的名字是park_m呢？这里的m显然就是 GMP 中的线程 M 啊，我是这样理解的：M 就像是一列高速运行的汽车，乘客是goroutine，当某个乘客因某些原因不能继续乘坐时，M 需要停下来让乘客下车，然后再开动去寻找下一位乘客，所以这个挂起 goroutine 的过程就像是 M 停泊了一样。
但为了叙述方便，我还是称 goroutine 停泊好了，毕竟比喻并不十分恰当，从指令角度看 M 可是一路狂奔从未停过，只是从代码所有权角度来看， M 确实是换了一位乘客。
runtime/netpoll.go
1 2 3 4 5 6 7 8 9 10
funcnetpollblockcommit(gp *g, gpp unsafe.Pointer)bool { r := atomic.Casuintptr((*uintptr)(gpp), pdWait, uintptr(unsafe.Pointer(gp))) if r { // Bump the count of goroutines waiting for the poller. // The scheduler uses this to decide whether to block // waiting for the poller if there is nothing else to do. atomic.Xadd(&netpollWaiters, 1) } return r }
反观文件 I/O 则不然，文件 I/O 没有异步和非阻塞特性（不考虑臭名昭著的AIO），当 M 因为系统调用陷入内核时，如果要读取的内容不在页高速缓存中，就会触发缺页处理，内核需要向磁盘发出 I/O 请求，因为这个过程不是异步的，内核会将 M 剥离，调度其它线程来运行。可想而知，此时此刻 go runtime 只能新建 M 来匹配 P，新建的 M 需要加入内核运行队列，等待内核调度，经过这样一番折腾，吞吐自然就下来了。
更可怕的是如果有大量 I/O 请求，势必会让更多的 M 陷入内核无法自拔，go runtime 除了创建更多的 M 之外别无良策，在这种情况下仍不断地创建 M 无异于扬汤止沸，如果 M 的数量超过 1 万，程序就 panic 了。
使用 DNS 作为服务发现机制有个潜在的复杂性，即传播需要一定的时间，因此，在一个正在终止的后端服务真正停止接受连接之前，我们需要为 gRPC 客户端留有更新主机列表的余地。因为有一个 TLL 时间与 DNS 记录相关联，也就是说 Envoy 会在这段时间内缓存主机列表，所以使用 DNS 时，优雅关闭流程需要一点技巧
下图展示了一个基本流程，它以一个失败的请求结束：
Figure 4: Terminating host makes request fail due to DNS caching
在这个场景中，因为服务端 pod 不再可用，但 Envoy 缓存依然持有其 IP，所以第二次客户端请求以失败告终。
要解决这个问题，我们有必要看一下 Kubernetes 是如何销毁 pod 的，这篇文章对此有详细的论述。它包含两个同时进行的步骤：在 Kubernetes service endpoints 中移除 pod（在我们的案例中，同时也会移除 DNS 记录列表中该 pod 的 IP） 和 向容器发送 TERM 信号，启动优雅关闭。
有鉴于此，我们使用 Kubernetes 的 pre-stop 钩子来阻止 TERM 信号的立即发送：
Figure 5: preStop hook
配置好 preStop 钩子之后，我们的流程就变成下面这样：
Figure 6: successful server pod shutdown flow
通过这种解决方式，我们为 Envoy 的 DNS 缓存留出足够的时间，使其过期并且重新刷新，从而剔除已经死亡的 pod IP。
未来改进
尽管 Envoy 为我们带来了性能提升和整体的简洁，但是基于 DNS 的服务发现依旧不是很理想。因为它是基于轮询的，在 TTL 过期之后，由客户端负责刷新主机池，所以不够健壮。
/* * context_switch - switch to the new MM and the new thread's register state. */ static __always_inline struct rq * context_switch(struct rq *rq, struct task_struct *prev, struct task_struct *next, struct rq_flags *rf) { prepare_task_switch(rq, prev, next); arch_start_context_switch(prev);
if (!next->mm) { // to kernel enter_lazy_tlb(prev->active_mm, next);
next->active_mm = prev->active_mm; if (prev->mm) // from user mmgrab(prev->active_mm); else prev->active_mm = NULL; } else { // to user membarrier_switch_mm(rq, prev->active_mm, next->mm); switch_mm_irqs_off(prev->active_mm, next->mm, next);
if (!prev->mm) { // from kernel /* will mmdrop() in finish_task_switch(). */ rq->prev_mm = prev->active_mm; prev->active_mm = NULL; } }
/* * %rdi: prev task * %rsi: next task */ .pushsection .text, "ax" SYM_FUNC_START(__switch_to_asm) /* * Save callee-saved registers * This must match the order in inactive_task_frame */ pushq %rbp pushq %rbx pushq %r12 pushq %r13 pushq %r14 pushq %r15
#ifdef CONFIG_RETPOLINE /* * When switching from a shallower to a deeper call stack * the RSB may either underflow or use entries populated * with userspace addresses. On CPUs where those concerns * exist, overwrite the RSB with entries which capture * speculative execution to prevent attack. */ FILL_RETURN_BUFFER %r12, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW #endif
#define switch_to(prev, next, last) \ do { \ ((last) = __switch_to_asm((prev), (next))); \ } while (0)
栈帧一层层解开，会返回到 context_switch 函数调用，继而回到schedule()。可见，任何一个进入内核态调用schedule()执行任务切换的进程，最终都会等到schedule()调用的返回。我们稍后会讲到 Go 运行时的协程调度，其schedule函数是不会返回的，所以它看起来并不像一个函数，这是区别于操作系统调度函数一个重要的点。
/* The userland implementation is: int clone (int (*fn)(void *arg), void *child_stack, int flags, void *arg), the kernel entry is: int clone (long flags, void *child_stack). The parameters are passed in register and on the stack from userland: rdi: fn rsi: child_stack rdx: flags rcx: arg r8d: TID field in parent r9d: thread pointer %esp+8: TID field in child The kernel expects: rax: system call number rdi: flags rsi: child_stack rdx: TID field in parent r10: TID field in child r8: thread pointer */
.text ENTRY (__clone) /* Sanity check arguments. */ movq $-EINVAL,%rax testq %rdi,%rdi /* no NULL function pointers */ jz SYSCALL_ERROR_LABEL testq %rsi,%rsi /* no NULL stack pointers */ jz SYSCALL_ERROR_LABEL
/* Insert the argument onto the new stack. */ subq $16,%rsi movq %rcx,8(%rsi)
/* Save the function pointer. It will be popped off in the child in the ebx frobbing below. 这里把线程要运行的函数fn压入新建线程的用户态堆栈中*/ movq %rdi,0(%rsi)
/* Do the system call. */ movq %rdx, %rdi movq %r8, %rdx movq %r9, %r8 mov 8(%rsp), %R10_LP movl $SYS_ify(clone),%eax
/* End FDE now, because in the child the unwind info will be wrong. */ cfi_endproc; syscall
L(thread_start): cfi_startproc; /* Clearing frame pointer is insufficient, use CFI. */ cfi_undefined (rip); /* Clear the frame pointer. The ABI suggests this be done, to mark the outermost frame obviously. */ xorl %ebp, %ebp
/* Set up arguments for the function call. */ popq %rax /* Function to call. 弹出函数地址 */ popq %rdi /* Argument. */ call *%rax /* 开始调用执行 */ /* Call exit with return value from function call. */ movq %rax, %rdi movl $SYS_ify(exit), %eax syscall cfi_endproc;
对高并发的执着追求，诞生了编程语言世界里五花八门的协程，或者说用户态线程，概念并不重要，重要的是，它们只能在用户态做文章。像Python、Java、C++、Go、Rust 等语言都提供了基于协程的并发模型，这里面由于 Go 是相对比较新生的语言，没有任何历史包袱，从而提供了完美的用户态线程，且将此并发模型内置于语言自身。这样做的好处是，开发并发程序变得异常简单，一个简简单单的go关键字就可以创建一个独立的任务，即一个独立的执行流，如果换做其它语言，想要创建一个独立的执行流只有线程或者进程这种由操作系统提供的原生方式（当然，很多语言也有对应的协程库，因本人未做过详细研究，故只考虑原生的并发模型）；然而，为了并发体系的自洽，Go 为其用户屏蔽了操作系统提供的线程模型，虽然用起来简单了，但理解上却多了些许障碍。
不知道你是否被上面的用户线程、内核线程、映射等概念搅的一头雾水呢？按照其语义，用户线程和内核线程就像是对立的两方，会有某个东西将它们联系起来构成“映射”，或许是内核，又或许是C库，但书中没讲，我能够理解《操作系统概念》是讲操作系统的设计与实现原理，会兼顾大部分操作系统，讲解的也是较为抽象的部分，不过现代绝大部分人只接触过Linux，而Linux内核提供的并发模型就只有一对一这一种，所里书里的内容如今看上去多少有些不合时宜。在 Linux 内核当中甚至并不区分进程和线程，它们统一都由task_struct这一种数据结构表示，并且基于其进行调度，也就是说，在内核看来每个task_struct只有一个执行流，至于在用户态这个大的执行流干些什么，内核并不关心。
要正确理解书中所表达的意图，就需要先把概念捋清楚，我以 Linux 为例来进行说明。
首先，需要把这里的内核线程拿掉，换成操作系统线程，即 Linux 内核提供的线程。我之所以不用内核线程是因为内核线程这个概念在 Linux 中也有对应的存在（参见《深入linux内核架构》2.4.2 内核线程），内核线程是一种只运行在内核地址空间的线程。所有的内核线程共享内核地址空间（对于 32 位系统来说，就是 3-4GB 的虚拟地址空间），所以也共享同一份内核页表，并且没有用户地址空间，这也是为什么叫内核线程，而不叫内核进程的原因。
或许，我们可以换个角度，抛开这些定义，站在 CPU 的角度去理解问题。所谓线程就是内核维护的一个数据结构，内核依靠这个结构来控制 CPU 上运行的代码，指令无论在用户态还是内核态，都是这个线程，所有的资源消耗都计入此线程，即便是与此线程无关的中断所消耗的资源也被记在该线程名下。协程就是用户空间代码维护的一个数据结构，用户空间代码可以通过控制 ip、sp 等寄存器来控制用户空间执行流的走向，就可以实现在不同的协程间切换，并把执行流的状态记录在对应的数据结构上，重要的是协程代码本身就属于操作系统用户态执行流中的指令。
仍然以前面展示进程切换时的图作为基础，为了配合 Go 的实际情况，将图中的进程换成线程来讲。现在想象一下，线程 A、B、C 是 go 程序底层的操作系统线程（GMP中的M），g1、g2、g3 为 go 程序在用户空间实现的协程，或者说叫 goroutine。值得注意的是，内核并不知道 goroutine 的存在，它仍然按照自己一贯的行为方式对 A、B、C 三个线程进行调度。
当A线程的时间片用完，或者发出阻塞的系统调用时，就会被内核调度出 CPU，继而把 C 线程调度到 CPU 上来执行。图中显示 A线程被换下 CPU0 的时候，B 线程仍然在 CPU1 上，这意味着其余的 goroutine 依然会得到执行的机会。再看被调度到 CPU0 上的 C 线程，它也是 go 程序底层的线程，这意味着在一个拥有双核的机器上，goroutine 总是有机会运行的，即便有些 goroutine 因为系统调用等某些原因导致其所在的操作系统线程被换下。go 总会保证有两个“活的”的线程一直待在 CPU 上轮番寻找 goroutine 来执行，除非操作系统内核看不下去，换其它的程序线程来执行，但 go 总会保证有两个准备好的线程可以随时被内核调度。
再来切一下近景，把 B 线程放大。在内核看来，黄色部分只代表 B 线程的用户态执行流，但就在这个黄色用户态执行流的内部正在轮番上演形形色色的任务，g1、g2、g3 三个 goroutine 正轮流在CPU上执行，绿色执行流代表 go 的 runtime，正是 runtime 居中调度，指挥得当，才让以 goroutine 为单位的任务都获得执行的机会。内核对这些一无所知，CPU也只会觉得奇怪：这个线程的用户态代码怎么老是频繁的切换堆栈？（见《溯源 goroutine 堆栈》 中对 go 协程堆栈的描述)
这种并发模型的优势显而易见，让我们来直观地感受一下。操作系统线程每次上下文切换需要大约 1000ns 的时间，而硬件有望在每纳秒的时间里执行 12 条指令，也就是说，当任务必须等待时，操作系统就会花费 12k 条指令去做线程切换，却不能将这些指令用在有意义的业务上。而 go 在用户态进行协程切换，极大地缓和了这种浪费，go 进行一次协程切换大概需要 200ns 或者 2.4k 条指令。简言之，go 用尽可能少的 os 级的线程调度来做更多的事情，方式就是在用户空间调度，这是语言级别的一种能力，可不严谨的说，go 的调度比 os 级调度便宜 5 倍，甚至更多！
PT_REGS_SP(regs) = (unsignedlong) frame; PT_REGS_DI(regs) = sig; /* In case the signal handler was declared without prototypes */ PT_REGS_AX(regs) = 0; /* * This also works for non SA_SIGINFO handlers because they expect the * next argument after the signal number on the stack. */ PT_REGS_SI(regs) = (unsignedlong) &frame->info; PT_REGS_DX(regs) = (unsignedlong) &frame->uc; PT_REGS_IP(regs) = (unsignedlong) ksig->ka.sa.sa_handler;
除了设置堆栈、程序计数器之外也设置了 rdi、rsi、rds 这几个寄存器，这是 x86_64 架构下 C 语言的函数调惯例，三个寄存器分别用于存放函数调用时前三个参数。记住这一点，后面介绍 Go 时会用到。
// Called using C ABI. TEXT runtime·sigtramp(SB),NOSPLIT,$0 // Transition from C ABI to Go ABI. PUSH_REGS_HOST_TO_ABI0()
// Call into the Go signal handler NOP SP // disable vet stack checking ADJSP $24 MOVQ DI, 0(SP) // sig MOVQ SI, 8(SP) // info MOVQ DX, 16(SP) // ctx CALL ·sigtrampgo(SB) ADJSP $-24
POP_REGS_HOST_TO_ABI0() RET
sigtramp实际上是真正的信号处理函数，进程从内核态收到信号回到用户态调用的处理函数就是它，注释中表明这个函数以 C 语言的调用惯例被调用，Go 在这里通过PUSH_REGS_HOST_TO_ABI0保存 go 自己调用惯例用的寄存器后，转换成自己的调用规范，等函数调用完毕之后，再通过POP_REGS_HOST_TO_ABI0恢复这些寄存器的值。
还记得上一节介绍 5.10版本的内核修改用户态寄存器时设置的 rdi、rsi、rdx 的值吗？这三个寄存器的值就是内核模仿调用sigtramp时传入的参数，现在 go 需要以自己的调用规约将其放置到堆栈上，来表示 sig、info、ctx 这三个参数（go1.17 改变了调用规约，已经由堆栈传递参数改为寄存器传递了，不知道为何此处仍然使用堆栈传递，我此处引用的代码是版本 1.18.1）。
// doSigPreempt handles a preemption signal on gp. funcdoSigPreempt(gp *g, ctxt *sigctxt) { // Check if this G wants to be preempted and is safe to // preempt. if wantAsyncPreempt(gp) { if ok, newpc := isAsyncSafePoint(gp, ctxt.sigpc(), ctxt.sigsp(), ctxt.siglr()); ok { // Adjust the PC and inject a call to asyncPreempt. ctxt.pushCall(abi.FuncPCABI0(asyncPreempt), newpc) } }
// Acknowledge the preemption. atomic.Xadd(&gp.m.preemptGen, 1) atomic.Store(&gp.m.signalPending, 0)
信号处理程序一旦被执行，舞台就交到了 go runtime 手里，ctxt的类型为*sigctxt，指向的是用户态堆栈中存放内核态堆栈内容的地址。然后信号处理程序通过isAsyncSafePoint来判断抢占位置是否安全，并返回安全的抢占地址。如果确认抢占没有问题，接着会调用pushCall方法来修改ctxt中的用户态硬件上下文，用于稍后再一次从内核态返回用户态时模拟出一个用户态程序调用asyncPreempt的假象：
1 2 3 4 5 6 7 8
func(c *sigctxt) pushCall(targetPC, resumePC uintptr) { // Make it look like we called target at resumePC. sp := uintptr(c.rsp()) sp -= goarch.PtrSize *(*uintptr)(unsafe.Pointer(sp)) = resumePC c.set_rsp(uint64(sp)) c.set_rip(uint64(targetPC)) }
TEXT ·asyncPreempt(SB),NOSPLIT|NOFRAME,$0-0 PUSHQ BP MOVQ SP, BP // Save flags before clobbering them PUSHFQ // obj doesn't understand ADD/SUB on SP, but does understand ADJSP ADJSP $368 // But vet doesn't know ADJSP, so suppress vet stack checking NOP SP MOVQ AX, 0(SP) ...... MOVUPS X15, 352(SP) CALL ·asyncPreempt2(SB) MOVUPS 352(SP), X15 MOVUPS 336(SP), X14 ...... ADJSP $-368 POPFQ POPQ BP RET
// func mcall(fn func(*g)) // Switch to m->g0's stack, call fn(g). // Fn must never return. It should gogo(&g->sched) // to keep running g. TEXT runtime·mcall<ABIInternal>(SB), NOSPLIT, $0-8 MOVQ AX, DX // DX = fn
// save state in g->sched MOVQ 0(SP), BX // caller's PC MOVQ BX, (g_sched+gobuf_pc)(R14) LEAQ fn+0(FP), BX // caller's SP MOVQ BX, (g_sched+gobuf_sp)(R14) MOVQ BP, (g_sched+gobuf_bp)(R14)
// switch to m->g0 & its stack, call fn MOVQ g_m(R14), BX MOVQ m_g0(BX), SI // SI = g.m.g0 CMPQ SI, R14 // if g == m->g0 call badmcall JNE goodm JMP runtime·badmcall(SB) goodm: MOVQ R14, AX // AX (and arg 0) = g MOVQ SI, R14 // g = g.m.g0 get_tls(CX) // Set G in TLS MOVQ R14, g(CX) MOVQ (g_sched+gobuf_sp)(R14), SP // sp = g0.sched.sp PUSHQ AX // open up space for fn's arg spill slot MOVQ 0(DX), R12 CALL R12 // fn(g) POPQ AX JMP runtime·badmcall2(SB) RET
这两句是保存程序计数器的值到g->sched:
1 2
MOVQ 0(SP), BX // caller's PC MOVQ BX, (g_sched+gobuf_pc)(R14)
由此观之，asyncPreempt更像是 Linux 内核中的schedule()：调度发生在函数执行过程中，而函数执行完毕要等到下一次被调度的时候才会发生。 而 go 借助信号机制所实现的抢占，无非就是依靠信号处理程序这一次控制权埋点，以便在执行流最终从内核态返回时执行asyncPreempt代码，从而再一次收获 CPU 的控制权。
是时候再从指令的视角在宏观上来理解 go 的信号抢占流程了：
图 8-1 显示了通过异步抢占执行流从 g1 切换到 g2 的过程：
g1被时钟中断，从内核返回时发现有抢占信号。
执行流从内核态返回到用户态，执行信号处理程序（第一个绿色的 go runtime 执行流）。
信号处理程序执行完毕返回内核，内核做一些恢复后，再次返回到用户态。
从内核态返回后的执行流被 go runtime 窃取，转而执行调度（第二个绿色的 go runtime 执行流）。
g2 被选择，换上 CPU 执行。
9
文章写到这里，基本上把我想讲的已经讲完了，也算基本上完成了自己“观其大略，本其脉络”的目标，我曾在《从CPU的视角说起》 一文中说道：我目前所寻求的信息，意在建立计算机系统的世界观与 Go 语言的世界观，是在陷入具体细节之前为自己提供一个大致的轮廓，让自己对计算机运行的脉络有一个关键性的认识。 即便如此，里面也不可避免的出现很多具体而微的内容。我略过了很多环节，并不是因为它们不重要，是因为它们是细节，是更丰富的东西，也是我尚未探索的东西。
我们在上一篇讨论了进线程的堆栈，现在继续探索 go 中的协程栈。如果吊一下书袋的话，口称 go 协程是不严谨的，go 的协程不同于其他语言的协程，go 的协程是一种有栈协程，每一个协程都有自己的协程堆栈，因此 go 官网发明了一个新词 goroutine，以区别于普通的 coroutine。我们接下来就聊聊 goroutine 的堆栈。在此之前，先来回顾一下上一篇中对进线程堆栈位置的总结。
go 重写了运行时，如果不使用 cgo 的话，编译完成的 go 程序是静态链接的，不依赖任何C库，这使它拥有不错的可移植性，在较新内核上编译好的程序，拉到旧版本内核的操作系统上依然能够运行。在这一点上，rust 并没有多少优势，反而新生语言 hare 表现足够强劲。
不依赖 C 库，意味着 go 对 heap 的管理有自己的方式。 那么， go 管理的 heap 是否与之前内存空间布局图中的 heap 位置相同就要打一个大大的问号了。要搞清楚这个问题，我们需要到 runtime 的源码中一探究竟，且要挖到 go 与内核的接口处，找出其申请内存的方式方可。
本文并不打算分析 go 的内存分配器，也不打算介绍堆栈的分配算法，仅仅为了解决 goroutine 堆栈在虚拟地址空间中位置的疑惑。想了解内存管理和堆栈分配算法的读者可以参考详解Go中内存分配源码实现与一文教你搞懂 Go 中栈操作。
先从普通 goroutine 的创建开始吧！
在 go 中，每通过go func(){}的方式开启一个 goroutine 时，编译器都会将其转换成对 runtime.newproc的调用：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
// Create a new g running fn. // Put it on the queue of g's waiting to run. // The compiler turns a go statement into a call to this. funcnewproc(fn *funcval) { gp := getg() pc := getcallerpc() // 切换到线程堆栈创建 g systemstack(func() { newg := newproc1(fn, gp, pc)
_p_ := getg().m.p.ptr() runqput(_p_, newg, true)
if mainStarted { wakep() } }) }
newproc 仅仅是对 newproc1 的包装，创建新 g 的动作不能在用户堆栈上进行，所以这里切换到底层线程的堆栈来执行。
// Create a new g in state _Grunnable, starting at fn. callerpc is the // address of the go statement that created this. The caller is responsible // for adding the new g to the scheduler. funcnewproc1(fn *funcval, callergp *g, callerpc uintptr) *g { _g_ := getg()
if fn == nil { _g_.m.throwing = -1// do not dump full stacks throw("go of nil func value") } acquirem() // disable preemption because it can be holding p in a local var
_p_ := _g_.m.p.ptr() // 从 P 的空闲链表中获取一个新的 G newg := gfget(_p_) // 获取不到则调用 malg 进行创建 if newg == nil { newg = malg(_StackMin) casgstatus(newg, _Gidle, _Gdead) allgadd(newg) // publishes with a g->status of Gdead so GC scanner doesn't look at uninitialized stack. } ...... }
newproc1 方法很长，里面主要是获取 G ，然后对获取到的 G 做一些初始化的工作。当创建 G 时，会先从缓存的空闲链表中获取，如果没有空闲的 G ，再进行创建。所以，我们这里只看 malg 函数的调用。
// Allocate a new g, with a stack big enough for stacksize bytes. funcmalg(stacksize int32) *g { newg := new(g) if stacksize >= 0 { stacksize = round2(_StackSystem + stacksize) systemstack(func() { newg.stack = stackalloc(uint32(stacksize)) }) newg.stackguard0 = newg.stack.lo + _StackGuard newg.stackguard1 = ^uintptr(0) // Clear the bottom word of the stack. We record g // there on gsignal stack during VDSO on ARM and ARM64. *(*uintptr)(unsafe.Pointer(newg.stack.lo)) = 0 } return newg }
malg 会创建新的 G 并为其设置好堆栈，以及堆栈的边界，以供日后扩容使用。这里重点看 stackalloc 函数，堆栈的内存的分配就是由它来完成的，函数的返回值赋给新 G 的 stack 字段。
G 的 stack 字段是一个 stack 结构体类型，里面标记了堆栈的高地址和低地址：
1 2 3 4 5 6 7
// Stack describes a Go execution stack. // The bounds of the stack are exactly [lo, hi), // with no implicit data structures on either side. type stack struct { lo uintptr hi uintptr }
我们接着看这个 stack 是怎么创建出来的。
stackalloc 的函数比较长，里面涉及到大堆栈和小堆栈的分配逻辑，这里就不贴大段的代码了。这个函数不管是从 cache 还是 pool 中获取内存，最终都会在内存不够时调用 mheap 的allocManual函数去分配新的内存：
// Try to add at least npage pages of memory to the heap, // returning how much the heap grew by and whether it worked. func(h *mheap) grow(npage uintptr) (uintptr, bool) { assertLockHeld(&h.lock) ask := alignUp(npage, pallocChunkPages) * pageSize totalGrowth := uintptr(0) // This may overflow because ask could be very large // and is otherwise unrelated to h.curArena.base. // curArena 无需初始化，但问题是怎么判断 Arena 边界呢 end := h.curArena.base + ask nBase := alignUp(end, physPageSize) if nBase > h.curArena.end || /* overflow */ end < h.curArena.base { // 尝试分配新的 Arena，但有可能跨越 hint 区域，所以全额申请 // Not enough room in the current arena. Allocate more // arena space. This may not be contiguous with the // current arena, so we have to request the full ask. av, asize := h.sysAlloc(ask) // 此时已经将需要的内存 reserve 了 if av == nil { print("runtime: out of memory: cannot allocate ", ask, "-byte block (", memstats.heap_sys, " in use)\n") return0, false }
ifuintptr(av) == h.curArena.end { // 说明是连续的，拓展此 curArena 的边界 // The new space is contiguous with the old // space, so just extend the current space. h.curArena.end = uintptr(av) + asize } else { // 感觉像是这一次不够分配的，但也别浪费，把剩余的内存标记为已使用，加入到一个地方以供分配 // The new space is discontiguous. Track what // remains of the current space and switch to // the new space. This should be rare. if size := h.curArena.end - h.curArena.base; size != 0 { // Transition this space from Reserved to Prepared and mark it // as released since we'll be able to start using it after updating // the page allocator and releasing the lock at any time. sysMap(unsafe.Pointer(h.curArena.base), size, &memstats.heap_sys) // Update stats. atomic.Xadd64(&memstats.heap_released, int64(size)) stats := memstats.heapStats.acquire() atomic.Xaddint64(&stats.releagrowsed, int64(size)) memstats.heapStats.release() // Update the page allocator's structures to make this // space ready for allocation. h.pages.grow(h.curArena.base, size) totalGrowth += size } // Switch to the new space. // 把 curArena 切换到新的地址 h.curArena.base = uintptr(av) h.curArena.end = uintptr(av) + asize }
// Recalculate nBase. // We know this won't overflow, because sysAlloc returned // a valid region starting at h.curArena.base which is at // least ask bytes in size. nBase = alignUp(h.curArena.base+ask, physPageSize) }
// 更新 base // Grow into the current arena. v := h.curArena.base h.curArena.base = nBase
// 把分配的那块内存标记为 Prepared // Transition the space we're going to use from Reserved to Prepared. sysMap(unsafe.Pointer(v), nBase-v, &memstats.heap_sys)
// ...... 省略部分代码
// Update the page allocator's structures to make this // space ready for allocation. h.pages.grow(v, nBase-v) totalGrowth += nBase - v return totalGrowth, true }
func(h *mheap) sysAlloc(n uintptr) (v unsafe.Pointer, size uintptr) { assertLockHeld(&h.lock)
n = alignUp(n, heapArenaBytes)
// First, try the arena pre-reservation. v = h.arena.alloc(n, heapArenaBytes, &memstats.heap_sys) if v != nil { size = n goto mapped }
// Try to grow the heap at a hint address. for h.arenaHints != nil { hint := h.arenaHints p := hint.addr if hint.down { p -= n } if p+n < p { // We can't use this, so don't ask. v = nil } elseif arenaIndex(p+n-1) >= 1<<arenaBits { // Outside addressable heap. Can't use. v = nil } else { v = sysReserve(unsafe.Pointer(p), n) } // 如果不相等，则说明 mmap 在建议的地址上没能分配成功 if p == uintptr(v) { // Success. Update the hint. if !hint.down { p += n } // 成功后，hint 的地址也跟着更新 hint.addr = p size = n break } // 此时，丢弃这次分配的内存，尝试下一个 arenaHints, 也就是下一个 1T 区间 // Failed. Discard this hint and try the next. // // TODO: This would be cleaner if sysReserve could be // told to only return the requested address. In // particular, this is already how Windows behaves, so // it would simplify things there. if v != nil { sysFree(v, n, nil) } h.arenaHints = hint.next h.arenaHintAlloc.free(unsafe.Pointer(hint)) }
if size == 0 { if raceenabled { // The race detector assumes the heap lives in // [0x00c000000000, 0x00e000000000), but we // just ran out of hints in this region. Give // a nice failure. throw("too many address space collisions for -race mode") }
// All of the hints failed, so we'll take any // (sufficiently aligned) address the kernel will give // us. // 所有的 hint 都失败了，然后让内核自动分配一个定量内存 v, size = sysReserveAligned(nil, n, heapArenaBytes) if v == nil { returnnil, 0 }
// Create new hints for extending this region. hint := (*arenaHint)(h.arenaHintAlloc.alloc()) hint.addr, hint.down = uintptr(v), true hint.next, mheap_.arenaHints = mheap_.arenaHints, hint hint = (*arenaHint)(h.arenaHintAlloc.alloc()) hint.addr = uintptr(v) + size hint.next, mheap_.arenaHints = mheap_.arenaHints, hint } // ......省略大段代码 return }
这里真正申请内存的操作是 sysReserve，让我们来一睹究竟：
1 2 3 4 5 6 7
funcsysReserve(v unsafe.Pointer, n uintptr) unsafe.Pointer { p, err := mmap(v, n, _PROT_NONE, _MAP_ANON|_MAP_PRIVATE, -1, 0) if err != 0 { returnnil } return p }
// sysMmap calls the mmap system call. It is implemented in assembly. funcsysMmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off uint32) (p unsafe.Pointer, err int)
mmap调用中的 flag _PROT_NONE, _MAP_ANON|_MAP_PRIVATE表示申请的内存块是无文件背景的匿名映射，这里在调用时传入了一个提示地址，用于告知内核尽量从要求的地址开始分配。
// 如果不相等，则说明 mmap 在建议的地址上没能分配成功 if p == uintptr(v) { // Success. Update the hint. if !hint.down { p += n } // 成功后，hint 的地址也跟着更新 hint.addr = p size = n break } // 此时，丢弃这次分配的内存，尝试下一个 arenaHints, 也就是下一个 1T 区间 // Failed. Discard this hint and try the next. // // TODO: This would be cleaner if sysReserve could be // told to only return the requested address. In // particular, this is already how Windows behaves, so // it would simplify things there. if v != nil { sysFree(v, n, nil) } h.arenaHints = hint.next h.arenaHintAlloc.free(unsafe.Pointer(hint))
// 只看 64 位系统的初始化部分 // Create initial arena growth hints. if goarch.PtrSize == 8 { // On a 64-bit machine, we pick the following hints // because: // // 1. Starting from the middle of the address space // makes it easier to grow out a contiguous range // without running in to some other mapping. // // 2. This makes Go heap addresses more easily // recognizable when debugging. // // 3. Stack scanning in gccgo is still conservative, // so it's important that addresses be distinguishable // from other data. // // Starting at 0x00c0 means that the valid memory addresses // will begin 0x00c0, 0x00c1, ... // In little-endian, that's c0 00, c1 00, ... None of those are valid // UTF-8 sequences, and they are otherwise as far away from // ff (likely a common byte) as possible. If that fails, we try other 0xXXc0 // addresses. An earlier attempt to use 0x11f8 caused out of memory errors // on OS X during thread allocations. 0x00c0 causes conflicts with // AddressSanitizer which reserves all memory up to 0x0100. // These choices reduce the odds of a conservative garbage collector // not collecting memory because some non-pointer block of memory // had a bit pattern that matched a memory address. // // However, on arm64, we ignore all this advice above and slam the // allocation at 0x40 << 32 because when using 4k pages with 3-level // translation buffers, the user address space is limited to 39 bits // On ios/arm64, the address space is even smaller. // // On AIX, mmaps starts at 0x0A00000000000000 for 64-bit. // processes. for i := 0x7f; i >= 0; i-- { var p uintptr switch { case raceenabled: // The TSAN runtime requires the heap // to be in the range [0x00c000000000, // 0x00e000000000). p = uintptr(i)<<32 | uintptrMask&(0x00c0<<32) if p >= uintptrMask&0x00e000000000 { continue } case GOARCH == "arm64" && GOOS == "ios": p = uintptr(i)<<40 | uintptrMask&(0x0013<<28) case GOARCH == "arm64": p = uintptr(i)<<40 | uintptrMask&(0x0040<<32) case GOOS == "aix": if i == 0 { // We don't use addresses directly after 0x0A00000000000000 // to avoid collisions with others mmaps done by non-go programs. continue } p = uintptr(i)<<40 | uintptrMask&(0xa0<<52) default: p = uintptr(i)<<40 | uintptrMask&(0x00c0<<32) } hint := (*arenaHint)(mheap_.arenaHintAlloc.alloc()) hint.addr = p hint.next, mheap_.arenaHints = mheap_.arenaHints, hint } } }
// Try to grow the heap at a hint address. for h.arenaHints != nil { hint := h.arenaHints p := hint.addr if hint.down { p -= n } if p+n < p { // We can't use this, so don't ask. v = nil } elseif arenaIndex(p+n-1) >= 1<<arenaBits { // Outside addressable heap. Can't use. v = nil } else { v = sysReserve(unsafe.Pointer(p), n) } // 如果不相等，则说明 mmap 在建议的地址上没能分配成功 if p == uintptr(v) { // Success. Update the hint. if !hint.down { p += n } // 成功后，hint 的地址也跟着更新 hint.addr = p size = n break } // 此时，丢弃这次分配的内存，尝试下一个 arenaHints, 也就是下一个 1T 区间 // Failed. Discard this hint and try the next. // // TODO: This would be cleaner if sysReserve could be // told to only return the requested address. In // particular, this is already how Windows behaves, so // it would simplify things there. if v != nil { sysFree(v, n, nil) } h.arenaHints = hint.next h.arenaHintAlloc.free(unsafe.Pointer(hint)) }
mmap 的调用都是围绕着 arenaHints 来进行的，并且每次申请成功后都会更新 hint 的 addr，这样就实现了连续增长，直到失败。如果失败了，就从下一个 1TiB 的区间再次开始！
go 的 GPM 模型此处不作介绍，建议阅读Scheduling In Go : Part II - Go Scheduler 来了解并发模型。我们只说其中的 M，每个M 都有一个 g0 堆栈，用于执行 runtime 代码，其中较为特殊的 M0 （即 go 进程的主线程，每个 go 程序仅有一个 M0）的 g0 堆栈是通过汇编语言进行初始化的。
我们先来看看 go 程序的入口地址：
richard@Richard-Manjaro:~ » readelf -h carefree
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x463f20
Start of program headers: 64 (bytes into file)
Start of section headers: 456 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 7
Size of section headers: 64 (bytes)
Number of section headers: 23
Section header string table index: 3
读取 ELF文件头可知，入口地址为0x463f20，因为禁用了 cgo，没有动态链接库，所以 Entry point 指示的地址既是程序的入口地址。继续看一下该地址指示的代码：
richard@Richard-Manjaro:~ » lldb ./carefree
(lldb) target create "./carefree"
Current executable set to '/home/richard/carefree' (x86_64).
(lldb) image lookup --address 0x463f20
Address: carefree[0x0000000000463f20] (carefree.PT_LOAD[0]..text + 405280)
Summary: carefree`_rt0_amd64_linux
(lldb)
_rt0_amd64_linux 即为程序的入口，当运行程序时，shell 会 fork 一个子进程出来，之后执行 execve() 系统调用来装载 go 的可执行文件，当内核装载完毕之后，会将 CPU 的程序计数器设置为此入口点，之后 go 程序开始执行。
// Disable signals during clone, so that the new thread starts // with signals disabled. It will enable them in minit. var oset sigset sigprocmask(_SIG_SETMASK, &sigset_all, &oset) ret := clone(cloneFlags, stk, unsafe.Pointer(mp), unsafe.Pointer(mp.g0), unsafe.Pointer(abi.FuncPCABI0(mstart))) sigprocmask(_SIG_SETMASK, &oset, nil)
if ret < 0 { print("runtime: failed to create new OS thread (have ", mcount(), " already; errno=", -ret, ")\n") if ret == -_EAGAIN { println("runtime: may need to increase max user processes (ulimit -u)") } throw("newosproc") } }
effective go 中文版 是我个人的文档轮子。为了帮助需要的人准确理解原文，特采纳中英双语格式，目前翻译初稿已经完成。
互联网上已有 effective go 的中文版，甚至还不止一版，那为什么还要再造这个轮子呢？首先，我个人的初衷是为了锻炼自己的英文理解与翻译水平，同时也能磨砺中文的语言组织能力，更是为了把 go 语言的基础夯实。
其次呢，我在读第一遍英文时，碰到有疑问的地方在中文版里往往得不到想要的答案，后来自己思考也解决了一些疑惑，有些问题呢是出自翻译的问题，比如最后一章有一句话：The program here provides a nicer interface to one form of data: given a short piece of text, it calls on the chart server to produce a QR code, a matrix of boxes that encode the text.
冒号之后的内容姑且不论，它是对 a nicer interface 的详细阐述。我们看前半句中的 one form of data 到底指指什么？从字面意思看，或者由翻译软件翻译的话意思应该是：一种数据类别。我所见的两个翻译版本分别翻译成了 一种数据格式 和 某种形式的数据，可见就是照字面翻译，只是为了语句通顺问题，各自进行了调整。但即便是进行了调整，整个句子依然说不通，此程序为一种数据格式提供了更好的的接口 其意几何呢？
其实，下文中文档便给出了详细代码，html 的代码中有一个输入表单。我们知道 form 不仅有形式、类别、种类的意思，还具有表格的意思，并且在前端领域我们习惯于术语表单。所以此处分明是一个数据的表单之意！再者说，form 之前使用了数量词 one 而非定冠词 a ，我认为这是另一条佐证，这句话的本意是：本程序为表单数据提供了更加友好的接口。
除翻译问题外，春秋笔法，微言大义似乎也能造成困扰。effective go 虽为入门级必读资料，其内容算不上艰深，然而某些细微之处，于新手而言并不见得就能轻易领会，所以我在某些地方也注释了自己的心得。这看起来颇有几分古人注书的感觉，只不过我注的内容未必都对，所注条目也不甚多，但总归是自己花了精力的所思所想，相必对有些人有用也未可知，因此闲暇之余，又翻译了一版，很期待各位能够给予斧正。
// AvailableBuffer returns an empty buffer with b.Available capacity. // This buffer is intended to be appended to and // passed to an immediately succeeding Write call. func(b *Writer) AvailableBuffer() []byte { return b.buf[b.n:][:0] }
funcmain() { w := bufio.NewWriter(os.Stdout) for _, i := range []int64{1, 2, 3, 4} { b := w.AvailableBuffer() b = strconv.AppendInt(b, i, 10) b = append(b, ' ') w.Write(b) } w.Flush() }
