问题
- 应用使用dbcp数据库连接池维护与oracle数据库的连接。偶尔会出现拿不到数据库连接的情况。
- IPv6造成死锁问题
结论
- dbcp配置最好研究一下官方文档
- 当服务器开启ipv6后，在特殊情况下，会影响性能，造成死锁。
IBM IPV6 Can Cause Poor Java Performance
ipv6造成的死锁问题
java.net.preferIPv4Stack设置
JVM源码系列: java InetAddress.getLocalHost() 在linux里实现
浅谈getaddrinfo函数的超时处理机制
- 解决办法
- JVM启动添加-Djava.net.preferIPv4Stack=true，禁用IPv6。
- 保持 hostname 、 /etc/sysconfig/network:HOMENAME 和 /etc/hosts 对机器名设置的一致性
-----------------------------------------以下正文 -----------------------------------------
0. 背景
公司有条很老的业务线，这个业务线有一个很老的管理系统。该系统虽说老当益壮，但是最近不知怎么的，大错不犯小错不断，招致不同部门的投诉轰炸。
系统异常的表现很有意思，访问页面都很正常，只要一使用登录功能就抛nginx的错误页面。偶尔出现这种情况，年轻的技术人员就会快速的重启项目，又可以正常使用了。
没有一次重启解决不了的问题，如果有，那就再重启一次。
但是不巧的是，最近不同业务线的问题集中爆发，到了必须清算过往的时候了。。。
1. 收集证据
通过简单的“走访”得知，以往系统偶尔会报拿不到数据库连接的错误。结合过往日志和异常表现，判断很可能数据库连接池就是罪魁祸首。（我们数据库用oracle，连接池用dbcp。对，就是大家几乎一致认为性能不咋地的dbcp）
我们又仔细研究了官方的说明，严谨的配置了相关参数，更新上线。
2. 从头再来
第二天是周六，早上正在吃饭的时候，业务群又爆了，系统又报错了！！！！！！！！
饭是吃不成了。安抚完业务方后，赶紧把现场保存了下来。
2.1 保存现场
# 查看项目进程ID: 126904
ps aux | grep your-app
2.1.1 查看数据库连接情况
# oracle端口为1521
lsof -p 126904 -nP | grep TCP | grep 1521
结果项目进程没有到oracle的tcp连接。
2.1.2 JVM dump
# dump文件
jmap -dump:format=b,file=heap.dump 126904
# 查看堆内存情况
jmap -heap 126904 > heap.txt
2.1.3 Thread dump
# 线程运行情况
jstack 126904 > thread.txt
2.1.4 分析工具
IBM HeapAnalyzer 分析dump文件
官网地址，不太直观。
IBM Thread and Monitor Dump Analyzer for Java (TMDA) 分析线程
官网地址，也不太直观。
jhat分析dump文件 <推荐>
# 启动分析
jhat heap.dump
加载完成后，访问127.0.0.1:7000即可。
fastthread.io 在线分析线程 <推荐>
官网地址，上传thread文件或者把thread信息粘贴进去，就可以自动分析。
优点是：非常直观。
2.1.5 排查过程
先做线程分析
将thread信息上传到fastthread.io，查看异常情况如下：
上图可以发现，有两个线程block了，有戏！
查看其中的69号和63号线程，发现是在等待<0x000000074d4c8208>对象，有戏！！！
此处，线程正在创建数据库连接，说明dbcp连接池配置没有问题
查看线程关系，原来是67号线程持有<0x000000074d4c8208>对象，导致创建数据库连接的线程阻塞了。
上图说明，67号线程在空跑CPU，所以63和69号线程一直拿不到对象锁，创建不了数据库连接，由于连接池配置获取连接超时时间为10s，所以前端页面就会报错了。
说明，这个线程会一直运行超过10s！！！！！
定位问题代码
ibatis 2.x
2.1.6 刨根问底
dbcp连接池的嫌疑排除了，现在的问题更加棘手了。只能求助bing（墙内）。
经过曲折的过程，最终定位到IPv6的问题，通过设置jvm参数，禁用了IPv6之后，异常再没有出现过。
