Tomcat查错日志

本地调试没有问题的程序，在生产系统一跑就出现各种问题。这个时候我们一般都通过定位部署容器的日志目录来检查问题，比如这里以Tomcat容器为例，我们可以在Tomcat根目录下的logs文件夹下找到catalina.log、localhost.log等日志文件。这些只能记录运行过程中的日志，如果遇到程序崩溃的问题，这里的日志就不能满足我们的查错需求了。

一、JVM致命错误

如果出现致命错误导致程序调停，那么我们就需要到另一个目录下进行查看日志。
这里我们以Tomcat为例，我们都知道常规日志都在根目录下的logs目录下，那么崩溃日志在哪里呢。
其实崩溃日志的记录地址在bin目录下，刚知道的时候还有一点意外，不过也不难理解，程序崩溃毕竟不是一件小事，所以记录在bin目录下也不是不可以，如果想配置到其他目录下也完全可以自定义。
我们进入到bin目录下，能够看到以hs_err_pid为前缀的文件就是崩溃日志。

二、了解日志

我们随便打开一个hs_err日志文件，文件片段内容如下：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7acfdf0a91, pid=6545, tid=0x00007f7acebe6700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x0000000003590800):  JavaThread "SockJS-4" [_thread_in_native, id=6583, stack(0x00007f7aceae6000,0x00007f7acebe7000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000003

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x0000000000000000, RDX=0x00000000000000c0
RSP=0x00007f7acebe1b00, RBP=0x00007f7acebe1df0, RSI=0x0000000000000000, RDI=0x00000000ffffffff
R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x00000000000a9ddb, R11=0x0000000000000217
R12=0x00007f7acebe2770, R13=0x00007f7acebe1b30, R14=0x0000000000000000, R15=0x00007f7acebe6db8
RIP=0x00007f7acfdf0a91, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

如果查看这些内容，肯定没办法理解实际的报错信息。我们需要再往下翻看，文中以j开头的就是java程序中出现的错误，且特别注意程序中的类名、方法名以及属性名等关键词。
例如：

j  com.huayun.service.thirdserivce.gateway.GatewayCommService.getFBoxDeviceInfoBySerialNumber(Ljava/lang/String;)Lcom/huayun/service/thirdserivce/param/GatewayFBoxDeviceOutput;+368

这是我在生产系统中真实发现的一个崩溃错误，表示在我的GatewayCommService类中的getFBoxDeviceInfoBySerialNumber方法Http请求超时，且未设置超时时长导致程序崩溃。
通过这一句日志内容，我们就能极快的定位到问题。

三、解决HttpClient超时问题

由于我的程序崩溃主要原因是HTTPClient超时问题，所以在这里分享一下我们在使用HttpClient的时候需要注意的内容。
首先我们在使用HttpClient的时候一定要假设服务端无法响应请求的情况，所以在这里我们一定要加上超时时间：

HttpGet httpGet = new HttpGet("http://stackoverflow.com/");  
RequestConfig requestConfig = RequestConfig.custom()  
        .setConnectTimeout(5000).setConnectionRequestTimeout(1000)  
        .setSocketTimeout(5000).build();  
httpGet.setConfig(requestConfig);  

参考资料:

• JVM致命错误日志(hs_err_pid.log)分析
• HttpClient超时设置详解