MyBatis的設計思想很簡單,可以看做是對JDBC的一次封裝,并提供強大的動態SQL映射功能。但是由于它本身也有一些緩存、事務管理等功能,所以實際使用中還是會碰到一些問題——另外,最近接觸了JFinal,其思想和Hibernate類似,但要更簡潔,和MyBatis的設計思想不同,但有一點相同:都是想通過簡潔的設計最大限度地簡化開發和提升性能——說到性能,前段時間碰到兩個問題:
- 在一個上層方法(DAO方法的上層)內刪除一條記錄,然后再插入一條相同主鍵的記錄時,會報主鍵沖突的錯誤。
- 某些項目中的DAO方法平均執行時間會是其他一些項目中的** 2倍 **。
第一個問題是偶爾會出現,在實驗環境無論如何也重現不了,經過分析MyBatis的邏輯,估計是兩個DAO分別拿到了兩個不同的Connection,第二個語句比第一個更早的被提交,導致了主鍵沖突,有待進一步的分析和驗證。對于第二個問題,本文將嘗試通過分析源代碼和實驗找到它的root cause,主要涉及到以下內容:
- 問題描述與分析
- MyBatis在Spring環境下的載入過程
- MyBatis在Spring環境下事務的管理
- 實驗驗證
項目環境
整個系統是微服務架構,這里討論的「項目」是指一個單獨的服務。單個項目的框架基本是Spring+MyBatis,具體版本如下:
Spring 3.2.9/4.3.5 + Mybatis 3.2.6 + mybatis-spring 1.2.2 + mysql connector 5.1.20 + commons-dbcp 1.4
與MyBatis和事務相關的配置如下:
//代碼1
<!-- bean#1-->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<!-- 一些數據庫信息配置-->
<!-- 一些DBCP連接池配置 -->
//在這里設置是否自動提交
<property name="defaultAutoCommit" value="${dbcp.defaultAutoCommit}" />
</bean>
<!-- bean#2-->
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="mapperLocations" value="classpath*:path/to/mapper/**/*.xml" />
</bean>
<!-- bean#3 -->
<bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
<!-- bean#4-->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value=".path.to.mapper" />
<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
</bean>
<!-- bean5 -->
<tx:annotation-driven transaction-manager="transactionManager" />
問題描述與分析
一倍的時間差挺嚴重的,平均到每次調用,正常的大約在6到10幾ms
,慢的要近20ms
,由于調用次數很多,導致整體性能會有很大的差別。經過仔細比對這幾個項目,發現DAO執行慢的項目的數據源配置(bean#1)中defaultAutoCommit
的配置都是false
。而且將此配置改為true
之后就恢復了正常。
由此推斷是在MyBatis在執行「非自動提交」語句時,進行等待,或者多提交了一次,導致實際調用數據庫API次數增多。但是這個推斷也有個問題,由于整個項目是在Spring環境中運行的,而且也開啟了Spring的事務管理,所以還是需要詳細的看一下MyBatis到底是如何裝配DAO方法與管理事務的,才能徹底解開謎團。
問題重現
首先寫一個Service,其中調用了同一個mapper類的兩個方法分別2次,insertModelList()
會在數據庫中插入兩條記錄,delModels()
方法會刪除這兩條記錄,代碼如下:
//代碼2
//@Transactional
public void testIS(){
List<Model> models= new ArrayList<>();
//省略一些數據工作。。。
modelMapper.insertModelList(50001l, models);
modelMapper.delModels(50001);
if (CollectionUtils.isNotEmpty(models))
modelMapper.insertModelList(50001, models);
modelMapper.delModels(50001);
}
public void testOther(){
System.out.println("加載類:");
System.out.println(modelMapper.getClass().getClassLoader());
modelMapper.delModels(50001);
}
實際項目中使用cat來進行執行時間的統計,這里也仿照cat,使用一個單獨的AOP類實現時間的計算:
//代碼3
public class DaoTimeAdvice {
private long time = 0;
private long num = 0;
public Object calcTime(ProceedingJoinPoint joinPoint) throws Throwable {
long then = System.nanoTime();
Object object = joinPoint.proceed();
long now = System.nanoTime();
setTime(getTime() + (now-then));
setNum(getNum() + 1);
return object;
}
//省略getter & setter。。。
public void printInfo() {
System.out.println("總共次數:" + num);
System.out.println("總共時間:" + time);
System.out.println("平均時間:" + time / num);
}
}
測試代碼:
//代碼4
public static void test(){
System.out.println(new SimpleDateFormat("[yyyy-MM-dd HH:mm:ss]").format(new Date())
+ " 開始測試!");
for (int i = 0; i < TEST_NUM; i++) {
ItemStrategyServiceTest ist = (ItemStrategyServiceTest) context.getBean("isTS");
ist.testIS();
if (i % 1000 == 0) {
System.out.println("1000次");
}
}
DaoTimeAdvice ad = (DaoTimeAdvice) context.getBean("daoTimeAdvice");
ad.printInfo();
ItemStrategyServiceTest ist = (ItemStrategyServiceTest) context.getBean("isTS");
ist.testOther();
System.exit(1);
}
測試結果:
defaultAutoCommit |
循環次數 | 共消耗時間(ns) | 平均時間(ns) |
---|---|---|---|
true | 40000 | 17831088316 | 445777 |
true | 40000 | 17881589992 | 447039 |
false | 40000 | 27280458229 | 682011 |
false | 40000 | 27237413893 | 680935 |
defaultAutoCommit為false
時的執行時間是true
的近1.5倍,并沒有重現2倍的時間消耗,估計是在cat統計或者其他AOP方法的執行時還有其他消耗,從而擴大了false
和true
之間的區別。
MyBatis在Spring環境下的載入過程
按照第一節中的配置文件,整個MyBatis中DAO的bean的裝配應該是這樣的:
- 先使用BasicDataSource裝配一個數據源的bean(bean#1),名字叫做
dataSource
。
這個bean很簡單,就是實例化并注冊到Spring的上下文中。
- 使用
dataSource
來創建sqlSessionFactory
(bean#2),這個bean創建時會掃描MyBatis的語句映射文件并解析。
在MyBatis中,真正的數據庫讀寫操作是通過SqlSession的實例來實現的,而SqlSession要通過SQLSessionFactory來管理。這里的org.mybatis.spring.SqlSessionFactoryBean
實現了FactoryBean類(這個類比較特殊,與主題無關,這里不再贅述),Spring會從這個bean中會獲取真正的SQLSessionFactory的實例,源代碼中顯示,實際返回的對象是DefaultSqlSessionFactory的實例。
- 使用
sqlSessionFactory
這個工廠類來創建mapper掃描器(bean#4),并創建含有DAO方法的實例。
為了讓上層方法可以通過普通的方法調用來使用DAO方法,需要往Spring上下文里注冊相應的bean,而在MyBatis的普通使用場景中是沒有mapper的實現類的(具體的SQL語句映射通過注解或者XML文件來實現),只有接口,在MyBatis中這些接口是通過動態代理實現的。這里使用的類是org.mybatis.spring.mapper.MapperScannerConfigurer
,它實現了org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor
接口,所以會在Spring中「所有的bean定義全部注冊完成,但還沒有實例化」之前,調用方法向Spring上下文注冊mapper實現類(動態代理的對象)。具體代碼如下:
//代碼5
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
if (this.processPropertyPlaceHolders) {
processPropertyPlaceHolders();
}
ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
//設置一些屬性
scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
}
/**
* Perform a scan within the specified base packages.
* @param basePackages the packages to check for annotated classes
* @return number of beans registered
*/
public int scan(String... basePackages) {
int beanCountAtScanStart = this.registry.getBeanDefinitionCount();
doScan(basePackages);
// Register annotation config processors, if necessary.
if (this.includeAnnotationConfig) {
AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
}
return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart);
}
在源代碼里可以看到,真正的mapper實現類是org.mybatis.spring.mapper.MapperFactoryBean<Object>
,具體的邏輯在方法org.mybatis.spring.mapper.ClassPathMapperScanner.processBeanDefinitions(Set<BeanDefinitionHolder>)
里。最后,每一個方法的執行,最終落入了org.mybatis.spring.SqlSessionTemplate
的某個方法中,并被如下這個攔截器攔截:
//代碼6
/**
* Proxy needed to route MyBatis method calls to the proper SqlSession got
* from Spring's Transaction Manager
* It also unwraps exceptions thrown by {@code Method#invoke(Object, Object...)} to
* pass a {@code PersistenceException} to the {@code PersistenceExceptionTranslator}.
*/
private class SqlSessionInterceptor implements InvocationHandler {
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
SqlSession sqlSession = getSqlSession(
SqlSessionTemplate.this.sqlSessionFactory,
SqlSessionTemplate.this.executorType,
SqlSessionTemplate.this.exceptionTranslator);
try {
Object result = method.invoke(sqlSession, args);
if (!isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) {
// force commit even on non-dirty sessions because some databases require
// a commit/rollback before calling close()
sqlSession.commit(true);
}
return result;
} catch (Throwable t) {
//省略一些錯誤處理
throw unwrapped;
} finally {
if (sqlSession != null) {
closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
}
}
}
}
- MyBatis在Spring環境下事務的管理
從源代碼中知道真正的SqlSessionFactory使用的是org.apache.ibatis.session.defaults.DefaultSqlSessionFactory
的實例,同時,事務管理使用org.mybatis.spring.transaction.SpringManagedTransactionFactory
。但是在代碼1的配置中,還添加了Spring事務管理的配置,就是在某個Service方法(或某個其他可被掃描到的方法)上加上@Transactional
注解,那么Spring的事務管理會自動創建事務,那么它和MyBatis的事務之間是怎么協作的呢?
可以看到在代碼6中的方法isSqlSessionTransactional()
,它會返回上層代碼中是否有Spring的事務,如果有,將不會執行下邊的commit()
。在我的項目中的實際情況是沒有Spring事務,所以肯定是走到了下面的commit()
,這個方法最終落到了SpringManagedTransactionFactory
中的commit()
,看代碼:
//代碼7
private void openConnection() throws SQLException {
this.connection = DataSourceUtils.getConnection(this.dataSource);
this.autoCommit = this.connection.getAutoCommit();
this.isConnectionTransactional = DataSourceUtils.isConnectionTransactional(this.connection, this.dataSource);
}
public void commit() throws SQLException {
if (this.connection != null && !this.isConnectionTransactional && !this.autoCommit) {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Committing JDBC Connection [" + this.connection + "]");
}
this.connection.commit();
}
}
可以看到,此處是否要執行commit()
操作是由3個變量決定的,如果DataSource的autoCommit
是false
,則其結果一定為true
,控制臺也會看到一行日志:Committing JDBC Connection [xxxxxx]
,剛好與項目中遇到的情況相同。這個提交動作是需要和數據庫交互的,比較耗時。
實驗驗證
由上一節分析得出,造成DAO方法執行時間變長的原因是會多執行一次提交,那么如果上層方法被Spring事務管理器托管(或者數據源的defaultAutoCommit
為true
,這個條件已經在剛開始的問題重現被驗證),則不會執行MyBatis的提交動作,DAO方法應該相應的執行時間會變短。于是將Service方法加上@transactional
注解,分別測試true
和false
的情況。結果:
defaultCommit | 循環次數 | 共消耗時間 | 平均時間 |
---|---|---|---|
true | 40000 | 7017113852 | 175427 |
false | 40000 | 7283591630 | 182089 |
可以看到執行的時間已經基本接近,由此基本可以確定是這個原因造成的。這里仍然有幾個疑點,尤其是問題重現時沒有出現2倍的時間消耗,如果你有別的想法,也歡迎提出來討論。