HttpWebRequest.BeginGetResponse是否会同线程触发回调引发挂起

核心结论先行 #

所有符合.NET异步编程模型（APM，即Begin/End配对方法的规范）的方法，都存在在调用发起线程上同步执行回调的可能性，HttpWebRequest.BeginGetResponse和你踩过坑的BeginGetRequestStream没有本质区别。
这种同线程同步触发回调的场景，是APM规范明确允许的行为：当Begin方法被调用时，如果操作已经在当前线程上完成，运行时会直接在调用栈上执行回调，不会将回调投递到线程池。

HttpWebRequest.BeginGetResponse 触发同线程回调的常见场景 #

• 本地环回地址、已缓存的请求快速命中响应
• 请求未发出即同步失败（如DNS解析失败、权限校验拦截）
• 连接池命中空闲连接，且响应数据已在内存中就绪

未正确处理导致挂起的原因 #

你目前用AutoResetEvent作为等待句柄的实现，是偶发挂起的高风险场景，典型的错误逻辑如下：

// 类级别的复用等待句柄（常见写法）
private readonly AutoResetEvent _waitHandle = new AutoResetEvent(false);

// 发起请求
public void SendRequest(WebRequest request) {
  request.BeginGetResponse(ResponseCallback, request);
  // 阻塞等待回调释放句柄
  _waitHandle.WaitOne();
}

// 回调逻辑
private void ResponseCallback(IAsyncResult ar) {
  try {
    var req = (WebRequest)ar.AsyncState;
    var response = req.EndGetResponse(ar);
    // 响应处理逻辑
  } finally {
    // 释放等待句柄
    _waitHandle.Set();
  }
}

当同线程触发回调时，执行顺序会打乱你对线程流程的预期：

1. 调用线程执行BeginGetResponse方法
2. 运行时直接在当前调用栈上同步执行ResponseCallback，走到finally块调用Set()——此时当前线程还在BeginGetResponse方法内部，根本没有执行到后面的WaitOne()逻辑
3. BeginGetResponse方法返回到调用线程，开始执行WaitOne()
   这种场景下，由于AutoResetEvent是复用的实例，上一次同步回调触发的Set()信号如果没有被正确消耗，就会导致：

• 某一次调用时，WaitOne直接被遗留的信号唤醒，跳过了真实的请求等待
• 某一次调用时，同步回调的Set()发生在WaitOne之前，信号被直接消耗，导致后续的WaitOne永远等不到新的信号，直接挂起
  更严重的死锁场景发生在：如果回调内部需要获取当前调用线程已经持有的锁、或者需要通过同步上下文跨线程投递消息，同线程执行的回调会直接等待当前线程释放资源，而当前线程正卡在WaitOne上，形成永久死锁——这也是测试套件挂起通常偶发的原因：只有请求刚好同步完成时才会触发，网络延迟较高、需要真实走IO流程时，回调会被投递到线程池，不会触发问题。

最佳处理方案 #

• 不要手动创建AutoResetEvent来做等待
  直接使用IAsyncResult自带的AsyncWaitHandle做等待，运行时会自动在操作完成（无论同步还是异步）时将该句柄置为信号态，完全不需要你在回调里手动调用Set()，从根源上避免执行顺序错位的问题。示例：

  IAsyncResult ar = request.BeginGetResponse(ResponseCallback, request);
  // 直接使用内置句柄等待，可传入超时时间
  ar.AsyncWaitHandle.WaitOne(TimeSpan.FromSeconds(30));
  // 操作完成后手动释放句柄
  ar.AsyncWaitHandle.Close();
  

• 回调逻辑必须区分同步执行和异步执行的场景
  在回调入口处首先判断ar.CompletedSynchronously属性：
  • 如果值为true，说明当前回调在Begin的调用线程上同步执行，此时不要在回调内做任何阻塞操作、不要等待任何其他句柄，直接处理完逻辑即可，避免卡住调用线程
  • 如果值为false，说明回调在线程池线程上执行，可以正常执行阻塞逻辑、设置等待句柄
• 如果你确实需要自定义等待逻辑，不要复用AutoResetEvent实例，每一次请求都新建独立的等待句柄，且必须在回调内判断CompletedSynchronously，同步执行的回调不需要手动Set句柄（因为此时调用线程还没开始等待）。

常见疑问澄清 #

• 关于“是否需要通过IAsyncResult判断状态再决定是否释放句柄”：完全不需要，只要你用内置的AsyncWaitHandle做等待，不管回调是同步还是异步触发，句柄都会被正确置位，不存在遗漏。
• 关于“是否不等待句柄就会导致回调不触发”：只要你正确调用了Begin方法，运行时强制保证回调一定会被执行，哪怕你完全不等待句柄、甚至直接丢弃返回的IAsyncResult，回调依然会在合适的时机被触发，不存在不执行的问题。

内容的提问来源于stack exchange，提问作者Itai Bar-Haim