部署Spring Boot项目，2核2G服务器需要优化哪些参数？-CLOUD技术博

在 2 核 2G（2 vCPU, 2GB RAM）的服务器上部署 Spring Boot 应用，属于典型的资源受限环境。如果不进行优化，JVM 极易因内存不足触发 OOM（Out Of Memory），或因 GC 频繁导致 CPU 飙升、服务响应极慢。

以下是针对该配置的核心优化方案，分为 JVM 参数调优、Spring Boot 配置、系统级优化和架构建议四个维度：

默认情况下，JVM 可能会尝试分配过大的堆内存或开启不必要的功能。你需要手动限制内存并调整垃圾回收策略。

最大堆内存 (-Xmx)：必须严格限制。服务器总内存 2G，扣除操作系统（约 300-400MB）、非堆内存（Metaspace、线程栈等）后，留给堆的空间不宜超过 512MB – 600MB。
- 建议设置：-Xmx512m 或 -Xmx600m。
初始堆内存 (-Xms)：为了减少启动时的动态扩容开销，建议与最大值保持一致。
- 建议设置：-Xms512m。
元空间 (-XX:MaxMetaspaceSize)：防止元空间过大占用过多内存。
- 建议设置：-XX:MaxMetaspaceSize=128m。

2G 内存下，G1 GC 可能略显沉重（需要维护大量数据结构），Serial GC 或 Parallel GC 通常更轻量且适合小内存场景。

推荐方案：使用 Serial Old + Serial New (即默认的 -XX:+UseSerialGC)。虽然它是单线程的，但在低负载下延迟极低，且没有并发开销。
备选方案：如果业务对吞吐量有一定要求，可尝试 Parallel GC (-XX:+UseParallelGC)，但需监控停顿时间。
避免：不要使用 G1 GC (-XX:+UseG1GC)，除非你非常熟悉其调优参数，否则在小内存下容易引发 Full GC 频繁。

推荐的启动命令示例：

java -Xms512m -Xmx512m 
     -XX:MaxMetaspaceSize=128m 
     -XX:+UseSerialGC 
     -Dspring.profiles.active=prod 
     -jar your-app.jar

(注：如果你的 Spring Boot 版本较新，也可以直接在 application.properties 中通过 JAVA_OPTS 环境变量传递这些参数)

除了 JVM，应用本身的配置也需“瘦身”：

关闭开发模式：确保 spring.profiles.active 为 prod，关闭 debug=true 和热加载功能。
数据库连接池优化：
- 连接数不宜过多，2 核 CPU 无法支撑高并发连接。
- HikariCP 默认配置通常较激进，建议修改 maximum-pool-size 为 5-10 之间。
```
spring:
datasource:
hikari:
  maximum-pool-size: 8
  minimum-idle: 2
```
Tomcat 线程池：
- 默认 Tomcat 线程数可能过高，导致上下文切换频繁。
- 建议将 server.tomcat.threads.max 设置为 50-100。
```
server:
tomcat:
threads:
  max: 80
```
关闭不必要的 Actuator 端点：只保留必要的健康检查，关闭 info, env 等敏感或无用端点，减少暴露面和内存占用。
日志级别：生产环境日志级别设为 INFO 或 WARN，避免 DEBUG 产生大量 IO 消耗。

服务器内核层面的优化同样重要：

增加 Swap 分区：
- 物理内存仅 2G，一旦突发流量导致内存短暂溢出，Swap 是最后的救命稻草。
- 建议创建一个 2G – 4G 的 Swap 文件（注意：Swap 会严重拖慢性能，仅作为防崩溃手段，不能作为日常运行依赖）。
```
# 创建 2G swap 文件示例
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
```
调整 VM Swappiness：
- 降低系统使用 Swap 的倾向，优先使用物理内存。
- 建议值：vm.swappiness = 10 (默认通常是 60)。
```
sysctl vm.swappiness=10
```
文件描述符限制：
- 防止连接数多时报错 "Too many open files"。
- 修改 /etc/security/limits.conf，增加 nofile 限制（如 65535）。

如果经过上述优化后，性能依然无法满足需求，说明 2C2G 确实不足以支撑当前业务逻辑，需考虑以下架构调整：

启用容器化隔离：
- 如果使用 Docker/K8s，务必在 docker run 或 K8s YAML 中显式限制 memory 和 cpu，防止容器内进程占满宿主机资源导致 OOM Kill。
引入缓存：
- 部署轻量级 Redis（或使用本地 Cache），大幅减少数据库查询压力，降低 CPU 和内存峰值。
异步化处理：
- 将非核心链路（如发送邮件、生成报表）剥离到消息队列（RabbitMQ/RocketMQ），避免阻塞主线程。
降级与限流：
- 集成 Sentinel 或 Resilience4j，当 QPS 超过阈值时自动限流或降级，保护服务器不宕机。
升级硬件：
- 如果业务增长明显，2C2G 是瓶颈。最直接的方案是升级到 2C4G 或 4C2G（取决于内存密集型还是 CPU 密集型）。

按照以上步骤调整后，你的 Spring Boot 应用在 2 核 2G 环境下应该能够稳定运行，并能承受中等程度的并发访问。