“后线程时代”, 这跟 好几个 名词 有关系, 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 ?