Go：死锁是如何触发的？

由创作原始 Go Gopher 作品的 Renee French 为“ Go 的旅程”创作的插图。

本文基于 Go 1.14。

死锁是当 Goroutine 被阻塞而无法解除阻塞时产生的一种状态。Go 提供了一个死锁检测器，可以帮助开发人员避免陷入这种情况。

检测

让我们从创建这种情况的示例开始：

主 Goroutine 在 channel 上被阻塞，并等待另一个 Goroutine 将数据写入 channel。然而，没有其他的 Goroutine 在运行，它不能被解除阻塞。这种情况将触发死锁错误:

死锁检测器基于对应用程序创建的线程的分析。如果已创建并活动的线程数大于等待工作的线程数，则会出现死锁情况。

这个公式中不包括为监视系统而创建的线程。

在检测到死锁时将创建四个线程：

• 一个用于主 goroutine，启动程序的那个。

• 一个叫做 sysmon，用于监视系统。

• 一个专用于垃圾收集器的 Goroutine 启动的。

• 在初始化过程中阻塞主 Goroutine 时创建的一个线程。由于此 Goroutine 被锁定在它的线程上，因此 Go 需要创建一个新的 Goroutine 来为其他 Goroutine 提供运行时间。

每次调用死锁检测器时，也可以通过一些调试信息将其可视化：

每当线程空闲时，就会通知检测器。调试的每一行显示空闲线程的递增数量。当空闲线程数等于活动线程数减去系统线程数时，就会发生死锁。在本例中，我们有三个空闲线程和三个活动线程（四个线程减去系统线程）。由于没有活动线程能够解除阻塞空闲线程，因此存在死锁情况。

但是，这种行为有一些限制。实际上，任何自旋的 Goroutine 都会使死锁检测器失效，因为线程将保持活动状态。

限制

现在，通过发送中断信号使 OS 信号停止程序来改进前面的示例：

这是新的输出：

通过键盘发送中断信号后，程序停止了。不再检测到死锁。具有 signal.Notify 的任何活动程序都将运行后台 goroutine，等待输入信号。该 Goroutine 保持活动状态，并且永远不会使活动线程数等于空闲线程数。这是此 Goroutine 的跟踪：

它的大部分时间都花在等待系统调用上。syscall 中的线程不在空闲列表中，因此不会导致死锁。

但是，可以通过调试工具找到它们。

调试

发现这些死锁的最好方法可能是编写单元测试。编写测试确保一次运行较小的代码段。在这种情况下，不应该受到信号处理程序或阻塞系统调用的干扰。然而，即使这样做 ，测试也会挂起，我们肯定会发现有可疑的地方。

如果你想可视化运行程序上的死锁，可以使用 pprof 之类的工具来可视化它。下面是我们修改后的第一个程序，添加了调试功能：

一旦程序运行，我们就可以使用命令 wget http://localhost:6060/debug/pprof/trace?seconds=5 对我们的应用程序进行配置，该命令会生成 5s 的跟踪信息。 这些痕迹告诉我们所有活动：

没有 Goroutine 一直在运行。可以使用以下命令通过 CPU 配置文件进行确认 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=5。下面是未显示活动的配置文件：