Hi'story进程
正在执行的一个应用程序
线程
单位时间操作系统分配的cpu资源
一个应用程序包含多个线程
多线程
为了更好的利用cpu资源
在窗体应用中: 主线程负责UI的更新、其余线程负责一些网络、文件处理 对于用户来说不会体验到被卡死的感觉
在Web程序中: 多线程意味着你可以处理更多的请求
异步
为了避免线程操作阻塞的情况出现
如上述多线程中，假如这个进程中拥有10个线程
有100个用户发起了HTTP请求 这些请求会对读取文件(假设需要2S)的时间然后再返回
假设没有其他时间消耗
100个用户 在10个线程并发的情况下如下:
| 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 第1-10位用户 | 处理 | 处理完成 | |||||||||
| 第11-20位用户 | 处理 | 处理完成 | |||||||||
| 第21-30位用户 | 处理 | 处理完成 | |||||||||
| 第31-40位用户 | 处理 | 处理完成 | |||||||||
| 第41-50位用户 | 处理 | 处理完成 | |||||||||
| 第51-60位用户 | 处理 | 处理完成 | |||||||||
| 第61-70位用户 | 处理 | 处理完成 | |||||||||
| 第71-80位用户 | 处理 | 处理完成 | |||||||||
| 第81-90位用户 | 处理 | 处理完成 | |||||||||
| 第91-100位用户 | 处理 | 处理完成 |
这虽然用到了多线程 但是这里面资源依然有个巨大的浪费 读取文件时的这2S的时间
此时 这个线程是没事干的状态 但是被这一步给阻塞了...
怎么办？
遇到这种事的时候 留个标记，让线程先处理其他事，别闲着😢，读取好文件时，再随便通知一个线程，让它接着在处理
那么当第一个线程遇到阻塞时，里面去接待下一个用户，时间线类似这样：
| 0 | 0.01 | 0.02 | 0.03 | 0.04 | ... | |
|---|---|---|---|---|---|---|
| 线程A处理第1位用户的请求 | 处理 | 没事干了，去处理其他事 | ||||
| 线程A处理第11位用户的请求 | 处理 | 没事干了，去处理其他事 | ||||
| 线程A处理第21位用户的请求 | 处理 | 没事干了，去处理其他事 | ||||
| 线程A处理第31位用户的请求 | 处理 | 没事干了，去处理其他事 | ||||
| ... |
最终类似这样
| 0 | 0.01 | 0.02 | 0.03 | 0.04 | 0.05 | 0.06 | 0.07 | 0.08 | 0.09 | 2 | ... | 2.09 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 第1-10位用户 | 处理 | 处理完成 | |||||||||||
| 第11-20位用户 | 处理 | 处理完成 | |||||||||||
| 第21-30位用户 | 处理 | 处理完成 | |||||||||||
| 第31-40位用户 | 处理 | 处理完成 | |||||||||||
| 第41-50位用户 | 处理 | 处理完成 | |||||||||||
| 第51-60位用户 | 处理 | 处理完成 | |||||||||||
| 第61-70位用户 | 处理 | 处理完成 | |||||||||||
| 第71-80位用户 | 处理 | 处理完成 | |||||||||||
| 第81-90位用户 | 处理 | 处理完成 | |||||||||||
| 第91-100位用户 | 处理 | 处理完成 |
你会发现 在之前的多线程中 第91-100位用户 可能在等待了18s后才开始被响应(转圈圈转了18s)
但是在异步操作中 第91-100位用户 可能在第0.09s时就已经得到了响应(几乎感知不出来)
这也就是为啥叫做异步编程可以避免线程不必要的阻塞 进而提升效率