Java Web项目在高并发场景下需要怎样的服务器资源配置？

高并发下 Java Web 的服务器配置，从来不是“堆硬件”就能解决的。很多团队一遇到流量洪峰就想着加 CPU、加内存，结果钱花了不少，系统还是崩。

核心逻辑就一条：瓶颈在哪，资源就往哪补。

下面按实战经验拆解几个关键维度：

1. CPU：别只看核数，要看线程模型

Java 是单线程处理请求的（Tomcat/Jetty 默认线程池），但高并发往往意味着大量 I/O 等待。

• 计算密集型（如复杂算法、加密解密）：必须多核 CPU。如果业务逻辑里全是 for 循环和数学运算，8 核可能都不够，得看单核性能。
• I/O 密集型（数据库查询、RPC 调用、文件读写）：这是大多数 Web 项目的常态。这时候 CPU 利用率可能只有 20%-30%，但线程池满了，请求排队。
  • 策略：如果是 I/O 密集，盲目上多核没用。重点是把线程池调大（比如从 200 调到 500+），或者把同步阻塞改成异步非阻塞（Netty + Reactor 模式）。
  • 坑点：不要为了省成本买低频 CPU（如某些云厂商的共享型实例），高并发下上下文切换会拖垮系统。

2. 内存：JVM 参数比物理内存更重要

很多人以为给机器塞 64G 内存就稳了，其实 JVM 配置不对，直接 OOM。

• 堆内存（Heap）：通常设为物理内存的 50%-70%。留足空间给操作系统做缓存和线程栈。
• 新生代/老年代比例：默认是 1:2，对于短生命周期对象多的场景（如 Session、临时 DTO），建议调成 1:1 甚至更激进，减少 Full GC 频率。
• GC 选型：
  • 延迟敏感型（支付、交易）：用 G1 或 ZGC，控制停顿时间。
  • 吞吐优先型（日志分析、报表）：CMS（虽已废弃但老项目还在用）或 Parallel GC。
• 元空间：动态X_X类、反射多的框架（Spring Boot 默认开启 AOP），元空间不够也会崩，记得预留足够空间。

3. 网络：带宽是硬伤

高并发下，CPU 和内存可能都没满，但网卡打满了，这就是典型的带宽瓶颈。

• 内网 vs 网络：
  • 集群内部通信（微服务间）：走内网万兆，配置要关注交换机端口速率。
  • 对外服务：带宽是按量付费最贵的地方。如果用户都在看图片/视频，单纯加应用服务器没用，必须上 CDN。
• TCP 参数优化：
  • tcp_tw_reuse：允许重用 TIME_WAIT socket。
  • somaxconn：增加监听队列长度，防止连接被丢弃。
  • 这些在 /etc/sysctl.conf 里改一下，比加机器管用。

4. 存储：数据库才是最大短板

90% 的高并发崩溃，最后都指向数据库锁表、慢查询或连接池耗尽。

• 连接池：HikariCP 是首选。默认最大连接数是 10，高并发下至少开到 200-500，根据 QPS 动态调整。
• 读写分离：主库扛不住写操作时，立刻切读库。
• 缓存策略：Redis 必须上。热点数据（如商品详情、用户信息）先查 Redis，再查 DB。注意缓存穿透和击穿问题，布隆过滤器不能少。
• 磁盘 IO：MySQL 对随机 IO 极其敏感。机械盘在高并发下基本废了，必须 SSD，最好 NVMe。

5. 架构层面的“资源配置”

有时候，软件架构比硬件配置更能决定上限。

• 水平扩展（Scale Out）：单机性能有天花板，不如搞负载均衡（Nginx/LVS）+ 无状态服务。加一台机器，配置不变，直接扩容。
• 限流熔断：Sentinel 或 Resilience4j。当流量超过阈值，直接拒绝部分请求，保护后端不被压垮。这比盲目加服务器更省钱。
• 动静分离：静态资源（JS/CSS/图片）全部扔 OSS+CDN，应用服务器只负责渲染动态页面。

6. 监控与调优

没监控就是盲人摸象。

• APM 工具：SkyWalking 或 Pinpoint，定位代码级耗时。
• 链路追踪：搞清楚请求卡在哪个微服务、哪条 SQL。
• 压测：上线前必须跑 JMeter 或 Wrk，模拟真实流量，找出真实的 QPS 上限，而不是拍脑袋定配置。

总结一句：
高并发配置没有标准答案。先压测，找瓶颈；瓶颈在 CPU 就换强单核，瓶颈在 IO 就上 SSD 和 Redis，瓶颈在网络就上 CDN 和负载均衡。千万别上来就堆硬件，那是掩耳盗铃。