javascript
Spring全家桶面试真题
文章目錄
- 1. Spring Boot
- 1.1 說說你對Spring Boot的理解
- 1.2 Spring Boot Starter有什么用？
- 1.3 介紹Spring Boot的啟動流程
- 1.4 Spring Boot項(xiàng)目是如何導(dǎo)入包的？
- 1.5 請描述Spring Boot自動裝配的過程
- 1.6 說說你對Spring Boot注解的了解
- 2. Spring
- 2.1 請你說說Spring的核心是什么
- 2.2 說一說你對Spring容器的了解
- 2.3 說一說你對BeanFactory的了解
- 2.4 說一說你對Spring IOC的理解
- 2.5 Spring是如何管理Bean的？
- 2.6 介紹Bean的作用域
- 2.7 說一說Bean的生命周期
- 2.8 Spring是怎么解決循環(huán)依賴的？
- 2.9 @Autowired和@Resource注解有什么區(qū)別？
- 2.10 Spring中默認(rèn)提供的單例是線程安全的嗎？
- 2.11 說一說你對Spring AOP的理解
- 2.12 請你說說AOP的應(yīng)用場景
- 2.13 Spring AOP不能對哪些類進(jìn)行增強(qiáng)？
- 2.14 JDK動態(tài)代理和CGLIB有什么區(qū)別？
- 2.15 既然有沒有接口都可以用CGLIB，為什么Spring還要使用JDK動態(tài)代理？
- 2.16 Spring如何管理事務(wù)？
- 2.17 Spring的事務(wù)傳播方式有哪些？
- 2.18 Spring的事務(wù)如何配置，常用注解有哪些？
- 2.19 說一說你對聲明式事務(wù)的理解
- 3. Spring MVC
- 3.1 什么是MVC？
- 3.2 DAO層是做什么的？
- 3.3 介紹一下Spring MVC的執(zhí)行流程
- 3.4 說一說你知道的Spring MVC注解
- 3.5 介紹一下Spring MVC的攔截器
- 3.6 怎么去做請求攔截？
- 4. MyBatis
- 4.1 談?wù)凪yBatis和JPA的區(qū)別
- 4.2 MyBatis輸入輸出支持的類型有哪些？
- 4.3 MyBatis里如何實(shí)現(xiàn)一對多關(guān)聯(lián)查詢？
- 4.4 MyBatis中的$和#有什么區(qū)別？
- 4.5 既然不安全，為什么還需要？什么時(shí)候會用到它？
- 4.6 MyBatis的xml文件和Mapper接口是怎么綁定的？
- 4.7 MyBatis分頁和自己寫的分頁哪個(gè)效率高？
- 4.8 了解MyBatis緩存機(jī)制嗎？
- 5. 其他
- 5.1 cookie和session的區(qū)別是什么？
- 5.2 cookie和session各自適合的場景是什么？
- 5.3 請介紹session的工作原理
- 5.4 get請求與post請求有什么區(qū)別？
- 5.5 get請求的參數(shù)能放到body里面嗎？
- 5.6 post不冪等是為什么？
- 5.7 頁面報(bào)400錯誤是什么意思？
- 5.8 請求數(shù)據(jù)出現(xiàn)亂碼該怎么處理？
- 5.9 如何在SpringBoot框架下實(shí)現(xiàn)一個(gè)定時(shí)任務(wù)？
- 5.10 調(diào)用接口時(shí)要記錄日志，該怎么設(shè)計(jì)？
- 5.11 了解Spring Boot JPA嗎？
- 5.7 頁面報(bào)400錯誤是什么意思？
- 5.8 請求數(shù)據(jù)出現(xiàn)亂碼該怎么處理？
- 5.9 如何在SpringBoot框架下實(shí)現(xiàn)一個(gè)定時(shí)任務(wù)？
- 5.10 調(diào)用接口時(shí)要記錄日志，該怎么設(shè)計(jì)？
- 5.11 了解Spring Boot JPA嗎？
1. Spring Boot
1.1 說說你對Spring Boot的理解
參考答案
從本質(zhì)上來說，Spring Boot就是Spring，它做了那些沒有它你自己也會去做的Spring Bean配置。Spring Boot使用“習(xí)慣優(yōu)于配置”的理念讓你的項(xiàng)目快速地運(yùn)行起來，使用Spring Boot很容易創(chuàng)建一個(gè)能獨(dú)立運(yùn)行、準(zhǔn)生產(chǎn)級別、基于Spring框架的項(xiàng)目，使用Spring Boot你可以不用或者只需要很少的Spring配置。
簡而言之，Spring Boot本身并不提供Spring的核心功能，而是作為Spring的腳手架框架，以達(dá)到快速構(gòu)建項(xiàng)目、預(yù)置三方配置、開箱即用的目的。Spring Boot有如下的優(yōu)點(diǎn)：
- 可以快速構(gòu)建項(xiàng)目；
- 可以對主流開發(fā)框架的無配置集成；
- 項(xiàng)目可獨(dú)立運(yùn)行，無需外部依賴Servlet容器；
- 提供運(yùn)行時(shí)的應(yīng)用監(jiān)控；
- 可以極大地提高開發(fā)、部署效率；
- 可以與云計(jì)算天然集成。
1.2 Spring Boot Starter有什么用？
參考答案
Spring Boot通過提供眾多起步依賴（Starter）降低項(xiàng)目依賴的復(fù)雜度。起步依賴本質(zhì)上是一個(gè)Maven項(xiàng)目對象模型（Project Object Model, POM），定義了對其他庫的傳遞依賴，這些東西加在一起即支持某項(xiàng)功能。很多起步依賴的命名都暗示了它們提供的某種或某類功能。
舉例來說，你打算把這個(gè)閱讀列表應(yīng)用程序做成一個(gè)Web應(yīng)用程序。與其向項(xiàng)目的構(gòu)建文件里添加一堆單獨(dú)的庫依賴，還不如聲明這是一個(gè)Web應(yīng)用程序來得簡單。你只要添加Spring Boot的Web起步依賴就好了。
1.3 介紹Spring Boot的啟動流程
參考答案
首先，Spring Boot項(xiàng)目創(chuàng)建完成會默認(rèn)生成一個(gè)名為 *Application 的入口類，我們是通過該類的main方法啟動Spring Boot項(xiàng)目的。在main方法中，通過SpringApplication的靜態(tài)方法，即run方法進(jìn)行SpringApplication類的實(shí)例化操作，然后再針對實(shí)例化對象調(diào)用另外一個(gè)run方法來完成整個(gè)項(xiàng)目的初始化和啟動。
SpringApplication調(diào)用的run方法的大致流程，如下圖：
其中，SpringApplication在run方法中重點(diǎn)做了以下操作：
- 獲取監(jiān)聽器和參數(shù)配置；
- 打印Banner信息；
- 創(chuàng)建并初始化容器；
- 監(jiān)聽器發(fā)送通知。
當(dāng)然，除了上述核心操作，run方法運(yùn)行過程中還涉及啟動時(shí)長統(tǒng)計(jì)、異常報(bào)告、啟動日志、異常處理等輔助操作。比較完整的流程，可以參考如下源代碼：
public ConfigurableApplicationContext run(String... args) {// 創(chuàng)建StopWatch對象，用于統(tǒng)計(jì)run方法啟動時(shí)長。StopWatch stopWatch = new StopWatch();// 啟動統(tǒng)計(jì)stopWatch.start();ConfigurableApplicationContext context = null;Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();// 配置Headless屬性configureHeadlessProperty();// 獲得SpringApplicationRunListener數(shù)組，// 該數(shù)組封裝于SpringApplicationRunListeners對象的listeners中。SpringApplicationRunListeners listeners = getRunListeners(args);// 啟動監(jiān)聽，遍歷SpringApplicationRunListener數(shù)組每個(gè)元素，并執(zhí)行。listeners.starting();try {// 創(chuàng)建ApplicationArguments對象ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);// 加載屬性配置，包括所有的配置屬性。ConfigurableEnvironment environment = prepareEnvironment(listeners, applicationArguments);configureIgnoreBeanInfo(environment);// 打印BannerBanner printedBanner = printBanner(environment);// 創(chuàng)建容器context = createApplicationContext();// 異常報(bào)告器exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class,new Class[] { ConfigurableApplicationContext.class }, context);// 準(zhǔn)備容器，組件對象之間進(jìn)行關(guān)聯(lián)。prepareContext(context, environment, listeners, applicationArguments, printedBanner);// 初始化容器refreshContext(context);// 初始化操作之后執(zhí)行，默認(rèn)實(shí)現(xiàn)為空。afterRefresh(context, applicationArguments);// 停止時(shí)長統(tǒng)計(jì)stopWatch.stop();// 打印啟動日志if (this.logStartupInfo) {new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);}// 通知監(jiān)聽器：容器完成啟動。listeners.started(context);// 調(diào)用ApplicationRunner和CommandLineRunner的運(yùn)行方法。callRunners(context, applicationArguments);} catch (Throwable ex) {// 異常處理handleRunFailure(context, ex, exceptionReporters, listeners);throw new IllegalStateException(ex);}try {// 通知監(jiān)聽器：容器正在運(yùn)行。listeners.running(context);} catch (Throwable ex) {// 異常處理handleRunFailure(context, ex, exceptionReporters, null);throw new IllegalStateException(ex);}return context; }1.4 Spring Boot項(xiàng)目是如何導(dǎo)入包的？
參考答案
通過Spring Boot Starter導(dǎo)入包。
Spring Boot通過提供眾多起步依賴（Starter）降低項(xiàng)目依賴的復(fù)雜度。起步依賴本質(zhì)上是一個(gè)Maven項(xiàng)目對象模型（Project Object Model, POM），定義了對其他庫的傳遞依賴，這些東西加在一起即支持某項(xiàng)功能。很多起步依賴的命名都暗示了它們提供的某種或某類功能。
舉例來說，你打算把這個(gè)閱讀列表應(yīng)用程序做成一個(gè)Web應(yīng)用程序。與其向項(xiàng)目的構(gòu)建文件里添加一堆單獨(dú)的庫依賴，還不如聲明這是一個(gè)Web應(yīng)用程序來得簡單。你只要添加Spring Boot的Web起步依賴就好了。
1.5 請描述Spring Boot自動裝配的過程
參考答案
使用Spring Boot時(shí)，我們只需引入對應(yīng)的Starters，Spring Boot啟動時(shí)便會自動加載相關(guān)依賴，配置相應(yīng)的初始化參數(shù)，以最快捷、簡單的形式對第三方軟件進(jìn)行集成，這便是Spring Boot的自動配置功能。Spring Boot實(shí)現(xiàn)該運(yùn)作機(jī)制鎖涉及的核心部分如下圖所示：
整個(gè)自動裝配的過程是：Spring Boot通過@EnableAutoConfiguration注解開啟自動配置，加載spring.factories中注冊的各種AutoConfiguration類，當(dāng)某個(gè)AutoConfiguration類滿足其注解@Conditional指定的生效條件（Starters提供的依賴、配置或Spring容器中是否存在某個(gè)Bean等）時(shí)，實(shí)例化該AutoConfiguration類中定義的Bean（組件等），并注入Spring容器，就可以完成依賴框架的自動配置。
1.6 說說你對Spring Boot注解的了解
參考答案
@SpringBootApplication注解：
在Spring Boot入口類中，唯一的一個(gè)注解就是@SpringBootApplication。它是Spring Boot項(xiàng)目的核心注解，用于開啟自動配置，準(zhǔn)確說是通過該注解內(nèi)組合的@EnableAutoConfiguration開啟了自動配置。
@EnableAutoConfiguration注解：
@EnableAutoConfiguration的主要功能是啟動Spring應(yīng)用程序上下文時(shí)進(jìn)行自動配置，它會嘗試猜測并配置項(xiàng)目可能需要的Bean。自動配置通常是基于項(xiàng)目classpath中引入的類和已定義的Bean來實(shí)現(xiàn)的。在此過程中，被自動配置的組件來自項(xiàng)目自身和項(xiàng)目依賴的jar包中。
@Import注解：
@EnableAutoConfiguration的關(guān)鍵功能是通過@Import注解導(dǎo)入的ImportSelector來完成的。從源代碼得知@Import(AutoConfigurationImportSelector.class)是@EnableAutoConfiguration注解的組成部分，也是自動配置功能的核心實(shí)現(xiàn)者。
@Conditional注解：
@Conditional注解是由Spring 4.0版本引入的新特性，可根據(jù)是否滿足指定的條件來決定是否進(jìn)行Bean的實(shí)例化及裝配，比如，設(shè)定當(dāng)類路徑下包含某個(gè)jar包的時(shí)候才會對注解的類進(jìn)行實(shí)例化操作。總之，就是根據(jù)一些特定條件來控制Bean實(shí)例化的行為。
@Conditional衍生注解：
在Spring Boot的autoconfigure項(xiàng)目中提供了各類基于@Conditional注解的衍生注解，它們適用不同的場景并提供了不同的功能。通過閱讀這些注解的源碼，你會發(fā)現(xiàn)它們其實(shí)都組合了@Conditional注解，不同之處是它們在注解中指定的條件（Condition）不同。
- @ConditionalOnBean：在容器中有指定Bean的條件下。
- @ConditionalOnClass：在classpath類路徑下有指定類的條件下。
- @ConditionalOnCloudPlatform：當(dāng)指定的云平臺處于active狀態(tài)時(shí)。
- @ConditionalOnExpression：基于SpEL表達(dá)式的條件判斷。
- @ConditionalOnJava：基于JVM版本作為判斷條件。
- @ConditionalOnJndi：在JNDI存在的條件下查找指定的位置。
- @ConditionalOnMissingBean：當(dāng)容器里沒有指定Bean的條件時(shí)。
- @ConditionalOnMissingClass：當(dāng)類路徑下沒有指定類的條件時(shí)。
- @ConditionalOnNotWebApplication：在項(xiàng)目不是一個(gè)Web項(xiàng)目的條件下。
- @ConditionalOnProperty：在指定的屬性有指定值的條件下。
- @ConditionalOnResource：類路徑是否有指定的值。
- @ConditionalOnSingleCandidate：當(dāng)指定的Bean在容器中只有一個(gè)或者有多個(gè)但是指定了首選的Bean時(shí)。
- @ConditionalOnWebApplication：在項(xiàng)目是一個(gè)Web項(xiàng)目的條件下。
2. Spring
2.1 請你說說Spring的核心是什么
參考答案
Spring框架包含眾多模塊，如Core、Testing、Data Access、Web Servlet等，其中Core是整個(gè)Spring框架的核心模塊。Core模塊提供了IoC容器、AOP功能、數(shù)據(jù)綁定、類型轉(zhuǎn)換等一系列的基礎(chǔ)功能，而這些功能以及其他模塊的功能都是建立在IoC和AOP之上的，所以IoC和AOP是Spring框架的核心。
IoC（Inversion of Control）是控制反轉(zhuǎn)的意思，這是一種面向?qū)ο缶幊痰脑O(shè)計(jì)思想。在不采用這種思想的情況下，我們需要自己維護(hù)對象與對象之間的依賴關(guān)系，很容易造成對象之間的耦合度過高，在一個(gè)大型的項(xiàng)目中這十分的不利于代碼的維護(hù)。IoC則可以解決這種問題，它可以幫我們維護(hù)對象與對象之間的依賴關(guān)系，降低對象之間的耦合度。
說到IoC就不得不說DI（Dependency Injection），DI是依賴注入的意思，它是IoC實(shí)現(xiàn)的實(shí)現(xiàn)方式，就是說IoC是通過DI來實(shí)現(xiàn)的。由于IoC這個(gè)詞匯比較抽象而DI卻更直觀，所以很多時(shí)候我們就用DI來代替它，在很多時(shí)候我們簡單地將IoC和DI劃等號，這是一種習(xí)慣。而實(shí)現(xiàn)依賴注入的關(guān)鍵是IoC容器，它的本質(zhì)就是一個(gè)工廠。
AOP（Aspect Oriented Programing）是面向切面編程思想，這種思想是對OOP的補(bǔ)充，它可以在OOP的基礎(chǔ)上進(jìn)一步提高編程的效率。簡單來說，它可以統(tǒng)一解決一批組件的共性需求（如權(quán)限檢查、記錄日志、事務(wù)管理等）。在AOP思想下，我們可以將解決共性需求的代碼獨(dú)立出來，然后通過配置的方式，聲明這些代碼在什么地方、什么時(shí)機(jī)調(diào)用。當(dāng)滿足調(diào)用條件時(shí)，AOP會將該業(yè)務(wù)代碼織入到我們指定的位置，從而統(tǒng)一解決了問題，又不需要修改這一批組件的代碼。
2.2 說一說你對Spring容器的了解
參考答案
Spring主要提供了兩種類型的容器：BeanFactory和ApplicationContext。
- BeanFactory：是基礎(chǔ)類型的IoC容器，提供完整的IoC服務(wù)支持。如果沒有特殊指定，默認(rèn)采用延
遲初始化策略。只有當(dāng)客戶端對象需要訪問容器中的某個(gè)受管對象的時(shí)候，才對該受管對象進(jìn)行初始化以及依賴注入操作。所以，相對來說，容器啟動初期速度較快，所需要的資源有限。對于資源有限，并且功能要求不是很嚴(yán)格的場景，BeanFactory是比較合適的IoC容器選擇。 - ApplicationContext：它是在BeanFactory的基礎(chǔ)上構(gòu)建的，是相對比較高級的容器實(shí)現(xiàn)，除了擁有BeanFactory的所有支持，ApplicationContext還提供了其他高級特性，比如事件發(fā)布、國際化信息支持等。ApplicationContext所管理的對象，在該類型容器啟動之后，默認(rèn)全部初始化并綁定完成。所以，相對于BeanFactory來說，ApplicationContext要求更多的系統(tǒng)資源，同時(shí)，因?yàn)樵趩訒r(shí)就完成所有初始化，容
器啟動時(shí)間較之BeanFactory也會長一些。在那些系統(tǒng)資源充足，并且要求更多功能的場景中，ApplicationContext類型的容器是比較合適的選擇。
2.3 說一說你對BeanFactory的了解
參考答案
BeanFactory是一個(gè)類工廠，與傳統(tǒng)類工廠不同的是，BeanFactory是類的通用工廠，它可以創(chuàng)建并管理各種類的對象。這些可被創(chuàng)建和管理的對象本身沒有什么特別之處，僅是一個(gè)POJO，Spring稱這些被創(chuàng)建和管理的Java對象為Bean。并且，Spring中所說的Bean比JavaBean更為寬泛一些，所有可以被Spring容器實(shí)例化并管理的Java類都可以成為Bean。
BeanFactory是Spring容器的頂層接口，Spring為BeanFactory提供了多種實(shí)現(xiàn)，最常用的是XmlBeanFactory。但它在Spring 3.2中已被廢棄，建議使用XmlBeanDefinitionReader、DefaultListableBeanFactory替代。BeanFactory最主要的方法就是 getBean(String beanName)，該方法從容器中返回特定名稱的Bean。
2.4 說一說你對Spring IOC的理解
參考答案
IoC（Inversion of Control）是控制反轉(zhuǎn)的意思，這是一種面向?qū)ο缶幊痰脑O(shè)計(jì)思想。在不采用這種思想的情況下，我們需要自己維護(hù)對象與對象之間的依賴關(guān)系，很容易造成對象之間的耦合度過高，在一個(gè)大型的項(xiàng)目中這十分的不利于代碼的維護(hù)。IoC則可以解決這種問題，它可以幫我們維護(hù)對象與對象之間的依賴關(guān)系，降低對象之間的耦合度。
說到IoC就不得不說DI（Dependency Injection），DI是依賴注入的意思，它是IoC實(shí)現(xiàn)的實(shí)現(xiàn)方式，就是說IoC是通過DI來實(shí)現(xiàn)的。由于IoC這個(gè)詞匯比較抽象而DI卻更直觀，所以很多時(shí)候我們就用DI來代替它，在很多時(shí)候我們簡單地將IoC和DI劃等號，這是一種習(xí)慣。而實(shí)現(xiàn)依賴注入的關(guān)鍵是IoC容器，它的本質(zhì)就是一個(gè)工廠。
在具體的實(shí)現(xiàn)中，主要由三種注入方式：
構(gòu)造方法注入
就是被注入對象可以在它的構(gòu)造方法中聲明依賴對象的參數(shù)列表，讓外部知道它需要哪些依賴對象。然后，IoC Service Provider會檢查被注入的對象的構(gòu)造方法，取得它所需要的依賴對象列表，進(jìn)而為其注入相應(yīng)的對象。構(gòu)造方法注入方式比較直觀，對象被構(gòu)造完成后，即進(jìn)入就緒狀態(tài)，可以馬上使用。
setter方法注入
通過setter方法，可以更改相應(yīng)的對象屬性。所以，當(dāng)前對象只要為其依賴對象所對應(yīng)的屬性添加setter方法，就可以通過setter方法將相應(yīng)的依賴對象設(shè)置到被注入對象中。setter方法注入雖不像構(gòu)造方法注入那樣，讓對象構(gòu)造完成后即可使用，但相對來說更寬松一些，
可以在對象構(gòu)造完成后再注入。
接口注入
相對于前兩種注入方式來說，接口注入沒有那么簡單明了。被注入對象如果想要IoC Service Provider為其注入依賴對象，就必須實(shí)現(xiàn)某個(gè)接口。這個(gè)接口提供一個(gè)方法，用來為其注入依賴對象。IoC Service Provider最終通過這些接口來了解應(yīng)該為被注入對象注入什么依賴對象。相對于前兩種依賴注入方式，接口注入比較死板和煩瑣。
總體來說，構(gòu)造方法注入和setter方法注入因?yàn)槠淝秩胄暂^弱，且易于理解和使用，所以是現(xiàn)在使用最多的注入方式。而接口注入因?yàn)榍秩胄暂^強(qiáng)，近年來已經(jīng)不流行了。
2.5 Spring是如何管理Bean的？
參考答案
Spring通過IoC容器來管理Bean，我們可以通過XML配置或者注解配置，來指導(dǎo)IoC容器對Bean的管理。因?yàn)樽⒔馀渲帽萖ML配置方便很多，所以現(xiàn)在大多時(shí)候會使用注解配置的方式。
以下是管理Bean時(shí)常用的一些注解：
2.6 介紹Bean的作用域
參考答案
默認(rèn)情況下，Bean在Spring容器中是單例的，我們可以通過@Scope注解修改Bean的作用域。該注解有如下5個(gè)取值，它們代表了Bean的5種不同類型的作用域：
2.7 說一說Bean的生命周期
參考答案
Spring容器管理Bean，涉及對Bean的創(chuàng)建、初始化、調(diào)用、銷毀等一系列的流程，這個(gè)流程就是Bean的生命周期。整個(gè)流程參考下圖：
這個(gè)過程是由Spring容器自動管理的，其中有兩個(gè)環(huán)節(jié)我們可以進(jìn)行干預(yù)。
2.8 Spring是怎么解決循環(huán)依賴的？
參考答案
首先，需要明確的是spring對循環(huán)依賴的處理有三種情況：
接下來，我們具體看看spring是如何處理第二種循環(huán)依賴的。
Spring單例對象的初始化大略分為三步：
從上面講述的單例bean初始化步驟我們可以知道，循環(huán)依賴主要發(fā)生在第一步、第二步。也就是構(gòu)造器循環(huán)依賴和field循環(huán)依賴。 Spring為了解決單例的循環(huán)依賴問題，使用了三級緩存。
/** Cache of singleton objects: bean name –> bean instance */ private final Map singletonObjects = new ConcurrentHashMap(256); /** Cache of singleton factories: bean name –> ObjectFactory */ private final Map> singletonFactories = new HashMap>(16); /** Cache of early singleton objects: bean name –> bean instance */ private final Map earlySingletonObjects = new HashMap(16);這三級緩存的作用分別是：
- singletonFactories ： 進(jìn)入實(shí)例化階段的單例對象工廠的cache （三級緩存）；
- earlySingletonObjects ：完成實(shí)例化但是尚未初始化的，提前暴光的單例對象的Cache （二級緩存）；
- singletonObjects：完成初始化的單例對象的cache（一級緩存）。
我們在創(chuàng)建bean的時(shí)候，會首先從cache中獲取這個(gè)bean，這個(gè)緩存就是sigletonObjects。主要的調(diào)用方法是：
protected Object getSingleton(String beanName, boolean allowEarlyReference) {Object singletonObject = this.singletonObjects.get(beanName);//isSingletonCurrentlyInCreation()判斷當(dāng)前單例bean是否正在創(chuàng)建中if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {synchronized (this.singletonObjects) {singletonObject = this.earlySingletonObjects.get(beanName);//allowEarlyReference 是否允許從singletonFactories中通過getObject拿到對象if (singletonObject == null && allowEarlyReference) {ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);if (singletonFactory != null) {singletonObject = singletonFactory.getObject();//從singletonFactories中移除，并放入earlySingletonObjects中。//其實(shí)也就是從三級緩存移動到了二級緩存this.earlySingletonObjects.put(beanName, singletonObject);this.singletonFactories.remove(beanName);}}}}return (singletonObject != NULL_OBJECT ? singletonObject : null); }從上面三級緩存的分析，我們可以知道，Spring解決循環(huán)依賴的訣竅就在于singletonFactories這個(gè)三級cache。這個(gè)cache的類型是ObjectFactory，定義如下：
public interface ObjectFactory<T> {T getObject() throws BeansException; }這個(gè)接口在AbstractBeanFactory里實(shí)現(xiàn)，并在核心方法doCreateBean（）引用下面的方法：
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {Assert.notNull(singletonFactory, "Singleton factory must not be null");synchronized (this.singletonObjects) {if (!this.singletonObjects.containsKey(beanName)) {this.singletonFactories.put(beanName, singletonFactory);this.earlySingletonObjects.remove(beanName);this.registeredSingletons.add(beanName);}} }這段代碼發(fā)生在createBeanInstance之后，populateBean（）之前，也就是說單例對象此時(shí)已經(jīng)被創(chuàng)建出來(調(diào)用了構(gòu)造器)。這個(gè)對象已經(jīng)被生產(chǎn)出來了，此時(shí)將這個(gè)對象提前曝光出來，讓大家使用。
這樣做有什么好處呢？讓我們來分析一下“A的某個(gè)field或者setter依賴了B的實(shí)例對象，同時(shí)B的某個(gè)field或者setter依賴了A的實(shí)例對象”這種循環(huán)依賴的情況。A首先完成了初始化的第一步，并且將自己提前曝光到singletonFactories中，此時(shí)進(jìn)行初始化的第二步，發(fā)現(xiàn)自己依賴對象B，此時(shí)就嘗試去get(B)，發(fā)現(xiàn)B還沒有被create，所以走create流程，B在初始化第一步的時(shí)候發(fā)現(xiàn)自己依賴了對象A，于是嘗試get(A)，嘗試一級緩存singletonObjects(肯定沒有，因?yàn)锳還沒初始化完全)，嘗試二級緩存earlySingletonObjects（也沒有），嘗試三級緩存singletonFactories，由于A通過ObjectFactory將自己提前曝光了，所以B能夠通過ObjectFactory.getObject拿到A對象(雖然A還沒有初始化完全，但是總比沒有好呀)，B拿到A對象后順利完成了初始化階段1、2、3，完全初始化之后將自己放入到一級緩存singletonObjects中。此時(shí)返回A中，A此時(shí)能拿到B的對象順利完成自己的初始化階段2、3，最終A也完成了初始化，進(jìn)去了一級緩存singletonObjects中，而且更加幸運(yùn)的是，由于B拿到了A的對象引用，所以B現(xiàn)在hold住的A對象完成了初始化。
2.9 @Autowired和@Resource注解有什么區(qū)別？
參考答案
2.10 Spring中默認(rèn)提供的單例是線程安全的嗎？
參考答案
不是。
Spring容器本身并沒有提供Bean的線程安全策略。如果單例的Bean是一個(gè)無狀態(tài)的Bean，即線程中的操作不會對Bean的成員執(zhí)行查詢以外的操作，那么這個(gè)單例的Bean是線程安全的。比如，Controller、Service、DAO這樣的組件，通常都是單例且線程安全的。如果單例的Bean是一個(gè)有狀態(tài)的Bean，則可以采用ThreadLocal對狀態(tài)數(shù)據(jù)做線程隔離，來保證線程安全。
2.11 說一說你對Spring AOP的理解
參考答案
AOP（Aspect Oriented Programming）是面向切面編程，它是一種編程思想，是面向?qū)ο缶幊?#xff08;OOP）的一種補(bǔ)充。面向?qū)ο缶幊虒⒊绦虺橄蟪筛鱾€(gè)層次的對象，而面向切面編程是將程序抽象成各個(gè)切面。如下圖，可以很形象地看出，所謂切面，相當(dāng)于應(yīng)用對象間的橫切點(diǎn)，我們可以將其單獨(dú)抽象為單獨(dú)的模塊。
AOP的術(shù)語：
- 連接點(diǎn)（join point）：對應(yīng)的是具體被攔截的對象，因?yàn)镾pring只能支持方法，所以被攔截的對象往往就是指特定的方法，AOP將通過動態(tài)代理技術(shù)把它織入對應(yīng)的流程中。
- 切點(diǎn)（point cut）：有時(shí)候，我們的切面不單單應(yīng)用于單個(gè)方法，也可能是多個(gè)類的不同方法，這時(shí)，可以通過正則式和指示器的規(guī)則去定義，從而適配連接點(diǎn)。切點(diǎn)就是提供這樣一個(gè)功能的概念。
- 通知（advice）：就是按照約定的流程下的方法，分為前置通知、后置通知、環(huán)繞通知、事后返回通知和異常通知，它會根據(jù)約定織入流程中。
- 目標(biāo)對象（target）：即被代理對象。
- 引入（introduction）：是指引入新的類和其方法，增強(qiáng)現(xiàn)有Bean的功能。
- 織入（weaving）：它是一個(gè)通過動態(tài)代理技術(shù)，為原有服務(wù)對象生成代理對象，然后將與切點(diǎn)定義匹配的連接點(diǎn)攔截，并按約定將各類通知織入約定流程的過程。
- 切面（aspect）：是一個(gè)可以定義切點(diǎn)、各類通知和引入的內(nèi)容，SpringAOP將通過它的信息來增強(qiáng)Bean的功能或者將對應(yīng)的方法織入流程。
Spring AOP：
AOP可以有多種實(shí)現(xiàn)方式，而Spring AOP支持如下兩種實(shí)現(xiàn)方式。
- JDK動態(tài)代理：這是Java提供的動態(tài)代理技術(shù)，可以在運(yùn)行時(shí)創(chuàng)建接口的代理實(shí)例。Spring AOP默認(rèn)采用這種方式，在接口的代理實(shí)例中織入代碼。
- CGLib動態(tài)代理：采用底層的字節(jié)碼技術(shù)，在運(yùn)行時(shí)創(chuàng)建子類代理的實(shí)例。當(dāng)目標(biāo)對象不存在接口時(shí)，Spring AOP就會采用這種方式，在子類實(shí)例中織入代碼。
2.12 請你說說AOP的應(yīng)用場景
參考答案
Spring AOP為IoC的使用提供了更多的便利，一方面，應(yīng)用可以直接使用AOP的功能，設(shè)計(jì)應(yīng)用的橫切關(guān)注點(diǎn)，把跨越應(yīng)用程序多個(gè)模塊的功能抽象出來，并通過簡單的AOP的使用，靈活地編制到模塊中，比如可以通過AOP實(shí)現(xiàn)應(yīng)用程序中的日志功能。另一方面，在Spring內(nèi)部，一些支持模塊也是通過Spring AOP來實(shí)現(xiàn)的，比如事務(wù)處理。從這兩個(gè)角度就已經(jīng)可以看到Spring AOP的核心地位了。
2.13 Spring AOP不能對哪些類進(jìn)行增強(qiáng)？
參考答案
2.14 JDK動態(tài)代理和CGLIB有什么區(qū)別？
參考答案
JDK動態(tài)代理
這是Java提供的動態(tài)代理技術(shù)，可以在運(yùn)行時(shí)創(chuàng)建接口的代理實(shí)例。Spring AOP默認(rèn)采用這種方式，在接口的代理實(shí)例中織入代碼。
CGLib動態(tài)代理
采用底層的字節(jié)碼技術(shù)，在運(yùn)行時(shí)創(chuàng)建子類代理的實(shí)例。當(dāng)目標(biāo)對象不存在接口時(shí)，Spring AOP就會采用這種方式，在子類實(shí)例中織入代碼。
2.15 既然有沒有接口都可以用CGLIB，為什么Spring還要使用JDK動態(tài)代理？
參考答案
在性能方面，CGLib創(chuàng)建的代理對象比JDK動態(tài)代理創(chuàng)建的代理對象高很多。但是，CGLib在創(chuàng)建代理對象時(shí)所花費(fèi)的時(shí)間比JDK動態(tài)代理多很多。所以，對于單例的對象因?yàn)闊o需頻繁創(chuàng)建代理對象，采用CGLib動態(tài)代理比較合適。反之，對于多例的對象因?yàn)樾枰l繁的創(chuàng)建代理對象，則JDK動態(tài)代理更合適。
2.16 Spring如何管理事務(wù)？
參考答案
Spring為事務(wù)管理提供了一致的編程模板，在高層次上建立了統(tǒng)一的事務(wù)抽象。也就是說，不管是選擇MyBatis、Hibernate、JPA還是Spring JDBC，Spring都可以讓用戶以統(tǒng)一的編程模型進(jìn)行事務(wù)管理。
Spring支持兩種事務(wù)編程模型：
編程式事務(wù)
Spring提供了TransactionTemplate模板，利用該模板我們可以通過編程的方式實(shí)現(xiàn)事務(wù)管理，而無需關(guān)注資源獲取、復(fù)用、釋放、事務(wù)同步及異常處理等操作。相對于聲明式事務(wù)來說，這種方式相對麻煩一些，但是好在更為靈活，我們可以將事務(wù)管理的范圍控制的更為精確。
聲明式事務(wù)
Spring事務(wù)管理的亮點(diǎn)在于聲明式事務(wù)管理，它允許我們通過聲明的方式，在IoC配置中指定事務(wù)的邊界和事務(wù)屬性，Spring會自動在指定的事務(wù)邊界上應(yīng)用事務(wù)屬性。相對于編程式事務(wù)來說，這種方式十分的方便，只需要在需要做事務(wù)管理的方法上，增加@Transactional注解，以聲明事務(wù)特征即可。
2.17 Spring的事務(wù)傳播方式有哪些？
參考答案
當(dāng)我們調(diào)用一個(gè)業(yè)務(wù)方法時(shí)，它的內(nèi)部可能會調(diào)用其他的業(yè)務(wù)方法，以完成一個(gè)完整的業(yè)務(wù)操作。這種業(yè)務(wù)方法嵌套調(diào)用的時(shí)候，如果這兩個(gè)方法都是要保證事務(wù)的，那么就要通過Spring的事務(wù)傳播機(jī)制控制當(dāng)前事務(wù)如何傳播到被嵌套調(diào)用的業(yè)務(wù)方法中。
Spring在TransactionDefinition接口中規(guī)定了7種類型的事務(wù)傳播行為，它們規(guī)定了事務(wù)方法和事務(wù)方法發(fā)生嵌套調(diào)用時(shí)如何進(jìn)行傳播，如下表：
| PROPAGATION_REQUIRED | 如果當(dāng)前沒有事務(wù)，則新建一個(gè)事務(wù)；如果已存在一個(gè)事務(wù)，則加入到這個(gè)事務(wù)中。這是最常見的選擇。 |
| PROPAGATION_SUPPORTS | 支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，則以非事務(wù)方式執(zhí)行。 |
| PROPAGATION_MANDATORY | 使用當(dāng)前的事務(wù)，如果當(dāng)前沒有事務(wù)，則拋出異常。 |
| PROPAGATION_REQUIRES_NEW | 新建事務(wù)，如果當(dāng)前存在事務(wù)，則把當(dā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ù)，則執(zhí)行與PROPAGATION_REQUIRED類似的操作。 |
2.18 Spring的事務(wù)如何配置，常用注解有哪些？
參考答案
事務(wù)的打開、回滾和提交是由事務(wù)管理器來完成的，我們使用不同的數(shù)據(jù)庫訪問框架，就要使用與之對應(yīng)的事務(wù)管理器。在Spring Boot中，當(dāng)你添加了數(shù)據(jù)庫訪問框架的起步依賴時(shí)，它就會進(jìn)行自動配置，即自動實(shí)例化正確的事務(wù)管理器。
對于聲明式事務(wù)，是使用@Transactional進(jìn)行標(biāo)注的。這個(gè)注解可以標(biāo)注在類或者方法上。
- 當(dāng)它標(biāo)注在類上時(shí)，代表這個(gè)類所有公共（public）非靜態(tài)的方法都將啟用事務(wù)功能。
- 當(dāng)它標(biāo)注在方法上時(shí)，代表這個(gè)方法將啟用事務(wù)功能。
另外，在@Transactional注解上，我們可以使用isolation屬性聲明事務(wù)的隔離級別，使用propagation屬性聲明事務(wù)的傳播機(jī)制。
2.19 說一說你對聲明式事務(wù)的理解
參考答案
Spring事務(wù)管理的亮點(diǎn)在于聲明式事務(wù)管理，它允許我們通過聲明的方式，在IoC配置中指定事務(wù)的邊界和事務(wù)屬性，Spring會自動在指定的事務(wù)邊界上應(yīng)用事務(wù)屬性。相對于編程式事務(wù)來說，這種方式十分的方便，只需要在需要做事務(wù)管理的方法上，增加@Transactional注解，以聲明事務(wù)特征即可。
3. Spring MVC
3.1 什么是MVC？
參考答案
MVC是一種設(shè)計(jì)模式，在這種模式下軟件被分為三層，即Model（模型）、View（視圖）、Controller（控制器）。Model代表的是數(shù)據(jù)，View代表的是用戶界面，Controller代表的是數(shù)據(jù)的處理邏輯，它是Model和View這兩層的橋梁。將軟件分層的好處是，可以將對象之間的耦合度降低，便于代碼的維護(hù)。
3.2 DAO層是做什么的？
參考答案
DAO是Data Access Obejct的縮寫，即數(shù)據(jù)訪問對象，在項(xiàng)目中它通常作為獨(dú)立的一層，專門用于訪問數(shù)據(jù)庫。這一層的具體實(shí)現(xiàn)技術(shù)有很多，常用的有Spring JDBC、Hibernate、JPA、MyBatis等，在Spring框架下無論采用哪一種技術(shù)訪問數(shù)據(jù)庫，它的編程模式都是統(tǒng)一的。
3.3 介紹一下Spring MVC的執(zhí)行流程
參考答案
3.4 說一說你知道的Spring MVC注解
參考答案
@RequestMapping：
作用：該注解的作用就是用來處理請求地址映射的，也就是說將其中的處理器方法映射到url路徑上。
屬性：
- method：是讓你指定請求的method的類型，比如常用的有g(shù)et和post。
- value：是指請求的實(shí)際地址，如果是多個(gè)地址就用{}來指定就可以啦。
- produces：指定返回的內(nèi)容類型，當(dāng)request請求頭中的Accept類型中包含指定的類型才可以返回的。
- consumes：指定處理請求的提交內(nèi)容類型，比如一些json、html、text等的類型。
- headers：指定request中必須包含那些的headed值時(shí)，它才會用該方法處理請求的。
- params：指定request中一定要有的參數(shù)值，它才會使用該方法處理請求。
@RequestParam：
作用：是將請求參數(shù)綁定到你的控制器的方法參數(shù)上，是Spring MVC中的接收普通參數(shù)的注解。
屬性：
- value是請求參數(shù)中的名稱。
- required是請求參數(shù)是否必須提供參數(shù)，它的默認(rèn)是true，意思是表示必須提供。
@RequestBody：
作用：如果作用在方法上，就表示該方法的返回結(jié)果是直接按寫入的Http responsebody中（一般在異步獲取數(shù)據(jù)時(shí)使用的注解）。
屬性：required，是否必須有請求體。它的默認(rèn)值是true，在使用該注解時(shí)，值得注意的當(dāng)為true時(shí)get的請求方式是報(bào)錯的，如果你取值為false的話，get的請求是null。
@PathVaribale：
作用：該注解是用于綁定url中的占位符，但是注意，spring3.0以后，url才開始支持占位符的，它是Spring MVC支持的rest風(fēng)格url的一個(gè)重要的標(biāo)志。
3.5 介紹一下Spring MVC的攔截器
參考答案
攔截器會對處理器進(jìn)行攔截，這樣通過攔截器就可以增強(qiáng)處理器的功能。Spring MVC中，所有的攔截器都需要實(shí)現(xiàn)HandlerInterceptor接口，該接口包含如下三個(gè)方法：preHandle()、postHandle()、afterCompletion()。
這些方法的執(zhí)行流程如下圖：
通過上圖可以看出，Spring MVC攔截器的執(zhí)行流程如下：
- 執(zhí)行preHandle方法，它會返回一個(gè)布爾值。如果為false，則結(jié)束所有流程，如果為true，則執(zhí)行下一步。
- 執(zhí)行處理器邏輯，它包含控制器的功能。
- 執(zhí)行postHandle方法。
- 執(zhí)行視圖解析和視圖渲染。
- 執(zhí)行afterCompletion方法。
Spring MVC攔截器的開發(fā)步驟如下：
開發(fā)攔截器：
實(shí)現(xiàn)handlerInterceptor接口，從三個(gè)方法中選擇合適的方法，實(shí)現(xiàn)攔截時(shí)要執(zhí)行的具體業(yè)務(wù)邏輯。
注冊攔截器：
定義配置類，并讓它實(shí)現(xiàn)WebMvcConfigurer接口，在接口的addInterceptors方法中，注冊攔截器，并定義該攔截器匹配哪些請求路徑。
3.6 怎么去做請求攔截？
參考答案
如果是對Controller記性攔截，則可以使用Spring MVC的攔截器。
如果是對所有的請求（如訪問靜態(tài)資源的請求）進(jìn)行攔截，則可以使用Filter。
如果是對除了Controller之外的其他Bean的請求進(jìn)行攔截，則可以使用Spring AOP。
4. MyBatis
4.1 談?wù)凪yBatis和JPA的區(qū)別
參考答案
ORM映射不同：
MyBatis是半自動的ORM框架，提供數(shù)據(jù)庫與結(jié)果集的映射；
JPA（默認(rèn)采用Hibernate實(shí)現(xiàn)）是全自動的ORM框架，提供對象與數(shù)據(jù)庫的映射。
可移植性不同：
JPA通過它強(qiáng)大的映射結(jié)構(gòu)和HQL語言，大大降低了對象與數(shù)據(jù)庫的耦合性；
MyBatis由于需要寫SQL，因此與數(shù)據(jù)庫的耦合性直接取決于SQL的寫法，如果SQL不具備通用性而用了很多數(shù)據(jù)庫的特性SQL的話，移植性就會降低很多，移植時(shí)成本很高。
日志系統(tǒng)的完整性不同：
JPA日志系統(tǒng)非常健全、涉及廣泛，包括：SQL記錄、關(guān)系異常、優(yōu)化警告、緩存提示、臟數(shù)據(jù)警告等；
MyBatis除了基本的記錄功能外，日志功能薄弱很多。
SQL優(yōu)化上的區(qū)別：
由于Mybatis的SQL都是寫在XML里，因此優(yōu)化SQL比Hibernate方便很多。
而Hibernate的SQL很多都是自動生成的，無法直接維護(hù)SQL。雖有HQL，但功能還是不及SQL強(qiáng)大，見到報(bào)表等復(fù)雜需求時(shí)HQL就無能為力，也就是說HQL是有局限的Hhibernate雖然也支持原生SQL，但開發(fā)模式上卻與ORM不同，需要轉(zhuǎn)換思維，因此使用上不是非常方便。總之寫SQL的靈活度上Hibernate不及Mybatis。
4.2 MyBatis輸入輸出支持的類型有哪些？
參考答案
parameterType：
MyBatis支持多種輸入輸出類型，包括：
其中，簡單的類型，其數(shù)值直接映射到參數(shù)上。對于Map或JavaBean則將其屬性按照名稱映射到參數(shù)上。
4.3 MyBatis里如何實(shí)現(xiàn)一對多關(guān)聯(lián)查詢？
參考答案
一對多映射有兩種配置方式，都是使用collection標(biāo)簽實(shí)現(xiàn)的。在此之前，為了能夠存儲一對多的數(shù)據(jù)，需要在主表對應(yīng)的實(shí)體類中增加集合屬性，用于封裝子表對應(yīng)的實(shí)體類。
嵌套查詢：
- 通過property屬性指定子表屬性名；
- 通過javaType屬性指定封裝子表屬性的集合類型；
- 通過ofType屬性指定子表的實(shí)體類型；
- 通過select屬性指定查詢子表所依賴的SQL，這個(gè)SQL需單獨(dú)定義，內(nèi)部包含查詢子表的語句。
嵌套結(jié)果：
- 通過property屬性指定子表屬性名；
- 通過ofType屬性指定子表的實(shí)體類型；
- 通過result子標(biāo)簽定義子表字段和屬性的映射關(guān)系。
4.4 MyBatis中的$和#有什么區(qū)別？
參考答案
使用#設(shè)置參數(shù)時(shí)，MyBatis會創(chuàng)建預(yù)編譯的SQL語句，然后在執(zhí)行SQL時(shí)MyBatis會為預(yù)編譯SQL中的占位符（?）賦值。預(yù)編譯的SQL語句執(zhí)行效率高，并且可以防止注入攻擊。
使用$設(shè)置參數(shù)時(shí)，MyBatis只是創(chuàng)建普通的SQL語句，然后在執(zhí)行SQL語句時(shí)MyBatis將參數(shù)直接拼入到SQL里。這種方式在效率、安全性上均不如前者，但是可以解決一些特殊情況下的問題。例如，在一些動態(tài)表格（根據(jù)不同的條件產(chǎn)生不同的動態(tài)列）中，我們要傳遞SQL的列名，根據(jù)某些列進(jìn)行排序，或者傳遞列名給SQL都是比較常見的場景，這就無法使用預(yù)編譯的方式了。
4.5 既然不安全，為什么還需要？什么時(shí)候會用到它？
參考答案
它可以解決一些特殊情況下的問題。例如，在一些動態(tài)表格（根據(jù)不同的條件產(chǎn)生不同的動態(tài)列）中，我們要傳遞SQL的列名，根據(jù)某些列進(jìn)行排序，或者傳遞列名給SQL都是比較常見的場景，這就無法使用預(yù)編譯的方式了。
4.6 MyBatis的xml文件和Mapper接口是怎么綁定的？
參考答案
是通過xml文件中，<mapper> 根標(biāo)簽的namespace屬性進(jìn)行綁定的，即namespace屬性的值需要配置成接口的全限定名稱，MyBatis內(nèi)部就會通過這個(gè)值將這個(gè)接口與這個(gè)xml關(guān)聯(lián)起來。
4.7 MyBatis分頁和自己寫的分頁哪個(gè)效率高？
參考答案
自己寫的分頁效率高。
在MyBatis中，我們可以通過分頁插件實(shí)現(xiàn)分頁，也可以通過分頁SQL自己實(shí)現(xiàn)分頁。其中，分頁插件的原理是，攔截查詢SQL，在這個(gè)SQL基礎(chǔ)上自動為其添加limit分頁條件。它會大大的提高開發(fā)的效率，但是無法對分頁語句做出有針對性的優(yōu)化，比如分頁偏移量很大的情況，而這些在自己寫的分頁SQL里卻是可以靈活實(shí)現(xiàn)的。
4.8 了解MyBatis緩存機(jī)制嗎？
參考答案
MyBatis的緩存分為一級緩存和二級緩存。
一級緩存：
一級緩存也叫本地緩存，它默認(rèn)會啟用，并且不能關(guān)閉。一級緩存存在于SqlSession的生命周期中，即它是SqlSession級別的緩存。在同一個(gè) SqlSession 中查詢時(shí)，MyBatis 會把執(zhí)行的方法和參數(shù)通過算法生成緩存的鍵值，將鍵值和查詢結(jié)果存入一個(gè)Map對象中。如果同一個(gè)SqlSession 中執(zhí)行的方法和參數(shù)完全一致，那么通過算法會生成相同的鍵值，當(dāng)Map 緩存對象中己經(jīng)存在該鍵值時(shí)，則會返回緩存中的對象。
二級緩存：
二級緩存存在于SqlSessionFactory 的生命周期中，即它是SqlSessionFactory級別的緩存。若想使用二級緩存，需要在如下兩處進(jìn)行配置。
在MyBatis 的全局配置settings 中有一個(gè)參數(shù)cacheEnabled，這個(gè)參數(shù)是二級緩存的全局開關(guān)，默認(rèn)值是true ，初始狀態(tài)為啟用狀態(tài)。
MyBatis 的二級緩存是和命名空間綁定的，即二級緩存需要配置在Mapper.xml 映射文件中。在保證二級緩存的全局配置開啟的情況下，給Mapper.xml 開啟二級緩存只需要在Mapper. xml 中添加如下代碼：
<cache />二級緩存具有如下效果：
- 映射語句文件中的所有SELECT 語句將會被緩存。
- 映射語句文件中的所有時(shí)INSERT 、UPDATE 、DELETE 語句會刷新緩存。
- 緩存會使用Least Rece ntly U sed ( LRU ，最近最少使用的）算法來收回。
- 根據(jù)時(shí)間表（如no Flush Int erv al ，沒有刷新間隔），緩存不會以任何時(shí)間順序來刷新。
- 緩存會存儲集合或?qū)ο?#xff08;無論查詢方法返回什么類型的值）的1024 個(gè)引用。
- 緩存會被視為read/write（可讀／可寫）的，意味著對象檢索不是共享的，而且可以安全地被調(diào)用者修改，而不干擾其他調(diào)用者或線程所做的潛在修改。
5. 其他
5.1 cookie和session的區(qū)別是什么？
參考答案
5.2 cookie和session各自適合的場景是什么？
參考答案
對于敏感數(shù)據(jù)，應(yīng)存放在session里，因?yàn)閏ookie不安全。
對于普通數(shù)據(jù)，優(yōu)先考慮存放在cookie里，這樣會減少對服務(wù)器資源的占用。
5.3 請介紹session的工作原理
參考答案
session依賴于cookie。
當(dāng)客戶端首次訪問服務(wù)器時(shí)，服務(wù)器會為其創(chuàng)建一個(gè)session對象，該對象具有一個(gè)唯一標(biāo)識SESSIONID。并且在響應(yīng)階段，服務(wù)器會創(chuàng)建一個(gè)cookie，并將SESSIONID存入其中。
客戶端通過響應(yīng)的cookie而持有SESSIONID，所以當(dāng)它再次訪問服務(wù)器時(shí)，會通過cookie攜帶這個(gè)SESSIONID。服務(wù)器獲取到SESSIONID后，就可以找到與之對應(yīng)的session對象，進(jìn)而從這個(gè)session中獲取該客戶端的狀態(tài)。
5.4 get請求與post請求有什么區(qū)別？
參考答案
- GET在瀏覽器回退時(shí)是無害的，而POST會再次提交請求。
- GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。
- GET請求會被瀏覽器主動cache，而POST不會，除非手動設(shè)置。
- GET請求只能進(jìn)行url編碼，而POST支持多種編碼方式。
- GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。
- GET請求在URL中傳送的參數(shù)是有長度限制的，而POST沒有。
- 對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制。
- GET比POST更不安全，因?yàn)閰?shù)直接暴露在URL上，所以不能用來傳遞敏感信息。
- GET參數(shù)通過URL傳遞，POST放在Request body中。
5.5 get請求的參數(shù)能放到body里面嗎？
參考答案
GET請求是可以將參數(shù)放到BODY里面的，官方并沒有明確禁止，但給出的建議是這樣不符合規(guī)范，無法保證所有的實(shí)現(xiàn)都支持。這就意味著，如果你試圖這樣做，可能出現(xiàn)各種未知的問題，所以應(yīng)該當(dāng)避免。
5.6 post不冪等是為什么？
參考答案
HTTP方法的冪等性是指一次和多次請求某一個(gè)資源應(yīng)該具有同樣的副作用。冪等性屬于語義范疇，正如編譯器只能幫助檢查語法錯誤一樣，HTTP規(guī)范也沒有辦法通過消息格式等語法手段來定義它。
POST所對應(yīng)的URI并非創(chuàng)建的資源本身，而是資源的接收者。比如：POST http://www.forum.com/articles的語義是在http://www.forum.com/articles下創(chuàng)建一篇帖子，HTTP響應(yīng)中應(yīng)包含帖子的創(chuàng)建狀態(tài)以及帖子的URI。兩次相同的POST請求會在服務(wù)器端創(chuàng)建兩份資源，它們具有不同的URI。所以，POST方法不具備冪等性。
5.7 頁面報(bào)400錯誤是什么意思？
參考答案
400狀態(tài)碼標(biāo)識請求的語義有誤，當(dāng)前請求無法被服務(wù)器理解。除非進(jìn)行修改，否則客戶端不應(yīng)該重復(fù)提交這個(gè)請求。通常情況下，是本次請求中包含有錯誤的參數(shù)，此時(shí)應(yīng)該排查前端傳遞的參數(shù)。
5.8 請求數(shù)據(jù)出現(xiàn)亂碼該怎么處理？
參考答案
服務(wù)端出現(xiàn)請求亂碼的原因是，客戶端編碼與服務(wù)器解碼方案不一致，可以有如下幾種解決辦法：
5.9 如何在SpringBoot框架下實(shí)現(xiàn)一個(gè)定時(shí)任務(wù)？
參考答案
Spring給我們提供了可執(zhí)行定時(shí)任務(wù)的線程池ThreadPoolTaskScheduler，該線程池提供了多個(gè)可以與執(zhí)行定時(shí)任務(wù)的方法，如下圖。在Spring Boot中，只需要在配置類中啟用線程池注解，就可以直接使用這個(gè)線程池了。
5.10 調(diào)用接口時(shí)要記錄日志，該怎么設(shè)計(jì)？
參考答案
可以定義一個(gè)記錄日志的組件，并通過AOP將其織入到這個(gè)接口的調(diào)用中。這種方式對接口無需做任何改造，業(yè)務(wù)代碼中也無需增加任何調(diào)用的邏輯，完美地消除了記錄日志和業(yè)務(wù)代碼的耦合度。
5.11 了解Spring Boot JPA嗎？
參考答案
I。所以，POST方法不具備冪等性。
5.7 頁面報(bào)400錯誤是什么意思？
參考答案
400狀態(tài)碼標(biāo)識請求的語義有誤，當(dāng)前請求無法被服務(wù)器理解。除非進(jìn)行修改，否則客戶端不應(yīng)該重復(fù)提交這個(gè)請求。通常情況下，是本次請求中包含有錯誤的參數(shù)，此時(shí)應(yīng)該排查前端傳遞的參數(shù)。
5.8 請求數(shù)據(jù)出現(xiàn)亂碼該怎么處理？
參考答案
服務(wù)端出現(xiàn)請求亂碼的原因是，客戶端編碼與服務(wù)器解碼方案不一致，可以有如下幾種解決辦法：
5.9 如何在SpringBoot框架下實(shí)現(xiàn)一個(gè)定時(shí)任務(wù)？
參考答案
Spring給我們提供了可執(zhí)行定時(shí)任務(wù)的線程池ThreadPoolTaskScheduler，該線程池提供了多個(gè)可以與執(zhí)行定時(shí)任務(wù)的方法，如下圖。在Spring Boot中，只需要在配置類中啟用線程池注解，就可以直接使用這個(gè)線程池了。
[外鏈圖片轉(zhuǎn)存中…(img-taMsqLji-1641471118189)]
5.10 調(diào)用接口時(shí)要記錄日志，該怎么設(shè)計(jì)？
參考答案
可以定義一個(gè)記錄日志的組件，并通過AOP將其織入到這個(gè)接口的調(diào)用中。這種方式對接口無需做任何改造，業(yè)務(wù)代碼中也無需增加任何調(diào)用的邏輯，完美地消除了記錄日志和業(yè)務(wù)代碼的耦合度。
5.11 了解Spring Boot JPA嗎？
參考答案
JPA即Java Persistence API，它是一個(gè)基于O/R映射的標(biāo)準(zhǔn)規(guī)范。也就是說它指定以了標(biāo)準(zhǔn)規(guī)則，不提供實(shí)現(xiàn)，軟件提供商可以按照標(biāo)準(zhǔn)規(guī)范來實(shí)現(xiàn)，而使用者只需按照規(guī)范中定義的方式來使用，不用和軟件提供商打交道。JPA主要實(shí)現(xiàn)有Hibernate、EclipseLink、OpenJPA等，我們使用JPA來開發(fā)，無論是采用哪一種實(shí)現(xiàn)方式都一樣。
總結(jié)
以上是生活随笔為你收集整理的Spring全家桶面试真题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： @staticmethod和@class
- 下一篇： Spring Retry 重试机制实现及