问ASP.NET内核中AsyncLocal的安全性

EN

对于.NET核心，AsyncLocal是CallContext的替代品。然而，目前还不清楚在ASP.NET核心中使用它有多“安全”。

在ASP.NET 4(MVC5)和更早的版本中，thread-agility model of ASP.NET made CallContext unstable。因此，在ASP.NET中，实现每个请求的逻辑上下文行为的唯一安全方法就是使用HttpContext.Current.Items。在幕后，HttpContext.Current.Items是用CallContext实现的，但它是以一种对ASP.NET安全的方式完成的。

相比之下，在OWIN/Katana Web API的上下文中，线程敏捷性模型不是问题。在careful considerations of how correctly to dispose it之后，我能够安全地使用CallContext。

但现在我要处理的是ASP.NET核心。我想使用以下中间件：

public class MultiTenancyMiddleware
{
    private readonly RequestDelegate next;
    static int random;

    private static AsyncLocal<string> tenant = new AsyncLocal<string>();
    //This is the new form of "CallContext".
    public static AsyncLocal<string> Tenant
    {
        get { return tenant; }
        private set { tenant = value; }
    }

    //This is the new verion of [ThreadStatic].
    public static ThreadLocal<string> LocalTenant;

    public MultiTenancyMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        //Just some garbage test value...
        Tenant.Value = context.Request.Path + random++;
        await next.Invoke(context);

        //using (LocalTenant = new AsyncLocal<string>()) { 
        //    Tenant.Value = context.Request.Path + random++;
        //    await next.Invoke(context);
        //}
    }
}

到目前为止，上面的代码似乎工作得很好。但至少有一个危险信号。在过去，确保将CallContext视为必须在每次调用后释放的资源是至关重要的。

现在我看到没有不言而喻的方法来“清理”AsyncLocal。

我加入了代码，注释掉了，展示了ThreadLocal<T>是如何工作的。它是IDisposable，因此它有一个明显的清理机制。相反，AsyncLocal不是IDisposable。这是令人不安的。

这是因为AsyncLocal还没有处于发布候选状态吗？或者这是因为真的不再需要执行清理？

即使我在上面的例子中正确地使用了AsyncLocal，ASP.NET核心中是否有任何老式的“线程敏捷性”问题会使这个中间件无法工作？

特别说明

对于那些不熟悉CallContext在ASP.NET应用程序中存在的问题的人，在this SO post, Jon Skeet中引用了一个in-depth discussion about the problem (而后者又引用了commentary from Scott Hanselman)。这个“问题”不是bug --它只是一个必须仔细考虑的情况。

此外，我可以亲自证明这种不幸的行为。在构建ASP.NET应用程序时，我通常会将负载测试作为自动化测试基础结构的一部分。在负载测试期间，我可以看到CallContext变得不稳定(其中可能有2%到4%的请求显示CallContext被破坏)。我也见过Web API GET具有稳定的CallContext行为，但POST操作都不稳定的情况。实现完全稳定性的唯一方法是依靠HttpContext.Current.Items。

然而，在ASP.NET核心的情况下，我不能依靠HttpContext.Items...there不是这样的静态访问点。我还不能为我正在修补的.NET核心应用程序创建负载测试，这也是我没有回答这个问题的部分原因。:)

：请理解我所讨论的“不稳定性”和“问题”根本不是bug。CallContext并没有什么缺陷。这个问题只是ASP.NET采用的线程分派模型的结果，解决方法很简单，就是知道问题的存在，并进行相应的编码(例如，在ASP.NET应用程序中使用HttpContext.Current.Items而不是CallContext )。

我提出这个问题的目的是理解这种动态如何在ASP.NET核心中应用(或不应用)，这样在使用新的AsyncLocal构造时，我就不会意外地构建不稳定的代码。