Spring:

@Configuration 會(huì)進(jìn)行動(dòng)態(tài)代理保證單例，不加會(huì)初始化多次纵装，不會(huì)生成動(dòng)態(tài)代理据某。

ConfigurationClassPostProcessor :

DefaultListableBeanFactory：

ConfigurationClassEnhancer: cglib代理癣籽，基于類實(shí)現(xiàn)筷狼， （代理名稱：xxBySpringCGLIB），BeanMethodInterceptor對(duì)目標(biāo)對(duì)象 攔截塑顺，保證對(duì)象不會(huì)重復(fù)創(chuàng)建

BeanFactoryPostProcessor：后置執(zhí)行器

BeanPostProcess： AOP基于此實(shí)現(xiàn)

BeanFactory定義了 IOC 容器的最基本形式严拒，并提供了 IOC 容器應(yīng)遵守的的最基本的接口，也就是 Spring IOC所遵守的最底層和最基本的編程規(guī)范勒奇。在? Spring 代碼中， BeanFactory 只是個(gè)接口劈彪，并不是 IOC 容器的具體實(shí)現(xiàn)顶猜，但是 Spring 容器給出了很多種實(shí)現(xiàn)长窄，如 DefaultListableBeanFactory 挠日、 XmlBeanFactory 、 ApplicationContext等冬骚，都是附加了某種功能的實(shí)現(xiàn)只冻。

一般情況下喜德，Spring 通過反射機(jī)制利用 <bean> 的 class 屬性指定實(shí)現(xiàn)類實(shí)例化 Bean垮媒。在某些情況下睡雇，實(shí)例化Bean 過程比較復(fù)雜，如果按照傳統(tǒng)的方式奄薇，則需要在 <bean> 中提供大量的配置信息馁蒂。配置方式的靈活性是受限的，這時(shí)采用編碼的方式可能會(huì)得到一個(gè)簡(jiǎn)單的方案饵隙。Spring 為此提供了一個(gè)org.springframework.bean.factory.FactoryBean 的工廠類接口金矛，用戶可以通過實(shí)現(xiàn)該接口定制實(shí)例化 Bean 的邏輯驶俊。

FactoryBean接口對(duì)于 Spring 框架來說占用重要的地位免姿， Spring 自身就提供了 70 多個(gè) FactoryBean 的實(shí)現(xiàn)胚膊。它們隱藏了實(shí)例化一些復(fù)雜 Bean 的細(xì)節(jié)，給上層應(yīng)用帶來了便利紊婉。從 Spring 3.0 開始药版， FactoryBean 開始支持泛型，即接口聲明改為 FactoryBean<T> 的形式：

區(qū)別：

BeanFactory是個(gè) Factory 喻犁，也就是 IOC 容器或?qū)ο蠊S刚陡， FactoryBean 是個(gè) Bean 。在 Spring 中株汉，所有的Bean 都是由 BeanFactory( 也就是 IOC 容器 ) 來進(jìn)行管理的筐乳。但對(duì) FactoryBean 而言，這個(gè) Bean 不是簡(jiǎn)單的 Bean乔妈，而是一個(gè)能生產(chǎn)或者修飾對(duì)象生成的工廠 Bean, 它的實(shí)現(xiàn)與設(shè)計(jì)模式中的工廠模式和修飾器模式類似。

AOP 是基于動(dòng)態(tài)代理模式實(shí)現(xiàn)的路召，具體實(shí)現(xiàn)上可以基于 JDK 動(dòng)態(tài)代理或者 Cglib 動(dòng)態(tài)代理勃刨。其中 JDK 動(dòng)態(tài)代理只能代理實(shí)現(xiàn)了接口的對(duì)象，而 Cglib 動(dòng)態(tài)代理則無此限制股淡。所以在為沒有實(shí)現(xiàn)接口的對(duì)象生成代理時(shí)身隐，只能使用 Cglib。

1. AOP 邏輯介入 BeanFactory 實(shí)例化 bean 的過程

2. 根據(jù) Pointcut 定義的匹配規(guī)則唯灵，判斷當(dāng)前正在實(shí)例化的 bean 是否符合規(guī)則

