标签：线程池 用户 工作 应用程序 https 状态 方法 read bsp
无阻塞 编程模型 涉及到 异步回调流， Task， async await， 线程池， 并发编程， 并行编程， 大并发架构， 操作系统 之上 编程模型 的 发展 等等 。
我这段时间对 这个领域 的 现状 进行了一些 收集整理 和 批判 ， 请看 ：
《后线程时代 的 应用程序 架构》 https://www.cnblogs.com/KSongKing/p/10228842.html
《我 反对 使用 async await》 https://www.cnblogs.com/KSongKing/p/10216913.html
单纯 从 执行效率 看， 也许 同步方法 最直接， 效率也最高 。 只要 配合 线程池 合理使用 线程 就可以 。
异步方法 的 意义 在于 实现 无阻塞 模式，
而 无阻塞 模式 的 意义 要在 大并发 且 IO 等待时间显著 、IO 可能长时间等待 、 IO 等待时间不确定（可能有意外） 的时候 才会 体现出来 。
什么是 IO 等待 ？ IO 等待 本质上是 CPU 对 外部设备 的 等待 。
从 应用 上说， IO 等待 就是 访问数据库， 调用 WebApi， 读写文件， RPC 等 。
假设 线程池 有 1000 个 线程， 可以同时处理 1000 个 用户 的 请求， 每个请求 都 需要 访问数据库，
如果 数据库 的 查询缓慢， 则 这 1000 个 线程 可能 都会 去等待 数据库， 当有 第 1001 个 以上的 用户 访问 网站 时， 线程池 将 没有 多余 的 线程 去 处理 第 1001 个 以上的 用户 的 请求， 这种情况 如果 持续一段时间， 就会变成 服务器 不能提供 服务， 如果 数据库 处于 “挂掉” 的 异常状态， 则 Web 服务器 线程池 里 的 1000 个 线程 都将 长期 等待数据库 而 挂起， 这样 服务器 就 不能提供 服务， 或者 变得 异常缓慢 （对 用户而言） 。
微服务 的 “雪崩‘， 大概 也是 从这里来的 。
且 从 广义 的 角度 来讲， 线程池 的 1000 个 线程 本来 还可以有一部分 去做 其它 工作（不需要 访问数据库 的 工作，或是 访问 其它数据库 的 工作）， 但 都卡在 访问 A 数据库 这里了 。
但是， 我们 又不能 采用 无限制 的 创建线程（New Thread）的 方式，
标签：线程池 用户 工作 应用程序 https 状态 方法 read bsp
原文地址：https://www.cnblogs.com/KSongKing/p/10287882.html
