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，稱為面向切面編程，用于將那些與業務無關，但卻對多個對象產生影響的公共行為和邏輯，抽取并封裝為一個可重用的模塊，減少系統中的重復代碼，降低了模塊間的耦合度，提高系統的可維護性。可用于權限認證、日志、事務處理。
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 啟動效率低。
官方微信
官方抖音
京公網安備 11030102010736號