common pool 数据库连接池泄露排查

        一次服务上线没多久，页面处于刷新状态，系统发生假死，查看后台日志，并未发现任何的异常信息，在请求接口处增加debug日志后发现，程序在执行到数据库查询相关的地方卡死了。

        怀疑是数据库连接的问题，但是使用Navicat连接数据库正常。通过jstack导出线程快照发现，

jstack <pid> >> jstack.log

 大量处于WAITTING状态的线程，而这些线程都是在调用borrowObject方法，这个是apache common pool 从连接池中获取连接的方法，使用完毕调用returnObject(),将连接归还到连接池。

//所有的可用连接 
private final Map<IdentityWrapper<T>, PooledObject<T>> allObjects = new ConcurrentHashMap<>(); 
 
//空闲的可用连接 
private final LinkedBlockingDeque<PooledObject<T>> idleObjects; 
 
//获取可用连接 
T borrowObject() throws Exception, NoSuchElementException, 
            IllegalStateException; 
 
//资源释放（将连接放回连接池） 
void returnObject(T obj) throws Exception; 

排查思路：

1.  怀疑存在数据库连接泄漏，可能是项目代码使用完连接没有关闭。就是每次开启一个数据库连接后都需要手动关闭连接， con.close()，如果不 close 掉的话，这个连接将会一直被占用，直到连接池中的连接耗尽为止。 经排查项目代码并未发现连接未关闭。
2. 仔细查看线程调用信息发现，获取数据库连接是由事务拦截器发起的， 

	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)

 查看对应的项目代码发现有个@Transactional注解，这个是spring提供的事务注解，每次执行方法时就会获取一个连接。可是此时，程序并没有和数据库相关的操作，这是个纯rest请求的类，而业务系统会定时去调用这个接口，  如果此时代码在请求rest接口的时候发生阻塞，就会导致，事务无法提交，连接也会一直被该请求占用。而再大的连接池也会被耗费殆尽。从而造成系统崩溃。

总结：正确使用@Transactional事务注解，如果方法没有涉及到数据库层面的操作，则无需开启事务，只有在需要保证数据一致性的场景才需要开启事务。这样也能减少数据库连接的压力。