Spring篇
Spring
目錄
1.1.14-ApplicationContext的加載方式
1.1.16-Spring 基於 xml 注入 bean 4種方式
1.1.19-@Autowired註解和@Resource的區別
1.1.1-什麼是框架
在我看來的話,框架可能會更加的像一個通用的工具,它可以直接拿來使用簡化我們一些結構,步驟,我們可以更具自己項目的拓展添加更多的組成部分,更加快速的提高生產力
例如我們需要做飯,首先要有材米油鹽,框架就像是把材米油鹽打包成了一個工具箱,我們每次做飯的時候就不用到超時購買,可以直接打開這個工具箱,獲取到需要的材料
1.1.2-什麼是Spring
Spring 是一個輕量級的 IoC 和 AOP 容器框架。是爲 Java 應用程序提供基礎性服務的一套框架,目的是用於簡化企業應用程序的開發,它使得開發者只需要關心業務需求。常見的配置方式有三種:基於 XML 的配置、基於註解的配置、基於 Java 的配置。
主要模塊:
-
Spring Core:核心類庫,提供 IOC 服務;
-
Spring Context:提供框架式的 Bean 訪問方式,以及企業級功能(JNDI、定時任務等);
-
Spring AOP:提供AOP 服務;
-
Spring DAO:對 JDBC 的抽象,簡化了數據訪問異常的處理;
-
Spring ORM:對現有的 ORM 框架的支持;
-
Spring Web:提供了基本的面向 Web 的綜合特性,例如多方文件上傳;
-
Spring MVC:提供面向 Web 應用的 Model-View-Controller 實現。
1.1.3-Spring-IOC
Ioc就是指的控制反轉,將創建對象的控制權轉移,我們之前創建一個對象的時候都是由自己去new一個對象的,完全是自己去把控,有了Spring之後,就可以交給Spring進行控制管理,同時解除了接口和實現的耦合性。
核心原理:配置文件+反射(工廠也可以)+容器
DI 依賴注入,和控制反轉是同一個概念的不同角度的描述,即 應用程序在運行時依賴 IoC 容器來動態注入對象需要的外部資源。
1.1.4-DI依賴注入
和控制反轉是同一個概念的不同角度的描述,即應用程序在運行時依賴 IoC 容器來動態注入對象需要的外部資源。
1.1.5-Spring 的 IOC 有三種注入方式
- 構造器注入
- setter 方法注入
- 註解注入
1.1.6-Spring-AOP
AOP是面向切面,作爲面向對象的一種補充。主要適用於和一些業務無關但是對多個對象產生影響的公共行爲和邏輯,封裝成一個可以重複利用的模塊,這個模塊被稱爲切面。一般用於權限處理,權限判斷,日誌,事務等非主要業務邏輯的事情。
1.1.7-AOP術語
-
連接點( Joinpoint ):可以被增強的方法都可以成爲連接點
-
切點( Pointcut ):真正被攔截到的點
-
增強( Advice ):攔截後要做的事情,對方法增加權限的校驗等
-
目標對象(Target):要被增強的對象
-
引介(Introduction)
-
織入(Weaving):指advice應用到target的過程
-
代理(Proxy)
-
切面(Aspect)
博主之前寫過的文章,有對AOP術語詳細的介紹:AOP
1.1.8-AOP的底層
底層是採用JDK動態代理和CGLIB動態代理實現的
博主之前寫過的文章,有對AOP術語詳細的介紹:AOP
1.1.9-Spring 的兩大核心
- IOC
- AOP
1.1.10-Spring 的兩大核心接口
- BeanFactory
- ApplicationContext
ApplicationContext 是 BeanFactory 的子接口
1.1.11-BeanFactory的功能
BeanFactory是Spring最底層的接口,包含了各種各樣的Bean,包括bean的配置,管理bean的加載,實例化,控制,生命週期等,同時還維護着bean直接的依賴關係。
1.1.12-BeanFactory的加載方式
BeanFactroy 採用的是延遲加載形式來注入 Bean 的,當我們要使用某一個Bean的時候,需要調用getBean方法來加載實例化,通常以變成的方式創建。
更多BeanFactory加載可以參考:https://my.oschina.net/chengxiaoyuan/blog/803213
1.1.13-ApplicationContext的功能
作爲 BeanFactory的派生類,在BeanFactory原有的功能外,更是提供了更加完整的功能,比如繼承 MessageSource,統一的資源文件訪問方式,提供在監聽器中註冊 bean 的事件,同時加載多個配置文件等,載入多個上下文
1.1.14-ApplicationContext的加載方式
容器一經啓動,就會創建所有的Bean。啓動時就可以直觀的發現Spring配置文件中的錯誤,有利於檢查依賴屬性是否注入。但是ApplicationContext會比較佔用空間。
1.1.15-Bean的作用域
singleton
使用該屬性定義Bean時,IOC容器僅創建一個Bean實例,IOC容器每次返回的是同一個Bean實例。
prototype
使用該屬性定義Bean時,IOC容器可以創建多個Bean實例,每次返回的都是一個新的實例。
request
該屬性僅對HTTP請求產生作用,使用該屬性定義Bean時,每次HTTP請求都會創建一個新的Bean,適用於WebApplicationContext環境。
session
該屬性僅用於HTTP Session,同一個Session共享一個Bean實例。不同Session使用不同的實例。
global-session
該屬性僅用於HTTP Session,同session作用域不同的是,所有的Session共享一個Bean實例。
更多作用域問題參考:理解Spring框架中Bean的作用域
1.1.16-Spring 基於 xml 注入 bean 4種方式
-
Set 方法注入
-
構造器注入
-
靜態工廠注入
-
實例工廠
1.1.17-Spring 的自動裝配
在 Spring 框架 xml 配置中共有 5 種自動裝配:
- no:默認的方式是不進行自動裝配的,通過手寫xml設置 ref 屬性來進行裝配 bean。
- byName:按bean名稱自動裝配
- byType:通過參數的數據類型進行自動裝配。
- constructor:利用構造函數進行裝配,並且構造函數的參數通過 byType 進行裝配。
- autodetect:首先會嘗試使用constructor進行自動裝配,如果失敗再嘗試使用byType。
自動裝配詳細參考:徹底搞明白Spring中的自動裝配和Autowired
1.1.18-@Autowired註解是什麼?
Spring管理的Bean對象可以採用自動裝配機制爲屬性賦值。基於註解方式進行自動裝配,一般使用@Autowired,@Qualifer,@Resource這些註解。
1.1.19-@Autowired註解和@Resource的區別
@Autowired:默認按類型裝配,默認情況下必須要求依賴對象存在,如果要允許null值,可以設置它的required屬性爲false。如果想使用名稱裝配可以結合@Qualifier註解進行使用。
@Resource:默認按照名稱進行裝配,名稱可以通過name屬性進行指定,如果沒有指定name屬性,當註解寫在字段上時,默認取字段名進行名稱查找。如果註解寫在setter方法上默認取屬性名進行裝配。當找不到與名稱匹配的bean時才按照類型進行裝配。但是需要注意的是,如果name屬性一旦指定,就只會按照名稱進行裝配。
區別詳細參考:@Autowired註解和@Resource的區別
1.1.20-Spring所用到的設計模式
-
工廠模式:BeanFactory 就是簡單工廠模式的體現,用來創建對象的實例
-
單例模式:Bean 默認爲單例模式
-
代理模式:Spring 的 AOP 功能用到了 JDK 的動態代理和 CGLIB 字節碼生成技術
-
模板方法:用來解決代碼重複的問題。比如. RestTemplate, JmsTemplate, JpaTemplate
1.1.21-Spring事務傳播行爲
百度圖片:
propagation_Required:需要 如果需要存在一個事務,則支持當前事務,如果沒有事務則開啓
propagation_Supports:支持 如果存在一個十五,支持當前事務,如果沒有食物,則非事務執行
propagation_Mandatory:必須 如果已經存在一個事務,支持當前事務,如果沒有一個活動的事務,則 拋出異常
propagation_Required_new:總是開啓一個新的事務,如果一個事務已經存在,則將這個存在的事務掛起
propagation_Not_supports:總是非事務地執行,並掛起任何存在的事務
propagation_Never:絕不 總是非事務執行,如果存在一個活動事務,則拋出異常
propagation_Nested:嵌套的 如果有就嵌套,沒有就開啓事務
1.1.22-Spring事務的特徵
Spring的事務特徵類似於MySQL的基本特徵
原子性(Atomicity)
- 所有操作要麼全部成功,要麼全部失敗回滾
一致性(Consistency)
- 要麼成功,要們失敗,失敗了要對前面的操作進行回滾,要保持一致
隔離性(Isolation)
- 多個用戶併發訪問數據庫時,比如操作同一張表時,數據庫爲每一個用戶開啓的事務,事務開始後,不能背其他的事務干擾
持久性(Durability)
- 持久性是指一個事務一旦被提交了,那麼對數據庫中的數據的改變就是永久性的,即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。
1.1.23-髒讀,幻讀,不可重複讀的問題
出現髒讀,幻讀,不可重複讀是事務可能會產生的問題
- 髒讀:髒讀是指當一個事務正在訪問數據,並且對數據進行了修改。而這種修改還沒有提交到數據庫中,這時,另外一個事務也訪問了這個數據,然後使用了這個數據。(準備數據回滾了,讀取了提交的數據)
- 幻讀:幻讀是指當事務不是獨立執行時發生的一種現象,例如第一個事務對一個表中的數據進行了修改,這種修改涉及到了表中的全部數據行。同時,第二個事務也修改了這個表中的數據,這種修改是向表中插入一行新數據。那麼,以後就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行,就好像發生了幻覺一樣。(讀取了修改前的數據)
- 不可重複讀:一個事務多次讀取同一數據,事務 B 在事務A多次讀取的過程中,對數據作了更新並提交,導致事務A每次讀取同一數據時,結果不一致。(讀取了插入前的數據)
1.1.24-Spring事務的隔離級別
Spring的隔離級別類似於MySQL的隔離級別
-
read uncommitted(讀未提交數據):允許事務讀取未被其他事務提交的變更數據,會出現髒讀、不可重複讀和幻讀問題。
-
read committed(讀已提交數據):允許事務讀取已經被其他事務提交的變更數據,可避免髒讀,仍會出現不可重複讀和幻讀問題。
-
repeatable read(可重複讀):確保事務可以多次從一個字段中讀取相同的值,在此事務持續期間,禁止其他事務對此字段的更新,可以避免髒讀和不可重複讀,仍會出現幻讀問題。
-
serializable(序列化):確保事務可以從一個表中讀取相同的行,在這個事務持續期間,禁止其他事務對該表執行插入、更新和刪除操作,可避免所有併發問題,性能會非常低。
1.1.25-Spring 框架中不同類型的事件
-
上下文更新事件(ContextRefreshedEvent):在調用ConfigurableApplicationContext 接口中的refresh()方法時被觸發。
-
上下文開始事件(ContextStartedEvent):當容器調用ConfigurableApplicationContext的Start()方法開始/重新開始容器時觸發該事件。
-
上下文停止事件(ContextStoppedEvent):當容器調用ConfigurableApplicationContext的Stop()方法停止容器時觸發該事件。
-
上下文關閉事件(ContextClosedEvent):當ApplicationContext被關閉時觸發該事件。容器被關閉時,其管理的所有單例Bean都被銷燬。
-
請求處理事件(RequestHandledEvent):在Web應用中,當一個http請求(request)結束觸發該事件
1.1.26-Spring的通知類型
1、前置通知org.springframework.aop.MethodBeforeAdvice
在目標方法執行前實施增強
2、後置通知org.springframework.aop.AfterReturningAdvice
在目標方法執行後實施增強
3、環繞通知org.aopalliance.intercept.MethodInterceptor
在目標方法執行前後實施增強
4、異常拋出通知org.springframework.aop.ThrowsAdvice
在方法拋出異常後實施增強
5、最終通知
目標方法執行之後執行的通知
詳細參考本人之前寫過的一篇文章,寫的不好請見諒:之前寫的文章AOP增強
1.1.27-Spring實現事務控制的兩種方式
聲明式事務和編程式事務
聲明式事務:用配置文件的方法或註解方法控制事務,其中包括了很多聲明屬性,它是通過AOP
實現的,自己不用額外的寫代碼,只要在Spring
配置文件中聲明即可;通常用在數據庫的操作裏面;
編程式事務:就是指通過手寫代碼的方式做事務處理,這種處理方式需要寫代碼,事務中的邏輯可以自己定製;可以是數據庫的操作,也可以是其他的操作。
聲明式事務管理也有兩種常用的方式,一種是基於tx和aop名字空間的xml配置文件,另一種就是基於@Transactional註解