日分享開始啦，請大家多多指教~

本篇總結 SSM 三大框架相關面試題~

1、什么是有狀態登錄和無狀態登錄？

• 有狀態登錄：

當客戶端第一次請求服務器時(請求登錄)，服務器創建 Session ，然后將登錄用戶身份信息保存到 Session 中，并將用戶身份信息作為 “門卡”，響應回客戶端，客戶端將服務器響應的 “門卡” 信息保存在本地 Cookie 中。

當下一次客戶端再次請求服務器時，這時候就直接將客戶端的 Cookie 中存放的 “門卡” 帶到服務器端，服務器端從 Session 中拿出數據和 “門卡” 進行對比，判斷是否可以同行。

• 無狀態登錄的缺點：

服務端保存大量用戶身份標識，增加服務端壓力。

客戶端請求依賴服務端，多次請求必須訪問同一臺服務器（如果是集群，相當于啟動了多個 Tomcat，這時候無法在多個 Tomcat 直接共享 Session 數據）。

• 無狀態登錄：

服務器不保存任何客戶端用戶的登錄信息！

客戶端的每次請求服務器必須自己具備身份信息標識（jwt），服務器端通過身份信息標識識別客戶端身份。

• 無狀態登錄的好處：

客戶端請求不依賴服務端的信息，任何多次請求不需要必須訪問到同一臺服務器。

減小服務端存儲壓力。

如何實現無狀態登錄？

如圖所示：

• 當客戶端第一次請求服務時，服務端對用戶進行信息認證（登錄）。
• 認證通過，將用戶身份信息(不包含密碼)進行加密形成 token，返回給客戶端，作為登錄憑證。
• 以后每次請求，客戶端都攜帶認證的 token。
• 服務的對 token 進行解密，判斷是否有效。

2、過濾器，攔截器，Aop區別？

過濾器和攔截器均體現了AOP的編程思想，都可以實現諸如日志記錄、登錄鑒權等功能，但二者的不同點也是比較多的。

1、實現原理不同

過濾器和攔截器 底層實現方式大不相同，過濾器是基于函數回調的，攔截器則是基于Java的反射機制（動態代理）實現的。

2、使用范圍不同

我們看到過濾器實現的是 javax.servlet.Filter 接口，而這個接口是在Servlet規范中定義的，也就是說過濾器Filter 的使用要依賴于Tomcat等容器，導致它只能在web程序中使用。

而攔截器(Interceptor) 它是一個Spring組件，并由Spring容器管理，并不依賴Tomcat等容器，是可以單獨使用的。不僅能應用在web程序中，也可以用于Application、Swing等程序中。

3、觸發時機不同

過濾器Filter是在請求進入容器后，但在進入servlet之前進行預處理，請求結束是在servlet處理完以后。

攔截器 Interceptor 是在請求進入servlet后，在進入Controller之前進行預處理的，Controller 中渲染了對應的視圖之后請求結束。

4、攔截的請求范圍不同

5、注入Bean情況不同

在實際的業務場景中，應用到過濾器或攔截器，為處理業務邏輯難免會引入一些service服務。

6、控制執行順序不同

實際開發過程中，會出現多個過濾器或攔截器同時存在的情況，不過，有時我們希望某個過濾器或攔截器能優先執行，就涉及到它們的執行順序。

3、什么是SpringMvc，說一說它的幾個核心組成？

① 前端控制器（DispatcherServlet）：主要用于接收客戶端發送的 HTTP 請求、響應結果給客戶端。

② 處理器映射器（HandlerMapping）：根據請求的 URL 來定位到對應的處理器（Handler）。

③ 處理器適配器（HandlerAdapter）：在編寫處理器（Handler）的時候要按照處理器適配器（HandlerAdapter） 要求的規則去編寫，通過適配器可以正確地去執行 Handler。

④ 處理器（Handler）：就是我們經常寫的 Controller 層代碼，例如：UserController。

