首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 网站开发 > Web前端 >

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

2013-04-07 
一次web应用没有响应的原因分析前几天,我们应用中遇到一个问题,在发布之后运行很短时间内某些页面就没有响

一次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、性能测试必须得做

热点排行