1. SDK 并发连接概述

先问一个最实在的问题：你写的 SDK，到底能扛住多少并发的网络请求？

我见过太多刚入行的同学，代码里直接 new 一个 Socket 就发请求了。单线程跑没问题，一上压测，CPU 飙到 99%，连接超时一大片。嗯，说白了就是没管过「并发连接」这回事。

这篇文章我们就聊聊这个老生常谈但又很容易踩坑的话题。

1.1 什么是 SDK 并发连接

SDK 里的并发连接，指的是你的客户端同时发起的、处于活跃状态的网络连接数。

举个例子：你的 App 要同时从三个服务接口拉数据，如果每个请求都走一个独立的 TCP 连接，那就是三条并发连接。如果用了连接池，可能就保持在一条连接上复用。

我需要特别强调一个概念——「并发」不等于「多线程」。并发连接强调的是同时进行的网络 I/O，它可以是多线程、异步、或者协程实现的。关键是你得知道上限在哪。

维度	说明	常见误区
并发数	同一时刻正在发送/接收的连接数量	以为设得越大越好
连接池大小	连接池里能保持的最大空闲连接	跟并发数混淆
超时时间	等待一个请求完成的截止时间	超时设太长导致队列堆积
重试策略	失败后重试的次数和间隔	重试把服务器打爆

这张表我后面还会反复提到。每个参数都会影响最终的并发表现。

1.2 为什么要调优并发连接参数

你想想看，同样的 SDK，默认参数可能只能支持 50 个并发，稍微调一下就能跑到 500。差别在哪？不在代码逻辑，就在那几个参数上。

我个人的习惯是：先理解业务场景，再调参数。比如你是做视频上传 SDK，还是做 HTTP API 调用 SDK，场景完全不同。

• 场景一：高吞吐 —— 需要尽量多的并发连接来压满带宽，但要注意不要打崩溃下游。
• 场景二：低延时 —— 连接复用、减少握手开销是关键，并发不宜太高，否则排队反而变慢。
• 场景三：资源受限 —— 手机端或 IoT 设备，并发数一高内存和 CPU 直接爆炸。

我在项目中遇到过最离谱的一次：一个物联网 SDK 默认最大连接数设成了 1024，结果跑在只有 64MB RAM 的芯片上，一启动就 OOM。调成 8 条连接后，问题全没了。

所以调优的核心目的就三个：提高吞吐、降低延时、控制资源。这三者往往需要 trade-off。

1.3 调优的核心逻辑框架

为了让你一眼看明白整个调优的路径，我画了一张图。它把从业务需求到最终参数的链条串起来了。

上面这条链路非常清晰：业务场景 → 目标指标 → 可调参数 → 约束因素 → 调优闭环。后面每一章都会围绕这个框架展开。

1.4 一些避坑经验

另外，有一个概念很容易混淆——「连接池大小」和「最大并发连接数」不是一回事。连接池是内部维护的空闲连接集合，而最大并发数是整体维度。我习惯用一个公式来估算初始值：

建议最大并发数 = min(CPU核心数 * 2, 下游服务QPS上限 / 单请求耗时(秒))

当然这只是粗估，后面章节会有更精确的计算方法。

1.5 本章小结（不用跳转，只是回顾）

• SDK 并发连接：同时进行的网络 I/O 数量，由多个参数共同决定。
• 调优目标是：在吞吐、延迟、资源三者之间找到平衡。
• 调优不是一锤子买卖，需要压测 → 监控 → 再调。
• 不要忽略操作系统和下游的限制，那些往往是真正的瓶颈。