Linux上Tomcat内存溢出怎么解决

Linux上Tomcat内存溢出定位与解决

一、快速判断错误类型

• 查看 $CATALINA_HOME/logs/catalina.out 或按日期的 catalina.yyyy-mm-dd.log，根据异常关键字确定类型：
  • Java heap space：堆内存不足，常见于大对象、集合未释放、一次性加载过多数据等。
  • PermGen space（JDK 7 及更早）：永久代/方法区不足，常见于应用加载大量类、JSP 预编译、第三方 JAR 多。
  • Metaspace（JDK 8+）：元空间不足，现象类似 PermGen，但参数不同。
  • unable to create new native thread：无法创建新线程，多与系统/容器线程数、栈大小或 ulimit 限制相关。
  • StackOverflowError：线程栈溢出，常见于极深递归或超大局部变量。以上判断路径与示例在 Tomcat 运维实践中被广泛采用。

二、对应处理方案与参数示例

• 堆内存不足（Java heap space）
  • 调整堆大小：将 -Xms 与 -Xmx 设为相同，避免运行期频繁扩容；通常不超过物理内存的约80%，并预留给系统与其他进程。
  • 示例（Linux，编辑 $CATALINA_HOME/bin/catalina.sh，在文件靠前位置设置）：
    • JAVA_OPTS=“-server -Xms2G -Xmx2G -XX:+UseG1GC -Dfile.encoding=UTF-8”
  • 若仍异常，结合内存分析工具定位对象泄漏或优化大对象/批量查询（见第四节）。
• 永久代/元空间不足（PermGen/Metaspace）
  • JDK 7 及更早：增大永久代
    • JAVA_OPTS=“-Xms1G -Xmx1G -XX:PermSize=128M -XX:MaxPermSize=256M”
  • JDK 8+：增大元空间（不设 MaxPermSize，改用 MaxMetaspaceSize）
    • JAVA_OPTS=“-Xms1G -Xmx1G -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M”
  • 若是类加载过多（多应用/多版本 JAR、JSP 频繁编译），同步清理无用应用与依赖，避免热部署反复加载类。
• 无法创建新线程（unable to create new native thread）
  • 检查系统/容器限制与当前用量：
    • ulimit -u（用户进程数）、ulimit -s（栈大小）、cat /proc/sys/kernel/threads-max
    • ps -eLf | wc -l（系统线程数）、jstack | wc -l（JVM 线程数）
  • 调整 Tomcat 线程与栈：
    • server.xml 中 的 maxThreads（如 200–500，视硬件与业务而定）、acceptCount；必要时适度增大线程栈 -Xss（如 256k–1M，增大可缓解栈深但会减少可创建线程数）。
    • 适度降低应用线程栈需求或优化代码，避免线程泄漏。
• 栈溢出（StackOverflowError）
  • 增大线程栈：如 -Xss512k 或更高（权衡可创建线程数）。
  • 优化代码：避免极深递归、避免在栈上构造超大对象（如巨大的字符串拼接/缓冲）。

三、Linux与Tomcat配置要点

• 设置位置与语法
  • 在 $CATALINA_HOME/bin/catalina.sh 靠前位置设置 JAVA_OPTS（不要在 setenv.sh 之外重复定义，避免被覆盖）。
  • 示例：
    • JAVA_OPTS=“-server -Xms2G -Xmx2G -XX:+UseG1GC -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M -Dfile.encoding=UTF-8”
• 避免常见误区
  • -Xmx 不应超过机器可用物理内存太多，且需为系统和其他服务预留资源；设置过大反而易触发系统 OOM 或影响 GC 停顿。
  • 建议 -Xms == -Xmx，减少堆动态扩缩带来的抖动。
  • 线程与栈是“此消彼长”的关系：增大 -Xss 会降低可创建线程上限，需结合 maxThreads 与业务并发综合权衡。

四、定位与优化步骤

• 监控与抓取现场
  • 观察 catalina.out 异常时间点与线程/内存状况；必要时使用 jstat -gc 观察 GC 与内存变化，使用 jmap -dump:format=b,file=heap.hprof 导出堆转储，配合 VisualVM/MAT 分析泄漏对象与引用链。
• 常见根因与修复
  • 代码侧：集合/缓存使用后未清理、长生命周期对象持有短生命周期引用、死循环/重复造对象、一次性拉取大量数据（如 > 10 万条）未分页。
  • 架构侧：缓存策略不当、对象生命周期设计不合理、依赖库版本冲突导致类重复加载。
  • 运维侧：线程数/栈/句柄超限、容器/系统资源紧张。
• 验证与回归
  • 复现路径压测、A/B 对比 GC 停顿与 OOM 频率，确认优化有效后再上线。

五、一键可用的安全起步配置示例

• JDK 8+（元空间，G1 GC）
  • JAVA_OPTS=“-server -Xms2G -Xmx2G -XX:+UseG1GC -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M -Xss256k -Dfile.encoding=UTF-8”
• JDK 7（永久代）
  • JAVA_OPTS=“-server -Xms2G -Xmx2G -XX:PermSize=128M -XX:MaxPermSize=256M -Xss256k -Dfile.encoding=UTF-8”
• 提示：将 2G 替换为与你的机器内存与业务并发相匹配的值，通常不超过物理内存的约80%；修改后重启 Tomcat 并观察 catalina.out 与 GC 日志。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！