上周三凌晨两点，漏洞运维群里跳出一条告警：订单导出接口响应时间从平均800毫秒飙到12秒。排查值班同事重启了服务，整改指标回落，结果大家各自睡去。漏洞第二天上午十点，排查同样的整改接口再次卡死，这次连带着数据库连接池也满了。结果没人再敢点重启。漏洞

问题定位花了整整一个下午。排查表面看是整改慢查询，但慢查询日志里那条SQL平时跑得好好的结果。用arthas挂上去看线程栈，漏洞发现大量线程堵在ZipOutputStream.write。排查奇怪，整改导出逻辑半年前就上线了，一直没动过。翻提交记录才注意到，三天前有个小伙子“优化”了导出代码，把原来的分批写入改成了全量内存压缩。他说是想减少IO次数，测试环境跑十万条数据没问题。生产环境单次导出量经常在五十万条以上，堆内存直接被打满，GC疯狂停顿，连带拖垮了整个应用。

这属于典型的“测试环境容量错觉”。我见过太多类似案例：开发在本地用几千条数据验证通过，就认为逻辑正确。容量问题从来不是逻辑问题，它是物理问题。内存就那么大，CPU就那么多核，你写代码时假设的“数据量不大”在真实场景里往往不成立。那个小伙子后来在复盘会上说，他以为分批写入的“批”是性能瓶颈。实际上那个批大小是经过压测调优的，每批五千条，正好匹配数据库游标读取速度和网络缓冲区大小。

整改动作分三步走。第一步回滚代码，这个最快，五分钟搞定。第二步把导出任务从主应用剥离，单独部署一个低配实例专门跑导出，防止再次拖垮核心链路。第三步才是真正有长期价值的：给导出接口加硬限制——单次最多二十万条，超出部分引导用户走异步任务。异步任务底层还是分批压缩，但每批处理完主动System.gc()？不，那太粗暴了。我们改成了每批处理完显式释放缓冲区引用，并监控老年代增长速率。超过阈值自动降级为流式输出，不再压缩。

排查过程中还挖出一个隐藏问题。那个慢查询SQL在特定参数下会走全表扫描，因为优化器选错了索引。平时数据分布均匀时没事，赶上月初某类订单集中生成，统计信息没来得及更新，执行计划就崩了。DBA后来加了一个强制索引提示，同时把统计信息收集频率从每天一次改成每四小时一次。这事让我想起以前一个前辈说的话：数据库优化器不是神，它也会犯错，你得给它兜底。

整个整改周期四天。上线后观察一周，导出接口P99稳定在1.5秒以内，数据库连接池峰值下降四成。那个小伙子没被处罚，但被要求写一份容量评估报告，把导出功能涉及的所有资源上限都算清楚。他算了两天，交上来的表格里有一栏写着“单条订单平均序列化后大小：2.3KB（含商品明细）”。这个数字以前没人关心过。

漏洞排查最怕两种态度。一种是“重启能解决的事都不叫事”，另一种是“测试环境没问题就是没问题”。前者掩盖症状，后者制造幻觉。真正有用的做法是：每次故障后追问一句“这个假设在什么条件下会失效”。导出功能假设数据量可控，那个假设的边界在哪里？没人知道，直到它被撞破。

现在我们的监控面板上多了一个指标：导出任务内存放大系数。正常值在1.2左右，超过1.8就告警。这个系数是实测出来的，不是拍脑袋定的。它比任何代码审查都管用，因为数字不会说谎。

(责任编辑：休闲)