⑤ 視圖解析器（ViewResolver）：進行視圖的解析，將 ModelAndView 對象解析成真正的視圖（View）對象返回給前端控制器。

⑥ 視圖（View）：View 是一個接口， 它的實現類支持不同的視圖類型（JSP，FreeMarker，Thymleaf 等）。

4、Springmvc執行流程？

① 首先，用戶發送 HTTP 請求給 SpringMVC 前端控制器 DispatcherServlet。

② DispatcherServlet 收到請求后，調用HandlerMapping 處理器映射器，根據請求 URL 去定位到具體的處理器 Handler，并將該處理器對象返回給 DispatcherServlet 。

③ 接下來，DispatcherServlet 調用 HandlerAdapter 處理器適配器，通過處理器適配器調用對應的 Handler 處理器處理請求，并向前端控制器返回一個 ModelAndView 對象。

④ 然后，DispatcherServlet 將 ModelAndView 對象交給 ViewResoler 視圖解析器去處理，并返回指定的視圖 View 給前端控制器。

⑤ DispatcherServlet 對 View 進行渲染（即將模型數據填充至視圖中）。View 是一個接口， 它的實現類支持不同的視圖類型（JSP，FreeMarker，Thymleaf 等）。

⑥ DispatcherServlet 將頁面響應給用戶。

5、什么是MyBatis 一、二級緩存？

一級緩存：作用域是 SqlSession，同一個 SqlSession 中執行相同的 SQL 查詢(相同的SQL和參數)，第一次會去查詢數據庫并寫在緩存中，第二次會直接從緩存中取。

• 一級緩存是基于 PerpetualCache 的 HashMap 本地緩存，默認打開一級緩存。
• 失效策略：當執行 SQL 時候兩次查詢中間發生了增刪改的操作，即 insert、update、delete 等操作 commit 后會清空該 SqlSession 緩存。

二級緩存：作用域是 NameSpace 級別，多個 SqlSession 去操作同一個 NameSpace 下的 Mapper 文件的 sql 語句，多個 SqlSession可以共用二級緩存，如果兩個 Mapper 的 NameSpace 相同，（即使是兩個 Mapper，那么這兩個 Mapper 中執行 sql 查詢到的數據也將存在相同的二級緩存區域中）。

• 二級緩存也是基于 PerpetualCache 的 HashMap 本地緩存，可自定義存儲源，如 Ehcache/Redis等。默認是沒有開啟二級緩存。
• 操作流程：第一次調用某個 NameSpace 下的 SQL 去查詢信息，查詢到的信息會存放該 Mapper對應的二級緩存區域。第二次調用同個 NameSpace 下的 Mapper 映射文件中的相同的 sql 去查詢信息時，會去對應的二級緩存內取結果。
• 失效策略：執行同個 NameSpace 下的 Mapepr 映射文件中增刪改 sql，并執行了commit 操作，會清空該二級緩存。

注意：實現二級緩存的時候，MyBatis 建議返回的 POJO 是可序列化的， 也就是建議實現 Serializable 接口。

如圖所示：

當 Mybatis 調用 Dao 層查詢數據庫時，先查詢二級緩存，二級緩存中無對應數據，再去查詢一級緩存，一級緩存中也沒有，最后去數據庫查找。

6、為什么說 Mybatis 是半自動ORM映射工具？它與全自動的區別在哪里？

ORM 是什么?

ORM（Object Relational Mapping），對象關系映射，是一種為了解決關系型數據庫數據與簡單 Java 對象（POJO）建立映射關系的技術。

為什么說 Mybatis 是半自動ORM映射工具？它與全自動的區別在哪里？

• 首先，像 Hibernate、JPA 這種屬于全自動 ORM 映射工具，使用 Hibernate 查詢關聯對象或者關聯集合對象時，可以根據對象關系模型直接獲取，所以它是全自動的。
• 而 Mybatis 在查詢關聯對象或關聯集合對象時，需要手動編寫 sql 來完成，所以，稱之為半自動 ORM 映射工具。
• 換句話來解釋就是說 MyBatis 是 半自動 ORM 最主要的一個原因是，它需要在 XML 或者注解里通過手動或插件生成 SQL，才能完成 SQL 執行結果與對象映射綁定。

