一次web应用没有响应的原因分析

前几天，我们应用中遇到一个问题，在发布之后运行很短时间内某些页面就没有响应了。

开始没太当回事，因为环境的原因，从数据库查询数据缓慢是有可能的。但后来发现数据库空闲的时候仍然这样。

1、首先，分析可能的原因是页面的组件没获取到导致数据没有展示，因为组件是从另一台server获取的，早先出现过这样的情况。随后查看firebug，网络通信一切正常，前台组件也没有报错。

2、其次，有可能是JVM的垃圾回收一直在进行。因为程序中有部分模块定时从数据库查询数据。所以使用visualvm查看，如下图所示，jvm的perm和堆都正常，线程也正常。

3、再次，从visualvm中将线程日志dump出来，发现七八处这样的。是业务逻辑对应的代码正在执行过程中，一看堆栈，怀疑应该是连接池中连接耗光了，获取新的连接去了。而且阻塞在获取连接上了。

"http-8086-9" - Thread t@233
   java.lang.Thread.State: WAITING
     at java.lang.Object.wait(Native Method)
     - waiting on <3c74e871> (a com.mchange.v2.resourcepool.BasicResourcePool)
     at com.mchange.v2.resourcepool.BasicResourcePool.awaitAcquire(BasicResourcePool.java:966)
     at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:208)
     at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:232)
     at com.mchange.v2.c3p0.PoolBackedDataSource.getConnection(PoolBackedDataSource.java:94)
     at com.mchange.v2.c3p0.ComboPooledDataSource.getConnection(ComboPooledDataSource.java:521)
     at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:81)
     at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
     at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
     at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:160)
     at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:81)
     at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1473)
     at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:555)
     at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371)
     at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:334)
     at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
     at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)

首先看了c3p0的源码，发现确实是在获取新的数据库连接。遂建议同事将c3p0的日志放开。

但同事怀疑我定期从数据库查询数据然后写入缓存的ReadWriteLock控制有问题。对这块我相对有信心，因为本身就是最经典的读写锁控制，而且从线程堆栈看，并没有发生线程死锁。

最后要求同事将c3p0的日志放开，最后发现部分操作导致c3p0管理的连接数量不断上涨。

原来是有数据库连接没有被正常释放！

程序重度依赖spring，事务使用spring管理的，dao层大量使用hibernateTemplate进行简单的查询操作，部分复杂的场景使用了jdbcTemplate，按道理这些部分都不会出现问题，普通的操作在结束之后都被spring接管了，事务该提交或回滚，连接也被释放（因为使用连接池，所以不是关闭）。

唯一的可能就是，有人自己获取了连接或者新建了会话，通过搜索，发现果然有一处代码是这样的，

先从hibernateTemplate获取到sessionFactory，然后openSession，执行一个复杂的原生sql查询，然后方法就结束了。

这肯定是有问题的，session没有关闭，数据库连接也就没有释放。

然后将此处改为使用jdbcTemplate执行查询，提交发布，连接数量稳定了，搞定。

总结：

1、hibernate进行复杂的查询很不方便，无论是HQL还是Criteria；

2、使用spring时，可考虑使用jdbcTemplate代替hibernate执行原生sql操作，优点是：方便，清晰、不用考虑session；

3、编码规范很重要；

4、性能测试必须得做





大小: 71.6 KB





大小: 36.2 KB

查看图片附件