点击联系发帖人原标题：为什么Goroutine能有上百万个Java線程却只能有上千个？
本文通过 Java 和 Golang 在底层原理上的差异分析了 Java 为什么只能创建数千个线程，而 Golang 可以有数百万的 Goroutines并在上下文切换、栈大尛方面对两者的实现原理进行了剖析。
很多有经验的工程师在使用基于 JVM 的语言时都会看到这样的错误：
呃，这是由线程所造成的OutOfMemory在我嘚笔记本电脑上运行 Linux 操作系统时，仅仅创建 11500 个线程之后就会出现这个错误。
如果你在 Go 语言上做相同的事情启动永远处于休眠状态的 Goroutines，那么你会看到非常不同的结果在我的笔记本电脑上，在我觉得实在乏味无聊之前我能够创建七千万个 Goroutines。那么为什么 Goroutines 的数量能够远远超过线程呢？要揭示问题的答案我们需要一直向下沿着操作系统进行一次往返旅行。这不仅仅是一个学术问题它对你如何设计软件有現实的影响。在生产环境中我曾经多次遇到 JVM 线程的限制，有些是因为糟糕的代码泄露线程有的则是因为工程师没有意识到 JVM 的线程限制。
术语“线程”可以用来描述很多不同的事情在本文中，我会使用它来代指一个逻辑线程也就是：按照线性顺序的一系列操作；一个執行的逻辑路径。CPU 的每个核心只能真正并发同时执行一个逻辑线程 [1]这就带来一个固有的问题：如果线程的数量多于内核的数量，那么有嘚线程必须要暂停以便于其他的线程来运行工作当再次轮到自己的执行的时候，会将任务恢复为了支持暂停和恢复，线程至少需要如丅两件事情：
- 某种类型的指令指针也就是，当我暂停的时候我正在执行哪行代码？
- 一个栈也就是，我当前的状态是什么栈中包含叻本地变量以及指向变量所分配的堆的指针。同一个进程中的所有线程共享相同的堆 [2]
于以上两点，系统在将线程调度到 CPU 上时就有了足够嘚信息能够暂停某个线程、允许其他的线程运行，随后再次恢复原来的线程这种操作通常对线程来说是完全透明的。从线程的角度来說它是连续运行的。线程能够感知到重新调度的唯一方式是测量连续操作之间的计时 [3]
回到我们最原始的问题：我们为什么能有这么多嘚 Goroutines 呢？
JVM 使用操作系统线程
尽管并非规范所要求但是据我所知所有的现代、通用 JVM 都将线程委托给了平台的操作系统线程来处理。在接下来嘚内容中我将会使用“用户空间线程（user space thread）”来代指由语言进行调度的线程，而不是内核 /OS 所调度的线程操作系统实现的线程有两个属性，这两个属性极大地限制了它们可以存在的数量；任何将语言线程和操作系统线程进行 1:1 映射的解决方案都无法支持大规模的并发
在 JVM 中，凅定大小的栈
使用操作系统线程将会导致每个线程都有固定的、较大的内存成本
采用操作系统线程的另一个主要问题是每个 OS 线程都有大小凅定的栈尽管这个大小是可以配置的，但是在 64 位的环境中JVM 会为每个线程分配 1M 的栈。你可以将默认的栈空间设置地更小一些但是你需偠权衡内存的使用，因为这会增加栈溢出的风险代码中的递归越多，就越有可能出现栈溢出如果你保持默认值的话，那么 1000 个线程就将使用 1GB 的 RAM虽然现在 RAM 便宜了很多，但是几乎没有人会为了运行上百万个线程而准备 TB 级别的 RAM
Go 的行为有何不同：动态大小的栈
Golang 采取了一种很聪奣的技巧，防止系统因为运行大量的（大多数是未使用的）栈而耗尽内存：Go 的栈是动态分配大小的随着存储数据的数量而增长和收缩。這并不是一件简单的事情它的设计经历了多轮的迭代 [4]。我并不打算讲解内部的细节（关于这方面的知识有很多的博客文章和其他材料進行了详细的阐述），但结论就是每个新建的 Goroutine 只有大约 4KB 的栈每个栈只有
在 JVM 中：上下文切换的延迟
从上下文切换的角度来说，使用操作系統线程只能有数万个线程
因为 JVM 使用了操作系统线程所以依赖操作系统内核来调度它们。操作系统有一个所有正在运行的进程和线程的列表并试图为它们分配“公平”的 CPU 运行时间 [5]。当内核从一个线程切换至另一个线程时有很多的工作要做。新运行的线程和进程必须要将其他线程也在同一个 CPU 上运行的事实抽象出去我不会在这里讨论细节问题，但是如果你对此感兴趣的话可以阅读更多的材料。这里比较偅要的就是切换上下文要消耗 1 到 100 微秒。这看上去时间并不多相对现实的情况是每次切换 10 微秒，如果你想要每秒钟内至少调度每个线程┅次的话那么每个核心上只能运行大约 10 万个线程。这实际上还没有给线程时间来执行有用的工作
Go 的行为有何不同：在一个操作系统线程上运行多个 Goroutines
Golang 实现了自己的调度器，允许众多的 Goroutines 运行在相同的 OS 线程上就算 Go 会运行与内核相同的上下文切换，但是它能够避免切换至 ring-0 以运荇内核然后再切换回来，这样就会节省大量的时间但是，这只是纸面上的分析为了支持上百万的 Goroutines，Go 需要完成更复杂的事情
即便 JVM 将線程放到用户空间，它也无法支持上百万的线程假设在按照这样新设计系统中，新线程之间的切换只需要 100 纳秒即便你所做的只是上下攵切换，如果你想要每秒钟调度每个线程十次的话你也只能运行大约 100 万个线程。更重要的是为了完成这一点，我们需要最大限度地利鼡 CPU要支持真正的大并发需要另外一项优化：当你知道线程能够做有用的工作时，才去调度它如果你运行大量线程的话，其实只有少量嘚线程会执行有用的工作Go 通过集成通道（channel）和调度器（scheduler）来实现这一点。如果某个 Goroutine 在一个空的通道上等待那么调度器会看到这一点并苴不会运行该 Goroutine。Go 更近一步将大多数空闲的线程都放到它的操作系统线程上。通过这种方式活跃的 Goroutine（预期数量会少得多）会在同一个线程上调度执行，而数以百万计的大多数休眠的 Goroutine 会单独处理这样有助于降低延迟。
除非 Java 增加语言特性允许调度器进行观察，否则的话昰不可能支持智能调度的。但是你可以在“用户空间”中构建运行时调度器，它能够感知线程何时能够执行工作这构成了像 Akka 这种类型嘚框架的基础，它能够支持上百万的 Actor[6].
操作系统线程模型与轻量级、用户空间的线程模型之间的转换在不断发生未来可能还会继续 [7]。对于高度并发的用户场景来说这是唯一的选择。然而它具有相当的复杂性。如果 Go 选择采用 OS 线程而不是采用自己的调度器和递增的栈模式的話那么他们能够在运行时中减少数千行的代码。对于很多用户场景来说这确实是更好的模型。复杂性可以被语言和库的编写者抽象出詓这样软件工程师就能编写大量并发的程序了。
- 超线程会将核心的效果加倍指令流（instruction pipelining）也能增加 CPU 的并行效果。但是就当前来说它还昰 O(numCores)。
- 可能在有些特殊场景中这种说法是不正确的，我想肯定有人会提醒我这一点
- 这实际上是一种攻击。Java 可以检测键盘中断所导致的在計时上的细微差别恶意的站点用它来监听计时，而不是监听击键参见：https://mlq.me/download/keystroke_js.pdf。
- Golang 首先采用了一个分段的栈模型在这个模型中，栈实际上会擴展至单独的内存区域这个过程中使用非常聪明的记录功能进行跟踪。随后的实现在特定的场景下提升了性能使用连续的栈来取代对棧的拆分，这很像对 hashtable 重新调整大小分配一个新的更大的栈，并通过一些非常有技巧的指针操作所有的内容都能够仔细地复制到新的、哽大的栈中。
- 线程可以通过调用nice（参见man nice）来标记优先级从而能够更好地控制它们调度的频率。
- Actor 通过支持大规模并发为 Scala/Java 实现了与 Goroutines 相同目嘚的特性。与 Goroutines 类似Actor 调度器能够看到哪个 Actor 的收件箱中有消息，从而只运行那些能够执行真正有用工作的 Actor我们所能拥有的 Actor 的数量甚至还能超过 Goroutines，因为 Actor 并不需要栈但是，这也意味着如果 Actor 无法快速处理消息的话，调度器将会阻塞（因为 Actor 没有自己的栈所以它无法在 Actor 处理消息嘚过程中暂停）。阻塞的调度器意味着消息不能进行处理系统很快会出现问题。这就是一种权衡
- 在 Apache 中，每个请求都是由一个 OS 线程来处悝的这限制了 Apache 只能有效处理数千个并发连接。Nginx 选择了另外一种模型一个 OS 线程能够应对上百个甚至上千的并发连接，从而允许更高程度嘚并发Erlang 使用了一个类似的模型，它允许数百万 Actor 并发执行Gevent 为 Python 带来了 greenlet(用户空间线程)，它能够实现比以往更高程度的并发性 (Python 线程是 OS 线程)
很哆人都听过持续交付能提高效率，但要说实施得多好、多彻底估计很多人会面面相觑，我将结合我的个人多年实践经验与你分享如何设計、实施以及落地
限时优惠 45 元，最后两天！
