嗨，我是菲利波，今天我设法给自己一个惊喜！（不是很好）我正在为RRDNS（CloudFlare的godns服务器）开发一个新的模块（我们称之为filter）。这是对权威模块的重写，该模块将IP地址添加到DNS答案中。它有一个CloudFlare ip表，如下所示：类型IPMap结构{sync.RWMutexM映射[字符串][]网络IP}它是一个全局过滤器属性：V2Filter结构类型{名称字符串IPTable*IPMap// [...]}马丁·索斯特勒的CC-BY-NC-ND图像表经常更改，因此后台goroutine定期从我们的分布式键值存储中重新加载它，获取锁（f。IPTable.锁定（）），更新它并释放锁（f。IPTable.解锁()). 每5分钟发生一次。所有的东西都在测试中工作，包括多个并发请求。今天，我们部署到一个非生产测试机器上，一切正常。几分钟。然后RRDNS停止回答新代码所服务的beta域的查询。什么。在我的笔记本电脑上工作™.这是IPTable消费函数。你也许能发现这个虫子。func（f*V2Filter）getCFAddr（…）（结果[]域名系统.RR) {f。IPTable.RLock文件()// [... 将f.IPTable.M中的IP附加到结果…]返回}f。IPTable.RUnlock（）从未被调用。哎哟。但它是一个RLock，所以多个getCFAddr调用应该可以工作，只有表重新加载才会中断，不是吗？相反，getCFAddr在几分钟后开始阻塞。给医生们！为了确保锁最终可用，阻塞锁调用将排除新的读卡器获取锁。https://golang.org/pkg/sync/#RWMutex.Lock所以一切正常，RLock堆积起来，直到表reload函数运行，然后挂起的锁调用导致所有后续RLock调用阻塞，中断RRDNS应答生成。在测试中，table reload函数在回答查询时从未运行过，因此getCFAddr不断累积RLock调用，但从未被阻塞。没有客户受到影响，因为A）该版本仍在非生产机器上测试，B）还没有真正的客户运行新代码。不管怎么说，这是一个有趣的方法来引起延迟的死锁。最后，这里可能有更好的工具空间。静态分析工具可能会输出所有锁定/解锁调用的列表，而动态分析工具可能会在测试结束时报告仍然[r]锁定的互斥锁。（或者这些工具可能已经存在，在这种情况下让我知道！）你想帮助（介绍：）和修复DNS服务器中每天回答超过500亿个查询的错误吗？我们正在伦敦、旧金山和新加坡招聘！