3. 如果符合贾铝，代理生成器將切面邏輯 Advice 織入 bean 相關(guān)方法中，并為目標(biāo) bean 生成代理對(duì)象

4. 將生成的 bean 的代理對(duì)象返回給 BeanFactory 容器，到此垢揩，AOP 邏輯執(zhí)行結(jié)束

所謂 IOC 玖绿，就是由 Spring IOC 容器來負(fù)責(zé)對(duì)象的生命周期和對(duì)象之間的關(guān)系

spring bean生命周期：

實(shí)例化bean對(duì)象，設(shè)置對(duì)象屬性叁巨，檢查aware相關(guān)接口并設(shè)置相關(guān)依賴斑匪，執(zhí)行BeanPostProcessor前置處理，

檢查是否有InitializingBean以決定是否調(diào)用afterPropertiesSet方法锋勺，檢查是否有配置初始化方法蚀瘸，

BeanPostProcessor后置處理，調(diào)用DisposableBean接口庶橱，是否配置有銷毀方法贮勃。

spring 解決循壞依賴問題：三層依賴

其中第一層是singletonObjects，首先會(huì)去看singletonObjects是否已經(jīng)創(chuàng)建了一個(gè)對(duì)象悬包。如果沒有，那么從第二層緩存earlySingletonObjects提前曝光對(duì)象的緩存中獲肉梢摇布近；如果沒有，那么最后從第三層緩存singletonFactories單實(shí)例工廠緩存中獲取丝格。當(dāng)獲取成功后撑瞧，會(huì)把第三層緩存singletonFactories的bean去掉，加入到第二層緩存中显蝌。

springmvc:

1.客戶端（瀏覽器）發(fā)送請(qǐng)求预伺，直接請(qǐng)求到 DispatcherServlet。

2.DispatcherServlet 根據(jù)請(qǐng)求信息調(diào)用 HandlerMapping曼尊，解析請(qǐng)求對(duì)應(yīng)的 Handler酬诀。

3.解析到對(duì)應(yīng)的 Handler（也就是我們平常說的 Controller 控制器）后，開始由 HandlerAdapter 適配器處理骆撇。

4.HandlerAdapter 會(huì)根據(jù) Handler 來調(diào)用真正的處理器開處理請(qǐng)求瞒御，并處理相應(yīng)的業(yè)務(wù)邏輯。

5.處理器處理完業(yè)務(wù)后神郊，會(huì)返回一個(gè) ModelAndView 對(duì)象肴裙，Model 是返回的數(shù)據(jù)對(duì)象，View 是個(gè)邏輯上的 View涌乳。

6.ViewResolver 會(huì)根據(jù)邏輯 View 查找實(shí)際的 View蜻懦。

7.DispaterServlet 把返回的 Model 傳給 View（視圖渲染）。

8.把 View 返回給請(qǐng)求者（瀏覽器）

OncePerRequestFilter： 為了兼容不同的web容器夕晓，默認(rèn)的所有filter繼承他宛乃。

Spring 事務(wù)：

? spring事務(wù)基于AOP實(shí)現(xiàn)，首先判斷當(dāng)前是否存在事務(wù)環(huán)境，然后根據(jù)事務(wù)的傳播行為以及隔離級(jí)別來管理事務(wù)提交與回滾烤惊。

臟讀乔煞、不可重復(fù)讀、幻讀:

臟讀：事務(wù)A讀到了事務(wù)B未提交的數(shù)據(jù)柒室。

不可重復(fù)讀：事務(wù)A第一次查詢得到一行記錄row1渡贾，事務(wù)B提交修改后，事務(wù)A第二次查詢得到row1雄右，但列內(nèi)容發(fā)生了變化空骚。

幻讀：事務(wù)A第一次查詢得到一行記錄row1，事務(wù)B提交修改后擂仍，事務(wù)A第二次查詢得到兩行記錄row1和row2

ACID：

原子性（Atomicity）

原子性是指事務(wù)是一個(gè)不可分割的工作單位囤屹，事務(wù)中的操作要么都發(fā)生，要么都不發(fā)生逢渔。

一致性（Consistency）

事務(wù)前后數(shù)據(jù)的完整性必須保持一致肋坚。