7、能否簡單說下Mybatis加載的流程？

• MyBatis 是以一個 SqlSessionFactory 實例為核心，SqlSessionFactory 的實例可以通過 SqlSessionFactoryBuilder 獲得。
• SqlSessionFactoryBuilder 可以從 XML 配置文件或一個預先配置的 Configuration 實例來構建出 SqlSessionFactory 實例。
• SqlSessionFactory 實例工廠可以生產 SqlSession ，它里面提供了在數據庫執行 SQL 命令所需的所有方法。

具體流程：

① 加載配置文件：需要加載的配置文件包括全局配置文件(mybatis-config.xml)和 SQL(Mapper.xml) 映射文件，其中全局配置文件配置了Mybatis 的運行環境信息(數據源、事務等)，SQL映射文件中配置了與 SQL 執行相關的信息。

② 創建會話工廠：MyBatis通過讀取配置文件的信息來構造出會話工廠(SqlSessionFactory)，即通過SqlSessionFactoryBuilder 構建 SqlSessionFactory。

③ 創建會話：擁有了會話工廠，MyBatis就可以通過它來創建會話對象(SqlSession)。會話對象是一個接口，該接口中包含了對數據庫操作的增刪改查方法。

④ 創建執行器：因為會話對象本身不能直接操作數據庫，所以它使用了一個叫做數據庫執行器(Executor)的接口來幫它執行操作。

⑤ 封裝SQL對象：執行器(Executor)將待處理的SQL信息封裝到一個對象中(MappedStatement)，該對象包括SQL語句、輸入參數映射信息(Java簡單類型、HashMap或POJO)和輸出結果映射信息(Java簡單類型、HashMap 或 POJO)。

⑥ 操作數據庫：擁有了執行器和SQL信息封裝對象就使用它們訪問數據庫了，最后再返回操作結果，結束流程。

8、什么是 Spring 三級緩存？

所謂三級緩存，其實就是org.springframework.beans.factory包下DefaultSingletonBeanRegistry類中的三個成員屬性：

• Spring一級緩存：用來保存實例化、初始化都完成的對象

Key：beanName

Value: Bean實例

private final Map<String, Object> singletonObjects=new ConcurrentHashMap<>(256);

• Spring二級緩存：用來保存實例化完成，但是未初始化完成的對象

Key：beanName

Value: Bean實例

和一級緩存一樣也是保存BeanName和創建bean實例之間的關系，與singletonObjects不同之處在于，當一個單例bean被放在里面后，那么bean還在創建過程中，就可以通過getBean方法獲取到了，其目的是用來循環檢測引用！

private final Map<String, Object> earlySingletonObjects=new ConcurrentHashMap<>(16);

• Spring三級緩存：用來保存一個對象工廠，提供一個匿名內部類，用于創建二級緩存中的對象

Key：beanName

Value: Bean的工廠

private final Map<String, ObjectFactory<?>> singletonFactories=new HashMap<>(16);

如圖所示，除了三級緩存是一個HashMap，其他兩個都是ConcurrentHashMap：

Spring之所以引入三級緩存，目的就是為了解決循環依賴問題！

除了上面三個Map集合，還有另一個集合這里也說一下：

用來保存當前所有已注冊的Bean

private final Set<String> registeredSingletons=new LinkedHashSet<>(256);

9、什么是 Spring循環依賴問題？如何解決？

首先，Spring 解決循環依賴有兩個前提條件：

• Setter方式注入造成的循環依賴（構造器方式注入不可以）
• 必須是單例

本質上解決循環依賴的問題就是依靠三級緩存，通過三級緩存提前拿到未初始化的對象。下面我們來看一個循環依賴的例子：

A 對象的創建過程：

1.創建對象A，實例化的時候把A對象工廠放入三級緩存

2.A 注入屬性時，發現依賴 B，轉而去實例化 B

