相信大家在使用SpringBoot的过程中，经常会使用到mybatis，通过使用mybatis-spring-boot-starter依赖进行自动配置，省去了自己依赖配置和Bean配置的很多麻烦。
有这么方便的starter，使大家不禁好奇，它究竟是怎么让我们能够不要任何配置就可以使用mybatis的，背后的原理究竟是什么？
本文将以mybatis-spring-boot-starter作为例子，探究它背后的秘密。
首先我们建立一个SpringBoot工程，并且添加mybatis-spring-boot-starter依赖（在此我们假设读者已经熟悉SpringBoot基本知识和操作）：
如果我们此时启动程序，Mybatis会随程序自动启动。
starter减少了我们依赖配置和代码中对象关系映射配置，我们分成两部分分析：
第一步我们分析starter的依赖，从pom文件检查工程的依赖：
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-autoconfigure</artifactId>
</dependency>
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
</dependency>
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis-spring</artifactId>
</dependency>
</dependencies>
可以看到，starter将需要的依赖全部引入，免去了我们配置的麻烦。
综上所述，spring的starter免去了我们配置的麻烦，是个很好用的系统，全文完，谢谢观看。
哈哈哈，如果文章写到这里就结束，大家肯定要打我了（读者内心：你写的这什么东西）
光靠引入依赖包并不足以说明为什么这些组件就能自动被装载，并且已经配置好了，所以我们分析下这些被引用的依赖，找到其中起作用的包。
首先mybatis，mybatis-spring都可以被忽略掉，这些就是正常的mybatis组件。
那可疑的就是这个mybatis-spring-boot-autoconfigure了。
直接打开这个jar包看里面的内容：
可疑的就是这个MybatisAutoConfiguration和spring.factories文件，其中spring.factories的内容：
# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.mybatis.spring.boot.autoconfigure.MybatisLanguageDriverAutoConfiguration,\
org.mybatis.spring.boot.autoconfigure.MybatisAutoConfiguration
首先百度一下spring.factories，这个是Spring的SPI机制，这个文件的内容也已经说的很明显了，自动配置，连注释都给带上了，哈哈。
代码通过SPI机制加载了两个类，其中最重要的是：
org.mybatis.spring.boot.autoconfigure.MybatisAutoConfiguration
我们打开这个类，查看其中代码：
@org.springframework.context.annotation.Configuration
@ConditionalOnClass({ SqlSessionFactory.class, SqlSessionFactoryBean.class })
@ConditionalOnSingleCandidate(DataSource.class)
@EnableConfigurationProperties(MybatisProperties.class)
@AutoConfigureAfter({ DataSourceAutoConfiguration.class, MybatisLanguageDriverAutoConfiguration.class })
public class MybatisAutoConfiguration implements InitializingBean { //......
可以看到，这是一个Spring配置类（因为有Configuration注解）
这个类需要在classpath中有SqlSessionFactory和SqlSessionFactoryBean定义时才会起效，并且要有一个DataSource的candidate注册到spring容器中
当这些条件都满足时，这个Configuration会注册一个SqlSessionFactorySqlSessionTemplate ：
@Bean
@ConditionalOnMissingBean
public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception { ...... @Bean
@ConditionalOnMissingBean
public SqlSessionTemplate sqlSessionTemplate(SqlSessionFactory sqlSessionFactory) { ......
而MyBatis整个数据库访问，都是围绕这两个对象展开的。
至此已经解开Mybatis自动配置的第一个问题了，还有第二个：我们定义的那些Dao是如何被扫描的？
请继续在这个类中往下看，类中间包裹了一个static subclass：
/**
* This will just scan the same base package as Spring Boot does. If you want more power, you can explicitly use
* {@link org.mybatis.spring.annotation.MapperScan} but this will get typed mappers working correctly, out-of-the-box,
* similar to using Spring Data JPA repositories.
*/
public static class AutoConfiguredMapperScannerRegistrar implements BeanFactoryAware, ImportBeanDefinitionRegistrar { private BeanFactory beanFactory; @Override
public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) { //......
registry.registerBeanDefinition(MapperScannerConfigurer.class.getName(), builder.getBeanDefinition());
}
这个类实现了ImportBeanDefinitionRegistrar，也就是会向Spring容器中注入一个bean定义，而这个bean定义就是MapperScannerConfigurer。
我们继续看MapperScannerConfigurer：
public class MapperScannerConfigurer
implements BeanDefinitionRegistryPostProcessor, InitializingBean, ApplicationContextAware, BeanNameAware {
//......
标红的部分已经很能说明问题了：这个类是BeanDefinitionRegistry的后处理器，可能会修改Spring容器中的BeanDefinition，果然，在下面我们就能找到对应的方法：
/**
* {@inheritDoc}
*
* @since 1.0.2
*/
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
if (this.processPropertyPlaceHolders) {
processPropertyPlaceHolders();
} ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);
scanner.setAddToConfig(this.addToConfig);
scanner.setAnnotationClass(this.annotationClass);
scanner.setMarkerInterface(this.markerInterface);
scanner.setSqlSessionFactory(this.sqlSessionFactory);
scanner.setSqlSessionTemplate(this.sqlSessionTemplate);
scanner.setSqlSessionFactoryBeanName(this.sqlSessionFactoryBeanName);
scanner.setSqlSessionTemplateBeanName(this.sqlSessionTemplateBeanName);
scanner.setResourceLoader(this.applicationContext);
scanner.setBeanNameGenerator(this.nameGenerator);
scanner.setMapperFactoryBeanClass(this.mapperFactoryBeanClass);
if (StringUtils.hasText(lazyInitialization)) {
scanner.setLazyInitialization(Boolean.valueOf(lazyInitialization));
}
scanner.registerFilters();
scanner.scan(
StringUtils.tokenizeToStringArray(this.basePackage, ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS));
}
其中最重要的部分就是这个标红的scan，我们跟进去看下（其实不跟进去大家应该也看出所以然来了，这里有个basePackage，是不是很熟悉？）：
/**
* Perform a scan within the specified base packages,
* returning the registered bean definitions.
* <p>This method does <i>not</i> register an annotation config processor
* but rather leaves this up to the caller.
* @param basePackages the packages to check for annotated classes
* @return set of beans registered if any for tooling registration purposes (never {@code null})
*/
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<>();
for (String basePackage : basePackages) {
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
if (candidate instanceof AbstractBeanDefinition) {
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
if (candidate instanceof AnnotatedBeanDefinition) {
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
if (checkCandidate(beanName, candidate)) {
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
definitionHolder =
AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
beanDefinitions.add(definitionHolder);
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
这里就是从basePackages中扫描到所有合适的类（准确的说应该是接口），并且将这些类（接口）生成对应的BeanDefinition，这是为了让Spring在实例化你定义的Dao时，能够成功，如果没有这一步，启动肯定会报“Cannot find candidate for autowired property xxx”这类错误，因为你在工程里面声明的本来就是个接口嘛。
并且请注意到最后面标红的applyScopedProxyMode，这会为你的Dao生成代理，这也是为何你调试代码时，调用到Dao时你把鼠标放上去，显示的Dao类型是一个MapperProxy<T>。
至此，Mybatis自动加载的原理基本上可以总结如下：
1. mybatis-spring-boot-starter将mybatis需要的依赖全部引入
2. starter同时通过SPI机制引入了一个配置Class：MybatisAutoConfiguration，它负责注册SqlSessionFactory和SqlSessionTemplate到Spring容器中，我们使用Mybatis时绝大部分功能靠这两个Bean实现
3. 引入了AutoConfiguredMapperScannerRegistrar这个bean到Spring容器，它负责将MapperScanner引入Spring容器，然后MapperScanner会将工程中所有的Dao扫描出来转换为BeanDefinition并且注册到Spring容器中
4. 当开发的工程中使用了某个Dao时，Spring能够从容器中找到这个Dao对应的BeanDefinition，将其实例化并且注入，这样开发者就可以使用了，这也是为何我们只定义了Dao的接口，但是工程运行时能够有实例Bean的原因