隔離性（Isolation）

事務(wù)的隔離性是多個(gè)用戶并發(fā)訪問數(shù)據(jù)庫時(shí)，數(shù)據(jù)庫為每一個(gè)用戶開啟的事務(wù)肃廓，不能被其他事務(wù)的操作數(shù)據(jù)所干擾智厌，多個(gè)并發(fā)事務(wù)之間要相互隔離。

持久性（Durability）

持久性是指一個(gè)事務(wù)一旦被提交盲赊，它對(duì)數(shù)據(jù)庫中數(shù)據(jù)的改變就是永久性的铣鹏，接下來即使數(shù)據(jù)庫發(fā)生故障也不應(yīng)該對(duì)其有任何影響

事務(wù)的隔離級(jí)別分為：未提交讀(read uncommitted)、已提交讀(read committed)哀蘑、可重復(fù)讀(repeatable read)诚卸、串行化(serializable)。

Spring 事務(wù)中哪幾種事務(wù)傳播行為?

支持當(dāng)前事務(wù)的情況：

TransactionDefinition.PROPAGATION_REQUIRED： 如果當(dāng)前存在事務(wù)绘迁，則加入該事務(wù)合溺；如果當(dāng)前沒有事務(wù)，則創(chuàng)建一個(gè)新的事務(wù)缀台。

TransactionDefinition.PROPAGATION_SUPPORTS： 如果當(dāng)前存在事務(wù)辫愉，則加入該事務(wù)；如果當(dāng)前沒有事務(wù)将硝，則以非事務(wù)的方式繼續(xù)運(yùn)行恭朗。

TransactionDefinition.PROPAGATION_MANDATORY： 如果當(dāng)前存在事務(wù)，則加入該事務(wù)依疼；如果當(dāng)前沒有事務(wù)痰腮，則拋出異常。（mandatory：強(qiáng)制性）

不支持當(dāng)前事務(wù)的情況：

TransactionDefinition.PROPAGATION_REQUIRES_NEW： 創(chuàng)建一個(gè)新的事務(wù)，如果當(dāng)前存在事務(wù)，則把當(dāng)前事務(wù)掛起。

TransactionDefinition.PROPAGATION_NOT_SUPPORTED： 以非事務(wù)方式運(yùn)行茉兰，如果當(dāng)前存在事務(wù)沧踏，則把當(dāng)前事務(wù)掛起歌逢。

TransactionDefinition.PROPAGATION_NEVER： 以非事務(wù)方式運(yùn)行，如果當(dāng)前存在事務(wù)翘狱，則拋出異常秘案。

其他情況：

TransactionDefinition.PROPAGATION_NESTED： 如果當(dāng)前存在事務(wù)，則創(chuàng)建一個(gè)事務(wù)作為當(dāng)前事務(wù)的嵌套事務(wù)來運(yùn)行潦匈；如果當(dāng)前沒有事務(wù)阱高，則該取值等價(jià)于TransactionDefinition.PROPAGATION_REQUIRED。

事務(wù)掛起： 不使用這個(gè)事務(wù)茬缩，如果拋出異常不影響事務(wù)赤惊。

嵌套事務(wù)：

? 如果里面出現(xiàn)了異常，回到保存點(diǎn)的狀態(tài)凰锡，外部事務(wù)不會(huì)回滾未舟，如果外部事務(wù)拋出異常，影響嵌套事務(wù)回滾掂为。

Spring 事務(wù)中隔離級(jí)別有哪幾種?

? TransactionDefinition 接口中定義了五個(gè)表示隔離級(jí)別的常量：

? ? 1.TransactionDefinition.ISOLATION_DEFAULT: 使用后端數(shù)據(jù)庫默認(rèn)的隔離級(jí)別裕膀，Mysql 默認(rèn)采用的 REPEATABLE_READ隔離級(jí)別 Oracle 默認(rèn)采用的 READ_COMMITTED隔離級(jí)別.

? ? 2.TransactionDefinition.ISOLATION_READ_UNCOMMITTED: 最低的隔離級(jí)別，允許讀取尚未提交的數(shù)據(jù)變更菩掏，可能會(huì)導(dǎo)致臟讀魂角、幻讀或不可重復(fù)讀

