300字范文,内容丰富有趣,生活中的好帮手!
300字范文 > common pool 数据库连接池泄露排查

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

时间:2019-11-09 12:00:30

相关推荐

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;

排查思路:

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

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

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

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

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。