在之前的文章《踩坑 Druid 连接池》说踩了坑，后面经人提醒，发现根因是一个等待获取连接的 Job 线程被终止了，通过直接调用线程的 stop 方法终止的，这种方式破坏了 ReentrantLock 锁的模型。
下面这个方法是在持有锁的情况下执行的，执行到 1491 行时，job 线程会把自己加入条件对象的等待队列、然后释放锁，等待其他线程来唤醒；
其他线程调用 notEmpty.signal() 方法时，会把 job 线程从条件对象的等待队列转移到 AQS 的获取队列上，让 job 线程重新获取锁、继续执行。
当上一个持有锁的线程释放锁后，它会唤醒下一个，即执行 662 行。
这周有个应用的一个实例出现了没有响应，庆幸运维那边在重启前做了线程和内存的 dump 。
线程 dump 文件打开一看，竟然4万多行。。后来发现同事用一个可视化工具来分析线程栈，我也把这个工具加入工具箱：IBM Thread and Monitor Dump Analyzer for Java
下图是这个工具的方法栈分析视图：
可以按线程名词、状态、方法栈的深度来进行排序。
下面说说这次踩的坑。
这是一个同事碰到的案例。
SpringBoot 应用卡死、无反应。
1、 导出线程栈，发现 Tomcat 处理线程都阻塞在获取连接上，从栈上看连接池使用的是 druid。
2、 对照 druid 源码，发现线程一直被阻塞是因为没有设置获取连接的超时时间。而从配置来看是有设置的。被阻塞的线程栈如下：
"http-nio-8006-exec-200" #7057 daemon prio=5 os_prio=0 tid=0x00007fc82c0a3800 nid=0x1b99 waiting on condition [0x00007fc7c9a57000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000c2923bd8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at com.alibaba.druid.pool.DruidDataSource.takeLast(DruidDataSource.java:1444)
at com.alibaba.druid.pool.DruidDataSource.getConnectionInternal(DruidDataSource.java:1088)
at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:953)
at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4544)
at com.alibaba.druid.filter.stat.StatFilter.dataSource_getConnection(StatFilter.java:661)
at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4540)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:931)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:923)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:100)
3、 通过内存 dump 发现，druid 连接池除 连接串、用户名、密码等几个属性之外的属性都是默认值。
此时连接池里总共有8个连接，都是空闲的，却没有线程能获取到连接，都在阻塞、没有被唤醒。网上查了下，应该是 druid 的bug。