? ? 3.TransactionDefinition.ISOLATION_READ_COMMITTED: 允許讀取并發(fā)事務(wù)已經(jīng)提交的數(shù)據(jù)昵济，可以阻止臟讀智绸，但是幻讀或不可重復(fù)讀仍有可能發(fā)生

? ? 4.TransactionDefinition.ISOLATION_REPEATABLE_READ: 對(duì)同一字段的多次讀取結(jié)果都是一致的，除非數(shù)據(jù)是被本身事務(wù)自己所修改访忿，可以阻止臟讀和不可重復(fù)讀瞧栗，但幻讀仍有可能發(fā)生。

? ? 5.TransactionDefinition.ISOLATION_SERIALIZABLE: 最高的隔離級(jí)別海铆，完全服從ACID的隔離級(jí)別迹恐。所有的事務(wù)依次逐個(gè)執(zhí)行，這樣事務(wù)之間就完全不可能產(chǎn)生干擾卧斟，也就是說殴边，該級(jí)別可以防止臟讀、不可重復(fù)讀以及幻讀珍语。但是這將嚴(yán)重影響程序的性能锤岸。通常情況下也不會(huì)用到該級(jí)別。

分布式事務(wù)：分布式事務(wù)由事務(wù)發(fā)起者板乙、資源管理器（參與者）是偷、事務(wù)協(xié)調(diào)者組成。

? 1 基于XA協(xié)議的兩階段提交方案

? ? 交易中間件與數(shù)據(jù)庫通過 XA 接口規(guī)范，使用兩階段提交來完成一個(gè)全局事務(wù)蛋铆， XA 規(guī)范的基礎(chǔ)是兩階段提交協(xié)議馋评。

? ? 第一階段是表決階段，所有參與者都將本事務(wù)能否成功的信息反饋發(fā)給協(xié)調(diào)者刺啦；

? ? 第二階段是執(zhí)行階段留特，協(xié)調(diào)者根據(jù)所有參與者的反饋，通知所有參與者洪燥，步調(diào)一致地在所有分支上提交或者回滾磕秤。

? 兩階段提交方案應(yīng)用非常廣泛，幾乎所有商業(yè)OLTP數(shù)據(jù)庫都支持XA協(xié)議捧韵。但是兩階段提交方案鎖定資源時(shí)間長(zhǎng)市咆，對(duì)性能影響很大，基本不適合解決微服務(wù)事務(wù)問題再来。

? 優(yōu)點(diǎn)：

? ? 1 較強(qiáng)的一致性蒙兰，適合于對(duì)數(shù)據(jù)一致性要求比較高對(duì)場(chǎng)景，當(dāng)然并不是100%一致性

? 缺點(diǎn)：

? 1 整個(gè)過程耗時(shí)過程芒篷，鎖定資源時(shí)間過長(zhǎng)搜变，同步阻塞（準(zhǔn)備階段回復(fù)后，一直等待協(xié)調(diào)者調(diào)用commit 或者rollback）针炉，CAP中達(dá)到了CP挠他，犧牲了可用性，不適合高并發(fā)場(chǎng)景

? 2 協(xié)調(diào)者可能存在單點(diǎn)故障

? 3 Commit階段可能存在部分成功篡帕，部分失敗情況殖侵，并沒有提及是否rollback

? 3PC三階段提交(非阻塞，引入超時(shí)和準(zhǔn)備階段)tcc——traction

? ? 進(jìn)入階段3之后镰烧，如果協(xié)調(diào)者或者執(zhí)行者因?yàn)榫W(wǎng)絡(luò)等問題拢军，接受不到docommit請(qǐng)求，超時(shí)后默認(rèn)都執(zhí)行doCommit請(qǐng)求怔鳖，解決了2PC的第三個(gè)缺點(diǎn)

? ? 第一階段canCommit

