标签 C 下的文章

后端程序员一定要看的语言大比拼:Java vs. Go vs. Rust

这是JavaGo和Rust之间的比较。这不是基准测试,更多是对可执行文件大小、内存使用率、CPU使用率、运行时要求等的比较,当然还有一个小的基准测试,可以看到每秒处理的请求数量,我将尝试对这些数字进行有意义的解读。

为了尝试尽可能公平比较,我在此比较中使用每种语言编写了一个Web服务。Web服务非常简单,它提供了三个REST服务端点(endpoint)。


Web服务提供的服务端点

这三个Web服务的代码仓库托管在github上

编译后的二进制文件尺寸

有关如何构建二进制文件的一些信息。对于Java,我使用maven-shade-pluginmvn package命令将所有内容构建到一个大的jar中。对于Go,我使用go build。最后,我使用了cargo build –release构建Rust服务的二进制文件。


每个程序的大小(以兆字节为单位)

编译后的文件大小还取决于所选的库/依赖项,因此,如果依赖项的身躯臃肿,则编译后的程序也将难以幸免。在我的特定情况下,针对我选择的特定库,以上是程序编译后的大小。

在后续的一个单独小节中,我会把这三个程序都构建并打包为docker镜像,并列出它们的大小,以显示每种语言所需的运行时开销。下面有更多详细信息。

内存使用情况

空闲状态


每个应用程序在内存空闲时的内存使用情况

什么?Go和Rust版本显示空闲时内存占用量的条形图在哪里?好了,它们在那里,只有JVM启动的程序在空闲状态时消耗160 MB以上的内存,它什么也没做。Go应用程序仅使用0.86 MB,Rust应用也仅使用了0.36 MB。这是一个巨大的差异!在这里,Java使用的内存比Go和Rust应用使用的内存高出两个数量级,只是空占着内存却什么都不做。那是巨大的资源浪费。

服务REST请求

让我们使用wrk发起访问API的请求,并观察内存和CPU使用情况,以及在我的计算机上三个版本程序的每个端点每秒处理的请求数。

wrk -t2 -c400 -d30s http://127.0.0.1:8080/hello
wrk -t2 -c400 -d30s http://127.0.0.1:8080/greeting/Jane
wrk -t2 -c400 -d30s http://127.0.0.1:8080/fibonacci/35

上面的wrk命令使用两个线程并在连接池中保持400个打开的连接,并重复调用GET端点,持续30秒。这里我仅使用两个线程,因为wrk和被测程序都在同一台计算机上运行,所以我不希望它们在可用资源(尤其是CPU)上相互竞争(太多)。

每个Web服务都经过单独测试,并且在每次运行之间都重新启动了Web服务。

以下是该程序的每个版本的三个运行中的最佳结果。

  • /hello

该端点返回Hello,World!信息。它分配字符串“ Hello,World!” 并将其序列化并以JSON格式返回。


/hello端点的CPU使用率


/hello端点的内存使用情况


/hello端点处理的每秒请求数

  • /greeting/{name}

该端点接受一个段路径参数{name},然后格式化字符串“Hello,{name}!”,序列化并以JSON格式的问候消息返回。


/greeting端点的CPU使用率


/greeting端点的内存使用情况


/greeting端点处理的每秒请求数

  • /fibonacci/{number}

该端点接受一个段路径参数{number},并返回序列化为JSON格式的斐波纳契数和输入数。

对于这个特定的端点,我选择以递归形式实现它。我毫不怀疑,迭代实现会产生更好的性能结果,并且出于生产目的,应该选择一种迭代形式,但是在生产代码中,有些情况下必须使用递归(并非专门用于计算第n个斐波那契数 )。为此,我希望该实现涉及大量CPU栈分配。


/fibonacci端点的CPU使用率


/fibonacci端点的内存使用情况


/fibonacci端点处理的每秒请求数

在Fibonacci端点测试期间,Java是唯一一个有150个请求超时的实现,如下面wrk的输出所示。


超时时间


/fibonacci端点的延迟

运行时大小

为了模拟现实世界中的云原生应用程序,并避免“它仅可以在我的机器上运行!”,我分别为这三个应用程序创建了一个docker镜像。

Docker文件的源代码包含在代码库相应程序文件夹下。

