在过去的一年里，我一直致力于Java和flex。在编写flex时，我的大多数代码部分都是异步的。这让我想到了同步执行语言与异步执行语言的真正优缺点。
与其他相比，它们更强大的区域是什么？它们落在哪些区域？
答案 0 :(得分：7)
我去年大部分时间都在Silverlight上编码，这意味着我花了很多时间思考（并与之抗争）你所描述的相同问题。
简而言之，正如其他人所指出的，异步模型的真正优势在于它能够创建与现实世界良好互操作的强大系统。如果UI线程在每次花费几秒钟时间停止以返回Web服务时，没有人能够真实地使用Silverlight（或Flash）应用程序。
最大的缺点是结果代码复杂且难以排除故障。错误处理之类的东西是PITA，但我必须处理的最烦人的事情是协调来自多个异步调用的响应。例如，如果您在拨打电话B之前需要来自呼叫A的信息，并且在拨打电话C之前需要来自呼叫B的信息（等等），则生成的代码看起来非常不愉快，并且容易受到各种奇怪的副作用的影响。 。有一些技术可以使所有这些东西都有效，甚至可以相当干净，但是如果你来自同步世界（就像我一样），这是一个重要的学习曲线。 （在我认为回调时，微软推动事件作为处理WCF调用的方式并没有帮助，因为它更清晰，更不容易受到我所讨论的那种奇怪的副作用的影响。）
（是的，其他人都说正确的语言不是异步语言，因为特定的框架需要以异步方式构建代码 - 但我理解你的意思。）
更新2014.09.23 -
自从我写了上面的答案之后，我已经做了很多关于各种异步框架的工作（可能是其他所有人都做了网络编码），并且我想添加一些额外的随机笔记：
如果你使用的是像C＃或F＃这样具有一流异步支持的语言，那么一旦你绕过那些奇怪的{{1}，你的很多东西都会变得容易多了。 } / async模式。能够在异步调用中轻松循环，并用简单的await包装整个事物，如果您不得不以旧的方式进行操作，那就太棒了。
如果您没有使用具有一流异步支持的语言，请开始使用该语言提供的任何try/catch或promise或future支持（例如， JQuery的task或Angular的$.Deferred()。这些更清晰，并且提供的结构比你通常使用回调的结构更好。
异步代码对于编写可伸缩的服务器端系统至关重要。使典型的Web服务器扩展得很好的一个最大问题是它开始耗尽线程，至少，如果它专门用一个线程来达到传入的请求就会这样做。如果该线程停止，因为它正在等待长时间运行的同步调用完成，它完全无法帮助解决其他问题。更好的方法是使您的Web服务器代码异步，这样当您等待数据库调用返回时，该线程可以在数据库运行时执行其他六个请求并执行任何数据库操作。此时，对于高度可扩展的系统，异步是城里唯一的游戏。 （只要询问任何节点爱好者。）
答案 1 :(得分：3)
（暂且不谈语义级别的讨论，即“同步/异步语言”）
基于“语言”构建的“框架”（无论它是什么）应该能够处理这种情况（同步/异步程序流）以便有用（阅读：$ wise）。
异步习语适用于各种规模。
在大规模，异步技术有助于构建可靠的系统，因为现实世界无论如何都是异步的。换句话说，人们需要在“异步思维”中思考，以应对失败，损失，延迟等现实生活中的情况。
即使在较小规模（例如GUI应用程序）上，事件（例如“鼠标点击”）也倾向于“异步”。当然，它们在某些时候被“序列化”（为了由运行某些软件的应用程序来处理）但它并没有改变事件（可能）发生的事实 关于有关节目的流程，“异步”。
答案 2 :(得分：1)
我认为这不是关于语言，而是关于框架。
反例：
当用C语言编写'Classic Mac'（MacOS 9及更早版本）应用程序时（如果有的话，是'同步'语言），您没有抢占式多线程，因此所有可能阻塞的系统调用都有异步对应，在哪里用参数包括回调函数填充数据块。然后你进行系统调用（它会立即返回），你的回调将被异步调用（在所谓的'中断级别'）。回调会执行另一个异步系统调用并创建一个与主要异步运行的长后台线程并不罕见。