|
1、Spring是什么? Spring是一個輕量級的IoC和AOP容器框架。是為Java應(yīng)用程序提供基礎(chǔ)性服務(wù)的一套框架，目的是用于簡化企業(yè)應(yīng)用程序的開發(fā)，它使得開發(fā)者只需要關(guān)心業(yè)務(wù)需求。常見的配置方式有三種：基于XML的配置、基于注解的配置、基于Java的配置。 主要由以下幾個模塊組成： Spring Core：核心類庫，提供IOC服務(wù)； Spring Context：提供框架式的Bean訪問方式，以及企業(yè)級功能（JNDI、定時任務(wù)等）； Spring AOP：AOP服務(wù)； Spring DAO：對JDBC的抽象，簡化了數(shù)據(jù)訪問異常的處理； Spring ORM：對現(xiàn)有的ORM框架的支持； Spring Web：提供了基本的面向Web的綜合特性，例如多方文件上傳； Spring MVC：提供面向Web應(yīng)用的Model-View-Controller實(shí)現(xiàn)。 2、Spring 的優(yōu)點(diǎn)？ （1）spring屬于低侵入式設(shè)計，代碼的污染極低； （2）spring的DI機(jī)制將對象之間的依賴關(guān)系交由框架處理，減低組件的耦合性； （3）Spring提供了AOP技術(shù)，支持將一些通用任務(wù)，如安全、事務(wù)、日志、權(quán)限等進(jìn)行集中式管理，從而提供更好的復(fù)用。 （4）spring對于主流的應(yīng)用框架提供了集成支持。 3、Spring的AOP理解： OOP面向?qū)ο?，允許開發(fā)者定義縱向的關(guān)系，但并適用于定義橫向的關(guān)系，導(dǎo)致了大量代碼的重復(fù)，而不利于各個模塊的重用。 AOP，一般稱為面向切面，作為面向?qū)ο蟮囊环N補(bǔ)充，用于將那些與業(yè)務(wù)無關(guān)，但卻對多個對象產(chǎn)生影響的公共行為和邏輯，抽取并封裝為一個可重用的模塊，這個模塊被命名為“切面”（Aspect），減少系統(tǒng)中的重復(fù)代碼，降低了模塊間的耦合度，同時提高了系統(tǒng)的可維護(hù)性?？捎糜跈?quán)限認(rèn)證、日志、事務(wù)處理。 AOP實(shí)現(xiàn)的關(guān)鍵在于 代理模式，AOP代理主要分為靜態(tài)代理和動態(tài)代理。靜態(tài)代理的代表為AspectJ；動態(tài)代理則以Spring AOP為代表。 （1）AspectJ是靜態(tài)代理的增強(qiáng)，所謂靜態(tài)代理，就是AOP框架會在編譯階段生成AOP代理類，因此也稱為編譯時增強(qiáng)，他會在編譯階段將AspectJ(切面)織入到Java字節(jié)碼中，運(yùn)行的時候就是增強(qiáng)之后的AOP對象。 （2）Spring AOP使用的動態(tài)代理，所謂的動態(tài)代理就是說AOP框架不會去修改字節(jié)碼，而是每次運(yùn)行時在內(nèi)存中臨時為方法生成一個AOP對象，這個AOP對象包含了目標(biāo)對象的全部方法，并且在特定的切點(diǎn)做了增強(qiáng)處理，并回調(diào)原對象的方法。 Spring AOP中的動態(tài)代理主要有兩種方式，JDK動態(tài)代理和CGLIB動態(tài)代理： ①JDK動態(tài)代理只提供接口的代理，不支持類的代理。核心InvocationHandler接口和Proxy類，InvocationHandler 通過invoke()方法反射來調(diào)用目標(biāo)類中的代碼，動態(tài)地將橫切邏輯和業(yè)務(wù)編織在一起；接著，Proxy利用 InvocationHandler動態(tài)創(chuàng)建一個符合某一接口的的實(shí)例, 生成目標(biāo)類的代理對象。 ②如果代理類沒有實(shí)現(xiàn) InvocationHandler 接口，那么Spring AOP會選擇使用CGLIB來動態(tài)代理目標(biāo)類。CGLIB（Code Generation Library），是一個代碼生成的類庫，可以在運(yùn)行時動態(tài)的生成指定類的一個子類對象，并覆蓋其中特定方法并添加增強(qiáng)代碼，從而實(shí)現(xiàn)AOP。CGLIB是通過繼承的方式做的動態(tài)代理，因此如果某個類被標(biāo)記為final，那么它是無法使用CGLIB做動態(tài)代理的。 （3）靜態(tài)代理與動態(tài)代理區(qū)別在于生成AOP代理對象的時機(jī)不同，相對來說AspectJ的靜態(tài)代理方式具有更好的性能，但是AspectJ需要特定的編譯器進(jìn)行處理，而Spring AOP則無需特定的編譯器處理。 InvocationHandler 的 invoke(Object proxy,Method method,Object[] args)：proxy是最終生成的代理實(shí)例; method 是被代理目標(biāo)實(shí)例的某個具體方法; args 是被代理目標(biāo)實(shí)例某個方法的具體入?yún)? 在方法反射調(diào)用時使用。 4、Spring的IoC理解： （1）IOC就是控制反轉(zhuǎn)，是指創(chuàng)建對象的控制權(quán)的轉(zhuǎn)移，以前創(chuàng)建對象的主動權(quán)和時機(jī)是由自己把控的，而現(xiàn)在這種權(quán)力轉(zhuǎn)移到Spring容器中，并由容器根據(jù)配置文件去創(chuàng)建實(shí)例和管理各個實(shí)例之間的依賴關(guān)系，對象與對象之間松散耦合，也利于功能的復(fù)用。DI依賴注入，和控制反轉(zhuǎn)是同一個概念的不同角度的描述，即 應(yīng)用程序在運(yùn)行時依賴IoC容器來動態(tài)注入對象需要的外部資源。 （2）最直觀的表達(dá)就是，IOC讓對象的創(chuàng)建不用去new了，可以由spring自動生產(chǎn)，使用java的反射機(jī)制，根據(jù)配置文件在運(yùn)行時動態(tài)的去創(chuàng)建對象以及管理對象，并調(diào)用對象的方法的。 （3）Spring的IOC有三種注入方式 ：構(gòu)造器注入、setter方法注入、根據(jù)注解注入。 IoC讓相互協(xié)作的組件保持松散的耦合，而AOP編程允許你把遍布于應(yīng)用各層的功能分離出來形成可重用的功能組件。 5、BeanFactory和ApplicationContext有什么區(qū)別？ BeanFactory和ApplicationContext是Spring的兩大核心接口，都可以當(dāng)做Spring的容器。其中ApplicationContext是BeanFactory的子接口。 （1）BeanFactory：是Spring里面最底層的接口，包含了各種Bean的定義，讀取bean配置文檔，管理bean的加載、實(shí)例化，控制bean的生命周期，維護(hù)bean之間的依賴關(guān)系。ApplicationContext接口作為BeanFactory的派生，除了提供BeanFactory所具有的功能外，還提供了更完整的框架功能： ①繼承MessageSource，因此支持國際化。 ②統(tǒng)一的資源文件訪問方式。 ③提供在監(jiān)聽器中注冊bean的事件。 ④同時加載多個配置文件。 ⑤載入多個（有繼承關(guān)系）上下文 ，使得每一個上下文都專注于一個特定的層次，比如應(yīng)用的web層。 （2）①BeanFactroy采用的是延遲加載形式來注入Bean的，即只有在使用到某個Bean時(調(diào)用getBean())，才對該Bean進(jìn)行加載實(shí)例化。這樣，我們就不能發(fā)現(xiàn)一些存在的Spring的配置問題。如果Bean的某一個屬性沒有注入，BeanFacotry加載后，直至第一次使用調(diào)用getBean方法才會拋出異常。 ②ApplicationContext，它是在容器啟動時，一次性創(chuàng)建了所有的Bean。這樣，在容器啟動時，我們就可以發(fā)現(xiàn)Spring中存在的配置錯誤，這樣有利于檢查所依賴屬性是否注入。 ApplicationContext啟動后預(yù)載入所有的單實(shí)例Bean，通過預(yù)載入單實(shí)例bean ,確保當(dāng)你需要的時候，你就不用等待，因?yàn)樗鼈円呀?jīng)創(chuàng)建好了。 ③相對于基本的BeanFactory，ApplicationContext 唯一的不足是占用內(nèi)存空間。當(dāng)應(yīng)用程序配置Bean較多時，程序啟動較慢。 （3）BeanFactory通常以編程的方式被創(chuàng)建，ApplicationContext還能以聲明的方式創(chuàng)建，如使用ContextLoader。 （4）BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但兩者之間的區(qū)別是：BeanFactory需要手動注冊，而ApplicationContext則是自動注冊。 6、請解釋Spring Bean的生命周期？ 首先說一下Servlet的生命周期：實(shí)例化，初始init，接收請求service，銷毀destroy； Spring上下文中的Bean生命周期也類似，如下： （1）實(shí)例化Bean： 對于BeanFactory容器，當(dāng)客戶向容器請求一個尚未初始化的bean時，或初始化bean的時候需要注入另一個尚未初始化的依賴時，容器就會調(diào)用createBean進(jìn)行實(shí)例化。對于ApplicationContext容器，當(dāng)容器啟動結(jié)束后，通過獲取BeanDefinition對象中的信息，實(shí)例化所有的bean。 （2）設(shè)置對象屬性（依賴注入）： 實(shí)例化后的對象被封裝在BeanWrapper對象中，緊接著，Spring根據(jù)BeanDefinition中的信息 以及 通過BeanWrapper提供的設(shè)置屬性的接口完成依賴注入。 （3）處理Aware接口： 接著，Spring會檢測該對象是否實(shí)現(xiàn)了xxxAware接口，并將相關(guān)的xxxAware實(shí)例注入給Bean： ①如果這個Bean已經(jīng)實(shí)現(xiàn)了BeanNameAware接口，會調(diào)用它實(shí)現(xiàn)的setBeanName(String beanId)方法，此處傳遞的就是Spring配置文件中Bean的id值； ②如果這個Bean已經(jīng)實(shí)現(xiàn)了BeanFactoryAware接口，會調(diào)用它實(shí)現(xiàn)的setBeanFactory()方法，傳遞的是Spring工廠自身。 ③如果這個Bean已經(jīng)實(shí)現(xiàn)了ApplicationContextAware接口，會調(diào)用setApplicationContext(ApplicationContext)方法，傳入Spring上下文； （4）BeanPostProcessor： 如果想對Bean進(jìn)行一些自定義的處理，那么可以讓Bean實(shí)現(xiàn)了BeanPostProcessor接口，那將會調(diào)用postProcessBeforeInitialization(Object obj, String s)方法。由于這個方法是在Bean初始化結(jié)束時調(diào)用的，所以可以被應(yīng)用于內(nèi)存或緩存技術(shù)； （5）InitializingBean 與 init-method： 如果Bean在Spring配置文件中配置了 init-method 屬性，則會自動調(diào)用其配置的初始化方法。 （6）如果這個Bean實(shí)現(xiàn)了BeanPostProcessor接口，將會調(diào)用postProcessAfterInitialization(Object obj, String s)方法； 以上幾個步驟完成后，Bean就已經(jīng)被正確創(chuàng)建了，之后就可以使用這個Bean了。 （7）DisposableBean： 當(dāng)Bean不再需要時，會經(jīng)過清理階段，如果Bean實(shí)現(xiàn)了DisposableBean這個接口，會調(diào)用其實(shí)現(xiàn)的destroy()方法； （8）destroy-method： 最后，如果這個Bean的Spring配置中配置了destroy-method屬性，會自動調(diào)用其配置的銷毀方法。 7、 解釋Spring支持的幾種bean的作用域。 Spring容器中的bean可以分為5個范圍： （1）singleton：默認(rèn)，每個容器中只有一個bean的實(shí)例，單例的模式由BeanFactory自身來維護(hù)。 （2）prototype：為每一個bean請求提供一個實(shí)例。 （3）request：為每一個網(wǎng)絡(luò)請求創(chuàng)建一個實(shí)例，在請求完成以后，bean會失效并被垃圾回收器回收。 （4）session：與request范圍類似，確保每個session中有一個bean的實(shí)例，在session過期后，bean會隨之失效。 （5）global-session：全局作用域，global-session和Portlet應(yīng)用相關(guān)。當(dāng)你的應(yīng)用部署在Portlet容器中工作時，它包含很多portlet。如果你想要聲明讓所有的portlet共用全局的存儲變量的話，那么這全局變量需要存儲在global-session中。全局作用域與Servlet中的session作用域效果相同。 8、Spring框架中的單例Beans是線程安全的么？ Spring框架并沒有對單例bean進(jìn)行任何多線程的封裝處理。關(guān)于單例bean的線程安全和并發(fā)問題需要開發(fā)者自行去搞定。但實(shí)際上，大部分的Spring bean并沒有可變的狀態(tài)(比如Serview類和DAO類)，所以在某種程度上說Spring的單例bean是線程安全的。如果你的bean有多種狀態(tài)的話（比如 View Model 對象），就需要自行保證線程安全。最淺顯的解決辦法就是將多態(tài)bean的作用域由“singleton”變更為“prototype”。 9、Spring如何處理線程并發(fā)問題？ 在一般情況下，只有無狀態(tài)的Bean才可以在多線程環(huán)境下共享，在Spring中，絕大部分Bean都可以聲明為singleton作用域，因?yàn)镾pring對一些Bean中非線程安全狀態(tài)采用ThreadLocal進(jìn)行處理，解決線程安全問題。 ThreadLocal和線程同步機(jī)制都是為了解決多線程中相同變量的訪問沖突問題。同步機(jī)制采用了“時間換空間”的方式，僅提供一份變量，不同的線程在訪問前需要獲取鎖，沒獲得鎖的線程則需要排隊(duì)。而ThreadLocal采用了“空間換時間”的方式。 ThreadLocal會為每一個線程提供一個獨(dú)立的變量副本，從而隔離了多個線程對數(shù)據(jù)的訪問沖突。因?yàn)槊恳粋€線程都擁有自己的變量副本，從而也就沒有必要對該變量進(jìn)行同步了。ThreadLocal提供了線程安全的共享對象，在編寫多線程代碼時，可以把不安全的變量封裝進(jìn)ThreadLocal。 10、Spring的自動裝配： 在spring中，對象無需自己查找或創(chuàng)建與其關(guān)聯(lián)的其他對象，由容器負(fù)責(zé)把需要相互協(xié)作的對象引用賦予各個對象，使用autowire來配置自動裝載模式。 在Spring框架xml配置中共有5種自動裝配： （1）no：默認(rèn)的方式是不進(jìn)行自動裝配的，通過手工設(shè)置ref屬性來進(jìn)行裝配bean。 （2）byName：通過bean的名稱進(jìn)行自動裝配，如果一個bean的 property 與另一bean 的name 相同，就進(jìn)行自動裝配。 （3）byType：通過參數(shù)的數(shù)據(jù)類型進(jìn)行自動裝配。 （4）constructor：利用構(gòu)造函數(shù)進(jìn)行裝配，并且構(gòu)造函數(shù)的參數(shù)通過byType進(jìn)行裝配。 （5）autodetect：自動探測，如果有構(gòu)造方法，通過 construct的方式自動裝配，否則使用 byType的方式自動裝配。 基于注解的方式： 使用@Autowired注解來自動裝配指定的bean。在使用@Autowired注解之前需要在Spring配置文件進(jìn)行配置，<context:annotation-config />。在啟動spring IoC時，容器自動裝載了一個AutowiredAnnotationBeanPostProcessor后置處理器，當(dāng)容器掃描到@Autowied、@Resource或@Inject時，就會在IoC容器自動查找需要的bean，并裝配給該對象的屬性。在使用@Autowired時，首先在容器中查詢對應(yīng)類型的bean： 如果查詢結(jié)果剛好為一個，就將該bean裝配給@Autowired指定的數(shù)據(jù)； 如果查詢的結(jié)果不止一個，那么@Autowired會根據(jù)名稱來查找； 如果上述查找的結(jié)果為空，那么會拋出異常。解決方法時，使用required=false。 @Autowired可用于：構(gòu)造函數(shù)、成員變量、Setter方法 注：@Autowired和@Resource之間的區(qū)別 (1) @Autowired默認(rèn)是按照類型裝配注入的，默認(rèn)情況下它要求依賴對象必須存在（可以設(shè)置它required屬性為false）。 (2) @Resource默認(rèn)是按照名稱來裝配注入的，只有當(dāng)找不到與名稱匹配的bean才會按照類型來裝配注入。 11、Spring 框架中都用到了哪些設(shè)計模式？ （1）工廠模式：BeanFactory就是簡單工廠模式的體現(xiàn)，用來創(chuàng)建對象的實(shí)例； （2）單例模式：Bean默認(rèn)為單例模式。 （3）代理模式：Spring的AOP功能用到了JDK的動態(tài)代理和CGLIB字節(jié)碼生成技術(shù)； （4）模板方法：用來解決代碼重復(fù)的問題。比如. RestTemplate, JmsTemplate, JpaTemplate。 （5）觀察者模式：定義對象鍵一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都會得到通知被制動更新，如Spring中l(wèi)istener的實(shí)現(xiàn)--ApplicationListener。 12、Spring事務(wù)的實(shí)現(xiàn)方式和實(shí)現(xiàn)原理： Spring事務(wù)的本質(zhì)其實(shí)就是數(shù)據(jù)庫對事務(wù)的支持，沒有數(shù)據(jù)庫的事務(wù)支持，spring是無法提供事務(wù)功能的。真正的數(shù)據(jù)庫層的事務(wù)提交和回滾是通過binlog或者redo log實(shí)現(xiàn)的。 （1）Spring事務(wù)的種類： spring支持編程式事務(wù)管理和聲明式事務(wù)管理兩種方式： ①編程式事務(wù)管理使用TransactionTemplate。 ②聲明式事務(wù)管理建立在AOP之上的。其本質(zhì)是通過AOP功能，對方法前后進(jìn)行攔截，將事務(wù)處理的功能編織到攔截的方法中，也就是在目標(biāo)方法開始之前加入一個事務(wù)，在執(zhí)行完目標(biāo)方法之后根據(jù)執(zhí)行情況提交或者回滾事務(wù)。 聲明式事務(wù)最大的優(yōu)點(diǎn)就是不需要在業(yè)務(wù)邏輯代碼中摻雜事務(wù)管理的代碼，只需在配置文件中做相關(guān)的事務(wù)規(guī)則聲明或通過@Transactional注解的方式，便可以將事務(wù)規(guī)則應(yīng)用到業(yè)務(wù)邏輯中。 聲明式事務(wù)管理要優(yōu)于編程式事務(wù)管理，這正是spring倡導(dǎo)的非侵入式的開發(fā)方式，使業(yè)務(wù)代碼不受污染，只要加上注解就可以獲得完全的事務(wù)支持。唯一不足地方是，最細(xì)粒度只能作用到方法級別，無法做到像編程式事務(wù)那樣可以作用到代碼塊級別。 （2）spring的事務(wù)傳播行為： spring事務(wù)的傳播行為說的是，當(dāng)多個事務(wù)同時存在的時候，spring如何處理這些事務(wù)的行為。 ① PROPAGATION_REQUIRED：如果當(dāng)前沒有事務(wù)，就創(chuàng)建一個新事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，該設(shè)置是最常用的設(shè)置。 ② PROPAGATION_SUPPORTS：支持當(dāng)前事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，如果當(dāng)前不存在事務(wù)，就以非事務(wù)執(zhí)行。‘ ③ PROPAGATION_MANDATORY：支持當(dāng)前事務(wù)，如果當(dāng)前存在事務(wù)，就加入該事務(wù)，如果當(dāng)前不存在事務(wù)，就拋出異常。 ④ PROPAGATION_REQUIRES_NEW：創(chuàng)建新事務(wù)，無論當(dāng)前存不存在事務(wù)，都創(chuàng)建新事務(wù)。 ⑤ PROPAGATION_NOT_SUPPORTED：以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。 ⑥ PROPAGATION_NEVER：以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。 ⑦ PROPAGATION_NESTED：如果當(dāng)前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行。如果當(dāng)前沒有事務(wù)，則按REQUIRED屬性執(zhí)行。 （3）Spring中的隔離級別： ① ISOLATION_DEFAULT：這是個 PlatfromTransactionManager 默認(rèn)的隔離級別，使用數(shù)據(jù)庫默認(rèn)的事務(wù)隔離級別。 ② ISOLATION_READ_UNCOMMITTED：讀未提交，允許另外一個事務(wù)可以看到這個事務(wù)未提交的數(shù)據(jù)。 ③ ISOLATION_READ_COMMITTED：讀已提交，保證一個事務(wù)修改的數(shù)據(jù)提交后才能被另一事務(wù)讀取，而且能看到該事務(wù)對已有記錄的更新。 ④ ISOLATION_REPEATABLE_READ：可重復(fù)讀，保證一個事務(wù)修改的數(shù)據(jù)提交后才能被另一事務(wù)讀取，但是不能看到該事務(wù)對已有記錄的更新。 ⑤ ISOLATION_SERIALIZABLE：一個事務(wù)在執(zhí)行的過程中完全看不到其他事務(wù)對數(shù)據(jù)庫所做的更新。 13、Spring框架中有哪些不同類型的事件？ Spring 提供了以下5種標(biāo)準(zhǔn)的事件： （1）上下文更新事件（ContextRefreshedEvent）：在調(diào)用ConfigurableApplicationContext 接口中的refresh()方法時被觸發(fā)。 （2）上下文開始事件（ContextStartedEvent）：當(dāng)容器調(diào)用ConfigurableApplicationContext的Start()方法開始/重新開始容器時觸發(fā)該事件。 （3）上下文停止事件（ContextStoppedEvent）：當(dāng)容器調(diào)用ConfigurableApplicationContext的Stop()方法停止容器時觸發(fā)該事件。 （4）上下文關(guān)閉事件（ContextClosedEvent）：當(dāng)ApplicationContext被關(guān)閉時觸發(fā)該事件。容器被關(guān)閉時，其管理的所有單例Bean都被銷毀。 （5）請求處理事件（RequestHandledEvent）：在Web應(yīng)用中，當(dāng)一個http請求（request）結(jié)束觸發(fā)該事件。 如果一個bean實(shí)現(xiàn)了ApplicationListener接口，當(dāng)一個ApplicationEvent 被發(fā)布以后，bean會自動被通知。 14、解釋一下Spring AOP里面的幾個名詞： （1）切面（Aspect）：被抽取的公共模塊，可能會橫切多個對象。 在Spring AOP中，切面可以使用通用類（基于模式的風(fēng)格） 或者在普通類中以 @AspectJ 注解來實(shí)現(xiàn)。 （2）連接點(diǎn)（Join point）：指方法，在Spring AOP中，一個連接點(diǎn) 總是 代表一個方法的執(zhí)行。 （3）通知（Advice）：在切面的某個特定的連接點(diǎn)（Join point）上執(zhí)行的動作。通知有各種類型，其中包括“around”、“before”和“after”等通知。許多AOP框架，包括Spring，都是以攔截器做通知模型， 并維護(hù)一個以連接點(diǎn)為中心的攔截器鏈。 （4）切入點(diǎn)（Pointcut）：切入點(diǎn)是指 我們要對哪些Join point進(jìn)行攔截的定義。通過切入點(diǎn)表達(dá)式，指定攔截的方法，比如指定攔截add*、search*。 （5）引入（Introduction）：（也被稱為內(nèi)部類型聲明（inter-type declaration））。聲明額外的方法或者某個類型的字段。Spring允許引入新的接口（以及一個對應(yīng)的實(shí)現(xiàn)）到任何被代理的對象。例如，你可以使用一個引入來使bean實(shí)現(xiàn) IsModified 接口，以便簡化緩存機(jī)制。 （6）目標(biāo)對象（Target Object）： 被一個或者多個切面（aspect）所通知（advise）的對象。也有人把它叫做 被通知（adviced） 對象。 既然Spring AOP是通過運(yùn)行時代理實(shí)現(xiàn)的，這個對象永遠(yuǎn)是一個 被代理（proxied） 對象。 （7）織入（Weaving）：指把增強(qiáng)應(yīng)用到目標(biāo)對象來創(chuàng)建新的代理對象的過程。Spring是在運(yùn)行時完成織入。 切入點(diǎn)（pointcut）和連接點(diǎn)（join point）匹配的概念是AOP的關(guān)鍵，這使得AOP不同于其它僅僅提供攔截功能的舊技術(shù)。 切入點(diǎn)使得定位通知（advice）可獨(dú)立于OO層次。 例如，一個提供聲明式事務(wù)管理的around通知可以被應(yīng)用到一組橫跨多個對象中的方法上（例如服務(wù)層的所有業(yè)務(wù)操作）。 15、Spring通知有哪些類型？ https://blog.csdn.net/qq_32331073/article/details/80596084 （1）前置通知（Before advice）：在某連接點(diǎn)（join point）之前執(zhí)行的通知，但這個通知不能阻止連接點(diǎn)前的執(zhí)行（除非它拋出一個異常）。 （2）返回后通知（After returning advice）：在某連接點(diǎn)（join point）正常完成后執(zhí)行的通知：例如，一個方法沒有拋出任何異常，正常返回。 （3）拋出異常后通知（After throwing advice）：在方法拋出異常退出時執(zhí)行的通知。 （4）后通知（After (finally) advice）：當(dāng)某連接點(diǎn)退出的時候執(zhí)行的通知（不論是正常返回還是異常退出）。 （5）環(huán)繞通知（Around Advice）：包圍一個連接點(diǎn)（join point）的通知，如方法調(diào)用。這是最強(qiáng)大的一種通知類型。 環(huán)繞通知可以在方法調(diào)用前后完成自定義的行為。它也會選擇是否繼續(xù)執(zhí)行連接點(diǎn)或直接返回它們自己的返回值或拋出異常來結(jié)束執(zhí)行。 環(huán)繞通知是最常用的一種通知類型。大部分基于攔截的AOP框架，例如Nanning和JBoss4，都只提供環(huán)繞通知。 同一個aspect，不同advice的執(zhí)行順序： ①沒有異常情況下的執(zhí)行順序： around before advice before advice target method 執(zhí)行 around after advice after advice afterReturning ②有異常情況下的執(zhí)行順序： around before advice before advice target method 執(zhí)行 around after advice after advice afterThrowing:異常發(fā)生 java.lang.RuntimeException: 異常發(fā)生 --------------------- 作者：a745233700 來源：CSDN 原文：https://blog.csdn.net/a745233700/article/details/80959716 版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！ |
|
|
