Java进程消失故障简单排查
主动退出使用strace-eexit_group-k-p$javapidstrace-eexit_group-k-ppgrepjava其中$javapid是Java线程运行时的pid如果java进程已经挂掉则只能查看日志或重启后使用命令查看JVM主动退出1.Error比如OOMexit_group的退出码非0代表异常退出。2.非守护线程退出比如在main函数中启动一个守护线程但是JVM执行完main函数退出此时exit_group的退出码为0代表线程正常退出。Error错误是jvm写到标准输出中的而不是Java中常见的logback日志因此需要查找进程的标准输出日志存储位置使用lsof-a-d1-cjava或nohupjava-jarxx.jarstdout.log来启动线程对性能要求较高时可以使用ebpf工具的exitsnoop来查看EXIT_CODE的值来判断信号杀死这种情况是被Linux系统杀死了比如Linux中的信号有如下kill-l如果进程不处理信号的话信号一般有三种默认行为其中Term表示杀死进程Core表示杀死进程且生成coredump文件Ign表示忽略信号。多数信号都会杀死进程。信号来源1.硬件触发如键盘键入CtrlC发SIGINT信号终端断开发SIGHUP信号等2.程序运行错误如非法内存访问发SIGSEGV信号调用abort会触发SIGABRT信号3.其他程序发送如kill -11会给对应线程发SIGSEGV信号依旧可以使用strace来排查通过信号的si_code就可知是其他程序发的信号如果strace不可用时可以使用ebpf工具的sigsnoop来查看PIDCOMM发送方SIG信号TPID接收方jvm自身处理了一些信号这使得jvm程序运行错误时jvm自身能保留一些现场数据在其工作目录中一般称为jvm崩溃日志hs_err_*.log文件包含导致崩溃的信号、线程栈、jvm进程信息、系统信息等如果通过ulimit开启了coredump即ulimit-cumlimited还会生成一个coredump文件以供gdb、jstack、jmap分析OOMKiller杀掉当可用内存不足时Linux为了保全大局会使用OOMKiller机制选择一些进程并干掉他而java通常是内存消耗比较大的所以经常被牺牲掉。通过以下命令检查内核日志dmesg-T|grep-ikilled如果发现了OOMKiller日志且进程号或时间点对应的上就可以确认。