作为我使用过的Java应用程序的基础镜像,openjdk:8-jre-alpine是已知大小最小的镜像之一,但是,这附带了一些警告,这些警告可能适用于您的应用程序,也可能不适用于您的应用程序,主要是alpine镜像在处理环境变量名称方面不是posix兼容的,因此您不能在Dockerfile中使用ENV中的(点)字符(不过这没什么大不了的),另一个是alpine Linux镜像是使用musl libc而不是glibc编译的,这意味着如果您的应用程序依赖于需要glibc,它可能无法正常工作。不过,在这里,alpine镜像工作是正常的。

至于应用程序的Go版本和Rust版本,我已经对其进行了静态编译,这意味着它们不希望在运行时镜像中存在libc(glibc,musl…等),这也意味着它们不需要运行OS的基本镜像。因此,我使用了scratch docker镜像,这是一个no-op镜像,以零开销托管已编译的可执行文件。

我使用的Docker镜像的命名约定为{lang}/webservice。该应用程序的Java,Go和Rust版本的镜像大小分别为113、8.68和4.24 MB。


最终Docker镜像大小

结论


三种语言的比较

在得出任何结论之前,我想指出这三种语言之间的关系。Java和Go都是支持垃圾回收的语言,但是Java会提前编译为在JVM上运行的字节码。启动Java应用程序时,JIT编译器会被调用以通过将字节码编译为本地代码来优化字节码,以提高应用程序的性能。

Go和Rust都提前编译为本地代码,并且在运行时不会进行进一步的优化。

Java和Go都是支持垃圾收集的语言,具有STW(停止世界)的副作用。这意味着,每当垃圾收集器运行时,它将停止应用程序,进行垃圾收集,并在完成后从停止的地方恢复应用程序。大多数垃圾收集器需要停止运行,但是有些实现似乎不需要这样做。

当Java语言在90年代创建时,其最大的卖点之一是一次编写,可在任何地方运行。当时这非常好,因为市场上没有很多虚拟化解决方案。如今,大多数CPU支持虚拟化,这种虚拟化抵消了使用某种语言进行开发的诱惑(该语言承诺可以运行在任何平台上)。Docker和其他解决方案以更为低廉的代价提供虚拟化。

在整个测试中,应用程序的Java版本比Go或Rust对应版本消耗了更多的内存,在前两个测试中,Java使用的内存大约增加了8000%。这意味着对于实际应用程序,Java应用程序的运行成本会更高。

对于前两个测试,Go应用程序使用的CPU比Java少20%,同时处理比java版多出38%的请求。另一方面,Rust版本使用的CPU比Go减少了57%,而处理的请求却增加了13%。

第三次测试在设计上是占用大量CPU的资源,因此我想从中挤出CPU的每一分。Go和Rust都比Java多使用了1%的CPU。而且我认为,如果wrk不是在同一台计算机上运行,那么这三个版本都会使CPU达到100%的上限值。在内存方面,Java使用的内存比Go和Rust多2000%。Java可以处理的请求比Go多出20%,而Rust可以处理的请求比Java多出15%。

在撰写本文时,Java编程语言已经存在了将近30年,这使得在市场上寻找Java开发人员变得相对容易。另一方面,Go和Rust都是相对较新的语言,因此与Java相比,自然而然的开发人员的数量更少些。不过,Go和Rust都拥有很大的吸引力,许多开发人员正在将它们用于新项目,并且有许多使用Go和Rust的生产中正在运行的项目,因为简单地说,就资源而言,它们比Java更有效。

在编写本文的程序时,我同时学习了Go和Rust。就我而言,Go的学习曲线很短,因为它是一种相对容易掌握的语言,并且与其他语言相比语法很小。我只用了几天就用Go编写了程序。关于Go需要注意的一件事是编译速度,我不得不承认,与Java/C/C++/Rust等其他语言相比,它的速度非常快。该程序的Rust版本花了我大约一个星期的时间来完成,我不得不说,大部分时间都花在弄清borrow checker向我要什么上。Rust具有严格的所有权规则,但是一旦掌握了Rust的所有权和借用概念,编译器错误消息就会突然变得更加有意义。违反借阅检查规则时,Rust编译器对您大吼的原因是因为编译器希望在编译时证明已分配内存的寿命和所有权。这样做可以保证程序的安全性(例如:没有悬挂的指针,除非使用了不安全(unsafe)的代码逃离检查),并且在编译时确定了释放位置,从而消除了垃圾收集器的需求和运行时成本。当然,这是以学习Rust的所有权系统为代价的。

