云服务器
在 2 核 2G（2 vCPU, 2GB RAM）的 Linux 服务器上，Tomcat 能支持的并发访问数量没有一个固定的标准答案。这个数值完全取决于你的业务场景、代码性能、请求处理时间以及 Tomcat 的配置策略。
在实际生产环境中，对于这种轻量级配置，通常的预估范围如下：
1. 核心影响因素分析
要理解并发能力，必须区分两个概念：连接数（Connections）和吞吐量（Throughput/QPS）。
- 内存限制（瓶颈所在）：
- 2GB 内存中，操作系统和基础服务（如 SSH、监控X_X等）会占用约 200-300MB。
- 留给 Java 堆内存（Heap）的空间通常在 512MB – 1GB 之间（建议
-Xmx设置为物理内存的 50%-70%）。 - 风险点：如果每个请求都需要创建大量对象或加载大文件，极易触发 OOM (Out Of Memory) 错误，导致服务崩溃。
- CPU 限制（处理能力）：
- 2 个 CPU 核心意味着同一时刻只能并行执行 2 个线程的计算任务。
- 如果业务逻辑涉及复杂的计算、数据库查询或网络 I/O 等待，CPU 容易达到 100% 使用率，导致响应变慢。
- Tomcat 线程池配置：
maxThreads设置过大（例如 1000），但实际能同时处理的“活跃”线程受限于 CPU。过多的阻塞线程会消耗大量内存（每个线程栈默认约 1MB），可能导致 OOM。
2. 不同场景下的预估数据
场景 A：纯静态资源或极简单的 API（Hello World 级别）
- 特征：无复杂逻辑，直接返回文本或图片，I/O 等待为主。
- 预估并发：
- 活跃并发数：可支撑 50 ~ 100 个同时在线的长连接。
- QPS (每秒请求数)：可达 1000 ~ 3000。
- 注意：此时主要瓶颈是磁盘 IO 或网络带宽，而非 CPU/内存。
场景 B：常规业务系统（CRUD + 数据库交互）
- 特征：每个请求需要查库、执行业务逻辑、返回 JSON。假设单次请求耗时 50ms。
- 预估并发：
- 活跃并发数：建议控制在 20 ~ 40 个。
- QPS：约 100 ~ 300。
- 原因：2 核 CPU 无法快速处理大量同步阻塞操作。如果并发超过 50，CPU 上下文切换频繁，响应延迟会急剧上升。
场景 C：高负载或复杂计算（大数据量、加密、复杂算法）
- 特征：单次请求耗时 > 200ms。
- 预估并发：
- 活跃并发数：建议不超过 5 ~ 10 个。
- QPS：可能低于 50。
- 风险：在这种配置下，一旦并发稍高，服务器极易发生雪崩。
3. 优化建议与配置调优
如果你必须在 2 核 2G 上运行 Tomcat，请务必进行以下调优以最大化稳定性：
-
限制 Java 堆内存：
不要使用默认值，强制限制最大堆内存，防止撑爆物理内存。JAVA_OPTS="-Xms512m -Xmx768m"(注：给 JVM 留足空间，剩余给 OS 缓存)
-
调整线程池参数 (
server.xml)：
将maxThreads设小，避免线程过多耗尽内存。<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="100" minSpareThreads="10" />对于 2 核机器，
maxThreads设为 50-100 通常足够。 -
启用 NIO 模式：
确保 Tomcat 使用的是NioEndpoint（Tomcat 8+ 默认），它比传统的 BIO 更节省内存，适合高并发连接。 -
开启 GZIP 压缩：
减少网络传输数据量，提升吞吐量。 -
引入反向X_X（强烈建议）：
不要让 Tomcat 直接暴露公网。在前端部署 Nginx。- Nginx 可以处理静态资源和负载均衡，承担大部分并发压力。
- Nginx 可以将动态请求转发给 Tomcat，起到削峰填谷的作用。
- 这样即使 Nginx 扛住了 1000 并发，后端 Tomcat 只需处理其中真正需要计算的少量请求。
结论
在 2 核 2G 的 Linux 服务器上：
- 安全并发上限：建议按 20 ~ 40 个活跃用户（同时正在处理请求）来规划。
- 流量上限：如果是简单接口，QPS 可做到 300 ~ 500；如果是复杂业务，QPS 应控制在 100 以内。
- 关键警告：如果你的应用预期并发超过 50 人同时在线，或者 QPS 超过 500，2 核 2G 的配置将无法保证服务的稳定性和低延迟，强烈建议升级服务器配置（至少 4 核 4G）或采用集群架构。