凌晨两点十七分，服务我盯着屏幕上那行红字——“应用程序错误，器上位于0x7c9316c5”，出现程序错误咖啡杯在鼠标垫旁边凉透了。应用这不是服务第一次了，上周三也是器上这个时间点，同一个错误码，出现程序错误同一个进程。应用服务器日志显示内存溢出前，服务CPU占用率从12%瞬间跳到97%，器上然后一切归零。出现程序错误

那台戴尔PowerEdge R740已经连续运行了214天，应用风扇声音像一台老旧洗衣机。服务我本来以为重启就能解决，器上结果第二天凌晨两点十五分，出现程序错误同样的错误又来了。这让我想起一个老运维的话：“服务器不会撒谎，它只是在用崩溃告诉你，你之前忽略了什么。”

查了事件查看器，发现是IIS工作进程w3wp.exe反复崩溃。再往前翻，应用程序池“ERP_Production”在崩溃前六分钟回收过一次。回收本身正常，但紧接着有大量Session状态需要重新加载——代码里用了InProc模式存储用户会话，一旦进程回收，所有会话数据全部丢失，页面再访问时就会触发空引用异常。

说白了，这是典型的“定时炸弹”架构。开发图省事，把会话状态放在进程内，觉得用户量不大无所谓。可服务器不是开发笔记本，它要同时扛住几百个并发请求，内存里的对象引用关系复杂到连GC都处理不过来。我甚至能想象那段代码长什么样：一个静态字典存用户购物车，没有加锁，没有过期清理，日积月累就成了内存黑洞。

解决过程倒不复杂。改了三处：第一，会话状态迁移到SQL Server，代价是每次请求多一次数据库往返，但换来进程回收不丢数据；第二，给那个静态字典加了ConcurrentDictionary，并设置绝对过期时间；第三，把应用程序池的“闲置超时”从20分钟改成0，避免空闲回收误伤长连接。

改完部署，监控了整整一周。错误日志再没出现过。但有意思的是，那台服务器的内存占用率反而降了15%——原来之前的内存泄漏一直在悄悄蚕食资源，只是没到临界点而已。

后来我跟同事开玩笑说，服务器上的应用程序错误就像慢性病，表面是突然发作，其实是日积月累的坏习惯。代码里每一处“先这样吧”的临时方案，都在给未来的崩溃埋单。那次之后，我养成了个习惯：每次部署前，先看代码里有没有静态集合、有没有非托管资源没释放、有没有把大对象放在高频访问路径上。

最后说句实在的，别迷信什么高可用集群、负载均衡，基础代码质量不过关，上再多机器也只是让错误分散得更均匀。服务器报错不可怕，可怕的是你以为重启就能解决，然后继续睡个安稳觉。它下次还会来，而且通常会挑你最不想它来的时候——比如凌晨两点十七分。