Java在Ubuntu上出现内存溢出怎么办

Java在Ubuntu出现内存溢出的处理步骤

一 快速判断与应急

• 查看异常类型，确认是堆、元空间、直接内存、线程还是GC异常：
  • Java heap space：堆内存不足
  • Metaspace / PermGen space：类元数据/永久代不足
  • unable to create new native thread：线程数超限或系统资源不足
  • Direct buffer memory：堆外/直接内存不足
  • GC overhead limit exceeded：GC耗时过长、回收效率低
• 立即开启故障取证参数，便于后续分析：
  • 启动时加上：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/your-app/heap.hprof
  • 采集GC日志：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/var/log/your-app/gc.log
• 临时缓解（仅用于应急，不能替代根因修复）：适度调大堆，例如：-Xms1g -Xmx2g；若确认是堆外/直接内存，可设置：-XX:MaxDirectMemorySize=512m。同时检查系统可用内存与容器配额是否充足。

二 常见类型与对应处置

三 定位与修复的实操流程

• 确认当前JVM参数与进程信息：
  • 查看进程与参数：ps -ef | grep java
  • 观察启动脚本中的 -Xms/-Xmx/-XX:MetaspaceSize/-XX:MaxMetaspaceSize 等配置
• 监控与GC分析：
  • 实时查看堆与GC：jstat -gc 1s
  • 导出堆转储：jmap -dump:format=b,file=heap.hprof
  • 使用 VisualVM / Eclipse MAT / JProfiler 分析对象占用与引用链，定位泄漏或大对象来源
• 代码与数据层优化：
  • 避免一次性加载海量数据，采用分页/流式处理
  • 清理集合/缓存的过期引用，使用有界缓存与合适的过期策略
  • 减少静态集合长期持有对象，修复资源未关闭与线程泄漏
• 参数与GC策略优化：
  • 合理设置堆大小（如 -Xms 与 -Xmx 接近，减少运行时扩缩开销）
  • 大堆或低停顿诉求可尝试 G1 GC：-XX:+UseG1GC -XX:MaxGCPauseMillis=200
  • 容器场景需同时调整容器内存限制，避免被cgroup/OOM Killer终止

四 Ubuntu与容器场景的注意事项

• 容器（Docker/K8s）务必设置容器内存上限，并与JVM -Xmx 匹配；否则可能出现容器内OOM或宿主机被抢占。示例：docker run -it --memory=4g your-image。
• 使用本地内存映射的应用（如Elasticsearch）需关注 vm.max_map_count：临时提升 sudo sysctl -w vm.max_map_count=262144，永久写入 /etc/sysctl.conf 并执行 sysctl -p。
• 系统层面确保有足够的物理内存/交换空间，并关闭不必要的占用内存进程，避免与JVM争用。

五 可直接使用的启动示例

• 通用Java应用（堆与GC基础配置，含取证）：
  • java -Xms1g -Xmx2g
    -XX:+UseG1GC -XX:MaxGCPauseMillis=200
    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app/heap.hprof
    -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/var/log/app/gc.log
    -jar /opt/app/app.jar
• Elasticsearch等本地内存映射密集场景（示例需按实际调整）：
  • 宿主机/容器：sysctl -w vm.max_map_count=262144
  • 启动示例（仅示意，具体以官方推荐为准）：
    • java -Xms2g -Xmx2g
      -XX:+UseG1GC
      -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/es/heap.hprof
      -jar /usr/share/elasticsearch/lib/elasticsearch-*.jar