Linux下Tomcat报错，该如何查看日志并排查原因？

在Linux服务器环境中，Tomcat作为应用服务器的地位举足轻重，其稳定运行直接关系到业务的连续性，无论是由于代码缺陷、资源瓶颈还是配置失误，Tomcat报错在所难免，掌握在Linux环境下高效、精准地查看和分析Tomcat报错，是每一位开发和运维人员的必备技能，本文将系统性地介绍一套完整的排查方法论，从日志定位、命令使用到常见问题解析,帮助您快速定位并解决Tomcat故障。

核心战场：理解Tomcat的日志体系

排查Tomcat报错，本质上就是解读其产生的日志，Tomcat的日志文件通常位于其安装目录下的 logs 文件夹中（即 $CATALINA_HOME/logs）,理解各个日志文件的用途是成功的第一步。

实战工具：Linux命令组合拳

掌握了日志文件,接下来就需要利用Linux强大的命令行工具来从海量日志信息中提炼出有价值的错误线索。

实时追踪：tail -f

当问题正在发生时，实时监控日志是最直接的方式。tail 命令可以查看文件的末尾，而 -f （follow）参数则能持续输出文件新增的内容。

# 进入Tomcat日志目录
cd $CATALINA_HOME/logs
# 实时监控 catalina.out 日志
tail -f catalina.out

在监控过程中，一旦看到 ERROR, Exception, FATAL 等关键词，就意味着需要重点关注，使用 Ctrl + C 可以退出监控，一个更稳健的选项是 tail -F，它能处理日志文件轮转的情况，即使日志文件被重命名或删除,它也能继续跟踪。

精准搜索：grep

当日志文件非常庞大时，使用 grep 进行模式搜索是最高效的方法。

# 在 catalina.out 中搜索所有包含 "ERROR"（不区分大小写）的行，并显示行号
grep -in "error" catalina.out
# 搜索 "OutOfMemoryError" 异常
grep "OutOfMemoryError" catalina.out
# 显示匹配行的前后各5行上下文，这对于理解错误发生前后的状况至关重要
grep -C 5 "SEVERE" catalina.out

分页浏览：less 或 more

如果需要查看整个日志文件，而不是实时监控或搜索，可以使用 less 或 more 命令进行分页浏览。less 功能更强大,支持向前和向后翻页以及搜索。

# 使用 less 打开日志文件
less catalina.out
# 在 less 界面中，输入 /error 即可向下搜索 "error"
# 输入 ?error 即可向上搜索
# 按 q 退出

常见错误场景与排查思路

结合以上工具,我们来剖析几个典型的Tomcat报错场景。

端口已被占用

这是最常见的启动失败原因之一，Tomcat默认使用8080端口，如果该端口被其他进程占用,启动时会报错。

排查步骤：

1. 使用 grep 在 catalina.out 中搜索 Address already in use 或 bind 相关的错误。
2. 确认端口被占用后，使用 netstat 或 lsof 命令找出占用端口的进程。

   # 查看8080端口被哪个进程占用
   lsof -i :8080
   # 或者
   netstat -tulpn | grep 8080

3. 根据进程ID（PID），决定是终止该进程（kill -9 <PID>），还是修改Tomcat的配置文件 conf/server.xml,将其监听端口改为其他可用端口。

内存溢出

当应用请求的内存超出了JVM分配的最大堆内存时，就会发生 java.lang.OutOfMemoryError: Java heap space 错误。

排查步骤：

1. 在 catalina.out 中搜索 OutOfMemoryError。
2. 如果确认是堆内存不足，需要调整JVM启动参数，最佳实践是在 $CATALINA_HOME/bin 目录下创建一个 setenv.sh 文件（如果不存在），并在其中定义 JAVA_OPTS 环境变量。

   # 在 setenv.sh 中添加以下内容
   # -Xms 设置初始堆大小
   # -Xmx 设置最大堆大小
   export JAVA_OPTS="-Xms512m -Xmx2048m"

3. 保存文件后，赋予执行权限 chmod +x setenv.sh,然后重启Tomcat使配置生效。

应用部署失败

应用本身的问题，如web.xml配置错误、依赖jar包缺失或版本冲突、代码编译错误等,会导致应用在启动阶段失败。

排查步骤：

1. 首选查看 localhost.YYYY-MM-DD.log，此文件会详细记录应用部署过程中的错误,通常会有非常明确的异常堆栈。
2. 如果该文件信息不足，再回过头去检查 catalina.out，看是否有相关的 SEVERE 级别日志。
3. 根据堆栈信息定位到具体的类或配置文件，进行修复。ClassNotFoundException 意味着缺少依赖，而XML解析错误则指向 web.xml 语法问题。

相关问答FAQs

问题1：为什么我的 catalina.out 文件增长得特别快，几天就几个G，我该如何管理？

解答： catalina.out 文件记录了所有标准输出和错误，如果应用程序中有大量的 System.out.println 或日志框架配置不当（将INFO及以上级别日志都输出到控制台），就会导致其迅速膨胀,管理策略如下：

1. 源头优化：检查应用程序的日志配置（如 logback.xml 或 log4j2.xml），确保日志被写入独立的文件，而不是控制台，移除不必要的 System.out.println。
2. 日志轮转：使用日志轮转工具自动切割和清理日志，Tomcat自带了 logrotate 工具，但更推荐的是使用 cronolog，你只需修改 catalina.sh 中的输出重定向语句，将 >> "$CATALINA_OUT" 2>&1 "&" 替换为 | cronolog "$CATALINA_BASE/logs/catalina.%Y-%m-%d.out" >> /dev/null &，这样catalina.out就会按天自动生成新文件,旧的文件可以被定期脚本清理。

问题2：我执行 ./startup.sh 后，Tomcat启动了，但马上就停止了，进程列表中找不到它，该怎么查？

解答： 这种“闪退”情况通常是启动过程中遇到了致命错误，导致进程无法正常初始化,排查思路要更加直接：

1. 直接查看启动脚本输出：直接执行 ./catalina.sh run，这个命令会启动Tomcat并将所有日志直接打印到当前终端，而不是后台运行并重定向到文件，这样你就能立刻看到导致启动失败的错误信息,非常直观。
2. 立即检查 catalina.out：在执行 startup.sh 后，立刻执行 tail -n 50 catalina.out 查看最后50行日志，致命错误（如端口占用、内存设置错误、JDK版本不匹配等）通常会在启动初期就记录在这里。
3. 检查权限：确保运行Tomcat的用户对 $CATALINA_HOME 目录及其子目录有足够的读写执行权限,权限不足也可能导致启动失败。