第3章 基础参数配置：并发数归纳总结
做对象存储加密SDK的性能调优，我第一个要跟你聊的就是并发数。为什么？
因为并发数直接决定了你的SDK能吃多少流量，也决定了你的应用会不会被压垮。我见过太多项目，上来就把并发数拉到几千，结果服务端还没崩，客户端先OOM了。也见过保守派只开10个并发，明明服务器扛得住，自己却活活把吞吐量压死了。
说白了，并发数就是你和存储服务之间那条管道的粗细。太细了水过不去，太粗了水管自己先爆掉。
并发数到底是什么？
在我调优的SDK里，并发数通常指同一时刻能进行的加密上传/下载任务数量。这个数不光是网络层面的连接数，还包含了加解密运算的线程数、缓冲区排队数。你想想看，每一个并发任务都要占用CPU、内存、网络句柄，这些资源是有限的。
我个人习惯把并发数拆成两个维度来看：
- 最大并发数 – 系统允许同时运行的任务上限
- 核心并发数 – 流量低谷时保持活跃的最小任务数
嗯，这里要注意，最大并发数不是越大越好。我记得有个项目，测试环境配了500并发跑得挺好，一上线生产就频繁报连接超时。后来一查，生产环境的存储网关有单节点连接数限制，网关端先扛不住了。
核心原则：并发数应小于等于服务端连接限额 - 其他业务预留连接数，再减去10%的安全缓冲。
并发数相关的核心参数
下面这张表列了我调优时最关注的一组参数。你可以在SDK的初始化配置里找到它们，名字可能略有不同，但逻辑是相通的。
| 参数名 | 作用 | 推荐调整范围 | 隐患指数 |
|---|---|---|---|
maxConcurrency | 最大并发任务数 | 16 ~ 512 | 高 |
corePoolSize | 核心线程数（长驻） | CPU核数 × (1~2) | 中 |
maxPoolSize | 线程池最大线程数 | CPU核数 × (2~4) | 高 |
queueCapacity | 等待队列容量 | 200 ~ 2000 | 中 |
connectionTimeout | 建立连接超时 | 500ms ~ 5000ms | 低 |
ioThreadCount | IO事件循环线程数 | 2 ~ 8 | 低 |
我曾经踩过的坑：有一次为了压榨性能，我把maxConcurrency设成了1024，结果客户端内存直接飙到4GB，GC频繁触发，最后吞吐量反而比512并发时低了30%。
并发数配置的核心逻辑
为什么这些参数要一起调，而不是只调一个？因为并发数的背后是一个生产-消费-排队的模型。我画了张图帮你理清它们的关系。
实践中最常用的配置策略
根据不同场景，我总结了三种常见的并发配置模板。你可以直接拿去做基准测试的起点。
小提示：我第一次调参时喜欢用表格把参数记下来，每次改一个变量，跑10分钟压测记录TPS和延迟P99。这样反复迭代3~5轮就能找到最优值。
| 场景 | 建议配置 | 适用条件 |
|---|---|---|
| 低并发、高稳定性 | maxConcurrency=32, corePoolSize=4, queue=500 |
对延迟抖动敏感，业务量平稳 |
| 中等并发、平衡型 | maxConcurrency=128, corePoolSize=8, queue=1000 |
日常业务，需要兼顾吞吐和稳定性 |
| 高并发、极致吞吐 | maxConcurrency=512, corePoolSize=16, queue=2000 |
批量处理、后台离线任务 |
这里再补充一句：ioThreadCount 一般设成2~4就够了，别超过8。为什么？因为IO线程主要处理事件循环，太多反而增加上下文切换。我试过设成16，结果CPU花在切换上的时间比干活还多。
一个实用的调参流程
- 先压测，找天花板 – 用默认参数跑压测，记录当前TPS、延迟、CPU、内存。
- 逐步增大并发数 – 每次翻倍，比如16→32→64→128，观察TPS拐点。
- 找到拐点后回调10%~20% – 拐点处的并发数往往已经让系统很紧张，留出安全余量。
- 微调队列和线程池 – 如果延迟抖动大，增大队列容量；如果CPU利用率低于70%，减小
corePoolSize。 - 验证稳定性 – 用目标并发数跑10分钟以上，观察有没有连接池耗尽、内存泄漏。
我个人最常用的检查点：压测期间用 jstack 或 VisualVM 看下线程状态，如果大量线程处于 BLOCKED 或 WAITING，说明并发数设大了，或者锁竞争严重。
避坑指南
我曾经在一个项目里遇到过：把 maxConcurrency 和 maxPoolSize 设成一样大，结果队列形同虚设，所有请求直接涌入线程池。一旦并发超过服务端限额，大量连接超时，线程池里全是重试任务，最后雪崩。后来我把队列容量调到 maxPoolSize × 5，问题才解决。
另一个常见误区：不管服务端有没有连接数限制，只管往上调并发。你想想看，对象存储服务通常都有每账号每秒请求数（QPS）限制，超过就返回429限流。你的SDK如果不停重试，不但自己压力大，还会被限流封得更死。
并发数调优的本质
总结一下，并发数调优就是在吞吐、延迟、资源消耗之间找平衡点。没有万能的配置，只有适合你业务场景的组合。我习惯把核心参数记在一张小卡片上，每次调优都对着它做增量修改。
嗯，这一章的内容就到这儿。你先把并发数的原理和参数对应关系理清楚，后面几章我们会基于这个基础，继续聊超时、重试、缓冲区这些更细的调优技巧。