在 runtime2.go(go 1.10) 中定义了 goroutine 生命周期中所有可能的状态，虽然状态不多，不过其状态切换的可能性还是蛮多的，整理了一张图： 带上 GC 以后，图会比较乱，去掉 GC 相关的状态切换以后，会清爽许多。这里所有的 goroutine 状态切换都是由 runtime 的函数触发的，我们把 runtime 字样也从图上删除： 抽时间写写状态切换的文章。 再来一张 p 状态切换的：

在《Designing Data-Intensive Application》一书中为当今大多数的互联网系统下了个定义，即数据密集型系统。在数据密集型系统中我们要应对的是数据的爆炸性增长问题。 为了应对问题我们采用了一些手段，比如 partition、replication，但这些手段，在一些场景或语言受限的情况下会带来一些麻烦的问题。本文主要讲一讲复制方面的问题。 说到复制 replication，可能大多数人第一印象都是存储系统中的复制，比如 MySQL 中基于 binlog 的复制，redis 中基于操作日志的复制，zk/etcd/kafka 中基于特定算法的复制(实质上也是基于 log 的复制)，等等。但复制的概念本身实际上是很广的，

plan9 assembly 完全解析 众所周知，Go 使用了 Unix 老古董(误 们发明的 plan9 汇编。就算你对 x86 汇编有所了解，在 plan9 里还是有些许区别。说不定你在看代码的时候，偶然发现代码里的 SP 看起来是 SP，但它实际上不是 SP 的时候就抓狂了哈哈哈。 本文将对 plan9 汇编进行全面的介绍，同时解答你在接触 plan9 汇编时可能遇到的大部分问题。 本文所使用的平台是

这篇和之前的汇编那篇一样，都是翻译自 github 的 go-internals 这个项目，我的翻译地址是： > https://github.com/cch123/go-internals 这篇写的比较长，如果讲深度的话。。那自己真是惭愧到不好意思去写 interface 的文章了。 不过还是要写，因为看这种基于汇编分析问题的东西，对于大多数人来说还是比较难。这篇其实也不能算面面俱到，而且作者的研究方法是从 binary asm 反推实现原理，实际上还可以直接去看编译器的代码的。 废话不多说，如下。 $ go version go version go1.

Bootstrap locate entry point 思路，找到二进制文件的 entry point，在 debugger 中确定代码位置。 使用 gdb: (gdb) info files Symbols from "/home/ubuntu/exec_file". Local exec file: `/home/ubuntu/exec_file', file type elf64-x86-64. Entry