通过PageMethods从JS调用C#异步函数时出现死锁问题

嘿，我碰到过好多次这种PageMethods调用异步C#方法死锁的情况，太懂你的痛苦了！咱们先搞清楚为啥会锁，再一步步解决。

死锁的根源在哪？ #

在传统ASP.NET（非Core）里，每个请求都绑定了一个同步上下文（SynchronizationContext），这个上下文一次只允许一个线程进入。当你用PageMethods调用async标记的后台方法时：

1. PageMethods的AJAX调用是同步等待结果的，会死死占住当前请求的上下文线程。
2. 你的async方法执行到await时，当前线程会释放回线程池，方法暂停。
3. 当await的操作完成后，async方法默认会试图回到原来的请求上下文继续执行后续代码，但此时这个上下文已经被PageMethods的同步等待逻辑占住了。
4. 两边互相等对方释放资源，直接就死锁了！

解决方案来了，按优先级选 #

方案1：给所有await加上ConfigureAwait(false)（最推荐） #

这是最直接且优雅的解决办法，让await之后的代码不回到原来的请求上下文，彻底避开上下文竞争。

比如你的后台async方法原本是这样：

[WebMethod]
public static async Task<string> MyAsyncMethod()
{
    // 调用另一个异步函数
    var result = await SomeOtherAsyncFunction();
    return result;
}

修改成这样，每个await后面都加上ConfigureAwait(false)：

[WebMethod]
public static async Task<string> MyAsyncMethod()
{
    var result = await SomeOtherAsyncFunction().ConfigureAwait(false);
    return result;
}

⚠️ 注意：如果你的方法里有多个await，每个都要加，确保后续代码都在线程池线程上执行，不碰原请求上下文。

方案2：强制同步执行（不推荐，应急用） #

如果你的业务场景暂时没法改异步逻辑，也可以把异步方法强制同步执行，但这种方法会浪费线程资源，高并发下影响性能，只能临时救急：

[WebMethod]
public static string MySyncMethod()
{
    // 用.GetAwaiter().GetResult()替代await，强制同步获取结果
    var result = SomeOtherAsyncFunction().GetAwaiter().GetResult();
    return result;
}

方案3：改用异步AJAX回调（前端调整） #

如果前端代码可以修改，完全可以抛弃PageMethods的同步等待逻辑，用原生AJAX的异步回调方式请求，这样后台的async方法就能正常执行，不会触发死锁。

比如前端换成这样的代码：

$.ajax({
    type: "POST",
    url: "WebForm1.aspx/MyAsyncMethod",
    contentType: "application/json; charset=utf-8",
    dataType: "json",
    success: function(response) {
        // 成功拿到结果后的处理逻辑
        alert(response.d);
    },
    error: function(xhr, status, error) {
        // 错误处理
        console.error(error);
    }
});

这种方式下前端不会同步等待，后台的async方法执行时就不会有上下文竞争的问题。

内容的提问来源于stack exchange，提问作者Neils Schoenfelder