这是一个创建于 2981 天前的主题，其中的信息可能已经有所发展或是发生改变。
类似 nodejs,假设如果业务上可并行的代码比较少(个人感觉大量的业务代码就是并行度不高的)，全都是下一步操作要等上一步的结果，代码里有不少 async/await,那可以说异步编程也是无法降低响应时间的.那异步编程带来了什么好处？
受限于机器硬件资源，单台服务器所能支撑的线程数是存在一个上限的，假设为 T，那么应用同时能处理的请求数（吞吐量）必然也不会超过 T。如果运行在像 Netty 这样的异步容器中，无论有多少个请求，用于处理请求的线程数是相对固定的，因此最大吞吐量就有可能超过 T。
上面这段那 java 来举例，说明异步编程未必能带来响应时间上的提升，但能提高吞吐量。
我不是很理解异步编程提高吞吐量这个点？大家能给能举一个通俗点的例子吗？也可以谈谈大家对异步编程好处的理解。
 | 1 hellommd 2018 年 1 月 22 日 |
 | 2 gouchaoer 2018 年 1 月 22 日 via Android callback hell 有啥好处。。。io 异步是方案，协程也是方案，基于 yield 的半协程次之 |
 | 3 tailf 2018 年 1 月 22 日 异步编程好处我感觉不太明显，坏处却是大大的有。 |
 | 4 SuperMild 2018 年 1 月 22 日 总体感觉异步为主的系统更容易提高健壮性，因为可以轻易忽略被卡住的部分（比如网络不通、文件被锁定等等），系统的其他部分照常运作。对于被卡住的部分，可以设定超时返回错误信息。用户的体验比较好。当然同步为主的系统也可以做到，但异步实现更轻松。 |
 | 5 QAPTEAWH 2018 年 1 月 22 日 “受限于机器硬件资源，单台服务器所能支撑的线程数是存在一个上限的，假设为 T，那么应用同时能处理的请求数（吞吐量）必然也不会超过 T。如果运行在像 Netty 这样的异步容器中，无论有多少个请求，用于处理请求的线程数是相对固定的，因此最大吞吐量就有可能超过 T。” 这些话是扯蛋的。 理解异步意义的关键字 - IO 密集与 CPU 密集的区别 - 线程切换开销 |
Select Language