在 Linux 上处理 Java 应用故障时，日志往往是第一手线索，但不同问题适合的查看方式并不一样：有的要盯住最新输出，有的要回看大文件上下文，有的则需要快速筛出异常关键词。下面按实际排查路径，把常见命令和适用场景重新整理一遍，帮助你更快判断该用 tail、less、grep，还是直接去看启动日志和系统服务日志。
实时追踪最新日志：先用 tail
如果你已经知道日志文件路径，排查线上波动、接口报错或服务刚启动后的输出时，最直接的办法就是实时跟踪日志追加内容。
tail -f /path/to/your/logfile.logtail -f里的 -f 表示持续跟随文件变化。只要有新日志写入，终端就会立刻打印出来，适合观察问题是否仍在持续发生。结束查看时按 Ctrl+C 即可退出。
这个方式最适合两类场景：一类是应用正在运行，你想盯住错误是否再次出现；另一类是刚重启服务后，想立刻确认启动阶段有没有异常输出。
日志太长看不清：用 less 或 more 分页阅读
当日志文件内容很多，一屏看不完时，分页查看会比直接输出到终端更高效。
less /path/to/your/logfile.log或者：
more /path/to/your/logfile.log两者都能用来分页阅读日志，但 less 通常更常用，因为它支持更灵活的上下翻页，也能通过 / 直接搜索关键词。对于需要回看前后文、反复定位某段输出的情况，less 往往比 more 更顺手。
只看报错和关键字：grep 快速筛选
如果你已经大致知道要找什么，比如 ERROR、NullPointerException，或者某个请求 ID、类名、接口路径，那么直接搜索比通读整份日志更快。
grep "keyword" /path/to/your/logfile.log常见的增强用法还包括：
-i：忽略大小写，适合关键词写法不统一的日志；-C 5：显示匹配行前后各 5 行，便于同时看上下文。
grep 的价值在于先把范围缩小，再决定是否继续深挖。很多线上排障其实不是“看日志”，而是先把关键异常定位出来，然后再结合上下文判断问题来源。
需要进一步过滤处理：awk 和 sed
当 grep 还不够用，比如你想提取特定时间段内容、只保留符合条件的字段，或者把日志结果做进一步脚本化处理时，可以继续用 awk 或 sed。
awk '/keyword/ {print}' /path/to/your/logfile.log或者：
sed -n '/keyword/p' /path/to/your/logfile.log这两类工具更适合复杂过滤。它们的学习成本比 tail、less、grep 高一些，但在批量处理日志、写排障脚本或做定向提取时会很有用。
启动阶段日志怎么看
如果问题发生在 Java 应用启动过程中，先确认日志是否在启动命令中被明确指定。常见做法是在 java -jar 启动时通过 --logging.file 指定输出路径：
java -jar your-application.jar --logging.file=/path/to/your/logfile.log这样启动过程中的日志会写入指定文件，后续运行日志通常也会继续追加到同一位置。对于启动报错、配置加载失败、端口占用、依赖初始化异常这类问题，先找到这个文件通常比盲目翻系统目录更有效。
作为系统服务运行时：查看 journalctl
如果 Java 应用是通过 systemd 管理的服务，例如以 tomcat、myapp 等服务名运行，那么除了应用自身日志，还应该同步检查系统服务日志。
journalctl -u your-service-name把 your-service-name 替换成实际服务名即可。这里往往能看到应用启动失败、权限问题、资源限制或 systemd 层面的控制信息，对于“服务起不来但应用日志不完整”的情况尤其有帮助。
日志量上来后，考虑集中化日志工具
当服务数量增多、节点分散，或者需要跨机器检索、长期留存和可视化分析时，单靠命令行查看日志会逐渐变得吃力。这时可以考虑引入日志管理方案，比如 ELK Stack（Elasticsearch、Logstash、Kibana）或 Fluentd。
这类工具的核心价值在于集中收集、建立索引并提供可视化检索能力。前期部署确实需要投入，但对于生产环境来说，搜索效率、关联分析能力以及团队协作体验通常会明显优于手工登录服务器逐台排查。
实际排查时怎么选最省时间
如果只是确认最新报错是否还在出现，先用 tail -f；如果需要翻看大文件上下文，优先用 less；如果目标是异常关键字或某段调用栈，直接上 grep；遇到复杂提取需求，再考虑 awk 和 sed。而一旦问题发生在启动阶段或服务托管层，就别只盯应用日志，还要同时检查 journalctl。
换句话说，Linux 下查看 Java 日志没有一条万能命令，关键在于先判断问题发生在哪一层，再选对应工具。这样排查效率通常会高很多。
