Tomcat内存溢出怎么解决

Tomcat 内存溢出定位与解决

一、先判断是哪一类 OOM

• Java heap space：堆内存不足，常见于对象生命周期过长、缓存失控、一次性加载大数据等。
• Metaspace / PermGen space：类元数据区不足，常见于热部署频繁、依赖 JAR 过多、类加载器泄漏。
• unable to create new native thread：无法创建新线程，多与系统/容器线程数限制、栈空间或内存总量有关。
• StackOverflowError：线程栈溢出，常见于递归过深或方法调用层次异常。
  以上类型及典型成因可结合日志关键字与现象快速判断，例如出现“Metaspace”多为类元数据问题，“unable to create new native thread”多与系统限制相关。

二、快速处置与参数调整

• 调整堆与元空间（JVM 参数）
  • 建议将 -Xms 与 -Xmx 设为相同，避免运行期频繁扩缩堆；堆占用不宜超过物理内存的约80%。
  • Java 8 及以后使用 Metaspace，用 -XX:MaxMetaspaceSize 限制上限；Java 7 及更早使用 -XX:PermSize / -XX:MaxPermSize。
  • 示例（Linux，编辑 bin/catalina.sh，放在 cygwin=false 之前）：
    • JAVA_OPTS=“$JAVA_OPTS -Xms1024m -Xmx1024m -XX:+UseG1GC -XX:MaxMetaspaceSize=512m”
  • 示例（Windows，编辑 bin/catalina.bat）：
    • set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:+UseG1GC -XX:MaxMetaspaceSize=512m
  • 32 位环境堆上限通常仅 1.5G~2G，必要时迁移至 64 位。
• 作为服务运行时（Windows）
  • 若通过系统服务启动，修改 catalina.bat 的 JAVA_OPTS 可能不生效，需通过 tomcat8w.exe（或注册表）设置堆参数，或重新安装服务使参数生效。
• 连接数与并发
  • 适当降低 maxThreads、acceptCount，避免并发过高导致内存与线程压力叠加；按需优化 Connector 配置。
• 监控与 GC 日志
  • 打开 GC 日志，结合 jstat -gcutil 1000 观察 GC 频率与回收效果；必要时抓取堆转储进一步分析。
    以上做法可快速缓解因配置不足或短期峰值导致的内存问题，并为后续定位争取时间。

三、定位根因的工具与方法

• 堆转储与离线分析
  • 抓取堆快照：jmap -dump:live,format=b,file=heap.hprof
  • 分析快照：jhat heap.hprof 或用 VisualVM/MAT 定位占用最高的对象与 GC Roots 引用链。
• 在线监控
  • 使用 jconsole / VisualVM 观察堆、类、线程、CPU 等指标变化，辅助判断是否存在对象泄漏或瞬时峰值。
• 系统层面检查
  • 检查系统资源限制：ulimit -a（如 open files、max user processes），必要时调高；
  • 统计进程打开文件数：lsof -n | awk ‘{print $2}’ | sort | uniq -c | sort -nr | head，排查句柄泄漏。
• 代码与数据访问
  • 排查集合/缓存未清理、长生命周期引用、死循环/递归、一次性拉取大量数据等常见根因；对查询做分页/分批处理。
    以上方法配合日志关键字（如“Java heap space”“Metaspace”“unable to create new native thread”）可较快锁定问题域。

四、按场景给出配置与优化建议

五、常见坑位与预防

• 32 位 JVM 堆上限受限，生产建议使用 64 位 与足够的物理内存。
• 热部署/频繁发布易致 PermGen/Metaspace 与类加载器泄漏，建议控制版本更替、清理无用依赖、避免重复加载。
• 大对象/大文件/大查询结果一次性入内存，极易触发 heap OOM，务必分页/流式处理。
• 并发与缓存需设上限与淘汰策略，避免无界增长。
• 建立常态化监控与告警（如 GC 时间、内存使用、线程数、句柄数），并保留堆转储用于回溯分析。
  这些实践能显著降低 OOM 概率，并在问题发生时快速定位与恢复。