Tomcat内存不足的典型症状与判断方法
服务器中的Tomcat内存不足，本质是JVM堆或元空间撑不住当前业务负载，直接表现是java.lang.OutOfMemoryError报错或进程被系统OOM Killer强杀。 解决路径不是简单把数字调大，而是先定位是堆内存、元空间还是系统物理内存被挤爆，再针对性调整启动参数。
很多运维人员一看到Tomcat卡顿就重启,过一阵又复发。业内专家指出，重启只是把泄漏的内存暂时清空，不解决参数配置与业务体量不匹配的问题，下面从报错现象开始拆解，给出可直接照做的操作路径。
内存不足的几种典型表现
Tomcat不会只以“内存不足”四个字报错，它通常通过下面几种方式暴露问题：
- 日志里出现
java.lang.OutOfMemoryError: Java heap space：堆内存耗尽，最常见，通常是对象创建速度超过回收速度，或者有集合类不断累积数据。 - 日志里出现
java.lang.OutOfMemoryError: Metaspace：元空间耗尽，多见于应用频繁热部署、动态生成类、反射加载大量类的场景。 - Tomcat进程莫名消失，系统日志有
Out of memory: Kill process：这不是JVM自己报错，而是Linux内核OOM Killer发现系统物理内存不够，直接把Tomcat进程杀了。 - 响应变慢、频繁Full GC：还没报错但已经危险，用
jstat -gcutil <pid> 1000观察，老年代占用持续在较高水平且Full GC后降不下来，说明堆已经偏紧。
先分清是Tomcat内存问题还是JVM内存问题
这是排查的第一步,Tomcat自身作为Servlet容器，代码层面占用内存有限，真正吃内存的是部署在里面的Web应用。行业共识认为，超过八成的Tomcat内存告警，根因在应用侧的对象生命周期管理，而非Tomcat安装包本身。
判断方法很简单：查看catalina.out报错发生的位置，如果堆栈指向应用自己的类，优先从应用代码找泄漏点；如果报错发生在Tomcat内部线程池或连接器处理阶段，再看容器配置。tomcat和jvm内存调优区别就在这里Tomcat的连接数、线程数影响的是线程栈和请求缓冲，JVM的-Xmx控制的是堆上限，两者调的是不同维度，不能混为一谈。
tomcat内存溢出怎么解决从JVM参数入手
解决tomcat内存溢出怎么解决这个问题，核心动作是修改Tomcat启动脚本里的JVM参数，Tomcat本身不存内存配置，它通过catalina.sh或catalina.bat把参数传给JVM。
tomcat修改内存大小配置的标准做法
有三个参数是必须理解的：
-Xms：堆初始大小，建议和-Xmx设成一样，避免运行中反复扩堆引发停顿。-Xmx：堆最大大小，这是最关键的数值，设小了不够用，设大了挤占系统内存。-XX:MetaspaceSize和-XX:MaxMetaspaceSize：元空间上下限，JDK 8以后永久代被元空间取代，动态部署多的环境要关注这一项。
一个常见的起步配置参考（按服务器物理内存的50%到60%分配给JVM，剩余留给操作系统和堆外内存）：
| 参数 | 建议值示例 | 说明 |
|---|---|---|
-Xms |
2g | 与Xmx一致，减少扩堆 |
-Xmx |
2g | 不超过物理内存六成 |
-XX:MetaspaceSize |
256m | 元空间初始阈值 |
-XX:MaxMetaspaceSize |
512m | 防止元空间无限增长 |
-Xss |
512k | 线程栈大小，线程多时适当调小 |
具体数值要按服务器实际内存和应用压测结果来定,据工信部相关运行监测数据，中小型Web应用单节点JVM堆设置在2GB到4GB区间较为常见，但这只是参考区间，不能直接照搬。
不同操作系统下参数写在哪
Windows环境：打开Tomcat安装目录下bin\catalina.bat，在文件靠前位置找到set JAVA_OPTS，如果没有就自行添加一行：
set JAVA_OPTS=-Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512mLinux环境：编辑bin/catalina.sh，在cygwin=false之前插入：
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"改完保存,重启Tomcat，验证是否生效：执行ps -ef | grep tomcat找到进程号，再执行jinfo -flags <pid>，确认输出中包含刚设置的-Xmx值。
调大堆内存后反而更卡的坑
有人把-Xmx从1G直接拉到8G，结果Full GC停顿时长从几百毫秒涨到数秒，原因是堆越大，单次Full GC要扫描的对象越多。国内某大型云服务商的技术文档中曾提示，堆内存超过4GB后应优先考虑G1垃圾回收器，通过-XX:+UseG1GC开启，并用-XX:MaxGCPauseMillis设定目标停顿时间，参数不是越大越好，匹配业务峰值并留出余量才是正解。
Linux服务器tomcat内存调整的实操路径
Linux服务器tomcat内存调整除了改脚本参数，还要配合系统层面的观察和限制，否则改了JVM参数也可能被系统层面拦住。
用命令定位内存瓶颈
按顺序执行下面几个命令,基本能锁定问题层级：
free -h：看系统物理内存和Swap剩余，如果available列已经很小，先扩内存或降其他进程占用。top -p <tomcat_pid>：看Tomcat进程的RES列，即实际物理内存占用。jmap -heap <pid>：查看堆各区域使用情况，确认老年代是否接近上限。jstat -gcutil <pid> 1000 10：连续采样10次，看Full GC频率和回收效果。
调整后的验证与监控
参数改完不能只看“没报错”就结束，建议在业务高峰期观察两项指标：Full GC后老年代占用百分比是否回落到合理区间，以及Tomcat进程RES是否稳定，可以用nohup jstat -gcutil <pid> 60000 >> gc.log &把采样写入日志，持续追踪一天，若老年代在Full GC后仍持续上涨，大概率存在内存泄漏，需要拿jmap -dump:format=b,file=heap.bin <pid>导出堆转储，用分析工具进一步定位。
Tomcat内存问题Q&A
Tomcat内存不足和JVM内存不足是一回事吗
不完全一样,JVM内存不足是运行时堆、元空间等区域耗尽，JVM主动抛OutOfMemoryError；Tomcat内存不足是更宽泛的说法，还包含系统物理内存被挤爆、进程被内核杀掉的情况，排查时先看日志有没有OOM报错，没有报错但进程消失，就查系统OOM Killer记录（dmesg | grep -i kill）。
tomcat内存大小设置多少合适
没有统一值,起步可按服务器物理内存的50%到60%分配给-Xmx，再用压测或生产高峰的GC日志验证，判断依据是Full GC后老年代占用能明显回落、GC停顿在可接受范围，堆设得过大反而拉长单次回收停顿，需要结合回收器选型一起调。
修改JVM参数后Tomcat启动失败怎么办
先看logs/catalina.out里的报错首行，常见原因是参数拼写错误，比如-Xmx2g写成了-Xmx2G（部分旧版本不识别大写），或者JAVA_OPTS引号没闭合导致整行被截断，另一个高频原因是服务器物理内存不足，-Xms设得比系统可用内存还大，JVM直接拒绝启动，把参数逐项拆分测试即可定位到具体哪一项。
Tomcat内存调整的本质是让JVM的胃口和服务器家底、业务饭量三者对齐，盲调数字只会按下葫芦浮起瓢，先看清报错类型，再改对参数位置，最后用GC日志验证效果，这套路径比反复重启可靠得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795547.html
