Goroutines

在现代软件工程中，构建可以同时执行多个任务的应用程序不再是一种奢侈，而是一个核心需求。从高吞吐量 Web 服务器到实时流服务，并发性是性能的核心。 几十年来，C++、Java 和 Python 等传统编程语言依赖操作系统的本机线程模型来处理并发任务。然而，当 Google 在 2000 年代末设计 Go（Golang）时，他们走了一条完全不同的道路。 Go 没有暴露原始操作系统线程，而是引入了 Goroutines 和专门的 M:N Scheduler。 在本文中，我们将研究传统线程模型的架构限制，并探讨为什么 Go 的并发设计显着更高效、可扩展且对开发人员友好。 1. 传统线程的瓶颈（1:1 模型） 大多数传统的运行时系统使用 1:1 线程模型。在此模型中，用户空间代码中创建的每个线程都直接映射到由操作系统 (OS) 管理的一个内核空间线程。 虽然简单，但这种 1:1 映射引入了三个关键瓶颈： A. 内存开销（大堆栈大小） 操作系统线程是一种重资源。默认情况下，操作系统为每个线程分配固定的连续堆栈大小（通常为 1MB 到 8MB）。 如果您想要处理 10,000 个并发连接，则仅用于线程堆栈内存就需要 10GB 到 80GB RAM 来分配 10,000 个操作系统线程。 这使得在高连接数下处理高并发性变得极其昂贵，并且在标准服务器硬件上几乎不可能。 B. 高上下文切换成本 当操作系统将执行从一个线程切换到另一个线程时，它会执行上下文切换。由于操作系统线程由内核管理，因此上下文切换需要跨越用户-内核边界。 CPU 必须： 保存当前寄存器的状态。 刷新 CPU 高速缓存线并更新页表（转换后备缓冲区）。 跳转到内核模式，选择下一个线程，并加载其保存的状态。 转换回用户模式。 整个往返大约需要 1 到 2 微秒，这意味着数百或数千个 CPU 周期纯粹用于管理开销，而不是执行实际的业务逻辑。