通过消息重排自动检测 Go 程序中的并发缺陷
作者：互联网
背景
Go 是由 Google 发明的工业级编程语言，当时Google设计Go的目的是编写安全高效的并发程序。最近几年来，Go 快速普及，已经成为世界上最受开发者喜爱的编程语言之一。开发者们用 Go 编写了很多工业界的基础架构软件，比如 Docker，Kubernetes，和 gRPC等。
为了更加方便地编写并发程序，Go 有许多内置特性，比如轻量级的线程（ goroutines）和 信道（channels），并且推荐开发者使用信道发送消息的方式进行goroutines之间的通信。
但遗憾的是，用Go来编写正确的并发程序依然很困难，并发缺陷（concurrency bugs）仍然在Go程序中广泛存在。而且最近的一项研究还表明，错误地使用信道也会导致并发缺陷。在某些情况下，使用信道可能比使用锁（mutexes）更容易出错。
现有的检测技术
由于目前已有的检测方法大多是为传统的编程语言（例如C/C++，Java）而设计建造的，只能监控锁和共享内存使用，并不能监控信道，也无法检测错误使用信道而导致的缺陷，因此现有的缺陷检测技术并不能有效发现Go程序中的并发缺陷，尤其是那些由于错误的消息传递而导致的缺陷。
此外，现有的model checking技术虽然可以系统地检查所有可能的消息顺序，从而发现分布式系统中的并发缺陷。但因为只有极少数的消息顺序能够触发并发缺陷，因此通过穷举所有消息顺序来找缺陷是非常低效的。
目前为Go设计的静态检测器，只能检测有限类型的缺陷，不能分析大规模代码，而且会产生大量的误报和漏报。而为Go设计的动态检测器，则只能检测已经触发的缺陷。它们既无法改变程序的运行状态，也不能增加触发缺陷发生的可能性，因此会漏报许多并发缺陷。
Go的并发缺陷案例
在这里展示一个来自Docker的信道相关并发缺陷，来更清楚地说明为什么现有的检测技术无法有效地发现Go程序中的并发缺陷。
在如图所示的案例中，父goroutine在第4行调用了一个类方法。被调用的函数是在17-31行的方法Watch（）。方法Watch（）在18，19行创建了两个没有缓冲区的信道 ch 和 errCh，然后在22行创建了一个子goroutine，最后在30行返回了这两个新创建的信道。
子goroutine在23行调用了s.fetch()，检查了返回值，根据检查结果向errCh（25行）或者ch（27行）中发送一条消息。同时，父goroutine阻塞在了select语句（5-14行），来等待在Fire（），errCh，或者ch中传来的消息。其中来自Fire（）消息会在1秒钟之后收到。
如果Fire（）的消息先到达，父goroutine会选择第一个case，记录超时信息并从当前函数返回。在这之后，除了子goroutine，没有其他的goroutine可以访问ch或者errCh，因为没有其他的goroutine可以在这两个信道中收取信息。
由于errCh和ch都是没有缓冲区的信道，在它们上执行的发送操作会阻塞发送goroutine，一直到另外的goroutine在它们上执行接收操作。所以子goroutine会永远卡在25行或者27行的发送操作，导致goroutine泄漏。
这个例子展示了在Go程序中成功检测到信道相关并发缺陷的难度。在这个案例中，检测器必须同时满足2个条件，才能成功地检测到这个并发缺陷。
首先，这个缺陷只有当来自Fire（）的消息比其他两个信道的消息先一步到达才会触发（条件1）。与此同时，检测器还需要有能力推断，没有别的goroutine可以访问ch或者errCh，因此没有别的goroutine可以解锁发送操作（条件2）。
在现有的检测技术中，静态技术无法推断第4行调用的是17行的Watch（）函数，所以它们无法判断是不是还有其他的goroutine可以解锁子goroutine（无法满足条件2）。
此外，在测试中，我们发现来自Fire（）的消息从来没有先到达过，所以动态监测技术也会漏报这个缺陷（无法满足条件1）。
新的动态分析工具Gfuzz
为此，我们提出了一个新的动态分析工具GFuzz，用来快速地检测Go程序中信道相关的并发缺陷。
GFuzz可以检测阻塞缺陷（blocking bugs：一个或多个goroutine在执行中发生阻塞无法继续进行）和非阻塞缺陷（non-blocking bugs：所有goroutine都可以结束但是产生了一些非期望的结果，比如panic）。
GFuzz的设计围绕着Go程序中的并发消息。在Go程序中，并发消息的处理顺序是不确定的，开发者必须保证Go程序在所有可能的顺序下都能正确执行。但是，考虑到可能的处理顺序数量庞大，开发者在有限的时间和精力里，非常容易忽略一些顺序，从而导致并发缺陷。
GFuzz通过改变测试程序中并发消息的处理顺序，来增加阻塞缺陷和非阻塞缺陷的触发几率。同时，它也会监控程序的执行状态来捕捉触发的阻塞缺陷。
我们再来看这段Docker中的并发缺陷和修复补丁。
从理论上来说，第6行、第8行和第12行的并发消息，到达的顺序是不确定的。第6行的消息可以比第8行的、或者比第12行的更快或更慢到达。不管是哪一种情况，这段代码都应该能正确运行。
然而开发者没有考虑到第6行Fire（）消息先到达的情况，导致前文提到的阻塞缺陷。通过改变并发消息的处理顺序，GFuzz能分析这两种情况并且检测出缺陷。
Gfuzz设计过程中的挑战
尽管GFuzz的设计思路听起来非常直截了当，但要构建一个在实际操作中可顺畅使用的工具，我们依然要应对一系列的挑战。
第1个问题：GFuzz如何辨识并发消息？
如果没有识别并发消息，GFuzz可能会强制一个和已有的happens-before消息顺序相冲突的顺序，从而导致在现实中不可能发生的死锁。
在这里，我们采用了一个简单的方法来识别并发消息。
在同一个select下，所有的信道操作是可以同时发生的，因此这些信道操作处理的消息是并发的。改变这些消息的处理顺序，可以在保持程序原意不变的基础上，保证程序执行路径的改变。
为了强制测试程序按照具体的顺序来处理消息，GFuzz会把每个select都转换成一种特别的形式，以保证某一个case被优先处理。同时，GFuzz还提供了一个超时机制去避免死锁。
第2个问题，如何发现哪种消息顺序更容易触发缺陷，并且提高它们的分析优先级？
消息的处理顺序可能有无限多个，穷举这些消息是不现实的。我们使用了模糊测试（fuzzing）的思路，从已经分析过的消息顺序出发，去生成新的消息处理顺序，并且根据强制消息顺序时测试程序的执行反馈，来发现更可疑和更容易触发缺陷的顺序。
我们设计了一个公式来评价每个消息处理顺序的可疑程度，然后根据公式的计算结果来确定顺序的优先级。
第3个问题：如何确定一个与信道相关的阻塞缺陷已经触发了？
当一个goroutine阻塞在信道操作上时，其他任何可以使用这个信道的goroutine都能对其解锁。如果没有小心地对测试程序的执行状态进行检查，很容易产生漏报或者误报。
为了解决这个问题，在GFuzz动态监控测试程序执行时，信道引用在goroutine之间的传递。Gfuzz会根据这些信息来确定一个阻塞在信道操作的goroutine是不是能被其他goroutine解锁，从而进行阻塞缺陷的检测。
Gfuzz系统概述和实验评估
GFuzz会用完整的Go程序或者单元测试作为入口，来检测那些误用channel而导致的并发错误。在这个过程中，GFuzz通过持续生成新的消息顺序，来监测程序执行状态，同时筛选可疑顺序来加速寻找错误的过程。下图展示了GFuzz的系统概述。
GFuzz可以作为线下的测试工具，和已有的程序输入或者单元测试配合使用。启动GFuzz之后，它可以自动探索测试程序的执行状态，来发现之前未知的与信道相关的并发缺陷。
我们对GFuzz进行了实验和评估，评估结果如图所示。其中LoC是源代码行数，Test是用于我们实验的单元测试数量。
在“Detected New Bugs（发现新的缺陷）”下面的各列中，下角标b代表阻塞错误，NBK代表非阻塞错误；“-”代表没有错误；GFuzz3代表在前三个小时里找到的错误数量。“Overheads”这一列代表sanitizer的额外开销，“/”代表并不适用。
我们用了包括 Docker、Kubernetes 和 gRPC在内的7个流行的Go开源软件对GFuzz进行了评估。GFuzz 总共发现了 184 个以前未知的缺陷，包括 170 个阻塞错误和 14 个非阻塞错误，并产生12 个误报。
我们已经向软件开发者报告了所有错误。到目前为止，根据我们的报告，开发者已经确认了 124 个错误并修复了其中的 67 个。
此外，我们系统地将 GFuzz 与最先进的静态 Go 并发缺陷检测器 GCatch 进行了比较。GFuzz 在三个小时内发现的缺陷数量要显著地多于 GCatch发现的全部缺陷，这确认了 GFuzz 确实推进了 Go 并发缺陷检测的进展。
结论
总的来说，我们做出了以下3个贡献。
• 我们提出了利用消息重排来提高 Go 程序中并发缺陷的触发概率。
• 我们实现了GFuzz，它可以通过消息重排、顺序优先级的指定和对测试程序的动态检测，来有效地检测和发现与信道相关的并发错误。
• 我们进行了详细的实验来评估GFuzz。GFuzz 在大型开源Go软件中检测到 184 个以前从未被发现过的与信道相关的错误。
标签：GFuzz,自动检测,goroutine,并发,信道,重排,Go,缺陷 来源： https://www.cnblogs.com/ccwcxxjs/p/16189802.html