如何调整IIS托管InstanceContextmode设为Single的WCF服务生命周期管理方式

WCF设置的InstanceContextMode.Single，仅控制WCF运行时内部对服务实例的复用规则，完全无法干预底层宿主的生命周期。只要托管该服务的IIS应用域、应用池触发回收或重启，哪怕是单例模式的WCF服务也会被强制卸载，之前存在单例内存里的所有状态会被完全清空。这也是很多开发者配置了单例服务后，还是遇到服务定期“丢失状态”的根本原因。

应用池配置优化（覆盖90%以上的非预期重启场景） #

这部分调整是最核心的，因为IIS的自动回收绝大多数是从应用池层面触发的：

• 关闭固定时长自动回收：找到托管WCF服务的对应应用池，进入“回收”设置页，将默认的“固定时间间隔（分钟）”参数（默认值1740，也就是连续运行29小时就强制回收进程）修改为0，直接禁用按运行时长触发的定期回收。
• 关闭闲置超时回收：进入应用池的“进程闲置”配置项，将默认的“空闲超时（分钟）”参数（默认值20，也就是连续20分钟没有收到请求就回收应用池）修改为0，避免低流量时段应用池主动卸载服务。
• 调整内存阈值回收规则：还是在“回收”配置页，根据服务实际运行的内存峰值，大幅调高私有内存、虚拟内存的回收触发阈值——默认的阈值通常远低于单例服务长期运行的内存占用，很容易触发非预期回收；如果服务内存占用长期稳定，也可以直接关闭这类基于内存指标的回收触发规则。
• 清空定时回收计划：在回收配置的“特定时间”标签页，删除所有预设的固定时间点回收规则，避免运维窗口的固定回收操作打断单例服务运行。
• 关闭文件变动触发的回收：调整应用池配置，关闭“检测到web.config、bin目录文件变动即触发回收”的默认逻辑，避免部署文件替换、临时日志写入等操作意外触发服务重启。

应用域层面的补充阻断 #

哪怕应用池配置正确，应用池内的应用域也可能独立触发卸载，需要通过服务目录下的web.config补充配置：
在web.config的<system.web>节点下添加如下参数，关闭文件变动触发的应用域卸载逻辑：

<httpRuntime 
  waitChangeNotification="0" 
  maxWaitChangeNotification="0" 
  shutdownTimeout="30"
/>

默认状态下，IIS会监控web.config、bin目录的文件变动，检测到变动后会等待一段时间、处理完在途请求就直接卸载应用域，上述配置会阻断这个自动卸载流程，避免微小的文件操作就把单例WCF实例冲掉。同时需要调整应用域自身的闲置卸载超时，确保应用域不会在低流量时段提前卸载。

• 配置调整完成后，可以在WCF单例服务的构造函数里加一个全局静态计数器，每次实例初始化时计数器加1，通过服务接口把计数器值返回给调用方，就能直观判断服务有没有发生非预期的重启。
• 如果调整完所有IIS配置后，还是遇到不受控的重启（比如系统补丁安装、服务器例行维护触发的进程终止），可以考虑把WCF服务从IIS托管切换为Windows服务自托管，彻底脱离IIS的生命周期管理体系对单例实例的影响。

内容的提问来源于stack exchange，提问作者stovpc