题目：面试官问：你们压测时经常会「丢弃前几分钟的数据」，为什么？如果不丢弃会怎样？另外，你怎么判定系统已经进入稳态、可以开始取数？
难度：中级 题型：面试口述题
参考答案/答题要点：
1. 为什么前段数据不能要 冷启动阶段系统还没进入真实工作形态，指标严重失真：
- JVM/Go runtime 的 JIT 与分支预测未优化，首批请求 RT 可能是稳态的几倍甚至十几倍；
- 数据库连接池、Redis 连接、下游 RPC 长连接要现场建连，TCP/TLS 握手成本全压在首批请求上；
- 本地缓存、分布式缓存全 miss，流量直接打到 DB，DB 的 buffer pool 也是冷的，命中率低；
- GC 尚未形成稳定节奏，回收停顿的分布和稳态不一样；
- 服务注册发现、熔断降级、限流阈值的滑动窗口还没填满，行为不代表常态。
直接后果：前段 P99 虚高、TPS 上不去（还在爬坡）、错误率虚高（连接超时），算出来的整体均值和分位数都不置信，容易得出「不达标」的错误结论。
2. 怎么判定稳态
- 看曲线拐点：TPS、RT(P95/P99)、错误率、CPU、内存、GC 频率、下游连接数、队列积压，连续若干个采集周期（如 5 个 10s 点）波动在 ±5%~10% 内；
- 内存要区分「锯齿平稳」和「单调爬升」，后者是泄漏信号，不能当稳态；
- 兜底口径：固定预热时长，经验值 5~10 分钟，或取前 10%~20% 数据剔除，取决于压测总时长；
- 工具层面：JMeter 需在报告阶段手工截断时间窗，Gatling/hey 同理——分位数一定只用稳态窗口重算，不要信工具默认的全程汇总。
3. 反向加分点
- 「预热性能」本身是一个要单独出结论的指标，不是垃圾数据：冷启动达标时间、HPA 扩容后新实例多久能正常承接流量；
- 长时间稳定性测试（soak）还要盯后段：前段稳不代表后段稳，句柄泄漏、日志打满、数据量膨胀导致索引退化都在后半程暴露；
- 压测机自身也要预热并单独监控，否则会把压测机的 GC 抖动误判成被测服务的性能问题。
