做服务器稳定性测试这几年，我最大的感受是：很多人把稳定性测试和压力测试混为一谈，觉得“把请求打满，看服务挂不挂”就是稳定性测试了。真这么干，线上该出的事故一次都躲不掉。稳定性测试的核心，是把系统放在一个持续的、接近真实的负载下，长时间运行，去观察那些慢性的、累积的、平时不会立刻暴露的问题——内存泄漏、连接数只增不减、文件句柄耗尽、缓存穿透越来越严重。这些问题单看某一分钟，一切正常，拉长到几小时甚至几天，系统就一点点垮掉。
这篇文章我不打算念文档，就从实际运维和测试的视角，把我自己验证过的整套方法、踩过的坑、以及每个操作背后的为什么讲清楚。适合刚接手服务端稳定性测试的开发者，也适合已经做过一些压测、但总觉得不够系统的运维或测试同学。
1. 先搞清楚稳定性测试到底在测什么
1.1 稳定性测试和压力测试、负载测试的边界
很多团队在一开始就把目标定错了。压力测试是看系统的极限在哪，负载测试是看在预期容量下响应是否达标，而稳定性测试，看的是时间维度上的“持久”。同一个接口，压测工具打到每秒1000次，跑10分钟，平均响应时间稳定在50毫秒，服务一切正常——这只能说明当前负载下系统是好的。但如果把负载降到每秒400次，连续跑48小时，第三天早上内存占用从开始的2GB悄悄涨到了6GB，GC越来越频繁，响应时间从50毫秒漂移到了200毫秒，这才是稳定性测试要抓的问题。
所以第一件事：稳定性测试不是求快求猛，是求“长”求“匀”。它验证的是一个系统在持续运转过程中的自我维持能力。我一般会用一个很直白的比喻——压力测试是看一个人能举起多重的东西，稳定性测试是看一个人能不能连续走路八小时不崴脚。前者考爆发力，后者考耐力。
1.2 三类必须锁定的核心稳定性风险
根据我多年反复遇到的情况，稳定性问题大部分集中在三类：
资源类泄漏。内存、文件描述符、数据库连接、线程数，某个环节只增不减，最终触发系统的自我保护机制。这类问题一旦出现，系统不是立刻崩，而是性能一点点劣化，直到某个阈值被击穿。
状态类不一致。定时任务重复执行、缓存与数据库数据逐步偏差、分布式节点间心跳状态漂移，这类问题往往和时间强相关，跑短时间压测根本看不见。
长尾请求恶化。系统里总有少数慢请求，短时间看它们占比不高，但长时间运行下，慢请求会挤压线程池、占满队列，最终影响所有正常请求。
明确了这三类风险，后面每一步的测试设计都围绕它们展开，才不会跑偏。
2. 测试环境的搭建与前置准备
2.1 测试环境必须满足的四个条件
稳定性测试对环境的要求，比普通功能测试和压力测试苛刻得多。我踩过最大的坑，就是在配置缩水的测试环境里跑稳定性测试，最后定位到一个“内存泄漏”，结果排查半天发现是测试环境JVM堆配置跟生产不一致，白忙了三天。
建议至少满足这四个条件：
- 配置与生产对齐。CPU核数、内存、磁盘类型、操作系统参数（如文件句柄数、TCP连接参数等）要与生产环境一致或等比例缩小。如果做不到完全一致，至少核心指标必须一致。
- 数据规模接近生产。数据库里的数据量、缓存中的热点数据规模，要按生产数据量的一定比例做初始化。稳定性测试最怕“空库跑”，跑出来全是幻觉。
- 网络拓扑一致。如果生产环境是Nginx到应用再到数据库的三层结构，测试环境别图省事把Nginx去掉直连应用。超时配置、连接池、代理层的各种参数，都会影响稳定性结果。
- 独立的监控和日志链路。稳定性测试跑几天，如果不采集数据等于白跑。监控系统要独立部署，不能因为压测流量把监控系统本身打挂了。
2.2 监控指标怎么选：别只盯着CPU和内存
我见过太多人，一说监控就是CPU、内存、磁盘、网络，这四样当然要看，但对稳定性测试来说远远不够。真正帮助我定位问题的是下面这张指标清单：
| 类别 | 核心指标 | 说明 |
|---|---|---|
| 系统层 | CPU使用率、负载、内存、磁盘IO | 基础指标，任何异常首先体现在这里 |
| 应用层 | GC次数与耗时、线程池活跃数、队列堆积数 | 重点看趋势曲线，不是瞬时值 |
| 资源层 | 文件描述符数量、TCP连接数、数据库连接池占用 | 最容易出现缓慢泄漏的地方 |
| 业务层 | QPS、响应时间P99/P95、错误率、超时率 | 业务感知的直接体现 |
| 端到端 | 定时任务执行时长、日志堆积、缓存命中率 | 长期运行才暴露的问题 |
选指标有一个原则：每个业务指标必须配备一个底层指标作为解释依据。比如我看到QPS正常但P99持续上升，第一反应是查GC和我上面提到的连接池状态；如果P99抖动但GC正常，优先怀疑锁竞争或慢SQL。指标之间要能互相印证，否则排查起来一团乱麻。
2.3 测试工具与场景脚本准备
压测工具方面，成熟的开源方案我常用的是开箱即用的负载生成工具（如经典的并发压测组件或分布式压测平台），可以根据实际协议选择HTTP、TCP或数据库协议脚本。重要的是别用一个线程数固定不变的傻瓜脚本去跑长效稳定性，脚本本身需要有“业务剧本感”。
什么是剧本感？就是脚本里的请求组合、比例、频率，要贴近真实用户行为。比如一个电商系统，稳定性测试场景应该是：
- 70% 浏览商品（GET接口）
- 20% 加购物车与下单（POST接口）
- 8% 搜索
- 2% 极少数的异常操作（超时重试、重复提交）
其中有少部分用户会思考一段时间再操作，所以脚本里要加入合理的思考时间，而不是每秒钟都把并发顶满。真实场景是起伏的，不是一条水平线。
3. 稳定性测试的实施步骤与现场记录
3.1 第一步：先跑基准，拿到“健康基线”
很多人上来就直接加压，跑完发现内存涨了20%，就惊呼“泄漏了”。问题是涨20%可能只是缓存预热或连接池初始化，是正常现象。没有基线，你拿什么判断异常？
我每次做稳定性测试都强制先做半小时基准测试：用预期峰值负载的40%左右的压力，让系统“热身”，记录下各指标的正常范围。这半小时里，内存可能会有一次明显的上涨，线程池会初始化，缓存会逐步填充，这些都属于“出生效应”，不算问题。基线记录的意义，就是把这些正常波动和真正的劣化区分开。
打个比方，基线就是体检时的参考值范围，你总得知道正常血压是多少，才能说谁的血压偏高。
3.2 第二步：阶梯加压，而不是一步到位
正式测试时，我习惯分三到四个阶段把负载加到目标值。这样做有两个好处：一是每个阶梯停留足够时间，观察系统是否在每个档次都能稳住；二是万一系统在高负载下崩溃，你能确定崩在哪个负载区间。
具体节奏可以参考：40%负载跑1小时，70%负载跑2小时，100%负载跑4小时。在每个阶梯结束时，记录关键指标快照，特别关注是否有指标呈现出“上升不回落”的形态。如果发现在70%负载下内存占用每半小时就稳定上涨1%，别急着加满，先停下排查——这种“斜坡式增长”，就是典型泄漏信号。
3.3 第三步：长时间满负载跑批
目标负载跑够时间后，进入最核心的阶段——持续运行。这个阶段的长短取决于业务属性，一般建议至少24小时，金融类或底层基础设施类服务，我会建议跑7天。有一个词叫“浴盆曲线”，多数故障发生在早期（初始缺陷）和晚期（磨损耗尽），中间那段平稳期最安全。跑24小时基本能跨过早期故障区间，但如果想抓慢性的状态类问题，跑48小时以上的价值非常明显。
满负载阶段我要求每小时记录一次关键指标，同时设置自动告警。告警阈值不是“超过多少就报警”，而是“持续超过多少分钟才报警”。稳定性测试里，瞬时尖峰很常见，但持续劣化才可怕。
3.4 第四步：逐步减压，观察指标是否回落
很多人跑到这里就宣布测试结束，其实少了最关键的一步：减压恢复测试。把负载从100%逐步降回20%，观察内存、连接数、线程池等指标是否能回落到接近初始基线水平。
这个步骤测的是系统的“弹性恢复能力”。如果负载降下来了，内存占用却维持在高位，说明资源没有及时释放；如果连接数只增不减，降载后还顶着上限，说明存在连接泄漏。这类问题在长时间运行中比纯内存泄漏更隐蔽，也更危险。
3.5 结果记录与判读原则
整个测试过程要保存三类数据：指标趋势曲线图、日志抽取样本、故障时刻的线程转储和堆转储。判读数据时，我有一条铁律：看趋势，不看绝对数值。某个时刻CPU 80%不代表有问题，但如果CPU使用率在48小时内从30%缓慢爬升到80%，即使还没触发告警，也要高度警惕。
内存趋势方面，可以用一个简单的判断公式：记录每小时的堆内存使用增量，如果连续6小时每小时增量都大于0且没有回落迹象，基本可以判定存在泄漏。判断逻辑是：正常系统在固定负载下，内存波动应呈现平稳或周期震荡，而不是单调递增。
4. 稳定性测试中常见的疑难杂症与排查实录
4.1 内存泄漏：怎么区分缓存、GC问题和真泄漏
内存泄漏是稳定性测试最常抓到的狐狸。但先说一句公道话，很多被当成泄漏的案例，最后证实是“大缓存”或者“对象的合理驻留”。区分两者的方法很直观：
先看GC日志。如果老年代持续增长，但Full GC后能明显回落，这大概率是缓存或大对象在囤积，不属于严格意义上的泄漏。如果Full GC之后内存用量几乎不降，那就是有对象被错误地长期引用，真泄漏实锤。
我处理过的一个典型case：某个消息消费服务，跑了15个小时后内存翻倍。排查线程转储后发现，是消息确认回调里持有上游消息对象的引用，确认完成后没有被释放，导致每条消息对象都在堆里留一份。这种问题单看代码很难发现，因为开发时消息量小，根本感觉不到，但长时间积累就会拖垮系统。定位手段就是：周期性地抓堆转储，对比不同时间点的类实例数量，锁定只增不减的类。
提示：抓堆转储对服务性能有影响，不要在测试的峰值时刻抓取，最好选在阶梯负载之间的低负载窗口执行。
4.2 连接数堆积：从TCP连接到数据库连接池
连接数堆积是另一个高频问题。我见过一个线上事故：应用服务运行几天后，数据库连接池被占满，所有新请求排队等待连接，响应时间从几十毫秒飙升到几秒，最终引发雪崩。
排查这种问题，第一步先看系统层指标：用命令查看当前TCP连接数。如果TIME_WAIT状态的连接数非常多，大概率是服务端主动关闭连接导致，需要检查应用连接池的空闲回收策略；如果ESTABLISHED数持续上涨，则是连接只建不还，优先查代码里的连接获取与释放逻辑。
数据库连接池的排查要多看一层：连接池活跃数、空闲数、等待获取连接的线程数。如果发现活跃连接不高，但池子总量涨到上限，多半是配置了“最小空闲连接数”且回收策略没有生效。这类问题必须靠长时间运行的监控曲线才能看到，短时间压测根本暴露不了。
4.3 文件句柄与临时文件泄漏
文件句柄泄漏比重低，但一旦发生，影响范围非常大。全系统文件句柄到达上限后，不只是当前应用不可用，连同机的其他进程都会遭殃。
我处理的另一个case：日志框架配置成异步写文件，但每个请求都创建一个日志文件处理器，用完后没关闭。跑了一天后，文件句柄数一路涨到系统上限，新请求连日志都写不了，应用假死。排查手段是：测试过程中周期执行系统命令查看进程文件句柄数量，再结合/proc/进程ID/fd目录下的软链接，判断是哪些文件被频繁打开。
临时文件泄漏更隐蔽。应用在运行过程中产生临时文件，正常情况下用完即删，但异常时可能残留。我针对这个问题专门加上一层测试：在测试前后对比临时目录的文件数量，如果持续增长，说明清理逻辑有漏洞。磁盘占用恐慌大多就是这么来的。
4.4 CPU毛刺与长尾延迟的根源
稳定性测试里经常看到这样一种曲线：整体CPU不高，但每隔几分钟出现一次或者多次毛刺，P99响应时间也随之飙高。这类问题排查起来最费心力，因为不是持续劣化，是周期性劣化。
常见的元凶有三个：
- 定时任务与业务高峰重叠，大任务执行的瞬间把CPU打满
- JVM GC，特别是老年代GC，几分钟来一次，每次几百毫秒到几秒
- 外部依赖超时导致线程阻塞，阻塞线程堆积后集中恢复，形成一波延迟高峰
处理方案：拉开定时任务与业务高峰的窗口，优化GC参数，给外部调用设置合理的超时与熔断。注意排查这类问题时，务必把压测机的真实时间、应用日志时间、监控时间放在同一个时间轴上看，否则很难发现毛刺与定时任务的对应关系。
5. 容易被忽略但直接影响测试结论的细节
5.1 测试时长到底定多久
我常被问到一个问题：“稳定性测试跑多久合适？”说实话，没有一个放之四海而皆准的数字，但我会用两个标准来判断：
一看业务周期。如果你维护的是一个交易系统，支付高峰是每天固定的几个时段，至少得覆盖两个完整的业务日周期；如果你的业务有周末效应，还要包含周末。让测试跑过完整的业务波动周期，这是第一原则。
二看资源增长速率。如果测试启动后你发现内存每小时稳定增长0.5%，那么即使跑24小时也只增长了12%，看似不严重，但要预估一下：按这个速率，跑到第几天会触顶？如果答案是第4天，那你的测试时长就至少要覆盖到第4天附近，才能验证触顶之后系统是否具备自我保护能力——比如OOM前是否能优雅降级，还是直接崩溃。
5.2 流量模型不能“太平滑”
很多压测工具的默认模型是恒定速率，但真实的线上流量是会有波峰和波谷的。如果你全程用固定速率跑，测试结论只能说明“匀速运动时是稳定的”，完全验证不了“系统应对突发流量并回落后是否能恢复稳定”。
我的做法是：在长时间运行中，每隔一段时间就注入一次“冲击波”——把QPS在10秒内提升到正常值的2倍，持续2分钟再回落到正常值。冲击之后重点观察指标回稳的时间和是否留下后遗症。如果每次冲击后内存基线都比之前高一截，说明系统存在“不可恢复的漂移”，这类问题能在一轮冲击测试后暴露得淋漓尽致。
5.3 时间同步与日志链路
分布式系统的稳定性测试，时间同步是个基础但容易被无视的环节。节点间时钟漂移会导致日志时间线错乱、分布式事务超时计算不准。测试开始前，务必确保所有压测机、应用服务器、数据库服务器、监控服务器的时间一致，否则排查问题时会走非常多弯路。
5.4 数据清理与重复测试的干扰
稳定性测试跑完后，测试环境会积累大量脏数据、垃圾日志和临时文件。连跑几轮时，如果数据没清理干净，后一轮测试的基线会和前一轮完全不同，结论可信度会大打折扣。
我养成的习惯是：每轮稳定性测试结束后，做一次完整的环境重置——清空业务表数据并重新初始化到预置规模，清空日志文件，重启应用服务，确认各项指标回落到初始基线后再开始下一轮。这个操作虽然麻烦，但它是保证测试可复现、结论可信的基础。
6. 工具与报告：让测试结果有说服力
6.1 压测工具的选择逻辑
压测工具我没有“唯一推荐”，只有“合适推荐”。单机小规模验证，我用轻量级的命令行压测工具就够了，简单直接；需要模拟真实场景、多接口混合、长时间运行，我会用支持分布式施压的压测平台，配合脚本化场景设计。
关键在于：工具本身不能成为瓶颈。如果你用一台压测机压一个高并发服务，压测机自己CPU先跑满了，测出来的结果全是压测机的瓶颈，毫无参考价值。分布式施压或者多台压测机协同，是解决施压端瓶颈的标准做法。
6.2 测试报告的几条输出原则
稳定性测试报告和功能测试报告不同，它要回答的不是“功能是否通过”，而是“系统能否长期可靠运行”。报告里至少包含以下内容：
- 测试环境与生产环境的差异说明
- 基准基线数据与各阶段加压后的对比趋势图
- 资源指标与业务指标的时间线对照（方便复盘）
- 异常事件清单及对应处理过程
- 结论：是否达到稳定运行标准，遗留风险有哪些
报告用图表说话，趋势图比表格有说服力得多。一张内存趋势曲线图，比十句话都更能说明泄漏问题。
7. 我的几点实操体会
最后说几句掏心窝的话。
稳定性测试不是一次性的任务，它应该成为每次重要版本发布前的例行关卡。我经历过的几次重大线上事故，事后复盘都指向同一个结论：如果当时能跑48小时稳定性测试，问题完全可以提前暴露。那些积累性故障，像慢性病一样，平时没症状，发作起来很要命。
再分享一个我自己的小习惯：每次稳定性测试跑完后，我会把整个过程的监控数据归档，标注测试版本号。几个月后如果线上出现性能劣化，我还能翻出历史数据对比，判断是否是某次变更引入的回归。这个习惯救过我很多次。
稳定性测试这条路，没有太多炫技的空间，拼的就是耐心和对细节的敏感。把上面这套方法跑扎实，你的服务在“时间”这位考官面前，会从容很多。
