close wait 导致的java web容器假死

2019独角兽企业重金招聘Python工程师标准>>>

1.现象

线上tomcat或后台task java进程偶发性出现假死，完全没有规律

1.1 java环境

java -version

1.2 linux环境

// 查看操作系统版本信息
cat /proc/version

// 查看操作系统内核信息
uname -a

// 查看系统版本信息的命令
 lsb_release -a

2.分析步骤

2.1 查看进程存活状态

ps -ef | grep java

查询到该进程的ID是12635，监听的端口是10061，后面会用到

2.2 查看该端口的监听情况

// 查看该tomcat服务监听的端口，并将结果输出至日志文件
netstat -an | grep 10061 >> netstat-sku.log

// 查看前200行内容
head -n 200 netstat-sku.log

发现大量close wait，初步可以判断是close wait导致的假死

2.3 查看内存使用情况

// 查看内存使用情况
jmap -heap 12635

Eden Space 内存基本耗费完，但没有触发GC

2.4 查看线程状态

-F to force a thread dump. Use when jstack <pid> does not respond (process is hung) 强制线程转储。当jstack <pid>没有响应时使用(进程挂起)

// 将该进程的所有线程信息打印输出至指定文件
jstack -F 12635 >> jstack-12635.log

发现所有的线程处于BLOCKED状态

2.5 jstack -F后发现该tomcat进程从假死状态恢复到正常状态

3.结论(未完待续)

3.1 初步判断

极其像Linux内核的一个bug, 某个switch分支缺少memory barrier的正确处理，导致外部应用如JVM的lock被错误锁住；一般jstack连后就恢复 链接地址

参考资料

• https://www.infoq.com/news/2015/05/redhat-futex
• https://stackoverflow.com/questions/35165455/suspended-jvm-jstack-f-pid-only-fix

扫描二维码关注“熊英的小屋”，这里永远有一个位置为你开放

转载于:https://my.oschina.net/xiongying0214/blog/3000909