1、背景描述
某日某客户运维工程师接收到系统报障反应业务缓慢，工程师用命令kill -3 < WLS_PID >的方式发送一个SIGQUIT信号给Java应用之后，通常会有当前的Thread Dump输出，最后thread dump信息没有收集出来，相反weblogic进程自动退出，导致服务停止，业务无法正常工作。
2、系统环境
操作系统： Redhat6.4
JDK版本： JDK1.6
中间件版本：weblogic10.3.6
集群：否
3、故障处理过程
3.1、故障分析
2016-09-13 15:23左右，客户现场运维工程师接收到报障反应系统访问相当慢，于是运维工程师立即检查中间件运行情况，并做了一下线程转储收集。在做线程转储收集时候，服务被终止。现场工程师说当时执行了kill -3 这条命令来收集thread dump信息，没想到竟然把weblogic服务进程给杀掉了。他说以前平时常用kill -3来收集线程信息，今天竟奇怪的把服务给干掉了。他也反复确认操作的命令没错。
发现故障时间15:24产生了一个core dump文件，应该是kill -3信号产生的文件
分析产生的core文件，没有找到完整的信息
联想起以前处理过类似问题，weblogic进程自动退出。不想要操作系统调用正在终止JVM进程。 当某个组件将不正确的关闭信号发送到JVM时会发生此问题。 然后，JVM捕获这些信号，并关闭所有JAVA进程。
当时解决这个问题方法是，将-Xrs参数添加到标准WebLogic启动脚本中的JAVA_OPTIONS启动参数中。
为什么要加-Xrs参数的原因？
参数-Xrs是为了避免JVM对操作系统信号的使用。 这个参数告诉JVM不要为许多事情使用任何操作系统信号，而是依靠加载应用程序（启动器）来处理TERM，INT; HUP和QUIT。如果JVM作为服务运行，它可以接收CTRL_LOGOFF_EVENT，但不应该启动关闭，因为操作系统不会实际终止进程。
回过头来检查domain下的启动环境变量脚本，发现2016-09-07 22:23这个时间点setDomainEnv.sh环境变量脚本有改动过，而且在JAVA_OPTIONS变量后确实加入了参数-Xrs.
经过自己在几个不同版本测试环境下测试，加了这个-Xrs参数确实用kill -3会把服务进程杀死。不加这个-Xrs参数用kill -3不会把进程杀死，也能够收集thread dump信息
3.2、故障原因
将-Xrs参数添加到标准WebLogic启动脚本中的JAVA_OPTIONS启动参数中，如果用kill -3命令去收集thread dump信息，直接会触发操作系统信号杀掉服务进程。
3.3、解决方法
1、由于大家常用习惯用kill
-3命令来收集线程转储信息，导致出现这样的问题。记住以后在生产系统kill尽量不用，不管kill后面带什么信号参数，不建议在生产环境上面执行。
以下是抓取thread
dump常用方法
1）JVM自带的工具获取线程堆栈:
$JAVA_HOME/bin/jstack wls_pid
2）WebLogic自带的获取thread dump的工具:
/bin/setDomainEnv.sh
$JAVA_HOME/bin javaweblogic.Admin -url t3://localhost:9001 -username weblogic -password weblogic1THREAD_DUMP
3）使用utils.ThreadDumper
java -cpC:\bea\wlserver_10.3\server\lib\weblogic.jar utils.ThreadDumper
4）使用weblogic console方法生成
a.登录Admin Console ,点击对应的服务器
b.点击Server à Monitoring àThreads
c.点击: Dump Thread Stack按钮
5）使用WLST工具
java weblogic.WLSTthreaddump.py
欢迎大家关注我的微信公众号，里面有很多相关的技术干货，也能随时联系到我。谢谢！
（完）