2
访问StackExchange.Redis时出现死锁
调用StackExchange.Redis时，我陷入了僵局。 我不知道到底是怎么回事，这非常令人沮丧，我将感谢您提供任何有助于解决或解决此问题的建议。 如果您也有这个问题，并且不想阅读所有这些内容； 我建议您尝试设置PreserveAsyncOrder为false。 ConnectionMultiplexer connection = ...; connection.PreserveAsyncOrder = false; 这样做可能会解决此Q＆A即将发生的僵局，并且还可以提高性能。 我们的设置 该代码既可以作为控制台应用程序运行，也可以作为Azure工作者角色运行。 它使用HttpMessageHandler公开REST api，因此入口点是异步的。 代码的某些部分具有线程相似性（由单个线程拥有，并且必须由单个线程运行）。 代码的某些部分是仅异步的。 我们正在做异步同步和异步同步的反模式。（混合await和Wait()/ Result）。 访问Redis时，我们仅使用异步方法。 我们将.NET 4.5使用StackExchange.Redis 1.0.450。 僵局 当应用程序/服务启动时，它会正常运行一段时间，然后突然（几乎）所有传入请求停止运行，它们永远不会产生响应。所有这些请求都陷入僵局，等待对Redis的调用完成。 有趣的是，一旦发生死锁，对Redis的任何调用都将挂起，但前提是这些调用是由在线程池上运行的传入API请求进行的。 我们还从低优先级的后台线程对Redis进行了调用，即使死锁发生后，这些调用仍继续起作用。 似乎只有在线程池线程上调用Redis时才会发生死锁。我不再认为这是由于这些调用是在线程池线程上进行的。而是，即使发生死锁情况，似乎任何没有继续执行或具有同步安全继续执行的异步Redis调用都将继续起作用。（请参阅下面我的看法） 有关 StackExchange.Redis死锁 混合await和Task.Result（像我们这样，异步同步）导致死锁。但是我们的代码在没有同步上下文的情况下运行，因此不适用于这里，对吧？ 如何安全地混合同步和异步代码？ 是的，我们不应该那样做。但是我们这样做了，我们将不得不继续这样做一段时间。许多代码需要迁移到异步世界中。 同样，我们没有同步上下文，因此这不应引起死锁，对吗？ 设置ConfigureAwait(false)之前await没有任何影响。 异步命令和Task.WhenAny在StackExchange.Redis中等待后发生超时异常 这是线程劫持问题。目前情况如何？这可能是问题所在吗？ StackExchange.Redis异步调用挂起 从马克的答案： ...混合等待和等待不是一个好主意。除了死锁，这是“异步同步”-一种反模式。 但是他也说： SE.Redis内部绕过同步上下文（对于库代码而言是正常的），因此它不应具有死锁 因此，据我了解，StackExchange.Redis应该与我们是否使用sync-over-async反模式无关。只是不建议这样做，因为它可能是其他代码中死锁的原因。 但是，据我所知，在这种情况下，死锁确实在StackExchange.Redis内部。如果我错了，请纠正我。 调试结果 我发现僵局似乎有其源ProcessAsyncCompletionQueue上的124线CompletionManager.cs。 该代码段： while (Interlocked.CompareExchange(ref …