? ? ? 事務(wù)發(fā)起方發(fā)起事務(wù)后茉唉，事務(wù)協(xié)調(diào)器會(huì)給所有的事務(wù)參與者發(fā)起canCommit?的請(qǐng)求，參與者收到后根據(jù)自己的情況判斷是否可以執(zhí)行提交结执，如果可以則回執(zhí)OK度陆，否者返回fail，并不開啟本地事務(wù)并執(zhí)行献幔。具體參與者是如何判斷本地是否可以執(zhí)行提交協(xié)議并沒有具體規(guī)定懂傀，需要協(xié)議實(shí)現(xiàn)者自己規(guī)定，比如可能判斷參與者是否存在（網(wǎng)絡(luò)是否OK）或者本地?cái)?shù)據(jù)庫連接是否可用來判斷（YY）斜姥。

? ? ? 如果協(xié)調(diào)器發(fā)現(xiàn)有些發(fā)起方返回fail或者等待超時(shí)后參與者還沒返回則給所有事務(wù)參與者發(fā)起中斷操作鸿竖，具體中斷操作做什么協(xié)議也沒有具體規(guī)定沧竟。如果協(xié)調(diào)器發(fā)現(xiàn)所有參與者返回可以提交，則進(jìn)入第二階段缚忧。

? ? 第二階段preCommit

? ? ? 事務(wù)協(xié)調(diào)器向所有參與者發(fā)起準(zhǔn)備事務(wù)請(qǐng)求悟泵，參與者接受到后，開啟本地事務(wù)并執(zhí)行闪水，但是不提交糕非。剩下的與二階段的一階段一致。

? ? 第三階段commit

? ? ? 事務(wù)協(xié)調(diào)器向所有事務(wù)參與者發(fā)起提交事務(wù)的請(qǐng)求球榆，事務(wù)參與者接受到請(qǐng)求后朽肥，執(zhí)行本地事務(wù)的提交操作。如果事務(wù)協(xié)調(diào)器收到所有參與者提交OK則分布式事務(wù)結(jié)束持钉。

? ? 優(yōu)點(diǎn)：

? ? ? 降低了阻塞范圍衡招，在等待超時(shí)后協(xié)調(diào)者或參與者會(huì)中斷事務(wù)。避免了協(xié)調(diào)者單點(diǎn)問題每强，階段3中協(xié)調(diào)者出現(xiàn)問題時(shí)始腾，參與者會(huì)繼續(xù)提交事務(wù)。

? ? 缺陷：

? ? ? 腦裂問題依然存在空执，即在參與者收到PreCommit請(qǐng)求后等待最終指令浪箭，如果此時(shí)協(xié)調(diào)者無法與參與者正常通信，會(huì)導(dǎo)致參與者繼續(xù)提交事務(wù)辨绊，造成數(shù)據(jù)不一致奶栖。

? 2pc與3pc區(qū)別：

? ? ? 三階段與二階段最大不同在于三階段協(xié)議把二階段的第一階段拆分為了兩個(gè)階段，其中第一階段并不鎖定資源门坷，而是詢問參與者是否可以提交宣鄙，等所有參與者回復(fù)OK后在具體執(zhí)行第二階段鎖定資源。理論上如果第一階段返回都OK拜鹤，則第二階段和三階段執(zhí)行成功的概率就很大框冀，另外如果第一階段有些參與者返回了fail流椒，由于這時(shí)候其他參與者還沒有鎖定資源敏簿，所以不會(huì)造成資源的阻塞。3PC引入了超時(shí)提交的策略宣虾，而不是盲等待惯裕，

? TCC（事務(wù)補(bǔ)償）方案：

? ? TCC方案其實(shí)是兩階段提交的一種改進(jìn)。其將整個(gè)業(yè)務(wù)邏輯的每個(gè)分支顯式的分成了Try绣硝、Confirm蜻势、Cancel三個(gè)操作。Try部分完成業(yè)務(wù)的準(zhǔn)備工作鹉胖，confirm部分完成業(yè)務(wù)的提交握玛，cancel部分完成事務(wù)的回滾够傍。

? ? 事務(wù)開始時(shí)，業(yè)務(wù)應(yīng)用會(huì)向事務(wù)協(xié)調(diào)器注冊(cè)啟動(dòng)事務(wù)挠铲。之后業(yè)務(wù)應(yīng)用會(huì)調(diào)用所有服務(wù)的try接口冕屯，完成一階段準(zhǔn)備。之后事務(wù)協(xié)調(diào)器會(huì)根據(jù)try接口返回情況拂苹，決定調(diào)用confirm接口或者cancel接口安聘。如果接口調(diào)用失敗，會(huì)進(jìn)行重試瓢棒。

