“后线程时代”， 这跟 好几个 名词 有关系， C# async await 关键字， Socket Async， ThreadPool， 单体（Monosome）， “异步回调流” 。
“异步回调流” 是 “异步回调流派” 的 意思， node.js， libuv， Java Netty ， 这些 是 典型的 异步回调流 。
async await 是 单体（Monosome），
我在之前的 文章 《我 反对 使用 async await》 https://www.cnblogs.com/KSongKing/p/10216913.html 中 提到， “async await 正带领 C# 向 Javascript 进化” 。
至于 Socket Async ， 和 async await 有关系， 也跟 异步回调流 有关系 。
我们来看看 一位网友 从 一篇文章 上 节取 下来的 2 段文字 ：
所以， 从 理论 上看， 过多的 线程切换 对 性能 的 消耗 是 挺大的， 如果能 省去 这部分 开销， “节省” 下来的 性能 是 可观 的， 也许能让 服务器 的 吞吐量（并发量） 提高 1 个 数量级 。
所以， Visual Studio 自己也在使用 async await， 从 Visual Studio 有时候 报错 的 错误信息 来看， 错误信息 中含有 “MoveNext_xx ……” 这样的文字， 这就是 async await 。
线程池（ThreadPool） 本身 就能 将 线程数量 控制在一个 有限 的 范围内 ，
而 将 线程数量 控制在一个 有限 的 范围内 是 减少 线程切换 的 基础 。
我 猜测 async await 的 底层 是 基于 ThreadPool 的， 是以 ThreadPool 作基础的 。
如果是这样， 那么 async await 和 异步回调流 是 等价 的 。
什么是 异步回调流 ？
我们可以把 程序 分为 3 个部分 ：
1 顺序执行
2 等待 IO
3 定时轮询
1 把 顺序执行 的 多任务 放到 ThreadPool 的 工作队列 里 排队， 让 ThreadPool 调度执行，
2 对于 IO 调用， 采用 异步调用 的 方式， 传入 回调委托， 当 IO 完成时， 当 IO 完成时， 回调委托，
3 对于 定时轮询， 采用 ThreadPool 提供的方式， 如 Timer，
这样， 做到以上 3 点， 就是 纯粹 的 异步回调流 。
理论上， 异步回调 流 可以将 线程数量 控制在 有限 的 范围内， 或者， 只需要 使用 很小数量 的 线程 。
这样， 就像上面说的， 可以节省“可观”的 性能， 可能能让 服务器 的 吞吐量 提高 1 个 数量级 。
从 实验 中， 我们看到， 在 并发量 大 时， 比如 800 个 Socket 连接 以上时， ThreadPool 的 性能 优于 NewThread 的方式， NewThread 是指 为 每个连接 创建一个 线程 。
但是， 如果 Server 端 Socket 的 操作 全部使用 异步 的 方式， 是否 会比 同步的 Receive() Send() 方式 的 性能 更高， 这个 没有 看到 有说服力 的 实验 。
So ……
So …… ？
So ？