2. 并发性能指标体系

在并发系统的性能分析中，单看一个数字几乎无法说明问题。一个系统“每秒处理 8000 个请求”听起来不错，但如果每个请求的 P99 延迟高达 2 秒，用户体验依然糟糕；反过来，延迟很低但吞吐量上不去，系统容量又无法支撑业务增长。因此，工程上需要一套相互关联的指标体系，把“快”“多”“稳”“能扩展”这些模糊感受翻译成可测量、可比较、可优化的量。

吞吐量、延迟与响应时间：三个最基础也最容易混淆的量

吞吐量（Throughput）指单位时间内系统成功完成的请求数或事务数，常用单位是 req/s、TPS 或 QPS。它衡量的是“系统整体能处理多少工作量”，是一个面向系统容量的指标。

延迟（Latency）通常指单个请求从发出到收到响应所经历的时间，单位是毫秒或微秒。延迟关注的是“单个请求等了多久”，是一个面向用户体验的指标。在并发场景中，延迟往往用分位数描述，例如 P50、P95、P99，因为平均值会掩盖长尾。

响应时间（Response Time）与延迟高度相关，但工程语境中常把响应时间理解为“服务端从接收到请求到返回响应”的处理时间，而延迟可能包含网络传输、排队、客户端处理等端到端环节。二者是否等同，取决于测量点在哪里。做性能分析时，必须先明确测量边界，否则数据无法横向比较。

并发度：被低估的关键变量

并发度（Concurrency）指系统在某一时刻同时处于处理中的请求数量。它不等于线程数，也不等于连接数，而是“真正在推进的工作量”。根据利特尔法则（Little's Law），在稳定系统中：

并发度 = 吞吐量 × 平均响应时间
L = λ × W

这个公式非常实用。例如，某服务实测吞吐量为 2000 req/s，平均响应时间为 50 ms，那么平均并发度约为 2000 × 0.05 = 100。如果线程池只有 50 个线程，就说明大量请求在排队，线程数已成为瓶颈；如果线程池有 500 个线程，则说明线程利用率很低，可能存在锁竞争或 I/O 阻塞。

利特尔法则把吞吐量、延迟、并发度三者绑定在一起，任何一个量的变化都会牵动另外两个。这也是为什么性能调优不能只盯一个指标。

可扩展性、加速比与效率

可扩展性（Scalability）描述系统在增加资源（CPU、线程、节点）时，性能能否按预期提升。它通常用“加速比”来量化。

加速比（Speedup）定义为：

S(n) = T(1) / T(n)

其中 T(1) 是单资源下的执行时间，T(n) 是 n 个资源下的执行时间。理想情况下 S(n) = n，即线性加速。但现实中几乎不可能，因为存在串行部分、通信开销、锁竞争和资源争用。

效率（Efficiency）则进一步衡量资源利用质量：

E(n) = S(n) / n

当 E(n) 接近 1 时，说明增加资源几乎全部转化为性能收益；当 E(n) 明显下降时，说明扩展的边际收益在衰减。工程上，效率比加速比更能反映“值不值得继续加机器”。

阿姆达尔定律：串行部分决定扩展上限

阿姆达尔定律（Amdahl's Law）给出了加速比的理论上限。设程序中不可并行的串行部分占比为 p，则可并行部分为 1-p。使用 n 个处理器时：

S(n) = 1 / (p + (1-p)/n)

当 n 趋于无穷时，S(n) 趋于 1/p。也就是说，如果串行部分占 10%，那么无论加多少 CPU，最大加速比也不会超过 10 倍。这个结论对并发系统设计有直接指导意义：优化并发代码之前，先找出串行瓶颈——它可能是全局锁、单点数据库、共享队列，也可能是日志写入或序列化环节。

下面这张图把本节的核心指标关系、利特尔法则与阿姆达尔定律的约束放在同一张关系图中，便于对照理解。

工程含义：指标之间如何互相牵制

把这套指标放到真实系统中，会看到几个典型的工程规律。

第一，吞吐量与延迟通常不是同向变化。在低并发区间，增加并发度可以同时提升吞吐量并保持延迟稳定；但超过某个拐点后，继续增加并发度只会让请求排队，吞吐量趋于饱和甚至下降，而延迟快速上升。这个拐点就是系统的最优工作点，通常需要通过压测找到。

第二，并发度是连接吞吐量与延迟的桥梁。利特尔法则告诉我们，如果吞吐量不变而延迟上升，必然意味着并发度增加，也就是请求在系统中堆积。反过来，如果并发度不变而吞吐量下降，说明单个请求的处理时间变长了，可能是锁竞争加剧或资源争用。

第三，可扩展性受串行部分约束。阿姆达尔定律不是理论摆设。一个服务即使把业务逻辑并行化到 32 个线程，如果每次请求都要抢一把全局锁来更新计数器，那么这把锁就是串行部分。假设锁内操作占单请求总时间的 5%，理论上限就是 20 倍加速比，32 线程也只能接近这个上限，继续加线程收益极小。

第四，效率下降是扩展的预警信号。当 E(n) 从 0.9 降到 0.5，意味着新增资源有一半被浪费在协调、竞争或等待上。此时应该优先排查锁粒度、共享数据结构、线程池配置和 I/O 模型，而不是继续堆机器。

一个可操作的指标观测框架

在实际压测或线上观测中，建议同时采集以下指标，并保持测量边界一致：

需要强调的是，这些指标必须放在同一测量边界下比较。如果吞吐量统计的是服务端完成数，而延迟统计的是客户端端到端时间，两者就不能直接代入利特尔法则。工程实践中，建议在压测报告中明确标注：测量点、统计窗口、并发模型、是否包含网络时间。只有这样，指标才具有可复现性和可比较性。

最后，指标体系的真正价值不在于“收集了多少数字”，而在于建立因果判断能力：看到 P99 上升，能推断是并发度堆积还是单请求变慢；看到加速比不达标，能定位到串行瓶颈还是资源争用；看到效率下降，能判断是继续扩容还是先优化锁与共享状态。掌握这套指标之间的定量关系，才能在并发性能分析中从“凭感觉调参”走向“有依据决策”。