循环打印java.util.ConcurrentModificationException

 java.util.ConcurrentModificationException

的原因：

 

的原因：

 

 

报错位置是

是

         at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)

         at java.util.HashMap$KeyIterator.next(HashMap.java:828)

         at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314)

         at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382)

         at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324)

         at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298)

         at org.hibernate.ejb.EntityManagerImpl.close(EntityManagerImpl.java:86)

 

 

查回源码（hibernate3.2.4 sp1）

 

        

 

	/**
	 * Actually releases the batcher, allowing it to cleanup internally held
	 * resources.
	 */
	public void closeStatements() {
		try {
			releasing = true;

			try {
				if (batchUpdate!=null) batchUpdate.close();
			}
			catch (SQLException sqle) {
				//no big deal
				log.warn("Could not close a JDBC prepared statement", sqle);
			}
			batchUpdate=null;
			batchUpdateSQL=null;

			Iterator iter = resultSetsToClose.iterator();
			while ( iter.hasNext() ) {
				try {
					logCloseResults();
					( (ResultSet) iter.next() ).close();
				}
				catch (SQLException e) {
					// no big deal
					log.warn("Could not close a JDBC result set", e);
				}
				catch (Throwable e) {
					// sybase driver (jConnect) throwing NPE here in certain cases
					log.warn("Could not close a JDBC result set", e);
				}
			}
			resultSetsToClose.clear();

			iter = statementsToClose.iterator();
			while ( iter.hasNext() ) {
				try {
					closeQueryStatement( (PreparedStatement) iter.next() );
				}
				catch (SQLException e) {
					// no big deal
					log.warn("Could not close a JDBC statement", e);
				}
			}
			statementsToClose.clear();
		}
		finally {
			releasing = false;
		}
	}

 

 

 

 

 

 

 

 

查回源码（hibernate3.2.7 ga）

 

 

	/**
	 * Actually releases the batcher, allowing it to cleanup internally held
	 * resources.
	 */
	public void closeStatements() {
		try {
			releasing = true;

			try {
				if ( batchUpdate != null ) {
					batchUpdate.close();
				}
			}
			catch ( SQLException sqle ) {
				//no big deal
				log.warn( "Could not close a JDBC prepared statement", sqle );
			}
			batchUpdate = null;
			batchUpdateSQL = null;

			Iterator iter = resultSetsToClose.iterator();
			while ( iter.hasNext() ) {
				try {
					logCloseResults();
					( ( ResultSet ) iter.next() ).close();
				}
				catch ( SQLException e ) {
					// no big deal
					log.warn( "Could not close a JDBC result set", e );
				}
				catch ( ConcurrentModificationException e ) {
					// this has been shown to happen occasionally in rare cases
					// when using a transaction manager + transaction-timeout
					// where the timeout calls back through Hibernate's
					// registered transaction synchronization on a separate
					// "reaping" thread.  In cases where that reaping thread
					// executes through this block at the same time the main
					// application thread does we can get into situations where
					// these CMEs occur.  And though it is not "allowed" per-se,
					// the end result without handling it specifically is infinite
					// looping.  So here, we simply break the loop
					log.info( "encountered CME attempting to release batcher; assuming cause is tx-timeout scenario and ignoring" );
					break;
				}
				catch ( Throwable e ) {
					// sybase driver (jConnect) throwing NPE here in certain
					// cases, but we'll just handle the general "unexpected" case
					log.warn( "Could not close a JDBC result set", e );
				}
			}
			resultSetsToClose.clear();

			iter = statementsToClose.iterator();
			while ( iter.hasNext() ) {
				try {
					closeQueryStatement( ( PreparedStatement ) iter.next() );
				}
				catch ( ConcurrentModificationException e ) {
					// see explanation above...
					log.info( "encountered CME attempting to release batcher; assuming cause is tx-timeout scenario and ignoring" );
					break;
				}
				catch ( SQLException e ) {
					// no big deal
					log.warn( "Could not close a JDBC statement", e );
				}
			}
			statementsToClose.clear();
		}
		finally {
			releasing = false;
		}
	}

 

 

 

 

两个版本中的closeStatements方法不同，3.2.7中加了对ConcurrentModificationException的处理，当遇到这个异常时，就break，这样就不会再循环打印这个错误了。

 

查了一下jboss下的hibernate3.jar，这个包使用的是3.2.4版本的，如果修改这个错误，升级一下hibernate的版本即可。

另一个问题，商用上有两台内容服务器，部署的包一样，而环境也是一样（没认真检查），两台机都有打包电子书的操作，为什么一台机会循环打印日志，而另一台则不会呢？

认真看看hibernate3.2.7中加了对ConcurrentModificationException处理的注释：

大概意思是：这只会在很小概率下发生的，当用上事务管理和事务超时时，事务超时会通过hibernate已注册事务同步的一个单独线程进行回调，这时候这个单独的线程通过这段时间再执行任务，而同时应用的主线程也在执行，这样我们就会陷入一种像日冕物质抛射的状况，尽管这个本身就是不允许的，如果我们不采取措施处理这个问题，最终结果就是一个无止境的循环。。。

 

 

这里提及到事务超时，这里想起了内容1和内容2两台服务器，一台的日志暴涨，一台却不会，后台查一下是jboss的事务超时时间不同，内容1的是好几个小时，而内容2的是5分钟，应该跟这个有关系了。

 

 

解决方法：更换hibernate的版本和修改jboss的事务超时时间。