这也就意味着用户的查询会被阻塞，等待监控查询完成，从而导致用户查询堆积起来。当用户查询变慢或者暂时停止等待超时时，它仍然会占用一个用户数据库的数据库连接，而且应用服务器上执行的线程依然会消耗服务器上的内存。随着越来越多的用户线程开始停止，等待它们的监控调用超时，用户数据的连接数可能会被耗尽，这样其他非监控类的查询就不能再连接到用户数据库上。并且应用服务器上的线程需要把数据写回硬盘来释放内存，这样就会造成服务器上的内存交换。这种交换会使所有的处理变慢，还可能会使应用服务器的TCP堆栈达到上限，以致拒绝之后的连接。最后，新的用户请求将得不到处理，用户只能坐等浏览器或应用超时。从本质上来说，你的应用或平台已经停止工作了。如你所见，究竟是采用同步调用还是异步调用，这样-一个小疏忽就会轻松地造成一系列糟糕的事件。 这个场景当中最精糕的一点在于，造成问题的根本原因很隐蔽。由于我们是逐步探讨了这一系列事件，所以要理解问题所在相对比较容易，但如果系统的症状表现为系统载人Web页面开始变慢，在接下来的15分钟内，这种情况越来越严重，直到最后整个系统停止了运行，要诊断这个问题是非常困难的。或许你有足够的监控信息来帮助你诊断这些类型的问题，但是当你的站点停机了，而你又急于让它恢复服务时，要搞清楚这一系列事件的真相是倍有压力的。
尽管使用同步调用不当或过度会造成问题，但方法调用还是常常采用同步方式实现。为什么会这样?答案在于，同步调用比异步调用简单。你或许会补充说，“等等，同步调用的确更简单一些，不过更经常情况的是，我们的某些方法需要其他的方法先被调用才能成功完成。因此，我们不能在系统中使用大量的异步调用”。是的，的确如此。许多时候，你的确需要等待被调用的方法完成，并需要知道某些状态才能让线程继续运行。我们不是要告诉你所有的同步调用都不好，事实上，许多同步调用都是必需的，它们会让开发人员的日子简单得多。但也有许多时候，即使存在上述的依赖性，也是可以使用异步调用，并且应该使用异步调用来代替同步调用的。如果主线程不太关心被调用的线程是否完成了，例如监控调用，那么只需用一个简单的异步调用即可。如果你需要被调用的线程提供一些信息， 又不想妨碍主线程的执行，那么可以采用回调来获取这些信息。关于回调的详细介绍已经不在本书的范围之内了。回调功能的一个示例是，操作系统中用于报告硬件状况的中断处理例程。
异步协调
原方法与被调用的方法之间的异步协调和通信需要一种机制，以便原方法确认被调用的方法何时执行完毕或者是否执行完毕了。回调是一种方法，它们会以参数的形式传递给其他方法，
以便去除代码中不同层之间的耦合。在C和C+中，这是通过函数指针实现的；在Java中， 则是通过对象引用实现的。有许多设计模式都使用了回调，例如委托设计模式和观察者设计模式。高层的进程会充当低层的客户，通过传递引用来调用低层的方法。一个回调方法被调用的示例可以是像文件系统改变这样的同步事件。
在.NET框架中，异步通信的特征是使用了BeginBlah，其中Blah就是该方法的同步版本的名字。判断一个异步调用是否完成了的方法有四种:
第一种是轮询(IsCompleted属性)；
第二种是回调方法Delegate；
第三种是方法AsyncWaitHandle，等待调用完成；第四种是方法EndBlah，也是等待调用完成。
不同的语言提供了不同的方案来解决异步通信和协调问题。你需要了解你的语言和框架提供了什么解决方案，这样才能在需要的时候实现它们。
在上段中我们说过网站制作同步调用简单，因此使用同步调用的情况比使用异步调用的I彩得名。虽然这是事实，但它只是工程师忽视了同步调用的影响的部分原因。另部分原因是开发人员通常只看到小部分。在一个组织中，只有非常少的几个人能够览应用的全貌。你的架构师肯定应该他看到个局的应川，同样地，管理团队应该也可以看到。你必须依靠他们来解决难题，并解释同步调川会造成哪些扩展问题。
本文地址：//www.qlpinke.com//article/3900.html
