「同时」是一种错觉：从一杯咖啡说起

不会。一点都不会，甚至会更慢。

asyncio 是单线程的。异步买到的东西只有一样：在等待的时候去干别的活。而 CPU 密集的任务根本没有等待 —— 它从头到尾都在算。你把一个没有空隙的东西塞进一个专门用来填空隙的机制里，只会白付一笔调度开销。

更糟的是：那个跑得正欢的 CPU 密集协程不会主动让出事件循环，于是它会把整个进程的所有请求一起卡住。（第 13 章的 demo 会让你亲眼看到这一幕。）

CPU 密集只有一条路：多核并行。而在 Python 里，因为 GIL，这条路叫 multiprocessing。

只对了一半，而这一半的误传害了很多人。

关键事实：所有阻塞式 IO 在进内核之前都会释放 GIL。socket.recv、time.sleep、文件读写、requests.get —— 全都放手。

所以，用 10 个线程去抓 10 个网页，在 Python 里是真的会快接近 10 倍的。GIL 只在执行 Python 字节码时被持有。

准确的说法是：GIL 让 Python 多线程无法利用多核做计算，但完全不妨碍它并发做 IO。

不是。线程可能只有 8 个。

这是 Go 最漂亮的一手：conn.Read() 看起来是阻塞调用，但 runtime 把这个 fd 悄悄注册进了 netpoller（Linux 上就是 epoll），然后把这个 goroutine park 住，OS 线程立刻回去跑别的 goroutine。

你写的是最朴素的阻塞式代码，跑的是 epoll 事件循环。没有 async、没有 await、没有函数染色 —— 编译器和 runtime 把这件事整个吞了。这是 Go 在并发上最大的产品决策。

不是。它们甚至不在同一个层面上。

• 同步 / 异步说的是调用契约：我发出调用之后，我这条执行线还能不能往下走？
• 阻塞 / 非阻塞说的是线程的下场：在等待期间，那个 OS 线程是被占着不动，还是被交还回去干别的？

它们经常一起出现（「同步阻塞 IO」），但四种组合全都存在。最典型的反例：Kotlin 的 suspend 函数是「同步风格的代码，非阻塞的行为」 —— 代码从上往下读，但线程在挂起点被还回去了。

var counter = 0
// 线程 A 和线程 B 各执行 1000 次:
counter++

不一定。而且它大部分时候是对的 —— 这正是最恶毒的地方。

counter++ 不是一步，它是三步：LOAD（读到寄存器）、ADD（加一）、STORE（写回）。如果两个线程的 LOAD 挨在一起，它们会读到同一个旧值，然后各自加一、各自写回 —— 两次自增，只生效了一次。

第 8 章的 demo 会真的把这三条指令随机交错跑 1000 次，让你看着它丢。

这是你未来某次 OOM 的完整成因。

只要到达率 λ 长期大于处理率 μ，无界队列就会线性增长，永不回落。它没有消除压力，只是把压力推迟到内存耗尽的那一刻。

而且在 OOM 之前，你的延迟已经先崩了：队列里排着 1 万个请求，新来的那个就得等 1 万个请求的处理时间。一个「永不拒绝」的系统，会先变成一个「永远超时」的系统。

正确的做法叫背压：让队列有界，满了就把压力沿着管道往回传，一路传到源头。

它还在跑。没有人负责。这就是问题所在。

go f() 让控制流跳出去，再也不回来 —— 从这个角度看，它和 goto 是同一种病。2018 年那篇著名的《Go statement considered harmful》说的就是这件事。

后果：goroutine 泄漏是 Go 最常见的生产事故，而且编译器不会给你任何警告。

解药叫结构化并发：让「启动一个并发任务」变得像调用一个函数一样有始有终。Kotlin 的 coroutineScope、Python 3.11 的 TaskGroup、Java 的 StructuredTaskScope 全是这个思想。而 Go 是三门语言里唯一还没有它的。

大约 16.8 倍。而不是 95 倍。

Amdahl 定律：加速比 = 1 / ( (1−p) + p/n )。代进去：1 / (0.05 + 0.95/100) ≈ 16.8。

更残酷的是：哪怕你有无限个核，天花板也只有 1/(1−p) = 20 倍。那剩下的 5% 串行部分，多少个核都帮不上忙。

而这还是乐观的估计 —— 它没算争锁和缓存一致性的开销。真实系统里，核加到某个数之后，性能是会掉头向下的。