在竞争方面,我认为Go是Java(通常是JVM语言)的直接竞争对手,但不是Rust的竞争对手。另一方面,Rust是Java,Go,C和C ++的重要竞争对手。

由于他们的效率,我看到了自己将会在Go和Rust中编写更多的程序,但是很可能在Rust中编写更多的程序。两者都非常适合Web服务,CLI,系统程序(..etc)开发。但是,Rust比Go具有根本优势。它不是垃圾收集的语言,与C和C++相比,它可以安全地编写代码。例如,Go并不是特别适合用于编写OS内核,而这里又是Rust的亮点,并与C/C ++竞争,因为它们是使用OS编写的长期存在和事实上的语言。Rust与C/C++竞争的另一种方式在嵌入式世界中,我将继续进行讨论。

感谢您的阅读!

本文翻译自《Comparison between Java, Go, and Rust》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

图解Go运行时调度器

本文翻译自《Illustrated Tales of Go Runtime Scheduler》

译注:原文章结构有些乱,笔者自行在译文中增加了一些分级标题,让结构显得更清晰一些:)。

goroutines形式的Go并发是编写现代并发软件的一种非常方便的方法,但是您的Go程序是如何高效地运行这些goroutines的呢?

在这篇文章中,我们将深入Go运行时底层,从设计角度了解Go运行时调度程序是如何实现其魔法的,并运用这些原理去解释在Go性能调试过程中产生的Go调度程序跟踪信息

所有的工程奇迹都源于需要。因此,要了解为什么需要一个Go运行时调度程序以及它是如何工作的,我们可以让时间回到操作系统兴起的那个时代,回顾操作系统的历史可以使我们深入的了解问题的根源。如果不了解问题的根源,就没有解决它的希望。这就是历史所能做的。

一. 操作系统的历史

  1. 单用户(无操作系统)。
  2. 批处理,独占系统,直到运行完成。
  3. 多道程序(译注:允许多个程序同时进入内存并运行)

多道程序的目的是使CPU和I/O重叠(overlap)。(译注:多道程序出现之前,当操作系统执行I/O操作时,CPU是空闲的;多道程序的引入实现了在一个程序占用CPU的时候,另一个程序在执行I/O操作)

那怎么实现多道程序(的CPU与I/O重叠)呢?两种方式:多道批处理系统和分时系统。

  • 多道批处理系统

    • IBM OS/MFT(具有固定数量的任务的多道程序)
    • IBM OS/MVT(具有可变数量的任务的多道程序)在这里,每个作业(job)仅获得其所需的内存量。随着job的进出,内存的划分会发生变化。
  • 分时

    • 这是一种多道程序设计,可以在作业之间快速切换。决定何时切换以及切换到哪个作业的过程就称为调度(scheduling)

当前,大多数操作系统使用分时调度程序

那么这些调度程序将用来调度什么实体(entity)呢?

  • 不同的正在执行的程序(即进程process)
  • 或作为进程子集存在使用CPU的基本单元:线程

但是在这些实体的切换是有代价的。

  • 调度成本

img{512x368}

图: 进程和线程的状态变量

因此,使用一个包含多个线程的进程的效率更高,因为进程创建既耗时又耗费资源。但是随后出现了多线程问题:C10k成为主要问题。

例如,如果将调度周期定为10ms(毫秒),并且有2个线程,则每个线程将分别获得5ms。如果您有5个线程,则每个线程将获得2ms。但是,如果有1000个线程怎么办?给每个线程一个10μs(微秒)的时间片?错,这样做很愚蠢,因为您将花费大量时间进行上下文切换,但是真正要完成的工作却进展缓慢或停滞不前。

