linux查jdk日志本质是查jvm行为(gc、崩溃)和java应用日志(如spring boot的logback输出),而非jdk自身日志;需结合stderr、dmesg、tail -f、grep -i及-xlog等参数定位问题。

Linux 上查 JDK 日志,本质不是查“JDK 自己的日志”——JDK 本身不主动写日志,真正要查的是 JVM 启动过程、GC 行为、崩溃堆栈,以及 Java 应用(比如 Spring Boot)通过 Logback/Log4j 写出的日志。混淆这点,就容易在 /usr/lib/jvm 里翻半天空目录。
Java 进程启动失败时,先看 stderr 和 dmesg
很多“JDK 不工作”的问题根本不在 Java 层:缺库、内存不足、内核限制、权限错误。直接看 JVM 启动命令的输出最有效:
- 如果用
java -jar app.jar启动,没加> app.log 2>&1,错误会直接打到终端——别关窗口,Ctrl+C 前先复制 - 如果用 systemd 管理,执行
journalctl -u your-app.service -n 50 -e,重点看末尾几行,常见报错如:Cannot allocate memory、Could not reserve enough space for object heap、libz.so.1: cannot open shared object file - 运行
dmesg -T | tail -20,确认是否被 OOM killer 杀过,或出现Out of memory: Kill process—— 这比翻应用日志快十倍
tail -f 和 grep -i 是查应用日志的黄金组合
Spring Boot 默认不写文件日志,除非你配了 logback-spring.xml 或启动时加了 --logging.file.name=/var/log/myapp/app.log。别假设日志一定存在:
Linux系统管理专家,覆盖12大模块:用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词:useradd、sudo、sshd_config、chmod、SEL...
- 先确认路径:
ls -l /var/log/myapp/app.log*,注意滚动文件如app.log.2026-08-11.1 - 实时追日志:
tail -f /var/log/myapp/app.log,Ctrl+C 退出;想看最近 200 行:tail -n 200 /var/log/myapp/app.log - 搜关键错误:
grep -i "exception\|error\|failed\|timeout" /var/log/myapp/app.log | tail -20,加-i避免大小写漏判 - 查某次请求上下文:
grep -A10 -B5 "OrderService.*timeout" /var/log/myapp/app.log,-A10显示匹配行后 10 行,-B5显示前 5 行
JVM 自身行为日志得手动开,-Xlog 不能省
默认情况下,JVM 不输出 GC、类加载、JIT 编译等内部动作。线上排查卡顿、OOM、类加载冲突,必须提前加参数:
- 基础 GC 日志:
-Xlog:gc*:file=/var/log/myapp/gc.log:time,tags:filecount=5,filesize=100m(JDK 10+) - 查类加载问题:
-Xlog:class+load=debug,会打印每个类从哪个 jar 加载、是否重复定义 - 诊断 JIT 编译异常:
-Xlog:jit+compilation=debug - 注意:这些日志默认不落盘,不加
file=...就只打到控制台;且-Xlog语法和旧版-XX:+PrintGCDetails不兼容,混用会启动失败
查不到日志?先验证三件事
90% 的“日志找不到”问题,卡在这三个地方:
-
ps -ef | grep java看实际启动命令,确认有没有-Dlogging.file.name=...或--logging.file.name=...;没配就是只打 stdout/stderr - 检查日志目录权限:
ls -ld /var/log/myapp,确保运行 Java 的用户(如appuser)有写权限,否则日志静默失败 - 确认磁盘空间和 inodes:
df -h /var/log和df -i /var/log,inodes耗尽时,新建文件会失败,但错误不提示
真正难的不是命令怎么敲,而是分清哪段日志属于 JVM、哪段属于应用、哪段其实是内核在替你报错。盯着 app.log 找三天,不如先跑一遍 dmesg -T | grep -i "kill\|oom\|fail"。










