CentOS下Tomcat内存溢出解决方案

CentOS下Tomcat内存溢出定位与解决

一、快速判断与应急

• 查看异常类型与位置：在 $CATALINA_HOME/logs/catalina.out 搜索 OutOfMemoryError，常见有 Java heap space、PermGen space/Metaspace、unable to create new native thread。
• 获取进程号并快速体检：
  • 查看进程：ps -ef | grep tomcat
  • 堆/GC概况：jstat -gcutil 1000（每秒刷新）
  • 触发并导出堆转储：先确保磁盘空间充足，执行 jmap -dump:live,format=b,file=heapdump.hprof ；分析可用 jhat heapdump.hprof 或导入 Eclipse MAT。注意：生成 dump 会使 JVM 短暂停顿，生产环境谨慎操作。
• 临时止血：重启 Tomcat；若频繁 OOM，先增大堆（见下一节），再安排根因排查。

二、调整JVM内存参数

• 修改脚本位置与方式：编辑 $CATALINA_HOME/bin/catalina.sh，在 cygwin=false 之前添加 JAVA_OPTS（或优先使用 CATALINA_OPTS，仅对 Tomcat 生效）。示例：
  • JDK 8 及更早（含 PermGen）：
    • 建议将 -Xms 与 -Xmx 设为相同，避免运行期扩缩堆带来的抖动。
    • 示例：JAVA_OPTS=“$JAVA_OPTS -Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m”
  • JDK 8+（Metaspace，取代 PermGen）：
    • 移除 PermSize/MaxPermSize，改用 -XX:MetaspaceSize、-XX:MaxMetaspaceSize。
    • 示例：JAVA_OPTS=“$JAVA_OPTS -Xms1024m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m”
  • 可选GC策略：如 -XX:+UseG1GC（大堆、停顿可控场景常用）。
• 使配置生效：保存后执行 $CATALINA_HOME/bin/shutdown.sh 再 startup.sh；用 ps -ef | grep tomcat 或 jinfo 校验参数是否注入。
• 重要提示：若以系统服务方式运行（如 systemd 或安装版服务），需在该服务的配置中设置 JVM 参数，修改 catalina.sh 可能不生效。

三、常见诱因与代码侧优化

• 一次性加载大数据到内存（如查询 10万+ 条记录），应改为分页/游标处理。
• 集合、缓存使用后未及时清理，导致对象无法被 GC 回收；排查 static Map/LRU 等长期持有引用的结构。
• 死循环/递归或大对象频繁创建，短时间内对象激增。
• 定时任务并发或峰值叠加，瞬时内存压力过高；错峰执行、限流降级。
• 结合监控与堆转储定位“谁在占用内存”，优先处理占用最高且持续增长的对象链路。

四、运行环境与监控建议

• 系统资源与句柄限制：检查 ulimit -a，关注 open files、max user processes 等；必要时调高，避免“too many open files”或无法创建线程。
• 日志滚动：对 catalina.out 使用 Cronolog 或同类方案按时间切割，防止日志膨胀影响 I/O 与内存。
• 可视化与告警：用 jstat 持续观察 S0/S1/E/O/M、YGC/FGC；配置 Prometheus + Grafana + JMX Exporter 做长期监控与阈值告警。

五、参数模板与验证步骤

• 模板示例（按 JDK 版本区分，放在 catalina.sh 的 cygwin=false 之前）：
  • JDK 8（含 PermGen）：
    • JAVA_OPTS=“$JAVA_OPTS -server -Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseG1GC”
  • JDK 8+（Metaspace）：
    • JAVA_OPTS=“$JAVA_OPTS -server -Xms1024m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC”
• 验证步骤：
  1. 重启后在日志确认参数生效（或 jinfo ）。
  2. 用 jstat -gcutil 1000 观察 Eden/Old 使用与 GC 频率是否趋于平稳。
  3. 若仍 OOM：增大堆/元空间（不超过物理内存与容器配额），保留现场 heapdump.hprof 做离线分析。
  4. 分析聚焦“占用最高对象 + GC Roots 引用链”，回到代码侧治理根因。