Ubuntu上Java内存溢出怎么办

Ubuntu上Ja va内存溢出的定位与解决

说实话，Ja va内存溢出这个问题，在Ubuntu服务器上碰到过不少回，每次排查都有固定的套路。先别慌，按下面这几步走，基本能定位到根因。

一、快速判断与应急

首先，得搞清楚“溢”在哪里。看日志时关注几个关键字：Ja va heap space（堆空间不足）、Metaspace（元空间爆了）、Direct buffer memory（直接内存告急）、unable to create new native thread（线程数超限）。不同关键字对应不同的处理方式。

应急手段很简单：如果是堆空间不足，适当提升堆上限，比如从 -Xmx1g 提到 -Xmx2g。命令示例：ja va -Xms1g -Xmx2g -jar app.jar。但要注意，-Xmx 不要超过物理内存的80%，而且通常建议把 -Xms 和 -Xmx 设为相同值，避免运行时频繁扩缩堆导致抖动。

如果是元空间问题，Ja va 8及更早版本用 -XX:MaxPermSize 限制；Ja va 8+ 则用 -XX:MaxMetaspaceSize。直接内存问题则用 -XX:MaxDirectMemorySize 限制，并排查 ByteBuffer.allocateDirect 等调用是否及时释放。线程数超限时，先检查应用是否创建了过多线程，再考虑提升系统或容器的线程数限制。

二、系统层面排查

有时候Ja va进程不是自己崩的，而是被系统“干掉”的。执行 dmesg -T | grep -i 'oom\|kill'，如果看到Ja va进程被kill，说明系统整体内存不足。这时候要么降低JVM内存，要么优化应用，要么扩容机器。

别忘了用 top/htop 看看内存和CPU占用，free -h 查看系统可用内存与缓存。另外，用 ps -ef | grep ja va 确认当前生效的JVM参数，特别是 -Xms、-Xmx 和 -XX 系列。

三、JVM参数与GC调优建议

堆大小方面，前面说了，-Xms 和 -Xmx 设为相同，一般不超过物理内存的80%。年轻代可以用 -Xmn 设置，通常取 -Xmx 的1/4作为起点，再根据GC日志微调。

垃圾回收器选择上，大堆和低延迟场景优先考虑G1 GC，示例：-XX:+UseG1GC -XX:MaxGCPauseMillis=200。如果JDK版本在11以上，也可以结合业务特点测试ZGC或Shenandoah。其他常用参数包括开启分层编译 -XX:+TieredCompilation 提升运行期性能，必要时限制Metaspace和Direct Memory。

四、代码与数据访问优化

很多内存溢出其实是代码写法不当造成的。比如，避免一次性把海量数据装入内存——对JDBC、ES、文件等数据源采用流式、分页或批处理，边读边处理，减少驻留堆的对象数量。同时，及时清理集合、缓存、监听器，避免静态集合无限增长——这往往是内存泄漏的温床。

临时对象创建也要注意：循环里用StringBuilder替代字符串拼接，复用对象或使用对象池。选择合适的数据结构和算法，能明显降低内存占用和GC压力。

五、监控与根因分析工具

日常监控用 jstat -gc 观察YGC和FGC的次数与停顿，开启GC日志（如 -Xlog:gc*:file=gc.log:time）辅助定位。如果怀疑内存泄漏，用VisualVM、Eclipse MAT或JProfiler抓取堆转储（heap dump），分析支配树与对象保留路径——这是最直接的证据。

系统层面，推荐结合Prometheus + Grafana + JMX Exporter持续观测堆使用、GC时间、线程数等指标，并设置告警。这样问题还没严重到OOM就能提前发现，比事后补救省心得多。