在我們將站點(diǎn)從 ASP.NET + Windows 遷移至 ASP.NET Core + Linux 的過(guò)程中，目前遇到的最大障礙就是 —— 沒(méi)有可用的支持 .NET Core 的 memcached 客戶端。

我們一直用的是 EnyimMemcached ，在沒(méi)有其它選擇的情況下，我們自己嘗試著將 EnyimMemcached 遷移至 .NET Core。。?；?.NET Core 修改好了代碼，在開發(fā)環(huán)境下測(cè)試通過(guò)，在 Linux 服務(wù)器上自己訪問(wèn)很正常（沒(méi)有并發(fā)訪問(wèn)量），但是只要接入一定的訪問(wèn)量就會(huì)發(fā)生死鎖（deadlock），瀏覽器請(qǐng)求卡死。

這個(gè)問(wèn)題困擾了我們很長(zhǎng)時(shí)間，昨天才定位到是發(fā)生在將 memcached 服務(wù)器名稱解析為 IP 地址的時(shí)候。

var addresses = System.Net.Dns.GetHostAddressesAsync(host).Result;

這是我們?cè)趯?EnyimMemcached 遷移至 .NET Core 時(shí)修改過(guò)的代碼，之前調(diào)用的是同步方法：

var addresses = System.Net.Dns.GetHostEntry(host);

由于在 .NET Core Framework 的 System.Net.Dns 中沒(méi)有同步方法，只有異步方法，所以我們只能這樣調(diào)用異步方法。

看到上面的代碼，你也許會(huì)詫異：怎么用 .Result ，為什么不用 await ？不死鎖才怪呢。。。

你的詫異非常正確。我們也深知 .Result 的危害，在平時(shí)的代碼中堅(jiān)決不用。但當(dāng)時(shí)在修改 EnyimMemcached 的代碼時(shí)，由于這個(gè)方法是在 MemcachedClient 的構(gòu)造函數(shù)中調(diào)用的，沒(méi)法改為 await 調(diào)用，被迫用了 .Result ，然后又把這個(gè)地方的修改給忘了。。。昨天才剛剛發(fā)現(xiàn)，立馬意識(shí)到罪魁禍?zhǔn)追浅Ｓ锌赡芫褪沁@里的 .Result ，于是以此為突破口，想盡一切辦法實(shí)現(xiàn)在同步方法中調(diào)用異步辦法，并且在博問(wèn)中尋求支援 —— 在同步方法中調(diào)用異步方法時(shí)如何避免死鎖問(wèn)題 。

結(jié)果，用盡一切能想到與能找到的同步方法調(diào)用異步方法的方法，都沒(méi)能解決死鎖問(wèn)題。如果實(shí)在找不到解決方法，我們準(zhǔn)備采用最后一招也是最丑陋的一招 —— 不用 Dns.GetHostAddressesAsync() ，用 ProcessStartInfo 調(diào)用命令行命令解析 IP ，比如在 Linux 上用 getent hosts 主機(jī)名 。

在準(zhǔn)備放棄之前，今天又想了想還有哪些可能帶來(lái)線索的地方漏掉了呢？突然想到有個(gè)重要地方竟然忘了，還沒(méi)看 Dns.GetHostAddressesAsync() 的源代碼實(shí)現(xiàn)。雖然不報(bào)太大希望，不就是個(gè)異步方法嗎，但還是要看一下。

于是從 github 上簽出 corefx 的源代碼，打開 Dns.GetHostAddressesAsync() 源代碼一看，感覺(jué)有點(diǎn)怪怪的，怎么用了 Task.Factory.FromAsync() ？

public static Task<IPAddress[]> GetHostAddressesAsync(string hostNameOrAddress)
{
  NameResolutionPal.EnsureSocketsAreInitialized();
  return Task<IPAddress[]>.Factory.FromAsync(
    (arg, requestCallback, stateObject) => BeginGetHostAddresses(arg, requestCallback, stateObject),
    asyncResult => EndGetHostAddresses(asyncResult),
    hostNameOrAddress,
    null);
}

開始沒(méi)反應(yīng)過(guò)來(lái)，只是把這段代碼貼到博問(wèn)的補(bǔ)充問(wèn)題中，在貼完后突然反應(yīng)過(guò)來(lái)了，咦，怎么沒(méi)有 async 關(guān)鍵字？方法名最后是 Async，我們一直以為是 async 方法，而且絲毫沒(méi)有懷疑過(guò)。。。

沒(méi)有 async ，只是返回參數(shù)是 Task 類型，那在同步方法中調(diào)用完全沒(méi)問(wèn)題，只要在訪問(wèn) .Result 之前調(diào)用一下 .Wait() 方法就行了，于是改為下面的代碼：

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

死鎖問(wèn)題立馬解決！

方法名以 Async 結(jié)尾，卻不是 async 方法，當(dāng)時(shí)的感想就是 —— 你的眼睛背叛你的心。如果不是我自己的誤解（只要以 Async 結(jié)尾，就應(yīng)該是 async 方法），那就是一種流氓行為，就如 HttpClient 的流氓 —— 實(shí)現(xiàn)了 IDispose 接口，卻沒(méi)真正 Dispose 。

不管怎么樣，這個(gè)影響我們遷移至 .NET Core 的最大障礙終于消除了，值得慶祝！

支持 .NET Core 的 EnyimMemcached 的代碼還需要一些修改與完善，等修改好了，我們會(huì)把源代碼與 NuGet 包都發(fā)布出來(lái)。

通過(guò)此文希望能幫助到你解決這種問(wèn)題，謝謝大家對(duì)本站的支持！

最新評(píng)論