监控图上那条缓慢上扬的内存曲线，常常比瞬间飙到百分之百更令人棘手。突然打满至少能马上触发告警，而缓慢爬升可能延续数日乃至数周，业务表面上毫无异样，直到某次流量高峰叠加才暴露问题。更麻烦的是，重启服务后曲线归零，不少人就此认定已经处理完毕，实际上只是把观察起点重新拨了回去，泄漏的根因依旧留在原处。在网站托管场景中，这类情况需要一套固定的收敛顺序，而不是靠反复重启碰运气。
先判断是真实增长还是泄漏
第一步不是翻代码，而是把内存曲线和业务量叠在同一张图上看。调出同一时段的请求量、活跃连接数、新建连接速率，观察三条曲线是否同步。若请求量上升时内存随之上升、请求量回落后内存也相应回落，多半属于业务增长或缓存预热带来的正常占用。若请求量平稳甚至下降，内存却持续攀升且不回落，才更接近泄漏特征。这里有一个实用判断：取两个相隔较远的低峰时段作对比，业务量相近而内存基线明显抬高，就值得继续往下查。
从进程到队列逐层收窄
确认异常后，按从大到小的顺序逐步收敛。先看进程层面，对比各进程的内存占用排名，确认上涨集中在哪个服务，排除同机其他程序的干扰。再看线程与协程，观察线程数是否同步增长，线程栈占用是否异常。接着看连接，统计长连接数量与连接存活时长分布，连接只增不减往往意味着回收逻辑存在问题。然后看缓存，检查本地缓存和共享缓存是否设有上限与过期策略，无上限的字典式缓存是常见来源。最后看队列，确认消息队列、任务队列、待处理请求是否持续积压，积压会连带持有大量对象。每一层都记录可观察指标，避免凭印象下结论。
一份可复用的排查记录表
排查过程建议落成表格，字段包括观察时段、对照指标、当前结论和后续动作。例如某时段记录请求量与内存的比值，结论为疑似泄漏，动作为继续观察连接层；下一时段记录连接数与线程数变化，结论为连接未回收，动作为检查超时配置。每次只改一个变量，改完至少观察一个完整业务周期再判断效果。这样即使问题跨天跨周，接手的人也能顺着记录继续，而不必从头再来。
计划性重启只能算临时缓解
在根因未定位前，安排低峰期重启可以作为缓解手段，但必须配合两件事：一是重启前保存内存快照或导出关键指标，保留现场；二是重启后设定复查时间点，确认曲线是否重新抬升。如果重启后一周内曲线再次上行，说明问题并未解决，不能把重启当作结案。把每次重启的原因、时间和效果记入运维日志，才能避免同类问题被反复掩盖。
网站托管的价值不只在于机器在线，更在于问题可追踪、处理有章法。it数运在维护思路中强调先观察再动手、先记录再变更，让每一次排查都留下可复用的依据。内存缓慢上涨这类问题，最终依靠的不是某个技巧，而是一套稳定执行的顺序和清晰的记录习惯。
