共计 4391 个字符，预计需要花费 11 分钟才能阅读完成。
最艰难的事件就是意识本人！
集体网站，欢送拜访！
前言：
最近，测试部门的共事找到我，说他们测试时，没一会就发现服务接口申请始终无响应，Tomcat 跟死掉了一样，也没有返回任何的谬误响应，说让我连忙排查下；听完后，我霎时激灵了下，妹的，最近老是出问题，领导都要给我开批评大会了。哈哈，开玩笑的，像我这么英俊的人，领导怎么会忍心批评我呢，哼，我把这个问题马上解决掉，都不会让领导晓得的！
简略说下程序部署状况：tomcat + oracle
排查过程：
排查时，能够应用命令进行排查，也能够应用可视化监控工具；例如应用应用 JDK 自带的 jvisualvm.exe 监控工具。
命令排查过程：
1、申请服务无响应，首先看看 tomcat 是否是真的挂掉了：
命令：ps -ef | grep tomcat
通过下面的命令查看 tomcat 运行着；执行后果如下：
留神： 如果此服务器中运行着多个 tomcat，须要查看下图中画框的中央运行的 tomcat 地址是否正确；
通过命令查看发现，tomcat 失常运行着，那么这就是处于假死状态，上面接着排查。
2、查看 http 申请是否达到了 tomcat：
通过查看 tomcat 的 logs 目录下的 localhost_access_log 日志文件中 申请记录；
命令：tail -100f localhost_access_log
通过下面的命令查看实时的日志，执行完下面的查看日志的命令后，而后再次申请下程序，在日志中并没有发现申请记录，阐明 tomcat 处于一种假死状态，上面接着排查。
3、查看 tomcat 的 JVM 的 GC 状况：
查看 GC 状况，是否因为频繁的 GC，长时间的 GC，导致程序呈现长时间的卡顿，最终导致申请来不及解决，进入队列中进行期待，调用方长时间得不到响应，造成 tomcat 假死状态；
命令：jstat -gc pid time count
例如：jstat -gc 71129 1000 5 监控 71129 这个过程 JVM 的 GC 状况，每隔 1000ms 输入一次，共输入 5 次；
命令执行后果参数解析：
通过下面命令查看 GC 状况，发现垃圾回收也不频繁，并且进行 GC 的工夫也不长，应该不是 GC 的起因。
4、查看 tomcat 的 JVM 的堆状况：
查看堆内存的状况，是否存在堆内存溢出 导致 tomcat 假死，无奈为新申请调配堆内存资源；
命令：jmap -heap pid
例子：jmap -heap 71129 71129 是正在运行 tomcat 的过程号；
通过命令执行后果得悉，堆内存中可应用内存还很大，不会呈现内存溢出的问题，所以也不是堆内存过小导致的 tomcat 假死。
5、查看 tomcat 的 JVM 线程状况：
①、应用 jstack 命令导出以后 JVM 的线程 dump 快照，而后看看 dump 中线程都在干什么？
命令：jstack pid >> jvmThreadDump.log
例子：jstack 71129 >> jvmThreadDump.log
生成 71129 过程的 JVM 的线程快照，并将快照内容重定向到 jvmThreadDump.log 文件中；
留神：生成的 jvmThreadDump.log 在你以后执行命令的目录下。
②、接着应用命令 more 查看 jvmThreadDump.log 内容；
命令：more jvmThreadDump.log
如果的 dump 文件太大的话，须要应用 more 命令一点点看；执行完 more 命令的话，再按 enter 回车键 一点点展现文件内容；
③、通过查看线程快照文件，发现很多线程的状态是 WAITING 期待状态；
并且应用命令查看线程状态为 WAITING 的线程占总线程的比例：
留神：tomcatDump.log 为生成的线程快照文件名称，记得改为本人设置的名称；
count=`cat tomcatDump.log | grep java.lang.Thread.State | wc -l`; wait=`cat tomcatDump.log | grep WAITING | wc -l`; a=`echo | awk "{print $wait/$count*100}"`; echo "$a%"执行命令，失去后果：91.9786% ，发现九成多的线程处于期待状态；
至此，找到了 tomcat 假死的起因，然而还需进一步确定 什么起因导致的大量线程始终期待？
通过查看调用的服务接口代码得悉，此接口业务逻辑中本人没设置任何的锁，所以应该不是本人写的代码的问题，然而此接口中波及到了很多 JDBC 数据库操作，那是不是数据库连接池中的连贯不够用了呢？因为数据库连贯属于竞争资源，如果连接池中的连贯曾经耗尽了，那么接下来的进行 JDBC 的线程就须要进行 wait 期待连贯。
6、查看与数据库建设的 TCP 连贯状况：
在下面发现，大量线程处于期待状态，而通过剖析得悉，可能是因为数据库连接池中的连贯耗尽导致的，所以能够通过命令查看下，部署服务代码的服务器与数据库所在服务器建设的 TCP 连接数是否曾经达到了配置的数据库连接池的最大连接数；
命令：netstat -pan | grep 1521 | wc -l
因为本文中应用的数据库是 Oracle，所以 grep 搜寻匹配的端口号是 1521；
如果是 mysql 数据库则将端口号改为 3306 即可，netstat -pan | grep 3306 | wc -l；
如果设置了自定义的数据库端口号，则改为自定义的端口号即可；
通过命令查问到 曾经应用的数据库的连接数为 6 个，那接着看下设置的数据库连接池最大连接数；
数据源配置如下：
<Resource name="jdbc/testdemo"
type="javax.sql.DataSource"
factory="com.alibaba.druid.pool.DruidDataSourceFactory"
url="jdbc:oracle:thin:@192.168.3.125:1521:ora11g"
driverClassName="oracle.jdbc.driver.OracleDriver"
username="root"
password="root"
auth="Container"
initialSize="2"
maxActive="6"
minIdle="3"
maxWait="30000"
timeBetweenEvictionRunsMillis="30000"
minEvictableIdleTimeMillis="600000"
maxEvictableIdleTimeMillis="900000"
poolPreparedStatements="true"
maxOpenPreparedStatements="20"
validationQuery="select 1 from dual"
testOnBorrow="false"
testOnReturn="false"
testWhileIdle="true"
filters="wall,stat,log4j2"
/>通过查看数据源发现，连接池配置的最大连接数是 maxActive=”6″；发现目前程序中应用的连接数已达到最大值，那么前面再进行 JDBC 操作的线程将进入 期待状态，期待获取连贯；
至此，tomcat 假死的排查过程就完结了，并且起因也找到了，就是数据库连接池中的连贯耗尽了；所以，在前面测试中，须要在数据源中将最大连接数设置的大一些，并且也再进一步查看下代码，看看是否存在数据库连贯应用完后没有进行敞开的问题。
除了数据库连接池连贯耗尽会导致 tomcat 假死外，还有一些其它的状况也会导致产生，例如：redis 连接池连贯耗尽，或者是 redis 连贯应用完不开释，最终导致 redis 连贯耗尽。
除了应用下面的命令进行问题排查外，也能够间接应用可视化监控工具进行排查，更加简便、直观。
可视化监控工具排查
应用 JDK 自带的 jvisualvm.exe 工具进行 JMX 近程 可视化监控 tomcat；
jvisualvm.exe 位于 $JAVA_HOME/bin 目录下；
1、应用 JMX 实现近程监控步骤：
上面应用 JMX 实现近程监控的内容参考自：jvisualvm 近程监控 tomcat
①、在 Tomcat 的 bin 目录下的 startup.sh 文件中的 倒数第一行上 加上如下内容：
export CATALINA_OPTS="$CATALINA_OPTS
-Dcom.sun.management.jmxremote
-Djava.rmi.server.hostname=192.168.1.130
-Dcom.sun.management.jmxremote.port=7003
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false"下面内容参数解析：
-Dcom.sun.management.jmxremote 启用 JMX 近程监控
-Djava.rmi.server.hostname=192.168.1.130 这是连贯你的 tomcat 所在的服务器地址
-Dcom.sun.management.jmxremote.port=7003 jmx 连贯端口
-Dcom.sun.management.jmxremote.ssl=false 是否 ssl 加密
-Dcom.sun.management.jmxremote.authenticate=false 近程连贯须要明码认证在 startup.sh 文件中增加上下面的内容后，须要将 tomcat 重启下才会失效；
②、将 jvisualvm.exe 关上，界面如下：
③、在近程上右击，增加主机，输出服务器的 ip：就是在 startup.sh 文件中增加内容中的 hostname
④、在近程主机上右击，增加 JMX 连贯，手动在 ip 地址前面加上设置的 jmx 连贯端口 7003，而后点击确定即可：
⑤、通过下面的步骤，就曾经实现了近程监控连贯了，而后本人双击就能进行监控界面了：
2、查看监督内容：
通过查看监督画面得悉，CPU、GC、堆 Heap 的状况都没有问题，那接着查看下线程的状况：
点击下面图片中的 线程 Dump 按钮，生成线程的快照，快照文件内容局部如下：
通过查看快照文件内容发现，很多线程的状态的都是 WAITING 期待状态；
接下来的剖析排查过程就如下面的 命令排查过程 一样了。
总结：
下面的两种排查形式，自己比拟举荐还是应用第一种 命令排查，因为很多的状况是不会让你批改配置文件进行近程监控的，即使应用监控工具看起来更加直观、简便；所以，平时须要记一些罕用的排查命令，以备不时之需。
因为自己程度无限，如有问题，敬请提出；
❤不要遗记留下你学习的脚印 [点赞 + 珍藏 + 评论]嘿嘿ヾ
所有看文章不点赞都是“耍流氓”，嘿嘿ヾ (◍°∇°◍)ﾉﾞ！开个玩笑，动一动你的小手，点赞就完事了，你每个人出一份力量(点赞 + 评论) 就会让更多的学习者退出进来！非常感谢！~ω~=