? ? TCC方案讓應(yīng)用自己定義數(shù)據(jù)庫操作的粒度浴韭，使得降低鎖沖突、提高吞吐量成為可能脯宿。 當(dāng)然TCC方案也有不足之處念颈，集中表現(xiàn)在以下兩個(gè)方面：

? ? ? 對(duì)應(yīng)用的侵入性強(qiáng)。業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn)try连霉、confirm舍肠、cancel三個(gè)操作，應(yīng)用侵入性較強(qiáng)窘面，改造成本高翠语。

? ? ? 實(shí)現(xiàn)難度較大。需要按照網(wǎng)絡(luò)狀態(tài)财边、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略肌括。為了滿足一致性的要求，confirm和cancel接口必須實(shí)現(xiàn)冪等酣难。

? ? TCC與2pc/3pc區(qū)別： 2pc/3pc執(zhí)行需要依賴數(shù)據(jù)庫層面谍夭，而tcc更適合微服務(wù)應(yīng)用層面。?

? 基于MQ的最終一致性方案

? ? 消息一致性方案是通過消息中間件保證上憨募、下游應(yīng)用數(shù)據(jù)操作的一致性紧索。基本思路是將本地操作和發(fā)送消息放在一個(gè)事務(wù)中菜谣，保證本地操作和消息發(fā)送要么兩者都成功或者都失敗珠漂。下游應(yīng)用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應(yīng)操作尾膊。消息方案從本質(zhì)上講是將分布式事務(wù)轉(zhuǎn)換為兩個(gè)本地事務(wù)媳危，然后依靠下游業(yè)務(wù)的重試機(jī)制達(dá)到最終一致性「粤玻基于消息的最終一致性方案對(duì)應(yīng)用侵入性也很高待笑，應(yīng)用需要進(jìn)行大量業(yè)務(wù)改造，成本較高抓谴。

CAP理論：

C(Consistency)

? 一致性是說數(shù)據(jù)的原子性,這種原子性在經(jīng)典ACID的數(shù)據(jù)庫中是通過事務(wù)來保證的,當(dāng)事務(wù)完成時(shí),無論其是成功還是回滾,數(shù)據(jù)都會(huì)處于一致的狀態(tài).

? 在分布式環(huán)境中,一致性是說多點(diǎn)的數(shù)據(jù)是否一致.

A(Availability)

? 可用性是說服務(wù)能一直保證是可用的狀態(tài)暮蹂，當(dāng)用戶發(fā)出一個(gè)請(qǐng)求寞缝，服務(wù)能在有限時(shí)間內(nèi)返回結(jié)果。

而這種可用性是不關(guān)乎結(jié)果的正確與否仰泻，所以第租，如果服務(wù)一致返回錯(cuò)誤的數(shù)據(jù),其實(shí)也可以稱為其是可用的。

P(Tolerance of network Partition)

? 是指網(wǎng)絡(luò)的分區(qū)我纪，網(wǎng)絡(luò)中的兩個(gè)服務(wù)結(jié)點(diǎn)出現(xiàn)分區(qū)的原因很多慎宾，比如網(wǎng)絡(luò)斷了、對(duì)方結(jié)點(diǎn)因?yàn)槌绦騜ug或死機(jī)等原因不能訪問

一個(gè)分布式系統(tǒng)不可能滿足一致性浅悉，可用性和分區(qū)容錯(cuò)性這三個(gè)需求,最多只能同時(shí)滿足兩個(gè)趟据。

BASE理論：

? Basically Availble 犧牲高一致性，獲得可用性或可靠性 --基本可用

? Soft-state --軟狀態(tài)/軟事務(wù)术健，狀態(tài)可以有一段時(shí)間不同步汹碱，異步。

? Eventual Consistency --最終一致性荞估，最終數(shù)據(jù)是一致的就可以了咳促，而不是實(shí)時(shí)一致。