异步编程不仅仅是一种编程技巧，更是一种哲学。虽然，您的最后一个问题主要是关于编程方面的问题，但是我的回答是一个孤立的孤独症，因为它基本上是理论性的，但我想为您提供一个崭新的观点，而不是参考，而是基于相同的观点。
这是关于异步编程为什么以及如何进行编程的一些基础知识。
假设您去一家面包店（并假设在订购后将准备好蛋糕）-您有两种选择，要么选择等待直到蛋糕准备好，要么下订单然后回到家中取货稍后准备就绪。第一个（等待）是同步方法，后来是异步方法。不用说此示例提供了很好的参考，为什么您应该在同步上使用异步方法。
基于事件的编程只是构建异步系统的一种方式，它不仅是一种有用的设计模式，而且还是一种体系结构模式。我列出了以实际有用的方式使用该理论的情况-希望可以带来一些清晰度
异步系统的第一个示例是Unix系统IO。虽然我们知道read()，write()甚至select()调用块的程序流程，但操作系统里面，他们是异步的，即内核通常知道块设备（又名硬盘）将需要一些时间来填充缓冲，直到这种时候CPU是免费的从那个相应的线程开始，因此线程被保留为（未就绪）。请参阅1. Moris Bach“ Unix操作系统的设计”
另一个最常见的示例是大多数UI框架。在此，首先通过控制器调度所有用户的点击，然后控制器又回调相应的应用程序。重要的是，此类回叫不应让回叫等待，否则系统将冻结。如果从UI控制器到后端的回调涉及大量处理，则它们通常是异步的。
异步编程（作为纯设计模式）的另一个很好的例子是Active Object。活动对象是具有自己的私有线程的对象，因此一个对象可以将许多请求保留在队列中并一个接一个地执行。参考本文：活动对象。从企业软件到移动框架，这种模式都被大量使用。流行的Java / EJB和.NET 平台允许本地或远程异步方法调用，这实质上允许普通对象成为活动对象。活动对象早在Symbian中就存在了：Aapo Haapanen撰写的Symbian OS中的活动对象（另请参见：Symbian中的活动对象）。现在也存在于Android）。
除了Active对象，同一位作者Douglas C. Schmidt产生了许多其他作品，这些作品与Active对象其他相似之处，并且也是异步模式。请参阅此事件处理模式，并且可以在他的《面向模式的软件体系结构：并发和联网对象的模式-V2》一书中找到完整的论述。
当给定的对象需要在后台工作以实际完成工作的同时返回API 时，通常的方法是使用多线程系统来实现此目的。从C（posix），C ++（boost）到Java，C＃等到处都有线程系统。Active Object本质上只是一个可以隐藏它的抽象。了解为什么 Active对象实现优于裸线程。另一个不错的读物。
但是，这个概念超越了应用程序内部的线程或对象而变得异步。最好的用法之一是在分布式系统中，其中两个应用程序不一定需要彼此等待协调。老旧的（或不太好，无论您以哪种方式查看）RPC是同步的。[当然，还有其他异步RPC ]。但是，现代的替代方案，例如面向消息的中间件，确实有很好的异步性。
最后但也是最有趣的一个是可以从异步通信模型中受益的Agents编程。
尽管异步编程确实看起来很性感，但它却产生了自己的复杂性，其中包括：
- 返回值传递的框架
- 额外的通讯开销
- 同步构造的额外需求
- 如果操作不正确，则可能出现死锁，赛车等情况。
... 等等。
仅应出于真正原因使用它。
那么什么时候应该使用异步模型呢？什么时候应该放一个后台线程并允许调用者进行异步操作？适用时有一些好的经验法则（但不完整）
当系统要应用严格的严格资源对话时：例如，您要保持绝对固定数量的线程。异步模式强制系统执行队列。
当呼叫者需要做“其他有用的事情”时，确实是真实的。如此多次，另一个线程即使进行了解除阻塞，也无济于事，并徘徊在轮询结果的过程中。与基本同步模型相比，这确实会消耗更多的CPU。
在分布式系统中需要更高级别的可靠性时。（请参阅面向消息的中间件）。