前篇回顾：上一篇虫子给大家介绍了线程安全中容易出错的地方 内容不深 引发大家的思考与关注 看似简单的小程序可是为引发大麻烦的额 ~ ~
下面虫子给大家介绍下web应用范围的应用程序池、线程池以及数据库连接池中容易出现的问题
首先来看应用程序池
你的session丢失了吗？！ 有 当然有 不过我们一般都是设置超时时间或者新版本更新修改了配置文件导致丢失的。好吧，可以预见的异常虫子就不和大家多扯了。
应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔，所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。（概念又见概念、枯燥的东西( ⊙ o ⊙ )）
下面详细的概念虫子就不具体说了 几张图送上 有什么功能自己琢磨下
下面是重点了 看到了没 那个回收工作进程
IIS 将应用程序分散到隔离的池中，并自动检测内存泄漏、有缺陷的进程和过度利用的资源。如果发生问题，IIS 通过关闭然后重新部署有问题的资源并将有问题的进程连接到解析工具上进行管理。亮点来了
工作进程回收如何工作
1.默认情况下，WWW 服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。
2.WWW 服务可以终止一个工作进程，然后启动一个新的工作进程（如果工作负荷允许执行此操作的话）。
何时使用工作进程回收
1.无法修复 Web 服务器上您所主控的有故障的应用程序。
2.遇到不能确定的或间断性的故障。
3.应用程序由于性能监视的原因而泄漏内存。
4.先前已实施了临时性的重置解决方案，例如，计划执行 IISReset 命令行实用工具。
说得笼统点，我们经常碰到的就是：工作进程虚拟内存或者W3wp.exe 进程使用的内存达到阈值（session总体积过大）、未关注应用程序池时间配置
解决这类问题一方面可以禁用工作进程回收
在上图“回收”选项卡上，清除“回收工作进程（分钟）”复选框。
另外也可以改变session的存储方式
<sessionState mode=
"InProc"
stateConnectionString=
"tcpip=127.0.0.1:42424"
sqlConnectionString=
"data source=127.0.0.1;user id=sa;password="
cookieless=
"false"
timeout=
"20"
/>
|
将inproc（进程模式）改为StateServer，也就是将会话数据存储到单独的内存缓冲区中（这个最常用）或者改为SQL Server进行数据库会话管理。
本文转自 熬夜的虫子 51CTO博客，原文链接:http://blog.51cto.com/dubing/712449
