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

.NET 5.6.1任务基于并行库的应用程序停止了对NpgsqlConnection.Open()的NpSql.dll 3.1.6调用的响应。

经过进一步调查，似乎有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()。

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

最佳答案

更新:

我们的团队成员将错误报告从submitted转换为npsql。

在更彻底地搜索我们的日志后，由于竞争状况，我们发现NpSql dll版本3.1.6中的ConnectorPool.Allocate()来自NullReferenceException的单个实例。查看当前NpSql存储库中的ConnectorPool.cs，此问题已通过从版本3.1.7开始将静态_pruningTimer转换为基于实例的字段来解决。

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

关于c# - NpgsqlConnection.Open在对Monitor.Enter的Npgsql.ConnectorPool.Allocate()调用中被阻止，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39167187/