张瑞15129378030很多人第一次买云服务器，看到2核2G的配置，心里第一反应就是：这配置能跑Java Spring Boot吗？会不会卡到连登录页面都打不开？我这两年经手了好几台这种配置的服务器，可以负责任地说，这个问题没有一个简单的“能”或“不能”，关键看你部署的是什么项目、怎么配置JVM、有没有控制依赖。
这样说吧，如果你只是运行一个业务量很小的后台管理系统，2核2G不仅能跑，而且跑得相当稳；但如果你想什么都不改，默认参数直接丢上去，那它在流量稍微上来一点之后，大概率会出现一次让你印象深刻的OOM或者频繁Full GC。这篇文章我就用实际操作过的案例和数据，帮你把2核2G这台“小水管”上跑Spring Boot这件事拆开讲清楚。会从内存账本、CPU极限、JVM调优、真实测试到排查链路一点点说，适合刚买了小服务器不知道怎么部署的新手，也适合已经在跑但总觉得不稳的开发者。
1. 先给结论：能跑，但“流畅”二字是有前提条件的
如果非要给一个结论，我的判断是：Spring Boot应用跑在2核2G上完全可行，但“流畅”是有条件的。条件主要是三个：应用本身的业务复杂度不能太高、并发量在可接受范围内、JVM和容器参数经过合理调优。三个条件缺一个，体感都会很差。
我见过不少人在2核2G上直接跑一个没经过任何调优的Spring Boot + MySQL + Redis组合，结果服务重启了一段时间之后内存被吃光，进程被杀，还以为自己代码写崩了。其实问题往往出在默认参数上，而不是代码本身。
1.1 默认配置下，2G内存真的不够用
很多人对JVM内存的认知就是“堆内存”，但一个Java进程活着的时候，占用的远不止堆。默认情况下，JVM的堆最大值是物理内存的四分之一，2G机器上就是约512MB。这个512MB是堆空间，但JVM还要给元空间（Metaspace）、线程栈、JIT编译结果、GC管理结构、直接缓冲区等分配内存。
一个Spring Boot应用启动后，进程整体RSS在600MB到900MB之间是非常常见的。你要是再在这台2G的机器上装个MySQL、Redis，那内存账一下就爆了。我在后面会专门算这笔账，你一看就明白为什么默认配置会翻车。
1.2 CPU与内存之间的取舍
2核CPU意味着同一时刻只能有大约2个线程真正在跑。Java应用里，Tomcat默认开了200个线程，这200个线程大部分时间在等待IO，实际能并行计算的只有2个。所以CPU的瓶颈不在于线程数，而在于每个请求消耗的CPU时间。
举个例子，一个接口平均耗时50ms，其中CPU计算只占10ms，那么在2核CPU下，理论极限QPS大约在100左右（按CPU占用率100%算，实际还得打折）。如果接口平均耗时200ms，QPS极限会降到20-30。这个吞吐量对于内部系统、小网站、个人项目通常够用，但要是赶上秒杀、活动推送这类流量，肯定撑不住。
所以我经常跟朋友说：2核2G不是不能跑Java，是Java天生胃口大，你要学会给它“管饭”。管好了是真能稳，管不好别说流畅，起不起得来都是问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JVM与Spring Boot的内存账本：2G内存都花在哪了
想搞明白2G内存够不够，先得把内存的支出项列出来。我习惯把一台2G服务器上的内存花费分成四块：操作系统、JVM进程、中间件/数据库、业务层额外开销。每一块都比你想的更占地方。
2.1 操作系统本身就要占掉一块
别小看操作系统。一个干干净净的CentOS 7或Ubuntu Server，安装完基础组件后，常驻内存大概在200MB到400MB之间。如果你的系统里还装了宝塔面板这类运维面板，那基础内存占用还会再往上走，保守估计400MB以上。
也就是说，2G内存里，操作系统可能已经拿走了15%到20%。如果你用Docker部署，Docker守护进程本身也是要占内存的，虽然不大，但也是一笔开销。很多人在算内存的时候习惯性忽略系统占用的部分，最后一看free -h才发现实际可用的根本没有2G。
2.2 JVM进程的实际开销
前面提到，JVM进程的常驻内存不是只算堆。我来列一个比较典型的账，假设你用一个不包含数据库、默认参数的Spring Boot应用：
| 内存区域 | 默认大小 | 实际观测占用 |
|---|---|---|
| 堆内存（-Xmx） | 512MB（物理内存1/4） | 100-400MB |
| 元空间（Metaspace） | 无上限（默认） | 80-200MB |
| 线程栈 | 1MB/线程（默认） | 50-200MB |
| JIT编译器与CodeCache | 240MB（上限） | 20-80MB |
| GC结构与其他 | - | 30-100MB |
所以一个空的Spring Boot应用，刚启动后进程RSS大约500-700MB，如果加载了很多依赖、用了大量动态代理，元空间和CodeCache会更大。如果接口在跑、请求在涨，堆内存也会跟着涨到几百MB。综合下来，JVM进程占800MB左右是常态。
2.3 别忘了数据库和Redis
Spring Boot项目基本离不开数据库。一个MySQL实例跑起来，静态占用大约200MB到400MB，如果Buffer Pool设得比较大，分分钟能吃上1GB。Redis类似，虽然默认很小，但数据量多了之后几百MB也很正常。
这就是为什么很多人Java应用本身看着没爆，整机却内存耗尽的根源——你给MySQL和Redis留的内存不够了。它们在2G机器上会跟JVM抢内存，最终导致OOM Killer出手，把最大的进程杀掉。到时候你查日志，往往只能看到进程消失，根本不知道是谁干的。
2.4 估算一下2G机器的内存预算
我给自己总结了一套内存预算公式：操作系统300MB + JVM进程800MB + MySQL 300MB + Redis 200MB，加起来已经1.6GB，再算上日志、临时文件、网络缓冲区，2G几乎打满。所以摆在前面只有两个选择：要么把MySQL和Redis拆走，要么减少JVM的内存占用，要么降低其他组件的内存消耗。
这也是为什么我建议，在2核2G上部署Spring Boot时，如果预算允许，最好把数据库迁移到云数据库托管服务，或者单独放在另一台机器上。如果只能一台机器全扛，那必须精打细算每一块内存，后面我会给出具体的分配方案。
3. 2核CPU的算力极限：什么样的业务负载会先撑不住
内存的事说完，来看CPU。很多人只看内存够不够，忽略了CPU。实际上，当Spring Boot应用跑起来之后，CPU吃紧的情况比内存吃紧更隐蔽，也更难查。它不是一下子崩掉，而是慢慢变得迟钝，最终让你误以为是网络问题或代码问题。
3.1 Spring Boot应用里CPU被谁吃掉了
我排查过几个CPU飙高的案例，最常见的原因是这几种：
- Full GC频繁触发，GC线程占满了CPU
- Controller里做了大量同步计算，比如复杂的循环、字符串处理、JSON序列化
- 数据库连接池被打满，线程阻塞不断重试
- 频繁创建线程导致的上下文切换
- 反序列化大对象、大批量数据库查询
其中，Full GC是最常见的CPU杀手。当堆内存接近上限时，JVM会不断尝试回收内存，CMS或G1的GC线程会消耗大量CPU。表现出来就是系统负载很高，但业务接口访问不到，因为线程很可能在等待GC。这种情况你用top看，能看到Java进程的CPU占用率接近100%，但进去抓线程栈，发现全部在GC相关方法里。
3.2 并发模型与Tomcat线程池
Tomcat默认配置的max-threads是200。在2核CPU上，这200个线程不可能同时处于运行状态，大部分会阻塞在IO等待中。真正影响吞吐量的不是线程数，而是请求的处理时长和CPU核数。
这里可以做个简单估算。假设一个接口平均耗时100ms，其中10ms在使用CPU，剩下90ms在等待数据库查询或远程调用。那么在2核CPU上，理论上可以同时处理约20个请求（2核除以单请求10%的CPU占用率）。如果这个接口耗时变成200ms，可支撑的并发请求就降到10个。
所以2核CPU适合的是IO密集型的轻业务，不适合CPU密集型的重计算。你如果非要在2核2G上跑一个实时处理视频帧的任务，那不等流量上来，CPU自己就能打满。
3.3 2核CPU在不同业务场景下的实际感受
我按自己的经验给几类场景分个档，方便你对号入座：
| 场景 | 单请求CPU消耗 | QPS参考 | 2核2G是否撑得住 |
|---|---|---|---|
| 纯CRUD接口，查询单表 | 5%-10% | 50-100 | 撑得住，流畅 |
| 带复杂SQL/报表导出 | 20%-40% | 10-30 | 看数据量，容易CPU飙升 |
| 大量JSON读写/第三方调用 | 15%-30% | 30-60 | 勉强撑住，调优后可跑 |
| 实时消息推送/图片处理 | 50%-100% | 5-20 | 基本撑不住，建议升级 |
当然，这只是大致的体感，不是精确的压测数据。但能帮你判断，2核2G这台机器适合接多大的活。接对了，它就是一台性价比极高的小钢炮；接错了，它就是一台让你半夜爬起来重启服务器的祖宗。
4. 部署前的关键调优：让Spring Boot在2核2G上跑稳的必备操作
如果要我说一个最核心的观点，那就是：不要在2G内存上直接用默认参数部署Spring Boot。默认参数是为大内存机器设计的，而不是为这种小内存机器。下面这些都是我实际操作中验证过有效的调优手段，每一条都能实实在在把内存占用压下来。
4.1 JVM参数：把内存关进笼子
JVM参数是第一步。我的建议是显式指定堆大小、元空间大小、线程栈大小，并选择合适的GC。下面这组参数是我在2核2G上部署时比较常用的一套：
bash复制java -Xms512m -Xmx512m \
-XX:MaxMetaspaceSize=256m \
-XX:MaxDirectMemorySize=128m \
-Xss256k \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=200 \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/home/app/logs/ \
-jar myapp.jar
逐条解释一下我为什么这么配：
-Xms512m -Xmx512m：把初始堆和最大堆设为一致，避免堆扩容时出现CPU抖动和内存波动。512MB对2G机器来说是一个“留有余地”的数字，如果你把MySQL也放这台上，我建议降到384MB或256MB。-XX:MaxMetaspaceSize=256m：限制元空间大小。Spring Boot加载的类很多，元空间默认没有上限，必须给它上限，否则迟早吃光内存。-Xss256k：线程栈从默认的1MB降到256KB，这样可以让更多线程在有限内存里存活。这在低并发场景下几乎无感，但在2G机器上是实实在在的省内存。-XX:+UseG1GC：在JDK 11及之后，G1是默认GC，低延迟场景下效果不错；如果你用的是JDK 8，也可以考虑ParallelGC。G1在2G内存上能跑，但需要把目标停顿时间设合理。-XX:+HeapDumpOnOutOfMemoryError：内存溢出时自动生成堆转储文件，这是排查看家本领。真到OOM那天，没有这个文件你就只能靠猜。
要注意，-Xmx不要超过物理内存的一半，否则留给元空间、线程栈、操作系统和数据库的空间就不够了。我见过有人把-Xmx设成1536MB，结果堆没满系统先满了，进程直接被OOM Killer杀掉，白白背了“代码写得差”的黑锅。
4.2 Tomcat线程池与连接配置
Spring Boot内嵌的Tomcat可以通过配置文件调整。在application.yml里加上：
yaml复制server:
port: 8080
tomcat:
max-threads: 100
min-spare-threads: 10
accept-count: 200
max-connections: 1000
connection-timeout: 5000
把max-threads从默认的200降到100，是因为2核CPU根本用不到200个线程，100个已经足够；线程数太多反而增加上下文切换和内存占用。每个线程默认占1MB栈空间，200个线程就是200MB，降到100个线程再加上-Xss256k，这块内存直接省出一大截。
accept-count表示等待队列的长度，当线程池满了之后，新的请求会进入队列等待。这个值设太大会让请求排队时间变长，建议结合业务情况调整。连接超时设成5秒，可以防止因为网络抖动导致线程长时间挂起。
4.3 Spring Boot本体的瘦身
Spring Boot默认的自动配置很强大，但也意味着它会加载很多你用不到的功能。瘦身不是必须的，但能减少类加载量和内存占用，也能让启动速度更快。
- 用
spring-boot-starter-web、spring-boot-starter-jdbc等按需引入，不要图省事引入全家桶。一个不需要模板引擎的项目，非要把spring-boot-starter-thymeleaf也拉进来，纯属浪费内存。 - 在启动类上用
@SpringBootApplication(exclude = ...)排除不用的自动配置，比如你不需要数据源，就排除DataSourceAutoConfiguration。 - 如果需要频繁访问静态资源或传输JSON，开启Gzip压缩，减少网络带宽和序列化消耗。对大JSON响应，Gzip能节省60%以上的传输数据，也让CPU的序列化压力小一些。
yaml复制server:
compression:
enabled: true
mime-types: application/json,application/xml,text/html,text/plain
min-response-size: 2048
4.4 部署形态的选择：裸机还是Docker
2核2G上，我个人的经验是：可以直接用java -jar跑，也可以用Docker跑。Docker的好处是环境隔离、启停方便，但容器本身会占用一部分内存。如果你用Docker，一定要给容器设置内存限制，否则容器会贪婪地使用宿主机的内存，导致宿主机提前耗尽内存。
bash复制docker run -d --name myapp \
-m 512m \
-e JAVA_OPTS="-Xms256m -Xmx256m" \
-p 8080:8080 myapp:latest
-m 512m让容器最多只能使用512MB，这能防止JVM因为宿主机内存充足而把堆扩展到不合理的值。注意，如果容器里的JVM还是按宿主机物理内存来算默认堆大小，那在容器里跑Java就很容易出现“容器外看内存没爆，容器里面已经堆溢出”的迷惑情况。所以-e JAVA_OPTS里的-Xmx一定要设置，不能偷懒。
另外，在Linux系统上，如果你用的是JDK 8，我建议升级到JDK 11或17。JDK 8在容器环境下的内存感知能力比较弱，更容易出现容器里识别到宿主机全部内存的情况。JDK 11+默认开启了容器感知，能正确识别容器的内存上限，调优起来也省心很多。
5. 实测：三类典型Spring Boot应用在2核2G上的真实表现
调优参数说完了，光讲理论不行，我把自己实际部署过的三个项目情况拿出来分享，给大家一个“真实感”的参考。这几个项目都是2核2G的云服务器，系统是CentOS 7，JDK 11，MySQL 5.7也装在同一台机器上。
5.1 案例A：轻量级后台管理系统
一个公司内部的后台管理系统，有用户管理、角色权限、审计日志，用户量大概200人左右，峰值在线也就几十个人。接口基本都是单表CRUD，偶尔有一些多表查询。
部署后，JVM参数用的就是上面那套512MB堆配置。实测运行一周：
- 内存稳定在650MB左右，JVM常驻约500MB，MySQL约200MB，系统约300MB，合计约1GB，还有接近1GB的空余。
- CPU使用率日常在1%-5%之间，偶尔有人导出Excel时会飙到30%-40%，然后迅速回落。
- 接口响应时间平均在30ms以内，页面操作没有感知到卡顿。
结论：这种轻量级应用，2核2G非常流畅，甚至可以同时再跑一个Redis。如果你是个人项目、学习项目或者公司内部小系统，完全不用被“2G内存不够跑Java”这种说法吓住。
5.2 案例B：带定时任务和第三方接口的订单系统
一个小型电商商城的后端，有商品、订单、支付回调，还跑了好几个Spring定时任务，每天凌晨同步上游数据。流量不大，但业务逻辑相对复杂，订单表已经有几十万条。
部署后，我把堆内存调到768MB，并缩小了MySQL的Buffer Pool。实测运行情况：
- 日常内存占用在1.4GB左右，比较紧张，但没到OOM。
- 白天QPS大概20-40，CPU使用率高峰50%左右，主要消耗在支付回调的验签和订单查询上。
- 凌晨跑定时任务时，CPU使用率会冲到90%以上，但持续几分钟后回落。
结论：只要把定时任务的执行时间安排在业务低峰期，2核2G能扛住。但如果访问量再翻一倍，这台机器就得考虑升级了。另外，因为是同一台机器上既要跑Java又要跑MySQL，我不得不把MySQL的innodb_buffer_pool_size调小到256MB，牺牲一点查询性能换取整体稳定性。
5.3 案例C：实时数据推送服务
这个项目是给移动端做实时报警推送的，部署了WebSocket，服务端还要定时轮询多个数据源。跑起来之后，2核2G明显吃力。
原因是WebSocket长连接会占用线程和内存，几千个连接同时在线时，线程栈和堆内存快速飙升。加上轮询任务频繁触发，CPU也经常打满。最后我把服务拆成了两个实例：一台2核4G专门跑Java，原有的2核2G只做数据库和Redis，才算稳定下来。
结论：高并发、长连接、轮询密集型的应用，基本不适合2核2G。这种场景下，与其费劲调优，不如直接升级配置或者拆分架构。强行压榨小服务器，只会让线上事故变成常态。
5.4 几组关键数据的横向对比
| 指标 | 轻量级后台系统 | 订单系统 | 实时推送服务 |
|---|---|---|---|
| 日常内存占用 | 约1GB | 约1.4GB | 经常接近2GB |
| 日常CPU使用率 | 1%-5% | 20%-50% | 60%-100% |
| 接口平均响应 | 30ms | 80ms | 150ms+ |
| 结论 | 流畅 | 勉强够用 | 不建议 |
这三个案例其实给出了一个非常清晰的边界：2核2G适合低并发的CRUD型业务，能跑中等复杂度的业务但需要调优，承受不了高并发或重计算。你的项目属于哪一类，直接决定你会不会卡。
6. 翻车现场：在2核2G上最常见的OOM和卡顿排查链路
调优做得再到位，也难免遇到突发情况。这一章我分享几个在2核2G上真实踩过的坑，以及完整的排查链路。写出来是希望你在遇到类似问题时，不要慌，按顺序一步步查，大部分问题都能定位到根因。
6.1 现象：Java进程跑着跑着就被系统杀掉了
这个现象特别典型：服务运行几天后，突然从晚上到早上就访问不了了，登录服务器一看，Java进程已经没了。
排查步骤：
- 先看系统日志：
dmesg -T | tail -50，如果看到Out of memory: Kill process，说明是Linux的OOM Killer杀掉了进程。 - 查看当时的内存占用：
free -h，确认是哪一块把内存吃光了。 - 如果OOM Killer确实杀了Java进程，检查JVM堆内存使用情况：
jmap -heap <pid>，看看堆是否接近上限。 - 获取可能存在的堆转储文件，用MAT或JProfiler分析是大对象还是内存泄漏。
我遇到过一次，原因是代码里的一个定时任务把一个几十万行的查询结果全部加载进了内存，堆从512MB飙到1GB以上，直接触发了OOM Killer。解决方式不仅仅是要加内存，更关键的是要修代码。后来我把那个查询改成分页处理，问题就再没出现。这类问题光靠调参是治标不治本的。
6.2 现象：CPU使用率长期接近100%，接口响应极慢
还有一种情况：Java进程没死，但系统CPU使用率一直在90%以上，整个服务器的响应都非常慢。
排查步骤：
top命令找到吃CPU的Java进程PID。top -Hp <pid>查看这个进程内哪个线程最消耗CPU，记录线程ID。- 用
printf "%x\n" <线程ID>把线程ID转成十六进制。 - 执行
jstack <pid> > threaddump.txt，在线程栈里搜索这个十六进制线程ID，看它在干什么。
绝大多数情况你会定位到这样几类线程：
- GC线程，说明内存不健康，可能堆太小或者有内存泄漏
- 某个业务线程在跑一个非常致命的循环
- 线程长时间阻塞在
java.net.SocketInputStream.read，说明数据库或第三方接口慢了
有一个印象很深的案例，一个接口里调用了远程HTTP服务，远程服务没响应，但接口没设置超时时间，线程全部堵在SocketInputStream.read上，CPU不高，但线程池被打满，新请求全部进队列等待，表现为响应越来越慢。最后加了HttpClient的连接超时和读取超时，问题解决。这类问题在2G机器上特别容易暴露，因为线程池本来就小，几个线程卡住就能导致全线瘫痪。
6.3 现象：内存没爆，CPU不高，但接口就是慢
这类问题通常不是JVM层面的，而是外部依赖导致的：
- 数据库慢查询，没有索引，全表扫描
- 磁盘IO过高，内存不足导致swap读写频繁
- 网络带宽被打满
排查时我会顺手看几个指标：
iostat -x 1查看磁盘IOsar -n DEV 1 3查看网络流量- 开启MySQL慢查询日志，或者用
EXPLAIN分析SQL
内存不足导致swap频繁，在2G机器上非常常见。当你看到系统内存被耗尽、swap使用率很高时，JVM的GC性能会显著下降，因为GC线程访问的内存页面可能被换出到磁盘。这个情况非常隐蔽，CPU看起来不高，但每次GC都慢得离谱，接口响应时间自然被拉到几秒甚至十几秒。
解决方式是尽量减少其他进程的内存占用量，把堆内存控制在合理范围，或者干脆给机器加内存。swap不是不能用，但绝对不要把swap当成“内存不足时的救命稻草”，它只是应急保险丝，频繁触发说明内存已经严重不足了。
7. 如果实在不够用：轻量化、拆分与升级的三条路
以上调优和排查都做完了，如果你的业务在2核2G上还是不太行，那就别硬扛了。我有三条路可以走，按成本从低到高排列，你可以根据实际情况选。
7.1 轻量化：用更小的运行时降低内存占用
Spring Boot的生态确实方便，但如果应用本身足够简单，可以考虑用GraalVM Native Image把Spring Boot应用编译成原生可执行文件。原生镜像启动内存比JVM模式低很多，一个原生镜像的Spring Boot应用内存占用可以降到150MB以内，而且启动时间能到毫秒级。
不过原生镜像也有代价：编译时间较长、反射和动态代理受限、某些Spring Boot特性不兼容。如果你用了很多反射、动态代理、CGLIB这类机制，原生镜像的适配过程可能会让你头疼。需要根据项目的实际情况权衡，别为了省内存把开发效率搭进去。
另一个轻量化方向是基础镜像瘦身。如果你在用Docker部署，基础镜像从openjdk:8-jdk换成eclipse-temurin:17-jre-alpine，能省出两三百MB内存和大量磁盘空间。这一步几乎是零成本的，改了Dockerfile里的镜像名，重启一下就有效果。
7.2 拆分：把压力从Java进程上卸下来
一台2G机器上什么都要跑，内存自然紧张。拆分的思路是让数据库、Redis、对象存储等组件与Java进程分离，这是最推荐的方案，也是很多小团队从“单机跑天下”走向正规化的第一步。
- 用云数据库代替自建MySQL，机器上只留Java进程
- 用云Redis代替自建Redis
- 静态资源放到对象存储和CDN
- 把定时任务抽出来放到单独的函数计算
这样一台2核2G的服务器只跑Spring Boot应用，1.5GB以上的内存都给JVM，能承载的业务量会比混部大得多。我见过一个朋友把数据库迁到云数据库之后，同样的2核2G机器从“早晚要炸”变成了“稳如老狗”，应用的堆内存直接给到1GB，接口响应时间还下降了一个量级。
7.3 升级：什么时候该加内存或换机器
如果经过调优、瘦身之后仍然满足不了业务需求，那就不要犹豫，直接升级配置。我的建议是优先升级内存，从2G升到4G，CPU通常不是第一个瓶颈。4G内存下，JVM堆可以分配到1.5GB以上，Spring Boot应用的空间就宽裕多了。
如果你既要高并发又要大数据量，2核4G可能也不够，那就要考虑2核4G以上的套餐，或者直接上容器集群。不过这已经超出“小水管”的范畴了，属于业务成长到一定规模之后的必然升级路径。
我的个人经验是：给2核2G的机器定一个“业务阈值”，比如当你的应用QPS长期超过100、接口P99响应时间超过500ms，或者每日OOM次数不为0时，就该认真考虑升级了。别等到用户投诉才开始慌，到了那个阶段，每次半夜的电话都可能是因为这台小服务器又顶不住了。
最后分享一点使用心得
2核2G跑Spring Boot，本质上是“小马拉车”的工程。马能不能拉动车，取决于车有多重、路有多陡、你愿不愿意先给马卸货。我自己的习惯是：项目刚起步时，2核2G足够陪伴你走过最初的用户积累阶段。但你要时刻记得给它做体检——至少每周看一次内存和CPU曲线，上线新功能前跑一遍压测，别等服务器报警了才想起JVM参数调错了。
另外，既然资源紧张，就不要给代码留太多“富余”。Controller里的循环查询、一次性加载全表、无脑的日志打印，这些在4G机器上可能只是“不太优雅”，在2G机器上就是实实在在的灾难。把每一行代码都当成在给这台小服务器省钱，反而是件好事。我见过太多项目不是被流量打垮的，而是被自己代码里的浪费拖垮的。
如果你正在2核2G上折腾Spring Boot，希望这篇文章能帮你少走一些弯路。可以先从调整JVM参数开始，观察一周再决定要不要升级。这台机器，真的没有传说中那么弱，关键看你愿不愿意耐心去调它。