Go 的 net/http 服务器采用了每个连接一个 goroutine 的模型，结合运行时的 M:N 调度策略。当服务器接受一个 TCP 连接时，它立即生成一个轻量级的 goroutine 来处理该连接的整个生命周期，从而使主接受循环可以立即返回并接收下一个连接。这些 goroutine 由 Go 调度器复用到有限的 OS 线程池中，调度器会停放执行阻塞 I/O 的 goroutine，并将可运行的 goroutine 重新调度到可用的线程上。该架构使服务器可以使用仅有的少量内核线程维护成千上万的并发连接，避免了传统每个连接使用线程的服务器的内存开销。
我们需要建立一个实时遥测网关，能够通过持久的 HTTP/1.1 连接同时接收来自 50,000 个 IoT 设备的数据。
问题描述：我们最初使用 Python 和 Twisted 构建的原型提供了必要的并发性，但由于复杂的回调链和嵌套深的错误处理，很快变得不可维护。当我们尝试使用 Java 的每个连接一个线程的方法以简化代码时，我们遇到了操作系统的线程限制，大约在 32,000 个连接时，导致 JVM 崩溃，并出现 OutOfMemoryError: unable to create new native thread，因为每个线程消耗超过 1MB 的虚拟内存。
考虑的不同解决方案：
带有显式状态机的 Asyncio：我们评估了迁移到 Python 的 asyncio，以使用单个事件循环和协程。这将显著减少与线程相比的内存占用，但需要将我们所有的协议解析逻辑重写为 async/await 语法，并引入了意外阻塞事件循环的风险，因为某些 CPU 密集型操作可能会导致该问题。跨异步边界的调试堆栈跟踪也被证明对我们的开发团队来说非常困难。
JVM 实例的水平分片：我们考虑在负载均衡器后运行十个较小的 Java 实例，每个实例处理 5,000 个线程。这种方法解决了每个进程的线程限制，但引入了相当大的操作复杂性，需要额外的硬件资源，并且使跨集群的共享状态和连接粘性管理复杂化。维护这个微集群的操作开销超过了坚持使用 Java 的好处。
Go 的每个连接一个 goroutine 的模型：我们选择在 Go 中重新实现该网关，利用标准库的 net/http 和 net 包。服务器的 Serve 方法会自动为每个接受的 TCP 连接生成一个轻量级的 goroutine，而 Go 运行时的调度器透明地将这些 goroutine 复用到有限的 OS 线程池上。这使我们能够编写看起来简单的同步 I/O 代码，能够扩展到成千上万的连接，而无需手动管理状态机。
选择的解决方案和理由：我们选择了 Go 的实现，因为它结合了事件驱动系统的可扩展性和线程编程的简单性。运行时自动处理调度和非阻塞 I/O 的复杂性，使我们的开发人员能够专注于业务逻辑而不是并发原语。此外，goroutine 初始堆栈大小为 2KB，意味着理论上我们可以在内存预算内处理数百万个连接。
结果：生产系统在一台 8 核心服务器上成功管理了 75,000 个并发持久连接，消耗不到 4GB 的 RAM。CPU 利用率保持在 35-40% 的稳定水平，因为调度器有效地隐藏了 I/O 延迟，我们消除了管理分片 Java 实例集群的操作负担。
当成千上万的 goroutine 阻塞在同一个通道接收时，Go 的调度程序如何防止雷鸣之群问题？
Go 的调度程序使用先进先出（FIFO）等待队列来处理通道，而不是信号量式的唤醒所有。当发送者向通道写入时，调度器从接收队列中唤醒一个正在等待的 goroutine（等待时间最长的那个）。这确保只有一个 goroutine 消耗该值，防止了雷鸣之群问题，其中多个 goroutine 唤醒，争夺锁，除了一个以外的所有 goroutine 又回到睡眠状态。候选人常常错误地认为通道操作像条件变量一样广播给所有等待者。
为什么将 GOMAXPROCS 增加到物理 CPU 核心数量之外会降低 I/O 密集型 Go HTTP 服务器的性能？
虽然 Go 的调度程序自 1.14 版本以来具有抢占式特性，但拥有比核心更多的 OS 线程（M）会增加内核级上下文切换开销。对于 I/O 密集型服务器，过多的线程可能导致调度程序花费更多时间管理运行队列和线程交接，而不是执行用户代码。此外，每个 OS 线程都消耗内核资源（线程局部存储和内核堆栈的内存），这在超过必要并行性时可能会给操作系统施加压力。
当 goroutine 接受速率暂时落后于连接到达速率时，Go 的 net/http 服务器如何处理 TCP SO_BACKLOG 队列？
该服务器依赖于内核的监听背压队列（通过 net.ListenConfig 的 Backlog 或系统默认值控制）。如果 goroutine 启动缓慢，或者处理程序从侦听器接受连接的速度较慢，则内核会将进入的 SYN 排队在背压中。一旦背压填满，内核通过 TCP RST 拒绝新的连接。Go 的 Accept() 循环在其自己的 goroutine 中运行，并且理想情况下应快速生成处理程序 goroutine。但是，如果处理程序的生成延迟（例如，由于 GC 暂停或中间件中的互斥锁争用），连接会丢失。候选人常常忽视 Go 并未实现用户空间连接排队；它完全依赖于内核的背压，因此调整 SOMAXCONN 或 ListenConfig.Backlog 对于处理突发流量至关重要。