◆◆异步定义◆◆
关于异步的定义，网上有很多不同的形式，但是归根结底中心思想是不变的。无论是在http请求呼叫的层面，还是在cpu核心态和使用者态传输资料的层面，异步这个行为针对的是呼叫方：
一个可以无需等待被呼叫方的返回值就让操作继续进行的方法
在多数程序员的概念中一般是指执行绪处理的层面：
异步是计算机多执行绪的异步处理。与同步处理相对，异步处理不用阻塞当前执行绪来等待处理完成，而是允许后续操作，直至其它执行绪将处理完成，并回调通知此执行绪
可以这样通俗的理解，异步主要解决的问题是不阻塞呼叫方，用方这里可以是http请求的发起者，也可以是一个执行绪。
但此处需要明确的是:异步与多执行绪与并行不是同一个概念。
◆◆CPU密集型操作◆◆
我听有的同学说，异步解决的是IO密集型的操作，菜菜觉得是不准确的。异步同样可以解决CPU密集型操作，只不过场景有限而已。有一个前提：利用异步解决CPU密集型操作要求当前执行环境支援多执行绪才行，比如javascript这个语言，本质上它的执行环境是单执行绪的，所以对于CPU密集型操作，javascript会显得力不从心。
异步解决CPU密集操作一般情况下发生在同进程中，为什么这么说呢，如果发生在不同机器或者不同程序在很多情况下已经属于IO密集型的范围了。这里顺便提醒一下：IO操作可不单单是指磁盘的操作，所有有输入/输出(Input/Output)操作的都可以泛称为IO。
举个栗子吧：
在一个带有UI的软件上点选一个按钮，UI执行绪会发生操作行为，假如UI执行绪在执行过程中有一个计算比较耗时的操作（你可以想象成计算1--999999999的和），UI执行绪在同步操作的情况下会一直等待计算结果，在计算完毕之后才会继续执行剩余操作，在等待的这个过程中，呈现给使用者的情况就是UI卡住了，俗称假死了，带给使用者的体验是非常不好的。这种情况下，我们可以新启动一个执行绪去执行这个耗时的操作，当执行完毕，利用某种通知机制来通知原来执行绪，以便原来执行绪继续自己的操作。
启动新执行绪执行CPU密集型操作利用的其实就是多执行绪的优势，如果是单核CPU，其实这种优势并不明显
◆◆IO密集型操作◆◆
异步的优势在IO密集型操作中表现的淋漓尽致，无论是读取一个档案还是发起一个网络请求，菜菜的建议是尽量使用异步。这里首先普及一个小知识：其实每个外设装置都有自己的处理器，比如磁盘，所以每个外设装置都可以处理自己相应的请求操作。但是处理外设装置资讯的速度和cpu的执行速度来比较有着天壤之别。
上图展示了不同的 IO 操作所占用的 CPU 时钟周期，在计算机中，CPU 的运算速度最快，以其的运算速度为基准，时钟周期为1。其次是一级快取、二级快取和内存，硬盘和网络最慢，它们所花费的时钟周期和内存所花费的时钟周期差距在五位数以上，更不用提跟 CPU 和一级快取、二级快取的差距了。
由于速度的差距，所以几乎所有的IO操作都推荐使用异步。比如当读取磁盘一个档案的时候，同步状态下当前执行绪在等待读取的结果，这个执行绪闲置的时间几乎可以用蛋疼来形容。所以现代的几乎所有的知名第三方的操作都是异步操作，尤其以Redis，Nodejs 为代表的单执行绪执行环境令人刮目相看。
现在是微服务盛行的时代，UI往往一个简单的按钮操作，其实在后台程式可能呼叫了几个甚至更多的微服务界面（关于微服务这里不展开），如果程式是同步操作的话，那响应时间是这些服务界面响应时间的和，但是如果采用的是异步操作，呼叫方可以在瞬间把呼叫服务界面的操作传送出去，执行绪可以继续执行下边程式码或者等待所有的服务界面返回值也可以。最差的情况下，界面的响应时间为最慢的那个服务界面响应时间，这有点类似于木桶效应。
◆◆异步的回拨◆◆
通过以上介绍，我们一定要记住一个知识点：异步需要回调机制。异步操作之所以能在执行结果完成之后继续执行下面程式完全归功于回拨，这也是所有异步场景的核心所在，前到js的异步回拨，后到cpu核心空间copy资料到使用者空间完成通知 等等异步场景，回拨无处不在。说道回拨大部分语言都是注册一个回拨函式，比如js会把回拨的方法注册到执行的伫列，c#会把回拨注册到IOCP。这里延伸一下，在很多系统里，很多IO网络模型其实是属于同步范畴的，比如多路复用技术，真正异步非阻塞的推荐windows下的IOCP。
现在很多现代语言都支援更优秀的回拨方式，比如js和c# 现在都支援async 和await方式来进行异步操作。
据说windows下的IOCP才是真正的异步非阻塞模型，求评论区验证！
◆◆异步的特点◆◆
优势
异步操作无须额外的执行绪负担，使用回拨的方式进行后续处理，在设计良好的情况下，处理函式可以不必使用共享变数（即使无法完全不用，最起码可以减少 共享变数的数量），减少了死锁的可能。执行绪数量的减少，减少了执行绪上下文在cpu切换的开销。微服务环境（呼叫多个服务界面的情况下）加快了上层界面的响应时间，意味着增加了上层界面的吞吐量劣势
异步操作传统的做法都是通过回拨函式来实现，与同步的思维有些差异，而且难以除错如果当前环境有操作顺序的要求，异步操作为了保证执行的顺序需要做额外的工作由于多数情况下异步的回拨过程中的执行执行绪并非原来的执行绪，所以在捕获异常，上下文传递等方面需要做特殊处理，特别是不同执行绪共享程式码或共享资料时容易出问题。写在最后
在并发量较小的情况下，阻塞式 IO和异步IO的差距可能不是那么明显，但随着并发量的增加，异步IO的优势将会越来越大，吞吐率和效能上的差距也会越来越明显。在压力比较小的情况下，一般异步请求的响应时间大于同步请求的响应时间，因为异步的回拨也是需要时间的在大并发的情况下，采用异步呼叫的程式所用执行绪数要远远小于同步呼叫程式所用的执行绪数，cpu使用率也一样（因为避免了太多执行绪上下文切换的成本）
