在开始吹牛之前，老周说两个故事。
第一个故事是关于最近某些别有用心的人攻击.net的事，其实我们不用管它们，只要咱们知道自己是.net爱好者就行了，咱们就是因为热爱.net才会选择它。这些人在这段时间攻击.net，估计和.net的开源、跨平台有关，并且，据说VS 2015 Update 1会进一步深化和扩展全平台，估计有些人是沉不住气了，毕竟他们用的开发工具是比VS落后了四个多世纪的。最近又出了个Visual Studio Dev Essentials计划。
所以嘛，对于这些人，我把林妹妹的一首诗送给他们：
无端弄笔是何人？
作践.net太轻狂。
不悔自家无见识，
却将丑语怪他人。
接下来说说第二个故事。或许不少应届毕业生都在准备或者已经在找实习单位，或找工作了，于是有朋友私信老周，希望老周说说简历如何做的事情。这个嘛，一来，老周不是简历专家；二来，在本文中不好展开去谈，过一两天吧，老周找时间再写篇烂文，专门说说这个事；三来，仅为一家之言，以供参考。
============================================
好了，与主题无关的话说完了，下面开始说正事。记得在X月前，老周写过有关ThreadLocal的文章，也就是基于线程的本地变量存储。使用这个ThreadLocal的前提是：
1、变量必须是多个线程共享的，如果是线程范围内的局部变量就不需要了。
2、希望每个线程都能读写独立的变量值。
今天，老周再介绍一个功能和ThreadLocal类似的东东——AsyncLocal。
这个主要是用于保存异步等待上下文中的共享变量的值。从C# 5开始，引入了相当简便的异步等待语法，即await关键字调用异步方法，允许异步等待。
即代码在使用await关键字调用异步方法后，当前程序会等待异步方法返回后才会继续执行，但在这个等待过程中，不会阻塞当前线程，这比起编写委托来回调方便多了。
异步方法是基于Task的自动线程调度，在异步上下文的切换过程中，有可能会导致数据丢失。比如，在await调用前，对某个变量赋了值，而这个变量是多个线程共享的；当await调用返回后，有可能当前代码仍然处于先前的线程上，但也有可能被调度到其他线程上。这种情况一般发生在与应用程序UI线程无关的代码上，如果异步操作是由UI启动的，通常情况下不会调动异步上下文的线程，然而，如果异步操作是非UI触发的，典型的如在Main入口处启动的，这就很有可能出现异步上下文处于不同的线程上的情形。
这样描述太抽象，很难懂，没事，给大家看一个例子就知道了。
先定义一个异步方法：
static async Task RunAsync()
{
// 输出当前线程的ID
Console.WriteLine($"异步等待前，当前线程ID：{Thread.CurrentThread.ManagedThreadId}");
// 开始执行异步方法，并等待完成
await Task.Delay(50);
// 异步等待完成后，再次输出当前线程的ID
Console.WriteLine($"异步等待后，当前线程ID：{Thread.CurrentThread.ManagedThreadId}");
}
异步方法中，调用了Task.Delay方法，这个方法也是可以异步等待的，因此用await关键字来等待50毫秒。
然后，在Main入口处调用以上异步方法。
static void Main(string[] args)
{
// 声明一个委托实例
Action act = async () =>
{
await RunAsync();
};
// 执行委托
act();
Console.Read();
}
我这里是先声明一个Action委托实例，并通过Lambda表达式调用异步方法，并且异步等待其完成。因为使用了await关键字的方法上必须标注async修饰符，以说明该方法中出现异步等待代码，但是，Main入口方法上是不允许添加async修饰符的，所以，我就用一个委托来调用。
运行这个例子，你会有惊奇发现，请看，有图有真相。
看到没，await等待前，当前的线程是8，异步等待回来后，当前线程就被自动调度到10上了。
== 在线程8上
await Task.Delay(50);
== 在线程10上
从代码上看，await前后是连续的，但实际上，在执行阶段，它们已经处于不同的线程上了。
那么，我就想啊，如果在此种情况下使用ThreadLocal变量会发生什么事情。试试看。
// 线程共享变量
static ThreadLocal<int> local = new ThreadLocal<int>();
static void Main(string[] args)
{
// 声明一个委托实例
Action act = async () =>
{
await RunAsync();
};
// 执行委托
act();
Console.Read();
}
static async Task RunAsync()
{
// 给共享变量赋值
local.Value = 53000;
// 输出变量的值
Console.WriteLine($"异步等待前：{nameof(local)} = {local.Value}");
await Task.Delay(50); //异步等待
// 异步等待回来，再次输出变量的值
Console.WriteLine($"异步等待后：{nameof(local)} = {local.Value}");
}
上面例子使用了ThreadLocal声明线程间共享变量，在异步方法中，先给这个变量赋值为53000，然后await开始等待，等待返回后，再次输出变量的值。
好，注意看，意外发生了。
哟，有朋友估计会尖叫了，这是咋回事？await前不是给共享的变量赋了值吗，为什么等待返回后值会变回默认值0呢。前面老周说了，等待前，等待后是有可能处于不同的线程上，而ThreadLocal是为每个线程保存独立的值的。
假设，设置local值为53000是在线程A上执行的，那么，local变量为线程A保留了值53000；当代码执行到await关键字一行后，开始异步等待，而等待返回后，当前代码可能被调度到线程B上了。而53000是为线程A所存储的值，对于线程B，未赋值，所以就得到默认的值0。
很显然，ThreadLocal是不适合在异步上下文中使用的。下面就请出今天的主角——AsyncLocal。
把上面的代码中的ThreadLocal改为AsyncLocal。
// 线程共享变量
static AsyncLocal<int> local = new AsyncLocal<int>();
……
然后，再运程序，看图。
看到了吧，这下子好了，53000在异步上下文中被保留了。
现在，你明白了AsyncLocal的功能了吧。