您需要限制时间片的长度。在最后一种情况下,如果最小时间片为2ms并且有1000个线程,则调度周期需要增加到2s(10002ms)。如果有10,000个线程,则调度程序周期为20秒(100002ms)。在这个简单的示例中,如果每个线程都将分配给它的时间片用完,那么所有线程都完成一次运行需要20秒。因此,我们需要一些可以使并发成本降低而又不会造成过多开销的东西。

  • 用户层线程
    • 线程完全由运行时系统(用户级库)管理。
    • 理想情况下,快速高效:切换线程的代价不比函数调用多多少。
    • 操作系统内核对用户层线程一无所知,并像对待单线程进程(single-threaded process)一样对其进行管理。

在Go中,我们知道这样的用户层线程被称为“Goroutine”。

  • Goroutine

img{512x368}

图: goroutine vs. 线程

goroutine是由Go运行时管理的轻量级线程(lightweight thread)。要启动一个新的goroutine,只需在函数前面使用go关键字:go add(a, b)

  • Goroutine之旅
func main() {
    var wg sync.WaitGroup
    for i := 0; i <= 10; i++ {
        wg.Add(1)
        go func(i int) {
        defer wg.Done()
        fmt.Printf("loop i is - %d\n", i)
        }(i)
    }
    wg.Wait()
    fmt.Println("Hello, Welcome to Go")
}

https://play.golang.org/p/73lESLiva0A

您能猜出上面代码片段的输出吗?

loop i is - 10
loop i is - 0
loop i is - 1
loop i is - 2
loop i is - 3
loop i is - 4
loop i is - 5
loop i is - 6
loop i is - 7
loop i is - 8
loop i is - 9
Hello, Welcome to Go

如果我们看一下输出的一种组合,你可能马上就会有两个问题:

  • 11个goroutine如何并行运行?魔法?
  • goroutine以什么顺序运行?

img{512x368}

图:gopher版奇异博士

上面的这两个提问给我们带来了问题。

  • 问题概述
    • 如何将这些goroutines分配到在CPU处理器上运行的多个操作系统线程上运行?
    • 这些goroutines应该以什么顺序运行才能保证公平?

本文后续的讨论将主要围绕Go运行时调度程序从设计角度如何解决这些问题。但是,与所有问题一样,我们的讨论也需要定义一个明确的边界。否则,问题陈述可能太含糊,无法形成结论。调度程序可能针对多个目标中的一个或多个,对于我们来说,我们将自己限制在以下需求之内:

  1. 应该是并行、可扩展且公平的。
  2. 每个进程应可扩展到数百万个goroutine(C10M
  3. 内存利用率高。(RAM很便宜,但不是免费的。)
  4. 系统调用不应导致性能下降。(最大化吞吐量,最小化等待时间)

让我们开始为调度程序建模,以逐步解决这些问题。

二. Goroutine调度程序模型 (译者自行加的标题)

1. 模型概述(译者自行加的标题)

a) 一个线程执行一个Goroutine

局限性:

  • 并行和可扩展
    • 并行(是的)
    • 可扩展(不是真的)
  • 每个进程不能扩展到数百万个goroutine(C10M)。

b) M:N线程—混合线程

M个操作系统内核线程执行N个“goroutine”

img{512x368}

图: M个内核线程执行N个goroutine

实际执行代码和并行执行都需要内核线程。但是线程创建起来很昂贵,因此我们将N个goroutines映射到M个内核线程上去执行。Goroutine是Go代码,因此我们可以完全控制它。而且它在用户空间中,创建起来很便宜。

但是由于操作系统对goroutine一无所知。因此每个goroutine都有一个状态,以帮助调度器根据goroutine状态知道要运行哪个goroutine。与内核线程的状态信息相比,goroutine的状态信息很小,因此goroutine的上下文切换变得非常快。

  • 正在运行(Running) – 当前在内核线程上运行的goroutine。
  • 可运行(Runnable) – 等待内核线程来运行的goroutine。
  • 已阻塞(Blocked) – 等待某些条件的Goroutine(例如,阻塞在channel操作,系统调用,互斥锁上的goroutine)

img{512x368}

图: 2个线程同时运行2个goroutine

因此,Go运行时调度器通过将N个Goroutine多路复用到M个内核线程的方式来管理处于各种不同状态的goroutines。

2. 简单的M:N调度器

在我们简单的M:N调度器中,我们有一个全局运行队列(global run queue),某些操作将一个新的goroutine放入运行队列。M个内核线程访问调度程序从“运行队列”中获取并运行goroutine。多个线程正在尝试访问相同的内存区域,因此使用互斥锁来同步对该运行队列的访问。

