Ubuntu Java日志中常见警告解析

Ubuntu Java日志中常见警告解析

一 日志来源与快速定位

• 应用日志：由Log4j2、Logback、java.util.logging等输出，关注WARN/ERROR级别与堆栈。Ubuntu 上常见写入路径为**/var/log/应用名/或通过 systemd 的journald**查看（命令：journalctl -u 服务名 -f）。
• JVM致命错误日志：当 HotSpot 遇到不可恢复错误，会在工作目录生成hs_err_pid.log，内含信号、寄存器、线程、崩溃时栈、可能的指令地址等关键信息。
• 系统级日志：用于判定是否被系统终止或资源受限。Ubuntu 主要查看**/var/log/syslog**（而非传统的/var/log/messages）；命令：grep -i “killed|oom|java” /var/log/syslog。必要时结合 journalctl -k 查看内核日志。

二 常见警告与处置要点

• 内存提交失败（HotSpot 信息级警告）
  典型日志：Java HotSpot™ 64-Bit Server VM warning: INFO: os::commit_memory(…) failed; error=‘Cannot allocate memory’ (errno=12)。含义为操作系统无法提交更多内存页（不等于物理内存耗尽，也可能是虚拟内存/交换区/ulimit 限制）。处置要点：

  1. 检查系统资源：free -h、swapon -s、df -h；2) 适当降低**-Xmx/-Xms**；3) 减少线程数或降低**-Xss**；4) 检查容器/进程的内存限制与 cgroup；5) 确认使用64位JDK；6) 视情况增加物理内存/交换空间。

• Java 堆内存不足（OutOfMemoryError）
  典型日志：java.lang.OutOfMemoryError: Java heap space / Metaspace / unable to create new native thread。含义为堆/元空间/线程栈无法满足分配。处置要点：

  1. 堆问题：增大**-Xmx**，结合G1GC等回收器；2) 元空间：增加**-XX:MaxMetaspaceSize**；3) 线程：减少并发线程或降低**-Xss**；4) 排查内存泄漏（堆转储 + 分析工具）。

• 被系统终止（OOM Killer 或 SIGKILL）
  典型日志：/var/log/syslog 出现 “Out of memory: Kill process (java)” 或 “killed by SIGKILL”。含义为系统内存紧张，内核 OOM Killer 终止了 Java 进程。处置要点：

  1. 降低应用内存占用（见上条）；2) 增加物理内存/交换空间；3) 检查容器内存上限；4) 优化应用内存使用模式。

• JVM 崩溃但未生成 core dump
  典型日志：hs_err_pid.log 末尾出现 “Failed to write core dump. Core dumps have been disabled.”。含义为JVM 崩溃但当前环境禁止生成 core。处置要点：

  1. 在启动 Java 前执行：ulimit -c unlimited；2) 确保**/proc/sys/kernel/core_pattern**与目录可写；3) 如需保留现场，配置 core 文件命名与轮转。

• 忽略已废弃/不生效的 JVM 选项
  典型日志：Java HotSpot™ 64-Bit Server VM warning: ignoring option MaxPermSize=…; support was removed in 8.0。含义为JDK 版本不匹配导致选项被忽略。处置要点：

  1. JDK 8使用**-XX:MaxMetaspaceSize替代MaxPermSize**；2) 升级后清理不再支持的参数。

三 快速排查清单

• 第一步：确认日志归属
  应用日志看WARN/ERROR与堆栈；JVM 致命错误看hs_err_pid.log；系统终止看**/var/log/syslog**或 journalctl。

• 第二步：检查资源与限制
  free -h、swapon -s、ulimit -a、cat /proc//limits、docker/podman 的内存 limit。

• 第三步：调整 JVM 参数
  结合负载与版本，合理设置**-Xms/-Xmx/-Xss/-XX:MaxMetaspaceSize**，必要时切换/优化GC。

• 第四步：保留现场与复现
  开启core dump，保留hs_err_pid.log与业务日志，缩小复现步骤。

• 第五步：长期观测与优化
  规范日志级别与输出目的地（便于检索与分析），必要时引入ELK/Graylog或VisualVM/JProfiler做性能与内存分析。