3.同樣創建對象 B，注入屬性時發現依賴 A，一次從一級到三級緩存查詢 A，從三級緩存通過對象工廠拿到 A，把 A 放入二級緩存，同時刪除三級緩存中的 A，此時，B 已經實例化并且初始化完成，把 B 放入一級緩存。

4.接著繼續創建 A，順利從一級緩存拿到實例化且初始化完成的 B 對象，A 對象創建也完成，刪除二級緩存中的 A，同時把 A 放入一級緩存。

5.最后，一級緩存中保存著實例化、初始化都完成的A、B 對象。

從上面5步驟的分析可以看出，三級緩存解決循環依賴是通過把實例化和初始化的流程分開了，所以如果都是用構造器的話，就沒法分離這個操作(因為構造器注入實例化和初始是一起進行的)。因此構造器方式注入的話是無法解決循環依賴問題的。

解決循環依賴為什么必須要要三級緩存？二級不行嗎？

答案：不可以！

使用三級緩存而非二級緩存并不是因為只有三級緩存才能解決循環引用問題，其實二級緩存同樣也能很好解決循環引用問題。

使用三級而非二級緩存并非出于IOC的考慮，而是出于AOP的考慮，即若使用二級緩存，在AOP情形下，往二級緩存中放一個普通的Bean對象，BeanPostProcessor去生成代理對象之后，覆蓋掉二級緩存中的普通Bean對象，那么多線程環境下可能取到的對象就不一致了。

• 一句話總結就是，在 AOP 代理增強 Bean 后，會對早期對象造成覆蓋，如果多線程情況下可能造成取到的對象不一致~

10、說說Spring 里用到了哪些設計模式?

單例模式：Spring 中的 Bean 默認情況下都是單例的。無需多說。

工廠模式：工廠模式主要是通過 BeanFactory 和 ApplicationContext 來生產 Bean 對象。

代理模式：最常見的 AOP 的實現方式就是通過代理來實現，Spring主要是使用 JDK 動態代理和 CGLIB 代理。

…

單例模式

單例模式使?場景：

• 業務系統全局只需要?個對象實例，?如發號器、 redis 連接對象等。
• Spring IOC容器中的 Bean 默認就是單例。
• Spring Boot 中的 Controller、Service、Dao 層中通過 @Autowire的依賴注?對象默認都是單例的。

單例模式分類：

• 懶漢：就是所謂的懶加載，延遲創建對象，需要用的時候再創建對象。
• 餓漢：與懶漢相反，提前創建對象。

單例模式實現步驟：

• 私有化構造函數。
• 提供獲取單例的?法。

工廠模式

??模式介紹：它提供了?種創建對象的最佳?式，在創建對象時 不會對客戶端暴露創建邏輯，并且是通過使??個共同的接?來指向新創建的對象。

??模式有 3 種不同的實現?式：

① 簡單??模式（靜態工廠）：通過傳?相關的類型來返回相應的類，這 種?式?較單 ?，可擴展性相對較差。

② ???法模式：通過實現類實現相應的?法來決定相應的返回結果，這種?式的可擴展性?較強。

③ 抽象??模式：基于上述兩種模式的拓展，且?持細化產品。

應?場景：

解耦：分離職責，把復雜對象的創建和使?的過程分開。

復?代碼 降低維護成本：如果對象創建復雜且多處需?到，如果每處都進?編寫，則很多重復代碼，如果業務邏輯發?了改 變，需?四處修改；使???模式統?創建，則只要修改??類即可， 降低成本。

代理模式

代理模式最直觀的解釋就是，通過代理，將被代理對象 “增強”！(即，擴展被代理對象的功能)

代理模式分為靜態代理，和動態代理：動態代理的代理類是動態生成的 ， 靜態代理的代理類是我們提前寫好的邏輯。

Java 中實現動態代理的方式有 2 種：

• JDK 動態代理
• CGLIB 動態代理

今日份分享已結束，請大家多多包涵和指點！