img{512x368}

图: 简单的M:N调度器

但是,那些已阻塞的goroutine在哪里?

下面是goroutine可能会阻塞的情况:

  1. 在channel上发送和接收
  2. 网络I/O操作
  3. 阻塞的系统调用
  4. 使用定时器
  5. 使用互斥锁

那么我们将这些阻塞的goroutine放在哪里呢?— 将这些阻塞的goroutine放置在哪里的设计决策基本上是围绕一个基本原理进行的:

阻塞的goroutine不应阻塞底层内核线程!(避免线程上下文切换的成本)

channel操作期间阻塞的Goroutine

每个channel都有一个recvq(waitq),用于存储试图从该channel读取数据而阻塞的goroutine。

Sendq(waitq)存储试图将数据发送到channel而被阻止的goroutine 。(channel实现原理:-https://codeburst.io/diving-deep-into-the-golang-channels-549fd4ed21a8)

img{512x368}

图: channel操作期间阻塞的Goroutine

channel本身会将channel操作后的未阻塞goroutine放入“运行”队列(run queue)。

img{512x368}

图: channel操作后未阻碍的goroutine

那系统调用呢?

首先,让我们看一下阻塞系统调用。系统调用会阻塞底层内核线程,因此我们无法在该线程上调度任何其他Goroutine。

隐含阻塞系统调用可降低并行度。

img{512x368}

图: 阻塞系统调用可降低并行度

一旦发生阻塞系统调用,我们无法再在M2线程上安排任何其他Goroutine运行,从而导致CPU浪费。由于我们有工作要做,但没法运行它。

恢复并行度的方法是在进入系统调用时,我们可以唤醒另一个线程,该线程将从运行队列中选择可运行的goroutine。

img{512x368}

图: 恢复并行度的方法

但是现在,系统调用完成后,我们有超额等待调度的goroutine。因此,我们不会立即运行从阻塞系统调用中返回的goroutine。我们会将其放入调度程序的运行队列中。

img{512x368}

图: 避免超额等待调度

因此,在程序运行时,线程数远大于cpu核数。尽管没有明确说明,线程数大于cpu核数,并且所有空闲线程也由运行时管理,以避免启动过多的线程。

https://golang.org/pkg/runtime/debug/#SetMaxThreads

初始设置为10,000个线程,如果超过10,000个线程,程序将崩溃。

非阻塞系统调用-将goroutine阻塞在Integrated runtime poller上 ,并释放线程以运行另一个goroutine。

img{512x368}

例如,在非阻塞I/O(例如HTTP调用)的情况下。由于资源尚未准备就绪,第一个syscall将不会成功,这将迫使Go使用network poller并将goroutine暂停。

部分net.Read函数的实现:

    n, err := syscall.Read(fd.Sysfd, p)
        if err != nil {
            n = 0
            if err == syscall.EAGAIN && fd.pd.pollable() {
                if err = fd.pd.waitRead(fd.isFile); err == nil {
                    continue
                }
            }
    }

一旦完成第一个系统调用并明确指出资源尚未准备就绪,goroutine将暂停,直到network poller通知它资源已准备就绪。在这种情况下,线程M将不会被阻塞。

Poller将基于操作系统使用select/kqueue/epoll/IOCP等机制来知道哪个文件描述符已准备好,一旦文件描述符准备好进行读取或写入,它将把goroutine放回到运行队列中。

还有一个Sysmon OS线程,如果超过10ms未轮询网络,它就将定期轮询网络,并将已就绪的G添加到队列中。

基本上所有goroutine都被阻塞在下面操作上:

  1. channel
  2. 互斥锁
  3. 网络IO
  4. 定时器

有某种队列,可以帮助调度这些goroutine。

现在,运行时拥有具有以下功能的调度程序。

  • 它可以处理并行执行(多线程)。
  • 处理阻塞系统调用和网络I/O。
  • 处理阻塞在用户级别(在channel上)的调用。

但这不是可伸缩的(scalable)。

img{512x368}

图: 使用Mutex同步全局运行队列

您可以通过Mutex同步全局运行队列,但最终会遇到一些问题,例如

  1. 缓存一致性保证的开销。
  2. 在创建,销毁和调度Goroutine G时进行激烈的锁竞争。

使用分布式调度程序解决可伸缩性问题。

分布式调度程序-每个线程一个运行队列

img{512x368}

图: 分布式运行队列的调度程序

这样,我们可以看到的直接好处是,每个线程的本地运行队列(local run queue)现在都没有使用mutex。仍然有一个带有mutex的全局运行队列,但仅在特殊情况下使用。它不会影响可伸缩性。

但是现在,我们有多个运行队列。

  1. 本地运行队列
  2. 全局运行队列
  3. 网络轮询器(network poller)

我们应该从哪里运行下一个goroutine?

在Go中,轮询顺序定义如下:
1. 本地运行队列
2. 全局运行队列
3. 网络轮询器
4. 工作偷窃(work stealing)

即首先检查本地运行队列,如果为空则检查全局运行队列,然后检查网络轮询器,最后进行“偷窃工作”。到目前为止,我们对1,2,3有了一些概述。让我们看一下“工作偷窃(work stealing)”。

工作偷窃

如果本地工作队列为空,请尝试“从其他队列中偷窃工作”

img{512x368}

图: 偷窃工作

当一个线程有太多工作要做而另一个线程空闲时,工作偷窃可以解决这个问题。在Go中,如果本地队列为空,工作偷窃将尝试满足以下条件之一。

  • 从全局队列中拉取工作。
  • 从网络轮询器中拉取工作
  • 从其他线程的本地队列中偷窃工作

到目前为止,Go运行时的调度器具有以下功能:

  • 它可以处理并行执行(使用多线程)。
  • 处理阻塞系统调用和网络I/O。
  • 处理用户级别(比如:在channel)的阻塞调用。
  • 可伸缩扩展(scalable)

但这仍不是最有效的。

还记得我们在阻塞系统调用中恢复并行度的方式吗?

img{512x368}

图: 系统调用操作

它暗示在一个系统调用中我们可以有多个内核线程(可以是10或1000),这可能会比cpu核数多很多。这个方案将最终在以下期间产生了恒定的开销:

  • 偷窃工作时,它必须同时扫描所有内核线程(空闲的和运行goroutine的)本地运行队列,并且大多数都将是空闲的。
  • 垃圾回收,内存分配器都会遇到相同的扫描问题。(https://blog.learngoprogramming.com/a-visual-guide-to-golang-memory-allocator-from-ground-up-e132258453ed)

使用M:P:N线程克服效率问题。

M:P:N(3级调度程序)— 引入逻辑处理器P

P —表示处理器,可以将其视为在线程上运行的本地调度程序

img{512x368}

图: M:P:N模型

逻辑进程P的数量始终是固定的。(默认为当前进程可以使用的逻辑CPU数量)

然后,我们将本地运行队列(LRQ)放入固定数量的逻辑处理器(P)中(译者注:而不是每个内核线程一个本地运行队列)。

img{512x368}

图: 分布式三级运行队列调度程序

Go运行时将首先根据计算机的逻辑CPU数量(或根据请求)创建固定数量的逻辑处理器P。

每个goroutine(G)将在分配了逻辑CPU(P)的OS线程(M)上运行。

所以现在我们在以下期间没有了恒定的开销:

  • 偷窃工作 -只需扫描固定数量的逻辑处理器(P)的本地运行队列。
  • 垃圾回收,内存分配器也将获得相同的好处。

使用固定逻辑处理器(P)的系统调用呢?

Go通过将它们包装在运行时中来优化系统调用(无论是否阻塞)。

img{512x368}

图: 阻塞系统调用的包装器

阻塞SYSCALL方法封装在runtime.entersyscall(SB)和 runtime.exitsyscall(SB)之间。

从字面上看,某些逻辑在进入系统调用之前被执行,而某些逻辑在系统调用返回之后执行。进行阻塞的系统调用时,此包装器将自动将P与线程M(即将执行阻塞系统调用的线程)解绑,并允许另一个线程在其上运行。

img{512x368}

图:阻塞Syscall的M交出P

这使得Go运行时可以高效地处理阻塞的系统调用,而无需增加运行队列(译注:本地运行队列数量始终是和P数量一致的)。

一旦阻塞系统调用返回,会发生什么?

  • 运行时会尝试获取之前绑定的那个P,然后继续执行。
  • 运行时尝试在P空闲列表中获取一个P并恢复执行。
  • 运行时将goroutine放在全局队列中,并将关联的M放回M空闲列表。

自旋线程和空闲线程

当M2线程在syscall返回后变得空闲时。如何处理这个空闲的M2线程。从理论上讲,如果线程完成了所需的操作,则应将其销毁,然后再安排进程中的其他线程到CPU上执行。这就是我们通常所说的操作系统中线程的“抢占式调度”。

考虑上述syscall中的情况。如果我们销毁了M2线程,而同时M3线程即将进入syscall。此时,在OS创建新的内核线程并将其调度执行之前,我们无法处理可运行的goroutine。频繁的线程前抢占操作不仅会增加OS的负载,而且对于性能要求更高的程序几乎是不可接受的。

因此,为了适当地利用操作系统的资源并防止频繁的线程抢占给操作系统带来的负担,我们不会销毁内核线程M2,而是使其执行自旋操作并以备将来使用。尽管这看起来是在浪费一些资源。但是,与线程之间的频繁抢占以及频繁的创建和销毁操作相比,“空闲线程”要付出的代价更少。

Spinning Thread(自旋线程) — 例如,在具有一个内核线程M(1)和一个逻辑处理器(P)的Go程序中,如果正在执行的M被syscall阻塞,则运行时会请求与P数量相同的“Spinning Threads”以允许等待的可运行goroutine继续执行。因此,在此期间,内核线程的数量M将大于P的数量(自旋线程+阻塞线程)。因此,即使将runtime.GOMAXPROCS的值设置为1,程序也将处于多线程状态。

调度中的公平性如何?—公平地选择下一个要执行的goroutine

与许多其他调度程序一样,Go也具有公平性约束,并且由goroutine的实现所强加,因为Runnable goroutine应该最终得到调度并运行。

这是Go Runtime Scheduler的四个典型的公平性约束:

任何运行时间超过10ms的goroutine都被标记为可抢占(软限制)。但是,抢占仅在函数执行开始处才能完成。Go当前在函数开始处中使用了由编译器插入的协作抢占点。

  • 无限循环 – 抢占(约10毫秒的时间片)- 软限制

但请小心无限循环,因为Go的调度程序不是抢先的(直到Go 1.13)。如果循环不包含任何抢占点(例如函数调用或分配内存),则它们将阻止其他goroutine的运行。一个简单的例子是:

package main

func main() {
    go println("goroutine ran")
    for {}
}

如果你运行:

GOMAXPROCS=1 go run main.go

直到Go(1.13)才可能打印该语句。由于缺少抢占点,main Goroutine将独占处理器。

  • 本地运行队列 -抢占(〜10ms时间片)- 软限制
  • 通过每61次调度就检查一次全局运行队列,可以避免全局运行队列处于“饥饿”状态。
  • 网络轮询器饥饿 后台线程会在主工作线程未轮询的情况下偶尔会轮询网络。

Go 1.14有一个新的“非合作抢占”机制。

有了这种机制,Go运行时便有了具有所有必需功能的Scheduler。

  • 它可以处理并行执行(多线程)。
  • 处理阻塞系统调用和网络I/O。
  • 处理用户级别(在channel上)的阻塞调用。
  • 可扩展
  • 高效
  • 公平

这提供了大量的并发性,并且始终尝试实现最大的利用率和最小的延迟。

现在,我们总体上对Go运行时调度程序有了一些了解,我们如何使用它?Go为我们提供了一个跟踪工具,即调度程序跟踪(scheduler trace),目的是提供有关调度行为的信息并用来调试与goroutine调度器伸缩性相关的问题。

三. 调度器跟踪

使用GODEBUG=schedtrace=DURATION环境变量运行Go程序以启用调度程序跟踪。(DURATION是以毫秒为单位的输出周期。)

img{512x368}

图:以100ms粒度对schedtrace输出采样

有关调度器跟踪的内容,Go Wiki拥有更多信息。

参考:Dmitry Vyukov的可扩展Go Scheduler设计文档和演讲 https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit

Gopher艺术作品致谢:Ashley Mcnamara。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats