.NET Core中遇到奇怪的线程死锁问题：内存与线程数不停地增长

一个 asp.net core 站点，之前运行在Linux 服务器上，运行一段时间后有时站点会挂掉，在日志中记录很多“EMFILE too many open files”的错误：

Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -24 EMFILE too many open files

后来将这个 asp.net 站点部署到 Windows 服务器的 IIS 上。运行一段时间后，发现其中一台服务器出现503错误：

HTTP Error 503.2 - Service Unavailable
The serverRuntime@appConcurrentRequestLimit setting is being exceeded.

登上服务器一看，该站点的进程占用的内存竟然有1.2G，而同一负载均衡中另外一台正常的服务器内存占用只有40多M。然后看了一下进程中的线程数，惊呆了——竟然有8000多个线程！而另外一台正常的服务器只有20多个线程。

将这台服务器从负载均衡上摘下来之后，出现了更加让人惊呆的现象——在没有请求的情况下，这个 asp.net core 站点进程的内存占用与线程数一直在增长。就像在代码中写了一个死循环，在循环中不停地创建线程。

再后来内存增长到1.8G左右，线程数增长到1.3万左右，而且还在持续增长。

不仅内存与线程数在增长，而且CPU也一直在波动，这可是在没有任何请求的情况下，谁在偷偷地干活？

强制结束进程后恢复正常，但运行一段时间（通常是1天时间）后又会出现同样的问题。非常奇怪！

从目前分析的情况看，罪魁祸首可能是 EnyimMemcachedCore （支持.net core的memcached客户端，是我们从 EnyimMemcached 移植过来的），EnyimMemcachedCore 用到了 Socket 池，问题可能出在 Socket 池部分，源代码在 github 上（EnyimMemcachedCore源代码）。

windbg分析进程dump文件显示的线程情况：

0:000> .load C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.1\sos.dll
0:000> !threads
ThreadCount:      8014
UnstartedThread:  0
BackgroundThread: 8013
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no

发现大量线程中存在 coreclr!Thread::DoAppropriateWaitWorker 这个操作：

!uniqstack
 # Child-SP          RetAddr           Call Site
00 00000056`ed5ad118 00007ffa`080e13ed ntdll!NtWaitForMultipleObjects+0xa
01 00000056`ed5ad120 00007ff9`f1dc885e KERNELBASE!WaitForMultipleObjectsEx+0xed
02 00000056`ed5ad400 00007ff9`f1dc8a0d coreclr!Thread::DoAppropriateWaitWorker+0xfe
03 00000056`ed5ad4b0 00007ff9`f1dca52f coreclr!Thread::DoAppropriateWait+0x7d
04 00000056`ed5ad530 00007ff9`f1e3b726 coreclr!CLREventBase::WaitEx+0x7f
05 00000056`ed5ad580 00007ff9`f1e3b636 coreclr!AwareLock::EnterEpilogHelper+0xca
06 00000056`ed5ad640 00007ff9`f1f92b18 coreclr!AwareLock::EnterEpilog+0x62
07 00000056`ed5ad6a0 00007ff9`f1f92131 coreclr!AwareLock::Contention+0x258
08 00000056`ed5ad760 00007ff9`92388e2b coreclr!JITutil_MonContention+0xb1

该问题还在进一步排查中。。。

[12月3日13:00更新]

今天排查后怀疑是 EnyimMemcached 中下面的代码引起的：

private void ConnectWithTimeout(Socket socket, EndPoint endpoint, int timeout)
{
    var completed = new AutoResetEvent(false);
    var args = new SocketAsyncEventArgs();
    args.RemoteEndPoint = endpoint;
    args.Completed += OnConnectCompleted;
    args.UserToken = completed;
    socket.ConnectAsync(args);
    if (!completed.WaitOne(timeout) || !socket.Connected)
    {
        using (socket)
        {
            throw new TimeoutException("Could not connect to " + endpoint);
        }
    }
}

private void OnConnectCompleted(object sender, SocketAsyncEventArgs args)
{
    EventWaitHandle handle = (EventWaitHandle)args.UserToken;
    handle.Set();
}

已修改代码以定位是不是上面的代码引起的，要等待下次deadlock的发生。

[12月4日8:50更新]

终于可以重现这个问题，在有负载的情况下强制结束进程，详见录屏。

[12月4日12:20更新]

终于定位到了引起问题的代码：

Task<IPAddress[]> task = System.Net.Dns.GetHostAddressesAsync(host);
task.Wait();
var addresses = task.Result;

这是上次解决 EnyimMemcached 死锁问题 时埋下的坑，死锁发生在有并发请求时进行主机名的解析，在强制结束进程时重现是因为dns解析缓存失效。

改为下面的代码可解决死锁问题：

Task<IPAddress[]> task = System.Net.Dns.GetHostAddressesAsync(host);
if (task.Wait())
{
    var addresses = task.Result;
}

虽然死锁问题解决了，但在并发请求下task.Wait(5000)返回false，无法成功解析主机名。

问题的根源是在构造函数中用（且只能用）同步方式调用System.Net.Dns.GetHostAddressesAsync()异步方法。

最终解决方法见：尝试解决.NET Core Framework中Dns.GetHostAddressesAsync()引起的线程死锁

相关链接：

• 又踩.NET Core的坑：在同步方法中调用异步方法Wait时发生死锁

[12月3日16:10更新]

果然是上面的代码引起的死锁，改为下面的代码后问题解决：

private void ConnectWithTimeout(Socket socket, EndPoint endpoint, int timeout)
{
    var task = socket.ConnectAsync(endpoint);
    if (!task.Wait(timeout))
    {
        using (socket)
        {
            throw new TimeoutException("Could not connect to " + endpoint);
        }
    }
}