CLOUD技术博在 2 核 4G 的服务器配置下部署 Spring Boot + MySQL 应用时，不存在一个绝对固定的“最大并发连接数”数值，因为该数值高度依赖于具体的业务场景、代码逻辑（同步/异步）、数据库查询复杂度以及操作系统的资源调度策略。
不过，我们可以从 JVM 内存限制、MySQL 连接池配置 和 操作系统文件描述符限制 三个核心维度进行推导，给出一个合理的建议范围。
1. 核心瓶颈分析
A. JVM 与 内存限制 (最关键的约束)
Spring Boot 应用运行在 JVM 中，每个线程都会消耗栈内存。
- 默认堆内存：通常 Java 默认堆大小约为物理内存的 1/4 到 1/2。在 4G 内存中，如果系统预留 1G 给 OS 和其他进程，可用堆可能在 2G~3G 左右。
- 线程栈开销：默认线程栈大小通常为 1MB（64 位系统）。
- 估算：如果你设置
server.tomcat.threads.max为 500，仅线程栈就需要 $500 times 1text{MB} = 500text{MB}$。加上堆内存、元空间、GC 开销以及 MySQL 驱动本身的缓冲，纯应用层面的安全线程数通常在 200~400 之间。超过这个范围极易触发OutOfMemoryError: unable to create new native thread或频繁 Full GC 导致服务不可用。
B. MySQL 连接池 (HikariCP)
Spring Boot 默认使用 HikariCP。
- 连接数 ≠ 并发线程数：连接池中的连接是复用的。高并发下，多个线程可能复用同一个数据库连接（只要当前没有 DB 操作），或者快速切换连接。
- 建议值：对于 2C4G 的小规模应用，HikariCP 的
maximum-pool-size建议设置在 10 ~ 20 之间。- 原因：MySQL 本身也有单线程处理复杂查询的性能上限，且每个连接都需要消耗 Server 端内存。过大的连接池会导致 CPU 上下文切换剧烈，反而降低吞吐量。
- 注意：不要将连接池大小设置为与 Tomcat 最大线程数一致，这是常见的误区。
C. 操作系统文件描述符 (File Descriptors)
Linux 每个网络连接（Socket）都占用一个文件描述符。
- 默认限制：CentOS/Ubuntu 默认通常是 1024。
- 调整建议：需要修改
/etc/security/limits.conf和sysctl.conf，将nofile提升至 65535 甚至更高，以支持潜在的突发流量。如果不调整，连接数达到 1024 时会直接报错 "Too many open files"。
2. 推荐配置方案
基于上述分析，针对 2 核 4G 服务器的最佳实践配置如下：
| 组件 | 参数项 | 建议值 | 说明 |
|---|---|---|---|
| JVM | -Xms, -Xmx |
2048m / 2048m | 固定堆内存，避免动态扩容抖动 |
| JVM | -XX:ThreadStackSize |
512k 或 1024k | 减小线程栈可略微增加线程数，但需权衡 |
| Tomcat | server.tomcat.threads.max |
200 ~ 300 | 控制同时处理 HTTP 请求的线程数 |
| DB Pool | spring.datasource.hikari.maximum-pool-size |
15 ~ 25 | 保持少量活跃连接，利用连接复用 |
| OS | ulimit -n |
65535 | 必须调大，否则成为硬瓶颈 |
3. 结论与建议
在 2 核 4G 环境下：
- HTTP 并发连接数（Tomcat 线程）：建议控制在 200 ~ 300 之间。如果业务主要是 IO 密集型（如大量读写数据库），可以稍微调高；如果是 CPU 密集型（如复杂计算），应降至 100 ~ 150。
- 数据库连接数（HikariCP）：建议严格控制在 15 ~ 25 之间。切记不要盲目调大，小规格服务器更看重连接的“质量”而非“数量”。
- 实际吞吐量测试：最终数值必须通过压测（如使用 JMeter 或 wrk）确定。观察指标包括：
- CPU 使用率是否持续 > 80%？
- GC 频率和停顿时间（STW）是否过长？
- 响应时间（RT）是否出现尖峰？
最终建议：
先按 Tomcat Max Threads = 200 和 DB Pool Size = 15 启动，配合压力测试逐步增加负载。如果发现 CPU 满载或延迟增加，优先优化 SQL 语句或增加缓存（Redis），而不是单纯增加服务器配置或连接数。