Web中使用多线程来增强用户体验

　　你是不是想说：在页面调用webservice的时候，直接调用其异步实现不就完了吗?

　　这其实是行不通的，为了实现异步调用，我们需要对页面进行小小的改动，在Page元素里加上Async=true

　　我们很快就会发现这样做的问题：

　　让我们测试一下吧，现在我们在一个webservice的Helloworld方法中放入一个Thread。Sleep(10000)，然后调用他的异步实现。通过调试，我们可以发现虽然程序运行至HelloworldAsync时，非常快速的返回并往下运行，但是当所有逻辑处理完成后，页面并不Response，而是硬生生等待我们的线程睡醒了才返回。

　　可是如果我希望真正做到调了不管怎么办呢?

Web中使用多线程来增强用户体验

　　你可以使用Thread，或者ThreadPool，自己来启动一个线程，我推荐使用ThreadPool，这样的话，这些线程都会被iis的线程池管理起来，不会造成崩溃

　　我们来分析一下这两种模式的运用有什么特点

　　WebService自带的异步模式为下图的模式

Web中使用多线程来增强用户体验

　　主线程调用子线程执行一个耗时操作(work1)，同时执行一系列同步操作(w2...w5)，然后交给w1返回

　　这种模式适合于work1有返回的情况，并且为了让work1得到充分的工作时间，异步调用的过程开始的越早越好，对web程序设计者而言，这里有一个很重要的问题：线程占用。。

　　刚才我们谈过，asp.net中每个请求都会有有一个线程来处理，而可以使用的线程是有限的，服务器会使用一个线程池来管理线程，当线程耗尽，ok，新来的请求只能蹲着排队，所以对web开发者而言，线程是个宝贵的资源，所以这个方案在并行处理的同时也增加了耗尽线程池的风险，毕竟一个请求造成了多个线程

　　用线程池来实现的模式属于下图

Web中使用多线程来增强用户体验

　　这种模式适合无返回的情况，这种情况下，对子线程的调用应该越晚越好，我们可以看到，主、子线程共存的时间越短，我们的稀缺资源线程就越安全，请注意的是，也许总的执行时间不会比同步的情况更少，但是我们很快就返回了用户界面，所以用户体验能够得到提高

　　使用web多线程的缺点 ：

　　看了上面的叙述,你也许会说,那干脆把我所有的调用都改成异步调用吧,你尽管去做吧,绝对是一场灾难,因为在异步的同时,一定一会产生一个新的线程等待调用的返回,即使你调用函数的返回值为void,所以异步调用的负面效果将是会产生许多子线程,所以注意当你的调用非常耗时,这个子线程也将长期占用你的线程池,如果这样的调用大量出现,照样会消耗掉所有的可用线程

　　那么什么情况下适合在web上使用哪种多线程模式呢

　　我们来看看这段伪代码,他的用途是提交一个报告,方法传入一个报告,并从一个WebService中获得一些报告的内容,接着插入数据库,然后在文件服务器上生成一个报告文件,最后发出一个通知,让我们逐条命令的过一下这个方法,看看什么地方适合改为异步调用?(记得我们的讨论都是基于web的,关于桌面运用的多线程请参考 多线程总结一)