c# - NpgsqlConnection.Open 在 Npgsql.ConnectorPool.Allocate() 对 Monitor.Enter 的调用中被阻止

Question

.NET 5.6.1 Tasks Parallel Library - 基于应用程序在 NpSql.dll 3.1.6 调用 NpgsqlConnection.Open() 时停止响应。

经过进一步调查，似乎有 100 个线程为特定连接字符串提供服务，正在等待 Monitor.Enter 信号。等待线程的调用堆栈与此相同:

[GCFrame: 000000cd8922cec8] 
[GCFrame: 000000cd8922d0f0] 
[HelperMethodFrame: 000000cd8922d128] System.Threading.Monitor.Enter(System.Object)
Npgsql.ConnectorPool.Allocate(Npgsql.NpgsqlConnection, Npgsql.NpgsqlTimeout)
Npgsql.NpgsqlConnection.OpenInternal() 

锁转储指向孤立锁问题:MonitorHeld 值等于 1 个所有者 + 546 个等待者(1+546*2=1093)，锁所有者线程已死(线程为 0)

Index     SyncBlock      MonitorHeld    Owning  Thread    Info       Owner
220427  000000d26dd7b028   1093           1       0        XXX   Npgsql.ConnectorPool

ConnectorPool.Allocate() 中的不安全代码块内部没有生成有助于解释孤立锁的异常。

也没有理由相信我们的代码导致线程过早死亡:我们在应用程序的任何地方都没有显式调用Thread.Abort()。

在这一点上，我们没有想法了。感谢您查看这个。

Answer 1

更新:

1. 错误报告是 submitted由我们团队的一名成员发送给 npsql。

2. 在对我们的日志进行更彻底的搜索后，我们发现由于竞争条件，NullReferenceException 的单个实例来自 NpSql dll 版本 3.1.6 中的 ConnectorPool.Allocate()。看着ConnectorPool.cs在当前的 NpSql 存储库中，自版本 3.1.7 以来，已通过将静态 _pruningTimer 转换为基于实例的字段来解决此特定问题。

结论:从 NpSql 3.1.6 升级到 3.1.7 解决了 ConnectorPool.Allocate() 中的死锁。