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