令牌桶（token bucket）是最常用的限流算法。它用两个数描述一条规则：令牌补充的速度，和桶最多能存多少个令牌。它要解决的问题是：既把长期的平均速度压住，又允许短时间内的一阵突发。 限流、熔断、降级三者的关系见 限流、熔断与降级，这篇只讲令牌桶。 原理 想象一个桶： 系统以恒定速度 r 往桶里放令牌，比如每秒 5 个； 桶最多装 b 个令牌，比如 60 个，满了再放的令牌直接丢掉； 每个请求进来先从桶里取一个令牌，取到就放行，桶空了就拒绝（或者排队等）。 所以 r 管的是长期平均速度，b 管的是一次最多能连发多少。b 也叫突发容量（burst）。 用 r = 5/s、b = 60 走一遍： 时刻 发生了什么 桶里的令牌 0 秒 用户闲了很久，桶是满的 60 0 秒 一口气发了 40 个请求，全部放行 20 0～4 秒 没有请求，每秒补 5 个 40 4 秒 又连发 50 个：前 40 个放行，后 10 个被拒 0 4 秒之后 每 0.2 秒补 1 个，只能按每秒 5 个的速度继续 0～1 停 12 秒 补满 60 规律： ...
本文整理一般二叉树、二叉搜索树（BST）与平衡树的概念；BST 的插入、查找、删除与中序遍历的 Go 实现见我的 leetcode 仓库 下的 tree/（bst.go、bst_test.go）。 二叉树 (Binary Tree) 二叉树 (Binary Tree) 是包含 n 个节点的有限集合，该集合或者为空集（此时，二叉树称为空树），或者由一个根节点和两棵互不相交的、分别称为根节点的左子树和右子树的二叉树组成。 二叉树中的节点至多包含两棵子树，分别称为左子树和右子树，而左子树和右子树又分别至多包含两棵子树。由上述的定义，二叉树的定义是一种递归的定义。 graph TD n1((1)) n2((2)) n3((3)) n4((4)) n5((5)) n7((7)) n10((10)) n11((11)) n14((14)) n1 --> n2 n1 --> n3 n2 --> n4 n2 --> n5 n3 --> n7 n5 --> n10 n5 --> n11 n7 --> n14 满二叉树 Full Binary Tree 对于一棵二叉树，如果每一个非叶子节点都存在左右子树，并且二叉树中所有的叶子节点都在同一层中，这样的二叉树称为满二叉树。 graph TD n1((1)) n2((2)) n3((3)) n4((4)) n5((5)) n6((6)) n7((7)) n8((8)) n9((9)) n10((10)) n11((11)) n12((12)) n13((13)) n14((14)) n15((15)) n1 --> n2 n1 --> n3 n2 --> n4 n2 --> n5 n3 --> n6 n3 --> n7 n4 --> n8 n4 --> n9 n5 --> n10 n5 --> n11 n6 --> n12 n6 --> n13 n7 --> n14 n7 --> n15 完全二叉树 Complete Binary Tree 对于一棵具有 n 个节点的二叉树按照层次编号，同时，左右子树按照先左后右编号，如果编号为 i 的节点与同样深度的满二叉树中编号为 i 的节点在二叉树中的位置完全相同，则这棵二叉树称为完全二叉树。 ...
给 Go 服务加指标（比如「查一次词花了多少毫秒」），代码里要选一个埋点库。常见的两个选择是 Prometheus 官方的 client_golang 和 OpenTelemetry 的 Go SDK。两者都能产出同样的 Prometheus 指标，差别在覆盖范围、配置量和对后端的绑定程度。 采集、存储、展示这一层（Alloy、Prometheus、Loki、Grafana）的对比见 可观测性工具对比。本文只讲应用代码里的埋点这一层。 埋点库在哪一层 graph LR A["应用代码埋点库：client_golang 或 OTel SDK"] --> B["采集Prometheus 抓取 / Alloy / OTel Collector"] B --> C["存储Prometheus / Mimir / Grafana Cloud"] C --> D["展示Grafana"] 埋点库决定两件事：代码里怎么记录一个数字，以及这个数字以什么格式交出去（Prometheus 的 /metrics 文本格式，或者 OTLP 协议）。它不决定数据最后存在哪。 Prometheus client_golang github.com/prometheus/client_golang 是 Prometheus 项目的官方 Go 客户端，只做指标。 工作方式是拉（pull）：应用在内存里维护计数器和直方图，通过 HTTP 暴露一个 /metrics 端点，Prometheus（或 Alloy）定期来抓。应用不知道谁来读，也不主动往外发。 四种指标类型： 类型 用途 例子 Counter 只增不减的计数 请求总数、错误总数 Gauge 可增可减的当前值 正在处理的请求数、队列长度 Histogram 按桶统计分布，服务端可算分位数 请求耗时，用来算 p95/p99 Summary 客户端直接算分位数 很少用；分位数无法跨实例聚合，一般用 Histogram 最小示例： ...
背景 教材里常把编程语言分成 编译型（compiled） 和 解释型（interpreted）。二者是一组相对概念，但现代语言大多落在光谱中间，不宜一刀切。 脚本语言（scripting language） 在日常说法里，往往就是解释型一侧的别名，或更窄一点：强调「缩短 edit-compile-link-run、以源码直接跑、做自动化 / 嵌入」的那一类解释型语言。下文先讲编译 / 解释，再单独说脚本。 两种执行路径 类型 典型流程 运行时依赖 编译型 源码 → 编译器 → 机器码 / 本地二进制 → 直接由 OS 加载执行 一般不需要语言自带的解释器；可内嵌 runtime（如 GC） 解释型 源码（或中间表示）由 解释器 边读边执行 必须安装对应解释器 / 运行时 对照： 编译型（AOT）: 源码 ──compile──► 本地二进制 ──► 运行 解释型: 源码 ──► 解释器逐句执行 字节码 + VM: 源码 ──compile──► 字节码 ──► 解释 / JIT ──► 机器码 「预编译 / ahead-of-time（AOT）」说的是：运行前就编成可执行形态；日常口语里常与「编译型」混用。注意 C 里的「预编译」有时指 #include / #define 的预处理，那是编译流水线的一步，不是语言分类。 ...
为什么会发生调度？因为 CPU 是有限的，而操作系统上的进程很多，所以操作系统需要平衡各个进程的运行时间。比如说有的进程运行时间已经很长了，已经占用了 CPU 很长时间了，这个时候操作系统要公平，就会换下一个需要运行的进程。 抢占 vs 协作 从调度机制上来讲，调度可以分为抢占式和协作式。 非抢占，协作 非抢占方式是指一旦将调度资源（如 CPU）分配给某任务后，便让该任务一直执行，直到该任务完成或阻塞或主动让出 CPU 控制权，非抢占调度又称为协作式调度，它实现简单，并且对共享资源的访问也更安全（如允许使用不可重入函数）。非抢占算法常见的如 FIFO、STCF（Short Time to Complete First）等。 抢占 抢占方式则允许调度程序根据某种规则，剥夺当前进程的调度资源，将其分配给其它进程。常见的抢占策略有： 基于时间片 给每个进程分配时间片，当时间片用完后，则停止该进程重新调度下一个进程，这种均分 CPU 的算法，又叫轮转调度算法。 基于优先级 给每个进程分配一个优先级，一旦出现一个优先级更高的进程，则停止当前进程并切换到该高优先级进程，这种调度算法又叫优先级抢占。轮转调度和优先级抢占结合，即相同优先级的进程使用轮转调度，如果遇到更高优先级的进程，则可抢占 CPU，现代 OS 如 Linux 通常都使用这种混合调度策略（Linux 具体的调度器体系见 Linux 进程调度）。 基于优先级抢占容易出现优先级反转的问题：优先级低的任务持有一个被优先级高的任务所需要的共享资源，这种情况下，优先级低的任务有资源而得不到 CPU，优先级高的任务有 CPU 而得不到资源，从而阻塞（导致其它中优先级的任务获得执行）或者忙等（可能永远无法获得资源）。 解决优先级反转的方案： 给临界区一个高优先级，所有进入该临界区的任务将获得该高优先级，避免其被随意抢占； 当高优先级任务在等待低优先级进程持有资源时，低优先级进程将暂时获得高优先级进程的优先级，VxWorks 采用的方式； 禁止中断，也就是在临界区不可被抢占，Linux 采用的就是这种方式，在 thread_info.preempt_count 记录每个进程当前持锁计数； 另外，调度器是不能在进程指令流的任意一点执行打断的，因为进程可能此时正在做任何事情，如系统调用、死循环、锁操作等，要实现任意状态的可抢占性代价是很大的，需要 OS 和 App 的通力配合，特别是在涉及内核态的时候，目前所有 OS 都不能在进程执行的任意点进行抢占，只是说不断让抢占区更大、抢占点尽可能地密集。 实时 vs 非实时 从系统需求或用户角度而言，调度系统可以分为实时系统和非实时系统。 在实时操作系统中，系统必须在特定的时间内完成指定的应用。实时通常分为软实时（soft real-time）和硬实时（hard real-time），硬实时是指系统要有确定的最坏情况下的服务时间，即对于事件的响应时间截止期限无论如何都必须得到满足，通常应用在军工航天领域；而软实时只提供统计意义上的实时，比如应用要求在 95% 的情况下都会确保在规定的时间内执行某个任务，而不一定要求 100%。实时系统通常采用抢占调度，实现一个硬实时系统的代价是很高的，要做到进程可以在任意时刻被抢占，在现代 OS 上来讲基本是不可能的，因为 OS 的很多系统调用都是不可被打断的，并且很多操作具备时间的随机性，比如 CPU Cache Miss、Page Fault、CPU 分支预测器等等。 ...
Swiss Table 是什么 Swiss Table 是 Google 在 2017 年前后公开的一种高性能哈希表设计（最早用在 Abseil 库的 absl::flat_hash_map 里），本质上是开放地址法的一个工程变体：在经典的线性探测 / 二次探测之上，加入了按"组"批量比较的机制，充分利用 CPU 的 SIMD 指令与缓存局部性。基本的开链法、开放地址法概念见 开链法与开放地址法。 它已经被多个主流项目采纳：Rust 的 hashbrown（std::collections::HashMap 自 1.36 起的底层实现）就是 Google SwissTable 的 Rust 移植版；Go 1.24 内置的 map 也从桶+溢出桶的实现换成了基于 Swiss Table 思路的新实现（细节见 开链法与开放地址法#在-go-语言中的应用）。 核心设计 控制字节（control byte） Swiss Table 给每个槽位（slot）配一个额外的 1 字节"控制字节"，不存实际数据，只存槽位的状态和一段哈希指纹： 槽位状态：EMPTY（从未用过）、DELETED（曾经用过、已删除，即墓碑标记）、FULL（当前有效数据）。 如果槽位是 FULL，控制字节里还会存一段哈希指纹，Abseil 里称为 h2，取的是 key 完整哈希值的低 7 位。 h1 和 h2：哈希值一分为二 Swiss Table 把 key 的哈希值拆成两部分： h1：哈希值的剩余高位，用来计算这个 key 应该落在哪一个"组"（group），即决定探测起点，作用类似前文开放地址法里的 root = hash(key) % m。 h2：哈希值的低 7 位，存进控制字节，作为一个廉价的"预筛选"指纹。 分组批量比较 控制字节在内存中是连续排列的，按组打包（Abseil/hashbrown 里一组 16 个，Go 1.24 里一组 8 个，打包进一个 64 位控制字）。查找时： ...
开链法与开放地址法，Separate Chaining and Open Addressing 哈希表在插入元素时，如果两个不同的 key 计算出的哈希值落到了数组的同一个位置，就发生了哈希冲突（hash collision）。解决哈希冲突主要有两种思路：开链法（Separate Chaining）和开放地址法（Open Addressing）。Java 的 HashMap 用的是开链法；Python 的 dict 用的是开放地址法。Java 里也有用开放地址法的例子，比如 IdentityHashMap 和 ThreadLocal.ThreadLocalMap，详见后文「在 Java 中的应用」一节。 开链法，Separate Chaining 开链法是一种二维结构：第一维是一个数组，数组的每个槽位（bucket）挂着一个链表（第二维）。插入元素时，先用 hash 函数算出该 key 应该落在数组的哪个槽位，然后直接把这个 key（连同 value）作为一个节点追加到该槽位的链表上。 当多个不同的 key 计算出相同的槽位时，它们并不会互相覆盖或者被挪到别处，而是全部挂在同一个槽位的链表里，按顺序排列。查找时，先定位到槽位，然后遍历该槽位的链表，逐个比较 key 是否相等，直到找到目标或者遍历到链表末尾。 优点 实现简单，冲突处理直观，槽位之间互不影响。 删除操作非常简单，只需要从链表中把对应节点摘除即可，不会影响其它元素的查找路径。 负载因子（元素个数 / 数组长度）可以大于 1，只是链表会变长，查找退化为线性扫描。 负载因子，Load Factor 负载因子的英文是 load factor，公式为 load factor = 哈希表中总元素个数 / 数组长度（槽位数）。这里的"元素个数"指的是整个哈希表中的元素总数，而不是某一个槽位对应的元素个数；某个槽位挂了多少个元素（链表长度）反映的是 hash 分布是否均匀，是另一个维度的问题。例如数组长度为 16，哈希表中一共存了 12 个元素，此时 load factor 就是 0.75。 开链法下即使 load factor 大于 1（元素个数超过数组长度）也不会出错，只是链表会变长；而开放地址法由于只有一个数组，load factor 不能超过 1（数组会满）。 ...
golang interface interface 是一种类型 type foo interface { Get() int } 首先 interface 是一种类型，从它的定义可以看出来用了 type 关键字，更准确的说 interface 是一种具有一组方法的类型，这些方法定义了 interface 的行为。 go 允许不带任何方法的 interface ，这种类型的 interface 叫 empty interface。 如果一个类型实现了一个 interface 中所有方法，我们说类型实现了该 interface，所以所有类型都实现了 empty interface，因为任何一种类型至少实现了 0 个方法。go 没有显式的关键字用来实现 interface，只需要实现 interface 包含的方法即可。 ‘golang 获取interface{} 的数据类型’ https://blog.csdn.net/xia_xing/article/details/49423771 interface{} 可以接受任何类型的对象值 获取interface{}队形的数据类型，可以使用断言，或者 switch type 来实现 // Assertion project main.go package main import ( “fmt” ) type Bag struct { Key string } type Bag2 struct { Key int } func main() { var b1 interface{} var b2 interface{} ...
背景 2020 年前后，我在大连 R 公司负责车联网平台协议解析层的开发和维护。R 平台是一套部署在公有云上的 IoT 平台，接入大量在线车载设备，实时处理车辆上报的行车数据。 那时平台有一项新的合作需求：一家做共享汽车业务的公司（以下简称 M 公司）采购了 R 公司的车载设备，安装在共享汽车上，希望通过接口从 R 平台获取这些车辆的实时行车数据，再通过自己的 App 提供给用户查询车辆状态和行驶记录。 我负责这次集成的开发工作，包括改造行车数据服务的分流逻辑，以及独立开发一个面向 M 公司的数据推送服务。这也不是我第一次做类似的事，R 平台之前也有过给其他第三方提供数据接口的项目，但 M 公司是其中规模比较大的一家。 技术方案 行车数据服务本身改动不大。原来的逻辑是收到设备上报的数据后直接写入平台内部各个下游。这次只是加了一段分流逻辑：根据车辆底盘号（VIN）查询 Redis 中的客户映射关系，如果这辆车属于 M 公司，就把这条数据额外发送到一个专用的 Kafka topic。 Kafka topic 的另一侧是我新写的 Go Kafka consumer，消费消息后做数据格式转换，处理鉴权，再通过 HTTP POST 批量推送给 M 公司的接口。推送时有一个打包策略：收到 N 条数据就打包发出，或者超过一定时间没有新数据也把当前这批发出，每次 HTTP 请求可能包含多条记录。 VIN 到客户的映射关系存储在 Redis，由业务侧维护，数据服务只做读取。 工程细节 可观测性 对接第三方的接口，出问题时的排查成本比内部服务高很多——双方都需要对齐日志，搞清楚是哪一侧的问题。 我在这个服务里做了几件事： 每一批次数据带一个唯一的 trace ID，日志里记录发送时间、trace ID、完整 payload、M 公司 API 的响应时间和状态码。在调试阶段和试运行阶段，日志级别调到 debug，把 payload 全量打印出来，方便排查数据是否正确、格式是否符合对方预期。 除了日志，我还在服务里埋了监控指标，记录推送并发量和调用对方 API 的响应时间，接入 R 平台已有的 Grafana 看板，可以直观看到推送量和延迟的变化趋势。 ...
协程, Coroutine 协程别名: 微线程，纤程。英文:Coroutine, Green threads, fibers 传统编程语言中子程序或者函数是层级调用的,函数可以调用其它函数, 调用者需要等待被调用者结束之后继续执行, 函数调用是通过栈实现的. 一个线程就是按顺序执行一个或几个子函数, 函数调用只有一个入口和一个出口. 协程看上去也是函数,但是执行过程中在子程序内部可以中断,然后执行别的函数, 然后再被调度回来执行. 协程比线程有更高的执行效率, 协程没有线程切换的开销 协程在用户空间调度, 不涉及系统调用或任何阻塞调用, 不需要用来守卫关键区块的同步性原语（primitive）比如互斥锁、信号量等，并且不需要来自操作系统的支持 协程不需要多线程的锁机制, 为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。 协程是协作式多任务的, 线程典型是抢占式多任务的 因为协程是一个线程执行，那怎么利用多核CPU呢？最简单的方法是多进程+协程，既充分利用多核，又充分发挥协程的高效率，可获得极高的性能。 使用抢占式调度的线程实现协程，但是会失去某些利益（特别是对硬性实时操作的适合性和相对廉价的相互之间切换）。 协程是语言层级的构造，可看作一种形式的控制流，而线程是系统层级的构造。 名词对照 coroutine、goroutine、virtual thread、轻量级线程、协程、虚拟线程、用户态线程、绿色线程——这些名词基本上在说同一类东西，只是来自不同语言和时代： 术语 说明 coroutine（协程） 最广义的概念，包括协作式（asyncio）和抢占式（goroutine）两类 goroutine Go 的实现，抢占式，属于协程的子集 virtual thread（虚拟线程） Java 21 的叫法，强调"就是线程，只是轻量" green thread（绿色线程） 早期术语，泛指用户态管理的线程 用户态线程 / 轻量级线程 描述实现机制的技术术语 命名不同有历史原因： Go 作者刻意不叫"协程"，因为传统协程是协作式的，而 goroutine 是运行时抢占式调度的，更像轻量级线程 Java 叫"虚拟线程"是为了向后兼容——复用 Thread API，让现有代码改动最小 严格说，asyncio 协程（协作式、无栈）和 goroutine / 虚拟线程（抢占式、有栈）不是一回事，但常被混称为"协程"。 为什么需要用户态线程 OS 线程太重了 一个 OS 线程的代价： 默认栈大小 1~8 MB（Linux 默认 8MB） 创建/销毁需要系统调用，耗时微秒级 上下文切换需要陷入内核，保存/恢复大量寄存器 线程数受 OS 限制，通常几千到几万个 典型场景：一个 HTTP 服务，每个请求一个线程，1 万并发连接 → 80GB 内存光用在栈上，还没开始干活。 ...
Command Dispatcher（命令分发器）和 Command Bus（命令总线）是架构模式，属于应用层架构设计的范畴，不在 GoF 23 种设计模式之列。 注意：“Command Dispatcher” 是开发者社区的口语化称呼，没有权威模式书籍正式定义。对应的正式模式名是 EIP（企业集成模式）中的 Content-Based Router（见下文）。 两者不是同一个模式，Command Bus 是在 Content-Based Router 基础上增加了中间件管道的演化版本，核心差异在于中间件管道。 Command Dispatcher Command Bus 核心机制 ID → Handler 直接路由 ID → 中间件链 → Handler 中间件支持 无 有（日志、验证、事务等） 复杂度 简单 较复杂 典型场景 IoT 协议解析、游戏指令 CQRS、DDD 应用层 Command Dispatcher 核心结构： 收到消息 → 解析 ID → registry.get(id) → handler.Handle(data) 服务初始化时将每种指令的处理类注册到一个 Map。运行时收到消息后，解析出消息类型 ID，从注册表查找对应处理器并直接调用。 // Handler 接口，每种指令实现一个 type Handler interface { Handle(data []byte) error } // Dispatcher 维护 id -> handler 的注册表 type Dispatcher struct { handlers map[uint8]Handler } func NewDispatcher() *Dispatcher { return &Dispatcher{handlers: make(map[uint8]Handler)} } func (d *Dispatcher) Register(id uint8, h Handler) { d.handlers[id] = h } func (d *Dispatcher) Dispatch(id uint8, data []byte) error { h, ok := d.handlers[id] if !ok { return fmt.Errorf("unknown command id: 0x%02X", id) } return h.Handle(data) } // --- 具体指令处理类 --- type LoginHandler struct{} func (h *LoginHandler) Handle(data []byte) error { fmt.Printf("处理登录指令: %x\n", data) return nil } type LocationReportHandler struct{} func (h *LocationReportHandler) Handle(data []byte) error { fmt.Printf("处理位置上报: %x\n", data) return nil } // --- 初始化注册 --- func main() { d := NewDispatcher() d.Register(0x01, &LoginHandler{}) d.Register(0x02, &LocationReportHandler{}) // 收到一条原始消息，解析出 id=0x02 d.Dispatch(0x02, []byte{0x01, 0x02, 0x03}) } Command Bus 在 Dispatcher 的基础上增加了中间件管道，每条命令在到达 Handler 之前会依次经过所有中间件。 ...
golang kafka https://github.com/Shopify/sarama https://github.com/bsm/sarama-cluster
golang flag 获取命令行参数 flag.String("port", ":8080", "http listen port") 像flag.Int、flag.Bool、flag.String这样的函数格式都是一样的,第一个参数表示参数名称,第二个参数表示默认值,第三个参数表示使用说明和描述。flag.StringVar这样的函数第一个参数换成了变量地址,后面的参数和flag.String是一样的。 flag.Parse() 解析函数将会在碰到第一个非 flag 命令行参数时停止,非flag命令行参数是指不满足命令行语法的参数,如命令行参数为cmd -flag=true abc 则第一个非 flag 命令行参数为 “abc” 使用flag来操作命令行参数,支持的格式如下: -id=1 --id=1 -id 1 --id 1 package main import ( "flag" "fmt" ) func main() { ok := flag.Bool("ok", false, "is ok") id := flag.Int("id", 0, "id") port := flag.String("port", ":8080", "http listen port") var name string flag.StringVar(&name, "name", "123", "name") flag.Parse() fmt.Println("ok:", *ok) fmt.Println("id:", *id) fmt.Println("port:", *port) fmt.Println("name:", name) } 还是非常方便的。 执行一下: $ go run flag.go -id=2 -name=“golang” ok: false id: 2 port: :8080 name: golang 使用-h参数可以查看使用帮助: $ go run flag.go -h -id=0: id ...
golang tcp socket Golang的主要 设计目标之一就是面向大规模后端服务程序,网络通信这块是服务端 程序必不可少也是至关重要的一部分。在日常应用中,我们也可以看到Go中的net以及其subdirectories下的包均是"高频+刚需",而TCP socket则是网络编程的主流,即便您没有直接使用到net中有关TCP Socket方面的接口,但net/http总是用到了吧,http底层依旧是用tcp socket实现的。 网络编程方面,我们最常用的就是tcp socket编程了,在posix标准出来后,socket在各大主流OS平台上都得到了很好的支持。关于tcp programming,最好的资料莫过于W. Richard Stevens 的网络编程圣经《UNIX网络 编程 卷1: socket 联网API》 了,书中关于tcp socket接口的各种使用、行为模式、异常处理讲解的十分细致。Go是自带runtime的跨平台编程语言,Go中暴露给语言使用者的tcp socket api是建立OS原生tcp socket接口之上的。由于Go runtime调度的需要,golang tcp socket接口在行为特点与异常处理方面与OS原生接口有着一些差别。这篇博文的目标就是整理出关于Go tcp socket在各个场景下的使用方法、行为特点以及注意事项。 模型 从tcp socket 诞生后, 网络编程架构模型也几经演化, 大致是: “每进程一个连接” –> “每线程一个连接” –> “Non-Block + I/O多路复用 (linux epoll/windows iocp/freebsd darwin kqueue/solaris Event Port)"。伴随着模型的演化,服务程序愈加强大,可以支持更多的连接,获得更好的处理性能。 目前主流web server一般均采用的都是"Non-Block + I/O多路复用” (有的也结合了多线程、多进程) 。不过I/O多路复用也给使用者带来了不小的复杂度,以至于后续出现了许多高性能的I/O多路复用框架, 比如libevent、libev、libuv等,以帮助开发者简化开发复杂性,降低心智负担。不过Go的设计者似乎认为I/O多路复用的这种通过回调机制割裂控制流的方式依旧复杂,且有悖于"一般逻辑"设计,为此Go语言将该"复杂性"隐藏在Runtime中了: Go开发者无需关注socket是否是 non-block的,也无需亲自注册文件描述符的回调,只需在每个连接对应的goroutine中以"block I/O"的方式对待socket处理即可,这可以说大大降低了开发人员的心智负担。一个典型的Go server端程序大致如下: //go-tcpsock/server.go func handleConn(c net.Conn) { defer c.Close() for { // read from the connection ...