不幸的是，这个用于服务通信的库是同步的，我们希望对其使用进行并行化。

当未设置HttpContext时，将引发null异常：

明显的答案（HttpContext.Current = parentContext）无法工作，因为在其下有一些异步代码（无论出于何种原因），这有时会导致它不返回到同一线程，并且基本上放弃了Context，再次导致null

在示例代码注释中，你的问题有很重要的一部分。:)

通常，HttpContext不应在线程之间共享。它根本不是线程安全的。但是你可以设置HttpContext.Current（出于某种原因），因此你可以选择过着危险的生活。

这里更隐蔽的问题是该库具有同步API，并且正在执行异步同步-但以某种方式没有死锁（？）。在这一点上，我必须诚实地说，最好的方法是修复库：让供应商修复它，或提交PR，或者如果需要的话，只重写它。

但是，极有可能通过添加甚至更危险的代码来使这种工作正常进行。

因此，这是你需要了解的信息：

• ASP.NET（预核心）使用AspNetSynchronizationContext。上下文：
  • 确保一次只能在此上下文中运行一个线程。
  • HttpContext.Current为在上下文中运行的任何线程设置。

现在，你可以捕获SynchronizationContext.Current并将其安装在线程池线程上，但是除了非常危险之外，它还不能实现你的实际目标（并行化），因为一次AspNetSynchronizationContext只能允许一个线程进入。第三方代码的第一部分将能够并行运行，但是排队的所有内容AspNetSynchronizationContext将一次运行一个线程。

因此，我想到进行此工作的唯一方法是使用自己的自定义SynchronizationContext，该自定义在同一线程上恢复并HttpContext.Current在该线程上进行设置。我有一个AsyncContext类可以被用于此：

[HttpPost]
public async Task<IHttpActionResult> DoIt(IEnumerable<int> inputs)
{
  var context = HttpContext.Current;
  var tasks = inputs.Select(i =>
      Task.Run(() =>
          AsyncContext.Run(() =>
          {
            HttpContext.Current = context;
            var results = Some3rdPartyTool.CallEndpointSynchronously(MyRestEndpointConfig[i]);
            return results;
          })));
  var outcome = await Task.WhenAll(tasks);
}

因此，对于每个输入，都会从线程池（Task.Run）中抓取一个线程，并安装（AsyncContext.Run）自定义单线程同步上下文（），HttpContext.Current然后设置该代码，然后运行该代码。这可能行不通；它取决于如何精确地Some3rdPartyTool使用SynchronizationContextand和HttpContext。

请注意，此解决方案有几种不良做法：

• Task.Run在ASP.NET上使用。
• HttpContext从多个线程同时访问同一实例。
• AsyncContext.Run在ASP.NET上使用。
• 阻塞异步代码（由AsyncContext.Run，也可能由Some3rdPartyTool。

最后，我再次建议更新/重写/替换Some3rdPartyTool。但是，这堆黑客也许行得通。