註解驅動和註解配置有什麼區別

『壹』 spring里註解驅動是必須要配的嗎

spring里註解驅動是必須要配的。根據公開資料顯示得知Spring或Springmvc框架中要使用註解，需要配置註解驅動。

『貳』 springmvc配置問題，applicationContext中如果不寫註解驅動會怎麼樣，好像沒寫也能運行項目

springmvc聲明式開發，分為xml和註解開發。因此，即使沒有使用註解，使用的是xml也是能正常運行項目的。

如果滿意，望採納，謝謝！

『叄』 springBoot @RequestBody 寫在方法上與寫在參數上的區別

1. @Controller控制層組件，定義一個springMVC的控制器類，往往需要和@RequestMapping配合使用。2. @RestController相當於@ResponseBody+@Controller合在一起的作用。3. @Service服務層組件，用於標注業務層組件，表示定義一個bean，自動根據bean的類名實例化一個首寫字母為小寫的bean，也可以指定bean的名稱：@Service(「beanName」)。4. @Repository持久層組件，用於標注數據訪問組件，即DAO組件。5. @Component把普通pojo實例化到spring容器中，相當於配置文件中的 <bean id="" class=""/>。6. @RequestMapping用於配置控制層的訪問URL，可以用在控制器類上和控制器方法上，如果用在控制器類上，則訪問類中的方法是要加上類上的路徑，例如：@Controller@RequestMapping("/personal/linkInfo")public class LinkInfoController {@RequestMapping(value = "/addLinkInfo")public String addLinkInfo(LinkInfoReq linkInfoReq) {linkInfoService.addLinkInfo(linkInfoReq);return "redirect:/personal/linkInfo/toLinkInfo";}}上述代碼的訪問路徑就是XXX/personal/linkInfo/addLinkInfo。@RequestMapping源代碼如下圖：a) value：設置訪問的URL，數組，可以將多個請求映射到一個方法上去。支持通配符配置代碼示例：@RequestMapping(value = {"/page","/page*"})public void getInfo() {}上述代碼訪問路徑可以是：XXX/page，XXX/pageadc等滿足value條件的路徑。b) method：設置訪問的方法，數組，可是設置多個訪問方法映射到同一個方法上，默認為GET方法代碼示例：@RequestMapping(value = "/page", method = RequestMethod.POST)public void getInfo() {}上述代碼 /page路徑就只能用POST方法才能請求。method的可選值有GET,HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE。c) params：指定request中必須包含某些參數值是，才讓該方法處理。數組。@RequestMapping(value = "/page", params = {"type=1"})public void getInfo() {}上述代碼/page路徑只有請求參數中包含type且值等於1時才能訪問該方法。d) headers：指定request中必須包含某些指定的header值，才能讓該方法處理請求。數組。示例代碼：@RequestMapping(value = "/page", headers = {" content-type=text/plain " })public void getInfo() {}上述代碼/page路徑只有headers中content-type=text/plain才能訪問該方法。e) consumes：指定處理請求的提交內容類型（Content-Type），例如application/json, text/html。f) proces：指定返回的內容類型，僅當request請求頭中的(Accept)類型中包含該指定類型才返回。7. @ResponseBody通常使用在controller方法上，作用是將方法的返回值通過合適的HttpMessageConverter轉換成特定格式寫入到response的body區域，然後返回給客戶端，如果沒有使用@RequestBody註解，方法返回值將會封裝到ModelAndView並解析返回視圖。8. @RequestParam接受的參數來自requestHeader，即請求頭，用來接收GET和POST請求參數並將參數賦值到被@RequestParam註解的變數上，同樣可以使用requet.getParameter(「name」)獲取，默認的參數接受方式，如果controller方法的參數未使用@RequestParam，則默認也是使用@RequestParam接受參數。用來處理Content-Type: 為 application/x-www-form-urlencoded編碼的內容。@RequestParam有三個配置參數：a) required：是否必須，默認true，必須。b) defaultValue：默認值，請求的參數為空時使用默認值。c) value：請求的參數名。9. @RequestBody接受的參數來自requestBody，即請求體，一般用於處理非 Content-Type: application/x-www-form-urlencoded編碼格式的數據，比如：application/json、application/xml等類型的數據。10. @Autowired它可以對類成員變數，方法及構造函數進行標注，完成自動裝配工作，可以消除set，get方法。11. @Resource其作用和@Autowired相似。不同點：@Resource是java自己的註解，@Resource有兩個屬性重要屬性，分是name和type；Spring將@Resource註解的name屬性解析為bean的名字，而type屬性則解析為bean的類型。所以如果使用name屬性，則使用byName的自動注入策略，而使用type屬性時則使用byType自動注入策略。如果既不指定name也不指定type屬性，這時將通過反射機制使用byName自動注入策略。@Autowired是spring的註解，是spring2.5版本引入的，@Autowired只根據type進行注入，不會去匹配name。如果涉及到type無法辨別注入對象時，那需要依賴@Qualifier註解一起來修飾。@Resource裝配順序a) 如果同時指定了name和type，則從Spring上下文中找到唯一匹配的bean進行裝配，找不到則拋出異常b) 如果指定了name，則從上下文中查找名稱（id）匹配的bean進行裝配，找不到則拋出異常c) 如果指定了type，則從上下文中找到類型匹配的唯一bean進行裝配，找不到或者找到多個，都會拋出異常d) 如果既沒有指定name，又沒有指定type，則自動按照byName方式進行裝配；如果沒有匹配，則回退為一個原始類型進行匹配，如果匹配則自動裝配；推薦使用@Resource，不用謝set方法，並且這個註解屬於java自己的，減少了與spring的耦合度。12. @Value該註解有兩種使用方式：a) @Value(「${}」)這種使用方式注入的是配置文件里的參數這樣配置文件中的com.title就能配置到LinkInfoController的title屬性中b) @Value(「#{}」)該方式表示SpEl表達式通常用來獲取bean的屬性，或者調用bean的某個方法。這樣就可以把User對象的name配置到LinkInfoController的name屬性中。13. @Transactional用於配置spring事務管理。屬性信息如下：事物的傳播行為如下：14. @SpringBootApplication該註解其實是一個組合註解，源碼如下圖：比較重要的註解有三個：a) @SpringBootConfiguration從源代碼可以看到@SpringBootConfiguration繼承自@Configuration，這兩個註解的功能也是一樣的。b) @EnableAutoConfiguration此注釋自動載入應用程序所需的所有Bean。c) @ComponentScan該註解會掃描指定路徑下的的類，並將其加入到IoC容器中。在springboot中，@ComponentScan默認掃描@SpringBootApplication所在類的同級目錄以及它的子目錄。15. @Configuration從Spring3.0，@Configuration用於定義配置類，可替換xml配置文件，被註解的類內部包含有一個或多個被@Bean註解的方法，這些方法將會被或類進行掃描，並用於構建bean定義，初始化Spring容器。16. @Bean該註解主要用在@Configuration註解的類里，也可以用在@Component註解的類里。添加的bean的id為方法名。相當於配置文件里的<bean></bean>。@Configurationpublic class RedisConfig extends CachingConfigurerSupport{@Beanpublic CacheManager cacheManager(RedisConnectionFactory connectionFactory) {RedisCacheManager redisCacheManager = RedisCacheManager.create(connectionFactory);return redisCacheManager;}}如上代碼就相當於在xml文件里配置：<beans><bean id=" cacheManager " class=" com.mypage.config. RedisCacheManager "/></beans>17. @MapperScan指定要變成實現類的介面所在的包，然後包下面的所有介面在編譯之後都會生成相應的實現類添加位置：是在Springboot啟動類上面添加：18. @EnableCaching該註解是spring framework中的註解驅動的緩存管理功能。自spring版本3.1起加入了該註解。如果你使用了這個註解，那麼你就不需要在XML文件中配置cache manager了。@Configuration@EnableCachingpublic class RedisConfig extends CachingConfigurerSupport{/*** 採用RedisCacheManager作為緩存管理器* @param connectionFactory* @return*/@Beanpublic CacheManager cacheManager(RedisConnectionFactory connectionFactory) {RedisCacheManager redisCacheManager = RedisCacheManager.create(connectionFactory);return redisCacheManager;}}19. @EnableRedisHttpSession用來設置springboot使用redis存儲session，該註解會創建一個名字叫springSessionRepositoryFilter的Spring Bean，其實就是一個Filter，這個Filter負責用Spring Session來替換原先的默認HttpSession實現。示例代碼如下：@Configuration@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 60*30)public class HttpSessionConfig {}其中屬性maxInactiveIntervalInSeconds是設置session的有效時間，單位毫秒，默認1800ms。但其實這樣還是不夠的，還要在配置文件中設置redis存儲session:spring.session.store-type=redis這樣就可以了。

『肆』 spring2.0 和 spring2.5的區別

Spring經歷了兩次大修訂，第一次是2006年10月的Spring2.0，另一次是2007年11月的Spring2.5。
簡介：
1． JDK版本： JDK至少要1.4.2以上，如果仍然打算使用1.3的話就請用2.0.6/2.0.7版本吧。

(2) Spring對Java EE的支持
Spring框架繼續保持對Java EE1.3及以後版本的兼容，完全支持Java EE 5。
(3) Spring對伺服器(應用伺服器和Web伺服器)的支持
WebLogic：8.1、9.0、9.2、10
WebSphere：5.1、6.0、6.1
OC4J(Oracle)：10.1.3、11
JBoss：3.2、4.0、4.2
Tomcat：4.1、5.0、5.5、6.0
Jetty：4.2、5.1、6.1
Resin：2.1、3.0、3.1
GlassFish：v1、v2

控制反轉(IoC)容器：
(1) 新的bean作用域
Spring2.0
IoC容器中只支持singleton和prototype兩個不同的bean作用域，而在Spring2.5中則還支持request、session、global
session三個在web環境下使用的bean作用域，且提供了hooks，可以讓用戶創建自己的作用域。
(2) XML配置更簡單
Spring2.5對Spring 2.0的DTD進行了更新，使用時：<!DOCTYPE beans
PUBLIC "-//SPRING//DTD BEAN 2.0//EN"

"http://www.springframework.org/dtd/spring-beans-2.0.dtd">
spring-beans-2.0.dtd可在發布包下的dist/resources下找到。
(3) Annotation(註解)驅動配置
Spring2.5引入了完整的Annotation集合如：@Resource、@Autowired等

面向切面編程(AOP)：
(1) 更簡單的AOP XML配置
支持定義從JAVA對象中發展中來的切面
(2) 對@AspectJ的支持
加入了對bean(...)pointcut 元素的支持，在 spring定義的bean命名中對指定的命名進行匹配
(3) 對AspectJ load-time weaving的支持

中間層：
(1) XML聲明式事務配置更簡單
以前版本的事務配置方式仍然支持，Spring2.5支持裝載時織入和註解驅動的事務管理，這是通過context:load-time-weaver
和tx:annotation-driven mode="aspectj"的聯合使用進行的。
(2) 對Websphere 事務管理的完整支持
自動探測底層的JTA 事務平台，可以使用Spring 2.5的新 tx:jta-transaction-manager
配置元素。它會自動探測BEA WebLogic和IBM
WebSphere,注冊正確的PlatformTransactionManager。
(3) JPA
Spring 2.5對OpenJPA的支持升級到了OpenJPA 1.0，支持savepoint這樣的高級特性
(4) 非同步的JMS
在Spring 2.5中，
JCA風格的非同步消息監聽器設置也通過GenericMessageEndpointManager工具得到了支持。這是對標准JMS監聽器工具的補充，允許對ActionMQ和JORAM這些消息broker進行更深入的集成。Spring
2.5 還引入了一個XML
namespace來簡化JMS配置，可以對大量監聽器進行簡明配置。這一命名空間支持標準的JMS監聽器和JCA
setup風格，在配置時只有很小的改變。
(5) JDBC
引入了新類，Spring 2.5顯著的擴充了SimpleJdbcTemplate的功能，引入了SimpleJdbcCall
和SimpleJdbcInsert操作對象。

移植到Spring2.5：

從Spring2.0.X升級到Spring2.5隻需要把Spring2.5的jar復制到您工程目錄相應的配置。

改動處：可以參考發布包下的changelog.txt文件
在Spring2.5中，Spring Web
MVC不再在spring.jar里，Spring
MVC發布在lib/moles下，包是：spring-webmvc.jar和spring-webmvc-portlet.jar。

對struts1.x的支持獨立成spring-webmvc-struts.jar。
Spring2.0的'spring-jmx.jar'和
'spring-remoting.jar'已經被轉移到 Spring 2.5的'spring-context.jar'。
Spring 2.0的
'spring-support.jar' 被改名為 'spring-context-support.jar'。
Spring 2.0的'spring-jdo.jar', 'spring-jpa.jar',
'spring-hibernate3.jar', 'spring-toplink.jar' 和 'spring-ibatis.jar'
被合並到Spring 2.5大粒度的'spring-orm.jar'中。
Spring 2.5的 'spring-test.jar' 取代了'spring-mock.jar'。
Spring 2.5的 'spring-tx.jar' 取代了 'spring-.jar' 和'spring-jca.jar'
文件。
Spring主代碼中的Apache OJB支持被完全刪除了。
iBATIS SQL Maps 1.3支持被完全去除了。
Spring 2.5中，對 Hibernate 2.1 和 Hibernate 3.0 的支持已經去除。
Spring 2.5中，對JDO 1.0 的支持被去除。

2.5的新特性

Spring2.5rc1發布了，一直想知道它葫蘆里賣什麼葯，以下是文檔里的change.log

1． JDK版本： JDK至少要1.4.2以上，如果仍然打算使用1.3的話就請用2.0.6/2.0.7版本吧。
2． Jar包：SpringMVC 不再使用spring.jar 這個龐大的包了。 Spring-webmvc.jar,
spring-webmvc-portlet.jar 可以在 lib/moles 目錄下找到，而且對於Struts1.*
的支持的包也應該改成 spring-webmvc-struts.jar了。
3． XML配置：推薦使用XML
metadata格式，不過先前的DTD仍然支持。需要注意的一點是，Spring1.2的DTD繼續使用「singleton」屬性，但是新的Spring2.0
DTD不允許使用「singleton」屬性了，改成「scope」屬性來描述bean的生命周期。
4． 廢棄的類與方法：有些在先前版本標注過「@deprecated」的類與方法已經完全被廢棄了。
比如：
ResultReader : 被 RowMapper 介面取代。
BeanFactoryBootstrap : 考慮使用 BeanFactoryLocator
或自定義的bootstrap類來代替。
5． Apache OJB：注意Spring源代碼中已經完全把這個去掉了，但與之整合的類仍然可以在Spring Moles
project找到。https://springmoles.dev.java.net/
6． iBATIS：注意Spring已經不再支持iBATIS 的1.3版本了，
如果想繼續的話，請升級到2.3以上吧。
7． Hibernate：注意Spring已經不再支持Hibernate
3.1之前的版本了，也就是說2.1，3.0的版本也無法使用了。如果仍然要用的話，推薦使用Spring的2.0.6/2.0.7版本。
8．
JDO：注意Spring已經不支持JDO1.0了。同樣，你可以升級到2.0以上版本，或者使用Spring的2.0.6/2.0.7版本。
9． UrlFilenameViewControlle
r ：這個東東我也沒有接觸過，這里，我就簡單翻譯一下吧。
「考慮到嵌套路徑的請求，視圖名稱現在決定叫UrlFilenameViewControlle
r了，這是一個突破性的改變，並且意味著如果你從Spring1.*
升級到Spring2.0 你可以使用該類從而減少Spring Web MVC的配置工作。」

『伍』 SpringBoot核心原理：自動配置、事件驅動、Condition

SpringBoot是Spring的包裝，通過自動配置使得SpringBoot可以做到開箱即用，上手成本非常低，但是學習其實現原理的成本大大增加，需要先了解熟悉Spring原理。

如果還不清楚Spring原理的，可以先查看博主之前的文章，本篇主要分析SpringBoot的啟動、自動配置、Condition、事件驅動原理。

SpringBoot啟動非常簡單，因其內置了Tomcat，所以只需要通過下面幾種方式啟動即可：

可以看到第一種是最簡單的，也是最常用的方式，需要注意類上面需要標注 @SpringBootApplication 註解，這是自動配置的核心實現，稍後分析，先來看看SpringBoot啟動做了些什麼？

在往下之前，不妨先猜測一下，run方法中需要做什麼？對比Spring源碼，我們知道，Spring的啟動都會創建一個 ApplicationContext 的應用上下文對象，並調用其refresh方法啟動容器，SpringBoot只是Spring的一層殼，肯定也避免不了這樣的操作。

另一方面，以前通過Spring搭建的項目，都需要打成War包發布到Tomcat才行，而現在SpringBoot已經內置了Tomcat，只需要打成Jar包啟動即可，所以在run方法中肯定也會創建對應的Tomcat對象並啟動。以上只是我們的猜想，下面就來驗證，進入run方法：

SpringBoot的啟動流程就是這個方法，先看 getRunListeners 方法，這個方法就是去拿到所有的 SpringApplicationRunListener 實現類，這些類是用於SpringBoot事件發布的，關於事件驅動稍後分析，這里主要看這個方法的實現原理：

一步步追蹤下去可以看到最終就是通過SPI機制根據介面類型從 META-INF/spring.factories 文件中載入對應的實現類並實例化，SpringBoot的自動配置也是這樣實現的。

為什麼要這樣做呢？通過註解掃描不可以么？當然不行，這些類都在第三方jar包中，註解掃描實現是很麻煩的，當然你也可以通過 @Import 註解導入，但是這種方式不適合擴展類特別多的情況，所以這里採用SPI的優點就顯而易見了。

回到run方法中，可以看到調用了 createApplicationContext 方法，見名知意，這個就是去創建應用上下文對象：

注意這里通過反射實例化了一個新的沒見過的上下文對象 ，這個是SpringBoot擴展的，看看其構造方法：

如果你有看過Spring註解驅動的實現原理，這兩個對象肯定不會陌生，一個實支持註解解析的，另外一個是掃描包用的。

上下文創建好了，下一步自然就是調用refresh方法啟動容器：

這里首先會調用到其父類中 ：

可以看到是直接委託給了父類：

這個方法不會陌生吧，之前已經分析過了，這里不再贅述，至此SpringBoot的容器就啟動了，但是Tomcat啟動是在哪裡呢？run方法中也沒有看到。

實際上Tomcat的啟動也是在refresh流程中，這個方法其中一步是調用了onRefresh方法，在Spring中這是一個沒有實現的模板方法，而SpringBoot就通過這個方法完成了Tomcat的啟動：

這里首先拿到 TomcatServletWebServerFactory 對象，通過該對象再去創建和啟動Tomcat：

上面的每一步都可以對比Tomcat的配置文件，需要注意默認只支持了http協議：

如果想要擴展的話則可以對 additionalTomcatConnectors 屬性設置值，需要注意這個屬性沒有對應的setter方法，只有 addAdditionalTomcatConnectors 方法，也就是說我們只能通過實現 BeanFactoryPostProcessor 介面的 postProcessBeanFactory 方法，而不能通過 的 方法，因為前者可以通過傳入的BeanFactory對象提前獲取到 TomcatServletWebServerFactory 對象調用 addAdditionalTomcatConnectors 即可；而後者只能拿到BeanDefinition對象，該對象只能通過setter方法設置值。

這段代碼會在控制台列印所有的事件名稱，按照順序如下：

以上是正常啟動關閉，如果發生異常還有發布 ApplicationFailedEvent 事件。事件的發布遍布在整個容器的啟動關閉周期中，事件發布對象剛剛我們也看到了是通過SPI載入的 SpringApplicationRunListener 實現類 EventPublishingRunListener ，同樣事件監聽器也是在 spring.factories 文件中配置的，默認實現了以下監聽器：

可以看到有用於文件編碼的（ ），有載入日誌框架的（ LoggingApplicationListener ），還有載入配置的（ ConfigFileApplicationListener ）等等一系列監聽器，SpringBoot也就是通過這系列監聽器將必要的配置和組件載入到容器中來，這里不再詳細分析，感興趣的讀者可以通過其實現的 onApplicationEvent 方法看到每個監聽器究竟是監聽的哪一個事件，當然事件發布和監聽我們自己也是可以擴展的。

SpringBoot最核心的還是自動配置，為什麼它能做到開箱即用，不再需要我們手動使用 @EnableXXX 等註解來開啟？這一切的答案就在 @SpringBootApplication 註解中：

這里重要的註解有三個： @SpringBootConfiguration 、 @EnableAutoConfiguration 、 @ComponentScan 。 @ComponentScan 就不用再說了， @SpringBootConfiguration 等同於 @Configuration ，而 @EnableAutoConfiguration 就是開啟自動配置：

@AutoConfigurationPackage 註解的作用就是將該註解所標記類所在的包作為自動配置的包，簡單看看就行，主要看 ，這個就是實現自動配置的核心類，注意這個類是實現的 DeferredImportSelector 介面。

在這個類中有一個 selectImports 方法。這個方法在我之前的文章這一次搞懂Spring事務註解的解析也有分析過，只是實現類不同，它同樣會被 類調用，先來看這個方法做了些什麼：

追蹤源碼最終可以看到也是從 META-INF/spring.factories 文件中拿到所有 EnableAutoConfiguration 對應的值（在 spring-boot-autoconfigure 中）並通過反射實例化，過濾後包裝成 AutoConfigurationEntry 對象返回。

看到這里你應該會覺得自動配置的實現就是通過這個 selectImports 方法，但實際上這個方法通常並不會被調用到，而是會調用該類的內部類 AutoConfigurationGroup 的process和selectImports方法，前者同樣是通過 getAutoConfigurationEntry 拿到所有的自動配置類，而後者這是過濾排序並包裝後返回。

下面就來分析 是怎麼調用到這里的，直接進入 processConfigBeanDefinitions 方法：

前面一大段主要是拿到合格的 Configuration 配置類，主要邏輯是在 ConfigurationClassParser.parse 方法中，該方法完成了對 @Component 、 @Bean 、 @Import 、 @ComponentScans 等註解的解析，這里主要看對 @Import 的解析，其它的讀者可自行分析。一步步追蹤，最終會進入到 processConfigurationClass 方法：

這里需要注意 this.conditionEvaluator.shouldSkip 方法的調用，這個方法就是進行Bean載入過濾的，即根據 @Condition 註解的匹配值判斷是否載入該Bean，具體實現稍後分析，繼續跟蹤主流程 doProcessConfigurationClass ：

這里就是完成對一系列註解的支撐，我省略掉了，主要看 processImports 方法，這個方法就是處理 @Import 註解的：

剛剛我提醒過 是實現 DeferredImportSelector 介面的，如果不是該介面的實現類則是直接調用 selectImports 方法，反之則是調用 DeferredImportSelectorHandler.handle 方法：

首先創建了一個 DeferredImportSelectorHolder 對象，如果是第一次執行則是添加到 deferredImportSelectors 屬性中，等到 ConfigurationClassParser.parse 的最後調用process方法：

反之則是直接執行，首先通過register拿到 AutoConfigurationGroup 對象：

然後在 processGroupImports 方法中進行真正的處理：

在 getImports 方法中就完成了對process和 selectImports 方法的調用，拿到自動配置類後再遞歸調用調用 processImports 方法完成對自動配置類的載入。至此，自動配置的載入過程就分析完了，下面是時序圖：

在自動配置類中有很多Condition相關的註解，以AOP為例：

這里就能看到 @ConditionalOnProperty 、 @ConditionalOnClass 、 @ConditionalOnMissingClass ，另外還有 @ConditionalOnBean 、 @ConditionalOnMissingBean 等等很多條件匹配註解。

這些註解表示條件匹配才會載入該Bean，以 @ConditionalOnProperty 為例，表明配置文件中符合條件才會載入對應的Bean，prefix表示在配置文件中的前綴，name表示配置的名稱， havingValue 表示配置為該值時才匹配， matchIfMissing 則是表示沒有該配置是否默認載入對應的Bean。其它註解可類比理解記憶，下面主要來分析該註解的實現原理。

這里註解點進去看會發現每個註解上都標注了 @Conditional 註解，並且value值都對應一個類，比如 OnBeanCondition ，而這些類都實現了 Condition 介面，看看其繼承體系：

上面只展示了幾個實現類，但實際上Condition的實現類是非常多的，我們還可以自己實現該介面來擴展 @Condition 註解。Condition介面中有一個matches方法，這個方法返回true則表示匹配。該方法在 ConfigurationClassParser 中多處都有調用，也就是剛剛我提醒過的shouldSkip方法，具體實現是在 ConditionEvaluator 類中：

再來看看matches的實現，但 OnBeanCondition 類中沒有實現該方法，而是在其父類 SpringBootCondition 中：

getMatchOutcome 方法也是一個模板方法，具體的匹配邏輯就在這個方法中實現，該方法返回的 ConditionOutcome 對象就包含了是否匹配和日誌消息兩個欄位。進入到 OnBeanCondition 類中：

可以看到該類支持了 @ConditionalOnBean 、 @ConditionalOnSingleCandidate 、 @ConditionalOnMissingBean 註解，主要的匹配邏輯在 getMatchingBeans 方法中：

這里邏輯看起來比較復雜，但實際上就做了兩件事，首先通過 getNamesOfBeansIgnoredByType 方法調用 beanFactory.getBeanNamesForType 拿到容器中對應的Bean實例，然後根據返回的結果判斷哪些Bean存在，哪些Bean不存在（Condition註解中是可以配置多個值的）並返回MatchResult對象，而MatchResult中只要有一個Bean沒有匹配上就返回false，也就決定了當前Bean是否需要實例化。

本篇分析了SpringBoot核心原理的實現，通過本篇相信讀者也將能更加熟練地使用和擴展SpringBoot。

另外還有一些常用的組件我沒有展開分析，如事務、MVC、監聽器的自動配置，這些我們有了Spring源碼基礎的話下來看一下就明白了，這里就不贅述了。

最後讀者可以思考一下我們應該如何自定義starter啟動器，相信看完本篇應該難不倒你。

『陸』 spring常用註解作用與常用介面與後置處理器

從spring2.5之後，spring註解驅動開發慢慢取代了Spring的xml配置文件的作用，而且目前流行的SpringBoot開發也是基於spring註解驅動做擴展的，所以想要理解好SpringBoot，就必須掌握一些spring的註解驅動。

以前xml的做法是

現在使用spring註解的做法是

java8之後ComponentScan注冊加了@Repeatable(ComponentScans.class)，可以直接在配置類上標注多個@Componentscan，在java8之前想配置多個@Componentscan掃描，需要用@ComponentScans

給容器注冊組件(bean)的幾種方式
1.包掃描+組件標注註解(@Service、@Controller、@Repository、@Componet)，這種方式用於導入自己寫的類
2.@Bean方式導入，常用入導入第三方包裡面的類 默認bean id為導入執行的方法名
3.@Import方式導入(有三種用法)，默認的bean id為全類名
4.通過FactoryBean(工廠bean)

-bean創建->初始化->銷毀

applicationContextAeare和EmbeddedValueResolverAeare都是通過後置處理器來實現的

BeanFactoryPostProcessor是在bean定義信息載入完成後調用
是在bean定義信息將要載入時調用
先執行的實現類再執行BeanFactoryPostProcessor的實現類

創建bean的源碼位置
org.springframework.context.support.AbstractApplicationContext#
->org.springframework.beans.factory.BeanFactory#getBean(java.lang.String, java.lang.Class<T>)
-->org.springframework.beans.factory.support.AbstractBeanFactory#createBean
--->org.springframework.beans.factory.support.#doCreateBean
執行bean對象的實例化
->org.springframework.beans.factory.support.AbstractBeanFactory#createBean
給bean的屬性賦值
org.springframework.beans.factory.support.#populateBean

initializeBean方法主要做了三個操作1.循環執行後置處理器的的前置方法()、2.再執行初始化方法(invokeInitMethods)，3.再執行後置處理器的的後置方法()
org.springframework.beans.factory.support.#initializeBean(java.lang.String, java.lang.Object, org.springframework.beans.factory.support.RootBeanDefinition)

『柒』 mybatis和ibatis的區別

1、基本信息不同

mybatis：MyBatis 是一款優秀的持久層框架，它支持定製化 SQL、存儲過程以及高級映射。MyBatis 避免了幾乎所有的 JDBC 代碼和手動設置參數以及獲取結果集。

MyBatis 可以使用簡單的 XML 或註解來配置和映射原生信息，將介面和 Java 的 POJOs(Plain Ordinary Java Object,普通的 Java對象)映射成資料庫中的記錄。

ibatis：iBATIS提供的持久層框架包括SQL Maps和Data Access Objects（DAO），同時還提供一個利用這個框架開發的JPetStore實例。相對Hibernate和ApacheOJB等「一站式」ORM解決方案而言，ibatis 是一種「半自動化」的ORM實現。

iBATIS 目前提供了三種語言實現的版本，包括：Java、.NET以及Ruby。

2、開發時間不同

mybatis：MyBatis 本是apache的一個開源項目iBatis, 2010年這個項目由apache software foundation 遷移到了google code，並且改名為MyBatis 。2013年11月遷移到Github。

ibatis：iBATIS一詞來源於「internet」和「abatis」的組合，是一個由Clinton Begin在2001年發起的開放源代碼項目。

3、配置方法不同

mybatis簡化了編碼的過程，不需要去寫的實現類，直接寫一個的介面，再寫一個xml配置文件，整個mybatis就配置好了，也就是資料庫就連接好了，然後在service裡面直接調用就可以了，但是ibatis則不可以，必須要寫的實現類。mybatis是ibatis的升級版本。