Spring是一個(gè)輕量級(jí)框架，核心內(nèi)容是IOC和AOP。它目的是用于簡(jiǎn)化企業(yè)應(yīng)用程序的開(kāi)發(fā)，它使得開(kāi)發(fā)者只需要關(guān)心業(yè)務(wù)需求。主要包括以下七個(gè)模塊（簡(jiǎn)單了解一下就行）：
● Spring Context：提供框架式的Bean訪問(wèn)方式，以及企業(yè)級(jí)功能（JNDI、定時(shí)任務(wù)等）；
● Spring Core：核心類庫(kù)，所有功能都依賴于該類庫(kù)，提供IOC和DI服務(wù)；
● Spring AOP：AOP服務(wù)；
● Spring Web：提供了基本的面向Web的綜合特性，提供對(duì)常見(jiàn)框架如Struts2的支持，Spring能夠管理這些框架，將Spring的資源注入給框架，也能在這些框架的前后插入攔截器；
● Spring MVC：提供面向Web應(yīng)用的Model-View-Controller，即MVC實(shí)現(xiàn)。
● Spring DAO：對(duì)JDBC的抽象封裝，簡(jiǎn)化了數(shù)據(jù)訪問(wèn)異常的處理，并能統(tǒng)一管理JDBC事務(wù)；
● Spring ORM：對(duì)現(xiàn)有的ORM框架的支持；
(1)Spring屬于低侵入式設(shè)計(jì)，代碼的污染極低；
(2)Spring的DI機(jī)制將對(duì)象之間的依賴關(guān)系交由框架處理，減低組件的耦合性；
(3)Spring提供了AOP技術(shù)，支持將一些通用任務(wù)，如安全、事務(wù)、日志、權(quán)限等進(jìn)行集中式管理，從而提供更好的復(fù)用。
(4)Spring對(duì)于主流的應(yīng)用框架提供了集成支持。
IOC,英文Inversion of Control的縮寫(xiě)，即“控制反轉(zhuǎn)”，是一種設(shè)計(jì)思想。所謂控制反轉(zhuǎn)就是把對(duì)象（bean）對(duì)象和維護(hù)對(duì)象（bean）之間的關(guān)系的權(quán)利轉(zhuǎn)移到Sqring容器中去了（ApplicationContext.xml）而程序本身不在維護(hù)了。
什么意思呢？在javase中一個(gè)對(duì)象中使用另外的對(duì)象，就必須主動(dòng)通過(guò)new指令去創(chuàng)建依賴對(duì)象，使用完后還需要銷毀（比如Connection等），對(duì)象始終會(huì)和其他接口或類耦合起來(lái)。也就是說(shuō)創(chuàng)建對(duì)象的時(shí)機(jī)和主動(dòng)權(quán)都是由自己把控的，而 IOC 則是由專門(mén)的容器來(lái)幫忙創(chuàng)建對(duì)象，將所有的類都通過(guò)Spring容器中注冊(cè)，當(dāng)需要某個(gè)對(duì)象時(shí)，不再需要自己主動(dòng)去 new 了，只需告訴Spring容器，然后讓Spring容器主動(dòng)給你。也就是說(shuō)，對(duì)于某個(gè)具體的對(duì)象而言，以前是由自己控制它所引用對(duì)象的生命周期，而在IOC中，所有的對(duì)象都被 Spring容器控制，由 Spring 容器幫我們創(chuàng)建、查找及注入依賴對(duì)象，而引用對(duì)象只是被動(dòng)的接受依賴對(duì)象，所以這叫控制反轉(zhuǎn)。
IOC的一個(gè)重點(diǎn)就是在程序運(yùn)行時(shí)，動(dòng)態(tài)的向某個(gè)對(duì)象提供它所需要的其他對(duì)象，這一點(diǎn)是通過(guò)DI（Dependency Injection，依賴注入）來(lái)實(shí)現(xiàn)的，即應(yīng)用程序在運(yùn)行時(shí)依賴 IoC 容器來(lái)動(dòng)態(tài)注入對(duì)象所需要的外部依賴。而 Spring 的 DI 具體就是通過(guò)反射實(shí)現(xiàn)注入的，反射允許程序在運(yùn)行的時(shí)候動(dòng)態(tài)的生成對(duì)象、執(zhí)行對(duì)象的方法、改變對(duì)象的屬性。
IOC是解決耦合問(wèn)題的一種設(shè)計(jì)思想，DI是IOC的一種實(shí)現(xiàn)。IOC主要的實(shí)現(xiàn)方式有兩種：依賴查找（DL），依賴注入（DI）。
AOP，稱為面向切面編程，用于將那些與業(yè)務(wù)無(wú)關(guān)，但卻對(duì)多個(gè)對(duì)象產(chǎn)生影響的公共行為和邏輯，抽取并封裝為一個(gè)可重用的模塊，減少系統(tǒng)中的重復(fù)代碼，降低了模塊間的耦合度，提高系統(tǒng)的可維護(hù)性。可用于權(quán)限認(rèn)證、日志、事務(wù)處理。
Spring AOP中的動(dòng)態(tài)代理主要有兩種方式，JDK動(dòng)態(tài)代理和CGLIB動(dòng)態(tài)代理：
JDK動(dòng)態(tài)代理只提供接口的代理，不支持類的代理，因此要求被代理類實(shí)現(xiàn)接口。
CGLIB是通過(guò)繼承的方式做的動(dòng)態(tài)代理。
AOP實(shí)現(xiàn)的關(guān)鍵在于 代理模式，AOP代理主要分為靜態(tài)代理和動(dòng)態(tài)代理。靜態(tài)代理的代表為AspectJ；動(dòng)態(tài)代理則以Spring AOP為代表。靜態(tài)代理與動(dòng)態(tài)代理區(qū)別在于生成AOP代理對(duì)象的時(shí)機(jī)不同
（1）AspectJ是靜態(tài)代理，也稱為編譯時(shí)增強(qiáng)，AOP框架會(huì)在編譯階段生成AOP代理類，并將AspectJ(切面)織入到Java字節(jié)碼中，運(yùn)行的時(shí)候就是增強(qiáng)之后的AOP對(duì)象。
（2）Spring AOP使用的動(dòng)態(tài)代理，所謂的動(dòng)態(tài)代理就是說(shuō)AOP框架不會(huì)去修改字節(jié)碼，而是每次運(yùn)行時(shí)在內(nèi)存中臨時(shí)為方法生成一個(gè)AOP對(duì)象，這個(gè)AOP對(duì)象包含了目標(biāo)對(duì)象的全部方法，并且在特定的切點(diǎn)做了增強(qiáng)處理，并回調(diào)原對(duì)象的方法。
① JDK動(dòng)態(tài)代理只提供接口的代理，不支持類的代理，要求被代理類實(shí)現(xiàn)接口。JDK動(dòng)態(tài)代理的核心是InvocationHandler接口和Proxy類，在獲取代理對(duì)象時(shí)，使用Proxy類來(lái)動(dòng)態(tài)創(chuàng)建目標(biāo)類的代理類（即最終真正的代理類，這個(gè)類繼承自Proxy并實(shí)現(xiàn)了我們定義的接口），當(dāng)代理對(duì)象調(diào)用真實(shí)對(duì)象的方法時(shí)， InvocationHandler 通過(guò)invoke()方法反射來(lái)調(diào)用目標(biāo)類中的代碼，動(dòng)態(tài)地將橫切邏輯和業(yè)務(wù)編織在一起；
② 如果被代理類沒(méi)有實(shí)現(xiàn)接口，那么Spring AOP會(huì)選擇使用CGLIB來(lái)動(dòng)態(tài)代理目標(biāo)類。CGLIB（Code Generation Library），是一個(gè)代碼生成的類庫(kù)，可以在運(yùn)行時(shí)動(dòng)態(tài)的生成指定類的一個(gè)子類對(duì)象，并覆蓋其中特定方法并添加增強(qiáng)代碼，從而實(shí)現(xiàn)AOP。CGLIB是通過(guò)繼承的方式做的動(dòng)態(tài)代理，因此如果某個(gè)類被標(biāo)記為final，那么它是無(wú)法使用CGLIB做動(dòng)態(tài)代理的。
1.連接點(diǎn)（Join point）：指程序運(yùn)行過(guò)程中所執(zhí)行的方法。在Spring AOP中，一個(gè)連接點(diǎn)總代表一個(gè)方法的執(zhí)行。
2.切點(diǎn)（Pointcut）：切點(diǎn)用于定義要對(duì)哪些Join point進(jìn)行攔截。
切點(diǎn)分為execution方式和annotation方式。execution方式可以用路徑表達(dá)式指定對(duì)哪些方法攔截，比如指定攔截add*、search*。annotation方式可以指定被哪些注解修飾的代碼進(jìn)行攔截。
3.通知（Advice）：指要在連接點(diǎn)（Join Point）上執(zhí)行的動(dòng)作，即增強(qiáng)的邏輯，比如權(quán)限校驗(yàn)和、日志記錄等。通知有各種類型，包括Around、Before、After、After returning、After throwing。
4.切面（Aspect）：可以看成 Pointcut切點(diǎn) 和 Advice通知的結(jié)合，通知說(shuō)明了干什么和什么時(shí)候干（什么時(shí)候通過(guò)方法名中的before,after，around等就能知道），而切點(diǎn)說(shuō)明了在哪干（指定到底是哪個(gè)方法），這就是一個(gè)完整的切面定義。
5.目標(biāo)對(duì)象（Target）：包含連接點(diǎn)的對(duì)象，也稱作被通知（Advice）的對(duì)象。 由于Spring AOP是通過(guò)動(dòng)態(tài)代理實(shí)現(xiàn)的，所以這個(gè)對(duì)象永遠(yuǎn)是一個(gè)代理對(duì)象。
6.織入（Weaving）：通過(guò)動(dòng)態(tài)代理，在目標(biāo)對(duì)象（Target）的方法（即連接點(diǎn)Join point）中執(zhí)行增強(qiáng)邏輯（Advice）的過(guò)程。
7.引入（Introduction）：添加額外的方法或者字段到被通知的類。Spring允許引入新的接口（以及對(duì)應(yīng)的實(shí)現(xiàn)）到任何被代理的對(duì)象。例如，你可以使用一個(gè)引入來(lái)使bean實(shí)現(xiàn) IsModified 接口，以便簡(jiǎn)化緩存機(jī)制。
1. 前置通知（Before Advice）：在連接點(diǎn)（Join point）之前執(zhí)行的通知。
2. 后置通知（After Advice）：當(dāng)連接點(diǎn)退出的時(shí)候執(zhí)行的通知（不論是正常返回還是異常退出）。
3. 環(huán)繞通知（Around Advice）：包圍一個(gè)連接點(diǎn)的通知，這是最強(qiáng)大的一種通知類型。環(huán)繞通知可以在方法調(diào)用前后完成自定義的行為。它也可以選擇是否繼續(xù)執(zhí)行連接點(diǎn)或直接返回它們自己的返回值或拋出異常來(lái)結(jié)束執(zhí)行。
4. 返回后通知（AfterReturning Advice）：在連接點(diǎn)正常完成后執(zhí)行的通知（如果連接點(diǎn)拋出異常，則不執(zhí)行）
5. 拋出異常后通知（AfterThrowing advice）：在方法拋出異常退出時(shí)執(zhí)行的通知
● set()方法注入；
● 構(gòu)造器注入：①通過(guò)index設(shè)置參數(shù)的位置；②通過(guò)type設(shè)置參數(shù)類型；
● 接口注入；（用的比較少）
注意：通過(guò)Spring創(chuàng)建的對(duì)象默認(rèn)是單例的，如果需要?jiǎng)?chuàng)建多實(shí)例對(duì)象可以在標(biāo)簽后面添加一個(gè)屬性scope="prototype"：
<bean name="..." class="..." scope="prototype">
Spring Bean的生命周期只有四個(gè)階段：實(shí)例化 Instantiation --> 屬性賦值 Populate --> 初始化 Initialization --> 銷毀 Destruction
singleton， 也就是單例，意味著在整個(gè)Spring容器中只會(huì)存在一個(gè)Bean實(shí)例。
prototype，翻譯成原型，意味著每次從IOC容器去獲取指定Bean的時(shí)候，都會(huì)返回一個(gè)新的實(shí)例對(duì)象。
request， 針對(duì)每一次http請(qǐng)求，都會(huì)創(chuàng)建一個(gè)新的Bean
session，以sesssion會(huì)話為緯度，同一個(gè)session共享同一個(gè)Bean實(shí)例，不同的session產(chǎn)生不同的Bean實(shí)例
globalSession，針對(duì)全局session緯度，共享同一個(gè)Bean實(shí)例
當(dāng) bean 在 Spring 容器中組合在一起時(shí)，它被稱為裝配或 bean 裝配。Spring容器需要知道需要什么 bean 以及容器應(yīng)該如何使用依賴注入來(lái)將 bean 綁定在一起，同時(shí)裝配 bean。
Spring 容器能夠自動(dòng)裝配 bean。也就是說(shuō)，可以通過(guò)檢查 BeanFactory 的內(nèi)容讓 Spring 自動(dòng)解析 bean 的協(xié)作者。 自動(dòng)裝配的不同模式：
no - 這是默認(rèn)設(shè)置，表示沒(méi)有自動(dòng)裝配。應(yīng)使用顯式 bean 引用進(jìn)行裝配。
byName - 它根據(jù) bean 的名稱注入對(duì)象依賴項(xiàng)。它匹配并裝配其屬性與 XML文件中由相同名稱定義的 bean。
byType - 它根據(jù)類型注入對(duì)象依賴項(xiàng)。如果屬性的類型與 XML 文件中的一個(gè) bean 名稱匹配，則匹配并裝配屬性。構(gòu)造函數(shù)- 它通過(guò)調(diào)用類的構(gòu)造函數(shù)來(lái)注入依賴項(xiàng)。它有大量的參數(shù)。
autodetect - 首先容器嘗試通過(guò)構(gòu)造函數(shù)使用 autowire 裝配，如果不能，則嘗試通過(guò) byType 自動(dòng)裝配。
1）給容器注入組件注解
@Component：泛指各種組件
@Controller、@Service、@Repository都可以稱為@Component。
@Controller：控制層
@Service：業(yè)務(wù)層
@Repository：數(shù)據(jù)訪問(wèn)層
2）注入bean的注解
@Autowired、@Inject是默認(rèn)按照類型匹配的，
@Resource是按照名稱匹配的，@Autowired如果需要按照名稱匹配需要和@Qualifier一起使用，@Inject和@Name一起使用。
@Primary讓spring進(jìn)行自動(dòng)裝配的時(shí)候，默認(rèn)使用首選的bean，和@Qualifier一個(gè)效果。
3）切面（AOP）相關(guān)注解
@Aspect 聲明一個(gè)切面
@After 在方法執(zhí)行之后執(zhí)行（方法上）
@Before 在方法執(zhí)行之前執(zhí)行（方法上）
@Around 在方法執(zhí)行之前與之后執(zhí)行（方法上）
@PointCut 聲明切點(diǎn)
(1) @Autowired默認(rèn)是按照類型裝配注入的，默認(rèn)情況下它要求依賴對(duì)象必須存在（可以設(shè)置它required屬性為false）。
(2) @Resource默認(rèn)是按照名稱來(lái)裝配注入的，只有當(dāng)找不到與名稱匹配的bean才會(huì)按照類型來(lái)裝配注入
1. BeanFactory是Spring里面最底層的接口，是最簡(jiǎn)單的容器，只提供了實(shí)例化對(duì)象和拿對(duì)象的功能；ApplicationContext是應(yīng)用上下文，繼承BeanFactory接口，它是Spring的一個(gè)更高級(jí)的容器，提供了更多的有用的功能。
2. 兩者在裝載Bean的時(shí)候，BeanFactory在啟動(dòng)的時(shí)候不會(huì)去實(shí)例化Bean，只有從容器中拿Bean的時(shí)候才會(huì)去實(shí)例化，因此應(yīng)用啟動(dòng)的時(shí)候占用資源很少；而ApplicationContext在啟動(dòng)的時(shí)候就把所有的Bean全部實(shí)例化了。這樣系統(tǒng)在啟動(dòng)的時(shí)候，可以盡早的發(fā)現(xiàn)系統(tǒng)中的配置問(wèn)題， 建議web應(yīng)用在啟動(dòng)的時(shí)候就把所有的Bean都加載了，以便讓費(fèi)時(shí)的操作放到系統(tǒng)啟動(dòng)中完成。
兩者的區(qū)別在：前者是工廠類，簡(jiǎn)單理解成 beanName和bean對(duì)象映射關(guān)系的維護(hù)者（是個(gè)容器），提供根據(jù)beanName查詢bean對(duì)象的能力；后者是工廠類，描述的是Bean對(duì)象實(shí)例化的過(guò)程，用于生成特定類型的對(duì)象。BeanFactory is a factory, FactoryBean is a bean。
FactoryBean 當(dāng)你向容器注冊(cè)名字為 factoryBeanName 的 FactoryBean的時(shí)候，你向容器注冊(cè)的是 名字為&factoryBeanName的FactoryBean的對(duì)象，，通過(guò)factoryBeanName獲取到的是 FactoryBean#getObject 返回的對(duì)象，該對(duì)象不受Spring 容器管理.
當(dāng)創(chuàng)建Bean的過(guò)程中涉及到多個(gè)依賴對(duì)象的復(fù)雜配置（不是簡(jiǎn)單的屬性注冊(cè)），或者存在一定的復(fù)用性時(shí)，可以通過(guò) FactoryBean 簡(jiǎn)化一部分實(shí)例過(guò)程，減少無(wú)關(guān)Bean的注冊(cè)。例如 AbstractEntityManagerFactoryBean 相關(guān)實(shí)現(xiàn)。
Redis 提供兩種持久化機(jī)制 RDB（默認(rèn)） 和 AOF 機(jī)制:
RDB：是Redis DataBase縮寫(xiě)快照,按照一定的時(shí)間將內(nèi)存的數(shù)據(jù)以快照的形式保存到硬盤(pán)中，對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb。通過(guò)配置文件中的save參數(shù)來(lái)定義快照的周期。
優(yōu)點(diǎn)：
只有一個(gè)文件 dump.rdb，方便持久化。
容災(zāi)性好，一個(gè)文件可以保存到安全的磁盤(pán)。
性能最大化，fork 子進(jìn)程來(lái)完成寫(xiě)操作，讓主進(jìn)程繼續(xù)處理命令，所以是 IO 最大化。使用單 獨(dú)子進(jìn)程來(lái)進(jìn)行持久化，主進(jìn)程不會(huì)進(jìn)行任何 IO 操作，保證了 redis 的高性能
相對(duì)于數(shù)據(jù)集大時(shí)，比 AOF 的啟動(dòng)效率更高。
缺點(diǎn)：
數(shù)據(jù)安全性低。RDB 是間隔一段時(shí)間進(jìn)行持久化，如果持久化之間 redis 發(fā)生故障，會(huì)發(fā)生數(shù) 據(jù)丟失。所以這種方式更適合數(shù)據(jù)要求不嚴(yán)謹(jǐn)?shù)臅r(shí)候)
==
AOF持久化(即Append Only File持久化)，則是將Redis執(zhí)行的每次寫(xiě)命令記錄到單獨(dú)的日志文件
中，當(dāng)重啟Redis會(huì)重新將持久化的日志中文件恢復(fù)數(shù)據(jù)。當(dāng)兩種方式同時(shí)開(kāi)啟時(shí)，數(shù)據(jù)恢復(fù)Redis會(huì)優(yōu)先選擇AOF恢復(fù)
優(yōu)點(diǎn)：
數(shù)據(jù)安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進(jìn)行一次 命令操作就記錄 到 aof 文件中一次。
通過(guò) append 模式寫(xiě)文件，即使中途服務(wù)器宕機(jī)，可以通過(guò) redis-check-aof 工具解決數(shù)據(jù)一 致性問(wèn)題。
AOF 機(jī)制的 rewrite 模式。AOF 文件沒(méi)被 rewrite 之前（文件過(guò)大時(shí)會(huì)對(duì)命令 進(jìn)行合并重寫(xiě)），可以刪除其中的某些命令（比如誤操作的 flflushall）)
缺點(diǎn)：
AOF 文件比 RDB 文件大，且恢復(fù)速度慢。
數(shù)據(jù)集大的時(shí)候，比 rdb 啟動(dòng)效率低。
類與類之間的依賴關(guān)系形成了閉環(huán)，就會(huì)導(dǎo)致循環(huán)依賴問(wèn)題的產(chǎn)生。
比如下圖中A類依賴了B類，B類依賴了C類，而最后C類又依賴了A類，這樣就形成了循環(huán)依賴問(wèn)題。
1.通過(guò)構(gòu)造方法進(jìn)行依賴注入時(shí)產(chǎn)生的循環(huán)依賴問(wèn)題。
該情況會(huì)報(bào)異常，在new對(duì)象的時(shí)候就會(huì)堵塞住了，其實(shí)也就是”先有雞還是先有蛋“的歷史難題。
2.通過(guò)setter方法進(jìn)行依賴注入且是在多例模式下產(chǎn)生的循環(huán)依賴問(wèn)題。
該情況會(huì)報(bào)異常，每一次getBean()時(shí)，都會(huì)產(chǎn)生一個(gè)新的Bean，如此反復(fù)下去就會(huì)有無(wú)窮無(wú)盡的Bean產(chǎn)生了，最終就會(huì)導(dǎo)致OOM問(wèn)題的出現(xiàn)。
3.通過(guò)setter方法進(jìn)行依賴注入且是在單例模式下產(chǎn)生的循環(huán)依賴問(wèn)題。
因此在Spring中，前兩種都會(huì)報(bào)異常，只有第（3）種方式的循環(huán)依賴問(wèn)題能被解決。
Spring在單例模式下的setter方法依賴注入引起的循環(huán)依賴問(wèn)題，主要是通過(guò)二級(jí)緩存和三級(jí)緩存來(lái)解決的，其中三級(jí)緩存是主要功臣。解決的核心原理就是：在對(duì)象實(shí)例化之后，依賴注入之前，Spring提前暴露的Bean實(shí)例的引用在第三級(jí)緩存中進(jìn)行存儲(chǔ)。
Spring中有三個(gè)緩存，用于存儲(chǔ)單例的Bean實(shí)例，這三個(gè)緩存是彼此互斥的，不會(huì)針對(duì)同一個(gè)Bean的實(shí)例同時(shí)存儲(chǔ)。如果調(diào)用getBean，則需要從三個(gè)緩存中依次獲取指定的Bean實(shí)例。 讀取順序依次是一級(jí)緩存 ==> 二級(jí)緩存 ==> 三級(jí)緩存。
Spring啟動(dòng)過(guò)程是IOC容器的啟動(dòng)過(guò)程，本質(zhì)是創(chuàng)建和初始化bean工廠(BeanFactory).BeanFactory是Spring IOC的核心，Spring使用beanFactory來(lái)實(shí)例化，配置和管理bean。對(duì)于web程序，IOC容器啟動(dòng)過(guò)程即是建立上下文的過(guò)程，web容器會(huì)提供一個(gè)全局的servletContext上下文環(huán)境。其啟動(dòng)過(guò)程主要包含三個(gè)類，ContextLoaderListener，ContextLoader和XmlWebApplicationContext。
在web.xml中提供ContextLoaderListener上下文監(jiān)聽(tīng)器，在web容器啟動(dòng)時(shí)，會(huì)觸發(fā)容器初始化事件，ContextLoaderListener會(huì)監(jiān)聽(tīng)到這個(gè)事件，從而觸發(fā)ContextInitialized方法完成上下文初始化，這個(gè)方法中調(diào)用父類ContextLoader的方法完成上下文初始化。ContextLoader類中主要完成三件事：
1）創(chuàng)建WebApplicationContext；
2）加載對(duì)應(yīng)的Spring配置文件中的bean;(refresh方法,完成bean的加載）
3）將WebApplicationContext放入servletContext中。ContextLoaderListener監(jiān)聽(tīng)器初始化完之后，開(kāi)始初始化web.xml中配置的servlet，如DispatcherSevlet
ContextLoaderListener監(jiān)聽(tīng)器監(jiān)聽(tīng)的是servletContext，當(dāng)web容器初始化后，servletContext發(fā)生變化時(shí)，會(huì)觸發(fā)相應(yīng)事件。
Spring事務(wù)的本質(zhì)其實(shí)就是數(shù)據(jù)庫(kù)對(duì)事務(wù)的支持，沒(méi)有數(shù)據(jù)庫(kù)的事務(wù)支持，spring是無(wú)法提供事務(wù)功能的。Spring只提供統(tǒng)一事務(wù)管理接口，具體實(shí)現(xiàn)都是由各數(shù)據(jù)庫(kù)自己實(shí)現(xiàn)，數(shù)據(jù)庫(kù)事務(wù)的提交和回滾是通過(guò) redo log 和 undo log實(shí)現(xiàn)的。Spring會(huì)在事務(wù)開(kāi)始時(shí)，根據(jù)當(dāng)前環(huán)境中設(shè)置的隔離級(jí)別，調(diào)整數(shù)據(jù)庫(kù)隔離級(jí)別，由此保持一致。
①編程式事務(wù)管理使用TransactionTemplate。
②聲明式事務(wù)管理建立在AOP之上的。其本質(zhì)是通過(guò)AOP功能，對(duì)方法前后進(jìn)行攔截，將事務(wù)處理的功能編織到攔截的方法中，也就是在目標(biāo)方法開(kāi)始之前啟動(dòng)一個(gè)事務(wù)，在執(zhí)行完目標(biāo)方法之后根據(jù)執(zhí)行情況提交或者回滾事務(wù)。
聲明式事務(wù)最大的優(yōu)點(diǎn)就是不需要在業(yè)務(wù)邏輯代碼中摻雜事務(wù)管理的代碼，只需在配置文件中做相關(guān)的事務(wù)規(guī)則聲明或通過(guò)@Transactional注解的方式，便可以將事務(wù)規(guī)則應(yīng)用到業(yè)務(wù)邏輯中，減少業(yè)務(wù)代碼的污染。唯一不足地方是，最細(xì)粒度只能作用到方法級(jí)別，無(wú)法做到像編程式事務(wù)那樣可以作用到代碼塊級(jí)別。
Spring事務(wù)的傳播機(jī)制說(shuō)的是，當(dāng)多個(gè)事務(wù)同時(shí)存在的時(shí)候，Spring如何處理這些事務(wù)的行為。事務(wù)傳播機(jī)制實(shí)際上是使用簡(jiǎn)單的ThreadLocal實(shí)現(xiàn)的，所以，如果調(diào)用的方法是在新線程調(diào)用的，事務(wù)傳播實(shí)際上是會(huì)失效的。① PROPAGATION_REQUIRED：（默認(rèn)傳播行為）如果當(dāng)前沒(méi)有事務(wù)，就創(chuàng)建一個(gè)新事務(wù)；如果當(dāng)前存在事務(wù)，就加入該事務(wù)。
② PROPAGATION_REQUIRES_NEW：無(wú)論當(dāng)前存不存在事務(wù)，都創(chuàng)建新事務(wù)進(jìn)行執(zhí)行。
③ PROPAGATION_SUPPORTS：如果當(dāng)前存在事務(wù)，就加入該事務(wù)；如果當(dāng)前不存在事務(wù)，就以非事務(wù)執(zhí)行。‘
④ PROPAGATION_NOT_SUPPORTED：以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。
⑤ PROPAGATION_NESTED：如果當(dāng)前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行；如果當(dāng)前沒(méi)有事務(wù)，則按REQUIRED屬性執(zhí)行。
⑥ PROPAGATION_MANDATORY：如果當(dāng)前存在事務(wù)，就加入該事務(wù)；如果當(dāng)前不存在事務(wù)，就拋出異常。
⑦ PROPAGATION_NEVER：以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。
① ISOLATION_DEFAULT：這是個(gè) PlatfromTransactionManager 默認(rèn)的隔離級(jí)別，使用數(shù)據(jù)庫(kù)默認(rèn)的事務(wù)隔離級(jí)別。
② ISOLATION_READ_UNCOMMITTED：讀未提交，允許事務(wù)在執(zhí)行過(guò)程中，讀取其他事務(wù)未提交的數(shù)據(jù)。
③ ISOLATION_READ_COMMITTED：讀已提交，允許事務(wù)在執(zhí)行過(guò)程中，讀取其他事務(wù)已經(jīng)提交的數(shù)據(jù)。
④ ISOLATION_REPEATABLE_READ：可重復(fù)讀，在同一個(gè)事務(wù)內(nèi)，任意時(shí)刻的查詢結(jié)果都是一致的。
⑤ ISOLATION_SERIALIZABLE：所有事務(wù)逐個(gè)依次執(zhí)行。
1. @Transactional配置的方法非public權(quán)限修飾（例如private的就別加了）；
2. @Transactional所在類非Spring容器管理的bean（例如一個(gè)Util就別加了，都沒(méi)注入容器，你叫Spring怎么用他的AOP幫你管理事務(wù)？）；
3. @Transactional所在類中，注解修飾的方法被類內(nèi)部方法調(diào)用（例如同一個(gè)class類中，方法A調(diào)用方法B，只在方法B加了@Transactional注解，那就失效了）；
4. 業(yè)務(wù)代碼拋出異常類型非RuntimeException，事務(wù)失效；
5. 業(yè)務(wù)代碼中存在異常時(shí)，使用try…catch…語(yǔ)句塊捕獲，而catch語(yǔ)句塊沒(méi)有throw new RuntimeExecption異常（只有該異常或者他的父異常例如Exception可以回滾）;
6. 注解@Transactional中Propagation屬性值設(shè)置錯(cuò)誤（例如Propagation.NOT_SUPPORTED，一般不會(huì)這么設(shè)置）
7. mysql關(guān)系型數(shù)據(jù)庫(kù)，且存儲(chǔ)引擎是MyISAM而非InnoDB，則事務(wù)會(huì)不起作用。
在java中異常的基類為T(mén)hrowable，Error和Exception繼承Throwable。Exception中RuntimeException及其子類成為未檢查異常（unchecked），其它Exception成為已檢查異常（checked）。
Spring的事務(wù)管理默認(rèn)是針對(duì)unchecked exception回滾，也就是默認(rèn)對(duì)Error異常和RuntimeException異常以及其子類進(jìn)行事務(wù)回滾，且必須拋出異常，若使用try-catch對(duì)其異常捕獲則不會(huì)進(jìn)行回滾！（Error異常和RuntimeException異常拋出時(shí)不需要方法調(diào)用throws或try-catch語(yǔ)句）；
checked異常,checked異常必須由try-catch語(yǔ)句包含或者由方法throws拋出，且事務(wù)默認(rèn)對(duì)checked異常不進(jìn)行回滾。
單例模式應(yīng)該是大家印象最深的一種設(shè)計(jì)模式了。在Spring中最明顯的使用場(chǎng)景是在配置文件中配置注冊(cè)bean對(duì)象的時(shí)候設(shè)置scope的值為singleton 。
<bean class="com.bjpowernode.pojo.User" id="user" scope="singleton">
<property name="name" value="張三"></property>
</bean>
原型模式也叫克隆模式，Spring中該模式使用的很明顯，和單例一樣在bean標(biāo)簽中設(shè)置scope的屬性prototype即表示該bean以克隆的方式生成
<bean class="com.bjpowernode.pojo.User" id="user" scope="prototype">
<property name="name" value="張三"></property>
</bean>
模板模式的核心是父類定義好流程，然后將流程中需要子類實(shí)現(xiàn)的方法就抽象話留給子類實(shí)現(xiàn)，Spring中的JdbcTemplate就是這樣的實(shí)現(xiàn)。我們知道jdbc的步驟是固定
1）加載驅(qū)動(dòng),
2）獲取連接通道,
3）構(gòu)建sql語(yǔ)句.
4）執(zhí)行sql語(yǔ)句,
5）關(guān)閉資源
在這些步驟中第3步和第4步是不確定的,所以就留給客戶實(shí)現(xiàn)，而我們實(shí)際使用JdbcTemplate的時(shí)候也確實(shí)是只需要構(gòu)建SQL就可以了.這就是典型的模板模式。我們以query方法為例來(lái)看下JdbcTemplate中的代碼.
觀察者模式定義的是對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。使用比較場(chǎng)景是在監(jiān)聽(tīng)器中而spring中Observer模式常用的地方也是listener的實(shí)現(xiàn)。如ApplicationListener.
簡(jiǎn)單工廠模式：就是通過(guò)工廠根據(jù)傳遞進(jìn)來(lái)的參數(shù)決定產(chǎn)生哪個(gè)對(duì)象。Spring中我們通過(guò)getBean方法獲取對(duì)象的時(shí)候根據(jù)id或者name獲取就是簡(jiǎn)單工廠模式了。
<context:annotation-config/>
<bean class="com.bjpowernode.pojo.User" id="user" >
<property name="name" value="張三"></property>
</bean>
工廠方法模式：在Spring中我們一般是將Bean的實(shí)例化直接交給容器去管理的，實(shí)現(xiàn)了使用和創(chuàng)建的分離，這時(shí)容器直接管理對(duì)象，還有種情況是，bean的創(chuàng)建過(guò)程我們交給一個(gè)工廠去實(shí)現(xiàn)，而Spring容器管理這個(gè)工廠。這個(gè)就是我們講的工廠模式，在Spring中有兩種實(shí)現(xiàn)一種是靜態(tài)工廠方法模式，一種是動(dòng)態(tài)工廠方法模式。以靜態(tài)工廠來(lái)演示
/**
* User 工廠類
*
*/
public class UserFactory {
/**
* 必須是static方法
* @return
*/
public static UserBean getInstance(){
return new UserBean();
}
}
將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口。使得原本由于接口不兼容而不能一起工作的那些類可以在一起工作。這就是適配器模式。在Spring中在AOP實(shí)現(xiàn)中的Advice和interceptor之間的轉(zhuǎn)換就是通過(guò)適配器模式實(shí)現(xiàn)的。
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
@Override
public boolean supportsAdvice(Advice advice) {
return (advice instanceof MethodBeforeAdvice);
}
@Override
public MethodInterceptor getInterceptor(Advisor advisor) {
MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
// 通知類型匹配對(duì)應(yīng)的攔截器
return new MethodBeforeAdviceInterceptor(advice);
}
}
裝飾者模式：裝飾者模式又稱為包裝模式(Wrapper),作用是用來(lái)動(dòng)態(tài)的為一個(gè)對(duì)象增加新的功能。裝飾模式是一種用于代替繼承的技術(shù)，無(wú)須通過(guò)繼承增加子類就能擴(kuò)展對(duì)象的新功能。使用對(duì)象的關(guān)聯(lián)關(guān)系代替繼承關(guān)系，更加靈活，同時(shí)避免類型體系的快速膨脹。
spring中用到的包裝器模式在類名上有兩種表現(xiàn)：一種是類名中含有Wrapper，另一種是類名中含有Decorator。基本上都是動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。
具體的使用在Spring session框架中的SessionRepositoryRequestWrapper使用包裝模式對(duì)原生的request的功能進(jìn)行增強(qiáng)，可以將session中的數(shù)據(jù)和分布式數(shù)據(jù)庫(kù)進(jìn)行同步，這樣即使當(dāng)前tomcat崩潰，session中的數(shù)據(jù)也不會(huì)丟失。
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session</artifactId>
<version>1.3.1.RELEASE</version>
</dependency>
代理模式：Spring的AOP功能用到了JDK的動(dòng)態(tài)代理和CGLIB字節(jié)碼生成技術(shù)
策略模式：例如Resource的實(shí)現(xiàn)類，針對(duì)不同的資源文件，實(shí)現(xiàn)了不同方式的資源獲取策略。
責(zé)任鏈模式：AOP中的攔截器鏈
委托者模式：DelegatingFilterProxy，整合Shiro，SpringSecurity的時(shí)候都有用到。
橋接模式：可以根據(jù)客戶的需求能夠動(dòng)態(tài)切換不同的數(shù)據(jù)源。比如我們的項(xiàng)目需要連接多個(gè)數(shù)據(jù)庫(kù)，客戶在每次訪問(wèn)中根據(jù)需要會(huì)去訪問(wèn)不同的數(shù)據(jù)庫(kù)。
Spring MVC是一個(gè)基于MVC設(shè)計(jì)模式的請(qǐng)求驅(qū)動(dòng)類型的輕量級(jí)Web框架，通過(guò)把Model，View，Controller分離，將web層進(jìn)行職責(zé)解耦，把復(fù)雜的web應(yīng)用分成邏輯清晰的幾部分，簡(jiǎn)化開(kāi)發(fā)，減少出錯(cuò)，方便組內(nèi)開(kāi)發(fā)人員之間的配合。
1. 與Spring框架集成，因此擁有Spring的優(yōu)點(diǎn)。
2. 支持RestFul風(fēng)格以及支持各種請(qǐng)求資源的映射策略。
3. SpringMVC提供強(qiáng)大的約定大于配置的契約式編程支持，例如前端控制器(dispatcherServlet) ，請(qǐng)求到處理器映射（handlerMapping)，處理器適配器(HandlerAdapter)，視圖解析器（ViewResolver）。開(kāi)發(fā)人員僅需規(guī)定進(jìn)行配置即可。
4. 可以十分靈活地實(shí)現(xiàn)數(shù)據(jù)驗(yàn)證、格式化和數(shù)據(jù)綁定機(jī)制，可以使用任意對(duì)象進(jìn)行數(shù)據(jù)綁定操作。
(1)前端控制器 DispatcherServlet（不需要程序員開(kāi)發(fā)）
作用：接收請(qǐng)求、響應(yīng)結(jié)果，相當(dāng)于轉(zhuǎn)發(fā)器，有了DispatcherServlet 就減少了其它組件之間的耦合度。
(2)處理器映射器HandlerMapping（不需要程序員開(kāi)發(fā)）
作用：根據(jù)請(qǐng)求的URL來(lái)查找Handler
(3)處理器適配器HandlerAdapter
注意：在編寫(xiě)Handler的時(shí)候要按照HandlerAdapter要求的規(guī)則去編寫(xiě)，這樣適配器HandlerAdapter才可以正確的去執(zhí)行Handler。
(4)處理器Handler（需要程序員開(kāi)發(fā)）
(5)視圖解析器 ViewResolver（不需要程序員開(kāi)發(fā)）
作用：進(jìn)行視圖的解析，根據(jù)視圖邏輯名解析成真正的視圖（view）
(6)視圖View（需要程序員開(kāi)發(fā)jsp）
View是一個(gè)接口， 它的實(shí)現(xiàn)類支持不同的視圖類型（jsp，freemarker，pdf等等）
流程不用記得那么清楚，能把SpringMVC程序開(kāi)發(fā)步驟說(shuō)清楚就行。
第一步：發(fā)起請(qǐng)求到前端控制器(DispatcherServlet)
第二步：前端控制器向處理器映射器(HandlerMapping)發(fā)請(qǐng)求查找 Handler （可以根據(jù)xml配置、注解進(jìn)行查找）
第三步：處理器映射器向前端控制器返回Handler，處理器映射器會(huì)把請(qǐng)求映射為HandlerExecutionChain對(duì)象（包含一個(gè)Handler處理器（頁(yè)面控制器）對(duì)象，多個(gè)HandlerInterceptor攔截器對(duì)象），通過(guò)這種策略模式，很容易添加新的映射策略
第四步：前端控制器調(diào)用處理器適配器(HandlerAdapter)去執(zhí)行Handler
第五步：處理器適配器將會(huì)根據(jù)適配的結(jié)果去執(zhí)行Handler
第六步：Handler執(zhí)行完成給處理器適配器返回ModelAndView
第七步：處理器適配器向前端控制器返回ModelAndView （ModelAndView是springmvc框架的一個(gè)底層對(duì)象，包括 Model和view）
第八步：前端控制器請(qǐng)求視圖解析器（ViewResolver）去進(jìn)行視圖解析 （根據(jù)邏輯視圖名解析成真正的視圖(jsp)），通過(guò)這種策略很容易更換其他視圖技術(shù)，只需要更改視圖解析器即可
第九步：視圖解析器向前端控制器返回View
第十步：前端控制器進(jìn)行視圖渲染 （視圖渲染將模型數(shù)據(jù)(在ModelAndView對(duì)象中)填充到request域）
第十一步：前端控制器向用戶響應(yīng)結(jié)果
mvc是一種思想，可以理解成一種設(shè)計(jì)模式（設(shè)計(jì)模式就是日常開(kāi)發(fā)中編寫(xiě)代碼的一種好的方法和經(jīng)驗(yàn)的總結(jié)）。模型（model）-視圖（view）-控制器（controller），三層架構(gòu)的設(shè)計(jì)模式。用于實(shí)現(xiàn)前端頁(yè)面的展現(xiàn)與后端業(yè)務(wù)數(shù)據(jù)處理的分離。
mvc設(shè)計(jì)模式的好處
1.分層設(shè)計(jì)，實(shí)現(xiàn)了業(yè)務(wù)系統(tǒng)各個(gè)組件之間的解耦，有利于業(yè)務(wù)系統(tǒng)的可擴(kuò)展性，可維護(hù)性。
2.有利于系統(tǒng)的并行開(kāi)發(fā)，提升開(kāi)發(fā)效率。
@Controller：該注解用于控制層SpringMVC中的控制器
@RequestMapping：該注解用于url請(qǐng)求映射，可用于類或方法上。
@RequestBody：該注解實(shí)現(xiàn)接收http請(qǐng)求的json數(shù)據(jù)，將json轉(zhuǎn)換為java對(duì)象。
@ResponseBody：該注解實(shí)現(xiàn)將controller方法返回對(duì)象轉(zhuǎn)化為json對(duì)象響應(yīng)給客戶。
請(qǐng)求路徑上有個(gè)id的變量值，可以通過(guò)@PathVariable來(lái)獲取 @RequestMapping(value =“/page/{id}”, method = RequestMethod.GET)
@RequestParam用來(lái)獲得靜態(tài)的URL請(qǐng)求入?yún)?spring注解時(shí)action里用到。
是單例模式，在多線程訪問(wèn)的時(shí)候有線程安全問(wèn)題，解決方案是在控制器里面不能寫(xiě)可變狀態(tài)量，如果需要使用這些可變狀態(tài)，可以使用ThreadLocal機(jī)制解決，為每個(gè)線程單獨(dú)生成一份變量副本，獨(dú)立操作，互不影響。
可以將異常拋給Spring框架，由Spring框架來(lái)處理；我們只需要配置簡(jiǎn)單的異常處理器，在異常處理器中添視圖頁(yè)面即可。
相同點(diǎn)：都是基于mvc的表現(xiàn)層框架，都用于web項(xiàng)目的開(kāi)發(fā)。
不同點(diǎn)
1、前端控制器不一樣。Spring MVC的前端控制器是servlet：DispatcherServlet。struts2的前端控制器是filter：StrutsPreparedAndExcutorFilter。
2、請(qǐng)求參數(shù)的接收方式不一樣。Spring MVC是使用方法的形參接收請(qǐng)求的參數(shù)，基于方法的開(kāi)發(fā)，線程安全，可以設(shè)計(jì)為單例或者多例的開(kāi)發(fā)，推薦使用單例模式的開(kāi)發(fā)（執(zhí)行效率更高），默認(rèn)就是單例開(kāi)發(fā)模式。struts2是通過(guò)類的成員變量接收請(qǐng)求的參數(shù)，是基于類的開(kāi)發(fā)，線程不安全，只能設(shè)計(jì)為多例的開(kāi)發(fā)。
3、Struts采用值棧存儲(chǔ)請(qǐng)求和響應(yīng)的數(shù)據(jù)，通過(guò)OGNL存取數(shù)據(jù)，Spring MVC通過(guò)參數(shù)解析器是將request請(qǐng)求內(nèi)容解析，并給方法形參賦值，將數(shù)據(jù)和視圖封裝成ModelAndView對(duì)象，最后又將ModelAndView中的模型數(shù)據(jù)通過(guò)reques域傳輸?shù)巾?yè)面。Jsp視圖解析器默認(rèn)使用jstl。
4、與spring整合不一樣。Spring MVC是spring框架的一部分，不需要整合。在企業(yè)項(xiàng)目中，Spring MVC使用更多一些。
(1）轉(zhuǎn)發(fā)：在返回值前面加"forward:"，譬如"forward:user.do?name=method4"
(2）重定向：在返回值前面加"redirect:"，譬如"redirect:http://www.baidu.com"
SpringMVC的處理器攔截器,類似于Servlet開(kāi)發(fā)中的過(guò)濾器Filter，用于對(duì)處理器進(jìn)行預(yù)處理和后處理。
過(guò)濾器：依賴于servlet容器。在實(shí)現(xiàn)上基于函數(shù)回調(diào)，可以對(duì)幾乎所有請(qǐng)求進(jìn)行過(guò)濾，但是缺點(diǎn)是一個(gè)過(guò)濾器實(shí)例只能在容器初始化時(shí)調(diào)用一次。使用過(guò)濾器的目的是用來(lái)做一些過(guò)濾操作，比如：在過(guò)濾器中修改字符編碼；在過(guò)濾器中修改HttpServletRequest的一些參數(shù)，包括：過(guò)濾低俗文字、危險(xiǎn)字符等。
攔截器：依賴于web框架，在實(shí)現(xiàn)上基于Java的反射機(jī)制，屬于面向切面編程（AOP）的一種運(yùn)用。由于攔截器是基于web框架的調(diào)用，因此可以使用Spring的依賴注入（DI）進(jìn)行一些業(yè)務(wù)操作，同時(shí)一個(gè)攔截器實(shí)例在一個(gè)controller生命周期之內(nèi)可以多次調(diào)用。
通過(guò)ModelMap對(duì)象,可以在這個(gè)對(duì)象里面調(diào)用put方法,把對(duì)象加到里面,前臺(tái)就可以通過(guò)el表
達(dá)式拿到。
返回值可以有很多類型,有String, ModelAndView，但一般用String比較好。
通過(guò)Jackson框架就可以把Java里面的對(duì)象直接轉(zhuǎn)化成Js可以識(shí)別的Json對(duì)象。具體步驟如下 ：
(1)加入Jackson.jar
(2)在配置文件中配置json的映射
(3)在接受Ajax方法里面可以直接返回Object,List等,但方法前面要加上@ResponseBody注解。
京公網(wǎng)安備 11030102010736號(hào)