目錄
IOC的優點是什麼？什麼是控制反轉（Inversion of Control）與依賴注入（Dependency Injection）
Spring中的@Transactional 放在 類級別 和 方法級別 上有什麼不同？
爲什麼學習spring（優缺點）：
優點
方便解耦，簡化開發
1.Spring 就是一個大工廠，可以將所有對象創建和依賴關係維護，交給 Spring 管理
AOP 編程的支持
2.Spring 提供面向切面編程，可以方便的實現對程序進行權限攔截、運行監控等功能
聲明式事務的支持
3.只需要通過配置就可以完成對事務的管理，而無需手動編程
4.方便程序的測試
5.Spring 對 Junit4 支持，可以通過註解方便的測試 Spring 程序
6.方便集成各種優秀框架，如hibernate,Struts2,JPA等
7.Spring 不排斥各種優秀的開源框架，其內部提供了對各種優秀框架（如：Struts、Hibernate、MyBatis、Quartz 等）的直接支持
8.降低 JavaEE API 的使用難度
9.Spring 對 JavaEE 開發中非常難用的一些 API（JDBC、JavaMail、遠程調用等），都提供了封裝，使這些 API 應用難度大大降低
10. Spring屬於低侵入，代碼污染極低。
缺點
1.jsp中要寫很多代碼、控制器過於靈活，缺少一個公用控制器
2.Spring不支持分佈式，這也是EJB仍然在用的原因之一。
3.原本可以直接new對象的現在變成需要配置操作（僅對於不熟悉的人來說）
4.源碼複雜，底層調用深，大項目對源碼debug有難度
5.測試效率。配置多的話，容器啓動時間比較長，影響測試效率。所有有些測試，我們儘量都不啓動Spring容器。
6.有一定的上手成本（Spring boot幾乎解決了這個問題）
SpringMVC流程：
1、 用戶發送請求至前端控制器DispatcherServlet
2、 DispatcherServlet收到請求調用HandlerMapping處理器映射器。
3、 處理器映射器根據請求url找到具體的處理器，生成處理器對象及處理器攔截器(如果有則生成)一併返回給DispatcherServlet。
4、 DispatcherServlet通過HandlerAdapter處理器適配器調用處理器
5、 執行處理器(Controller，也叫後端控制器)。
6、 Controller執行完成返回ModelAndView
7、 HandlerAdapter將controller執行結果ModelAndView返回給DispatcherServlet
8、 DispatcherServlet將ModelAndView傳給ViewReslover視圖解析器
9、 ViewReslover解析後返回具體View
10、DispatcherServlet對View進行渲染視圖（即將模型數據填充至視圖中）。
11、DispatcherServlet響應用戶
實際加載流程簡述
//1.加載配置文件
doLoadConfig(config.getInitParameter("contextConfigLocation"));
//2.根據配置文件掃描所有的相關的類
doScanner(properties.getProperty("scanPackage"));
//3.初始化所有的相關的類的實例，並且將其放入到IOC容器之中，也就是Map中
doInstance();
//4.實現自動依賴注入
doAutowried();
//5.初始化HandlerMapping
initHandlerMapping();
SpringMVC中MVC分別指什麼，他們怎麼工作的
MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。
m代表model模型，v代表view視圖，c代表controller，控制器。m中包含你寫的業務邏輯，就是取數據的模型，v代表你顯示的視圖，c來控制m和v之間的關係。
SpringMVC攔截器與過濾器的區別
①攔截器是基於java的反射機制的，而過濾器是基於函數回調。
②攔截器不依賴於servlet容器，過濾器依賴於servlet容器。
③攔截器只能對action請求起作用，而過濾器則可以對幾乎所有的請求起作用。
④攔截器可以訪問action上下文、值棧裏的對象，而過濾器不能訪問。
⑤在action的生命週期中，攔截器可以多次被調用，而過濾器只能在容器初始化時被調用一次。
⑥攔截器可以獲取IOC容器中的各個bean，而過濾器就不行，這點很重要，在攔截器裏注入一個service，可以調用業務邏輯。
IOC的優點是什麼？什麼是控制反轉（Inversion of Control）與依賴注入（Dependency Injection）
參考鏈接：http://blog.csdn.net/bestone0213/article/details/47424255
IOC，即控制反轉（Inversion of Control，英文縮寫爲IoC），是一個重要的面向對象編程的法則來削減計算機程序的耦合問題，也是輕量級的Spring框架的核心。 不是什麼技術，而是一種設計思想。Ioc意味着將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。
比如以前找女朋友需要自己去做很多事情，而ioc相當於有了一個婚介所，我們只需要在上面說明我們需要什麼樣的女朋友，婚介所就會把這樣的女朋友給我們，如果這個女朋友不是我們想要的，我們就會拋出異常，後面的事就都不關我們管了。
Spring所倡導的開發方式就是如此，所有的類都會在spring容器中登記，告訴spring你是個什麼東西，你需要什麼東西，然後spring會在系統運行到適當的時候，把你要的東西主動給你，同時也把你交給其他需要你的東西。所有的類的創建、銷燬都由 spring來控制，也就是說控制對象生存週期的不再是引用它的對象，而是spring。對於某個具體的對象而言，以前是它控制其他對象，現在是所有對象都被spring控制，所以這叫控制反轉。
IoC的一個重點是在系統運行中，動態的向某個對象提供它所需要的其他對象。這一點是通過DI（Dependency Injection，依賴注入）來實現的。
控制反轉一般分爲兩種類型：
依賴注入（Dependency Injection，簡稱DI）
方法：
Spring：@Autowired
Java：@Resource
Java EE：@Inject
途徑：
字段（Field）注入
屬性（Setter）注入
方法（Method）注入
構造器（Constructor）注入
依賴查找（Dependency Lookup，簡稱DL）：已被廢棄
ID、別名、名稱查找：BeanFactory#getBean(String):Object
類型查找：BeanFactory#getBean(Class):T
註解查找：listableBeanFactory#getBeansWithAnnotation(Class)
FactoryBean查找：FactoryBean#getObject()
ObjectFactory查找：objectFactory#getObject()
IOC的優點:實現組件之間的解耦，提高程序的靈活性和可維護性。
IOC的缺點:
1、創建對象的步驟變複雜了，不直觀，當然這是對不習慣這種方式的人來說的。
2、因爲使用反射來創建對象，所以在效率上會有些損耗。但相對於程序的靈活性和可維護性來說，這點損耗是微不足道的。
3、缺少IDE重構的支持，如果修改了類名，還需到XML文件中手動修改，這似乎是所有XML方式的缺憾所在。
IOC的應用：
IOC模式將耦合代碼從程序中移出，放到統一的XML文件中管理。由IOC容器通過配置文件來管理對象的生命週期、依賴關係等，這樣就不用重新修改並編譯具體的代碼，從而實現組件之間的解耦。
Spring AOP原理
參考鏈接：https://blog.csdn.net/qq_35642036/article/details/79070152
AOP編程（面向切面編程）：這種在運行時，動態地將代碼切入到類的指定方法、指定位置上的編程思想就是面向切面的編程。
面向切面編程（AOP是Aspect OrientedProgram的首字母縮寫），我們知道，面向對象的特點是繼承、多態和封裝。而封裝就要求將功能分散到不同的對象中去，這在軟件設計中往往稱爲職責分配。實際上也就是說，讓不同的類設計不同的方法。這樣代碼就分散到一個個的類中去了。這樣做的好處是降低了代碼的複雜程度，使類可重用。
但是人們也發現，在分散代碼的同時，也增加了代碼的重複性。什麼意思呢？比如說，我們在兩個類中，可能都需要在每個方法中做日誌。按面向對象的設計方法，我們就必須在兩個類的方法中都加入日誌的內容。也許他們是完全相同的，但就是因爲面向對象的設計讓類與類之間無法聯繫，而不能將這些重複的代碼統一起來。
也許有人會說，那好辦啊，我們可以將這段代碼寫在一個獨立的類獨立的方法裏，然後再在這兩個類中調用。但是，這樣一來，這兩個類跟我們上面提到的獨立的類就有耦合了，它的改變會影響這兩個類。那麼，有沒有什麼辦法，能讓我們在需要的時候，隨意地加入代碼呢？這種在運行時，動態地將代碼切入到類的指定方法、指定位置上的編程思想就是面向切面的編程。
一般而言，我們管切入到指定類指定方法的代碼片段稱爲切面，而切入到哪些類、哪些方法則叫切入點。有了AOP，我們就可以把幾個類共有的代碼，抽取到一個切片中，等到需要時再切入對象中去，從而改變其原有的行爲。
這樣看來，AOP其實只是OOP的補充而已。OOP從橫向上區分出一個個的類來，而AOP則從縱向上向對象中加入特定的代碼。有了AOP，OOP變得立體了。如果加上時間維度，AOP使OOP由原來的二維變爲三維了，由平面變成立體了。從技術上來說，AOP基本上是通過代理機制實現的。
AOP在編程歷史上可以說是里程碑式的，對OOP編程是一種十分有益的補充。
AOP的源碼中用到了兩種動態代理來實現攔截切入功能：jdk動態代理和cglib動態代理。兩種方法同時存在，各有優劣。jdk動態代理是由java內部的反射機制來實現的，cglib動態代理底層則是藉助asm來實現的。總的來說，反射機制在生成類的過程中比較高效，而asm在生成類之後的相關執行過程中比較高效（可以通過將asm生成的類進行緩存，這樣解決asm生成類過程低效問題）。還有一點必須注意：jdk動態代理的應用前提，必須是目標類基於統一的接口。如果沒有上述前提，jdk動態代理不能應用。由此可以看出，jdk動態代理有一定的侷限性，cglib這種第三方類庫實現的動態代理應用更加廣泛，且在效率上更有優勢。
JDK動態代理生成的是兄弟，而Cglib生成的是子類
SpringBoot和SpringMVC的區別
參考鏈接：https://blog.csdn.net/u014590757/article/details/79602309#commentBox
spring boot只是一個配置工具,整合工具,輔助工具.
springmvc是框架,項目中實際運行的代碼
Spring 框架就像一個家族，有衆多衍生產品例如 boot、security、jpa等等。但他們的基礎都是Spring 的ioc和 aop. ioc 提供了依賴注入的容器， aop解決了面向橫切面的編程，然後在此兩者的基礎上實現了其他延伸產品的高級功能。
Spring MVC是基於Servlet 的一個 MVC 框架，主要解決 WEB 開發的問題，因爲 Spring 的配置非常複雜，各種XML、 JavaConfig、hin處理起來比較繁瑣。於是爲了簡化開發者的使用，從而創造性地推出了Spring boot，約定優於配置，簡化了spring的配置流程。
說得更簡便一些：Spring 最初利用“工廠模式”（DI）和“代理模式”（AOP）解耦應用組件。大家覺得挺好用，於是按照這種模式搞了一個 MVC框架（一些用Spring 解耦的組件），用來開發 web 應用（ SpringMVC ）。然後發現每次開發都寫很多樣板代碼，爲了簡化工作流程，於是開發出了一些“懶人整合包”（starter），這套就是 Spring Boot。
Spring MVC提供了一種輕度耦合的方式來開發web應用。
Spring Boot實現了自動配置，降低了項目搭建的複雜度。
衆所周知Spring框架需要進行大量的配置，Spring Boot引入自動配置的概念，讓項目設置變得很容易。Spring Boot本身並不提供Spring框架的核心特性以及擴展功能，只是用於快速、敏捷地開發新一代基於Spring框架的應用程序。也就是說，它並不是用來替代Spring的解決方案，而是和Spring框架緊密結合用於提升Spring開發者體驗的工具。同時它集成了大量常用的第三方庫配置(例如Jackson, JDBC, Mongo, Redis, Mail等等)，Spring Boot應用中這些第三方庫幾乎可以零配置的開箱即用(out-of-the-box)，大部分的Spring Boot應用都只需要非常少量的配置代碼，開發者能夠更加專注於業務邏輯。
對使用者來說，換用Spring Boot以後，項目初始化方法變了，配置文件變了，另外就是不需要單獨安裝Tomcat這類容器服務器了，maven打出jar包直接跑起來就是個網站，但你最核心的業務邏輯實現與業務流程實現沒有任何變化。
你是一個木匠，spring是錘子，spring MVC是釘子，而springboot就是一套 規定尺寸範圍的錘子和釘子。
如果我們想要開發web項目，可以直接用springMVC進行配置，也可以用spring boot配置使其成爲一個mvc，但是其幫我們做了很多mvc的配置，我們只要用就行了。
所以，用最簡練的語言概括就是：
Spring 是一個“引擎”；
Spring MVC 是基於Spring的一個 MVC 框架；
Spring Boot 是基於Spring4的條件註冊的一套快速開發整合包。
Spring Boot和Spring Cloud的區別
1、Spring boot 是 Spring 的一套快速配置腳手架，可以基於spring boot 快速開發單個微服務；Spring Cloud是一個基於Spring Boot實現的雲應用開發工具；
2、Spring boot專注於快速、方便集成的單個個體，Spring Cloud是關注全局的服務治理框架；
3、spring boot使用了默認大於配置的理念，很多集成方案已經幫你選擇好了，能不配置就不配置，Spring Cloud很大的一部分是基於Spring boot來實現。
4、Spring boot可以離開Spring Cloud獨立使用開發項目，但是Spring Cloud離不開Spring boot，屬於依賴的關係。
Spring常用註解
參考鏈接：https://mp.weixin.qq.com/s/4T9zJ6A12kfCxCRyS7gQaA
Spring中的@Transactional 放在 類級別 和 方法級別 上有什麼不同？
@Transactional放在類級別上等同於該類的每個方法都放上了@Transactional
放在方法級別上表示僅對方法有效，還可以覆蓋類上的註解
Spring Bean生命週期詳解，其是怎麼回收的
參考鏈接：https://blog.csdn.net/a327369238/article/details/52193822
SpringMVC與Structs2的區別
1、Struts2是類級別的攔截， 一個類對應一個request上下文，SpringMVC是方法級別的攔截，一個方法對應一個request上下文，而方法同時又跟一個url對應,所以說從架構本身上SpringMVC就容易實現restful url,而struts2的架構實現起來要費勁，因爲Struts2中Action的一個方法可以對應一個url，而其類屬性卻被所有方法共享，這也就無法用註解或其他方式標識其所屬方法了。
2、由上邊原因，SpringMVC的方法之間基本上獨立的，獨享request response數據，請求數據通過參數獲取，處理結果通過ModelMap交回給框架，方法之間不共享變量，而Struts2搞的就比較亂，雖然方法之間也是獨立的，但其所有Action變量是共享的，這不會影響程序運行，卻給我們編碼 讀程序時帶來麻煩，每次來了請求就創建一個Action，一個Action對象對應一個request上下文。
3、由於Struts2需要針對每個request進行封裝，把request，session等servlet生命週期的變量封裝成一個一個Map，供給每個Action使用，並保證線程安全，所以在原則上，是比較耗費內存的。
4、 攔截器實現機制上，Struts2有以自己的interceptor機制，SpringMVC用的是獨立的AOP方式，這樣導致Struts2的配置文件量還是比SpringMVC大。
5、SpringMVC的入口是servlet，而Struts2是filter（這裏要指出，filter和servlet是不同的。以前認爲filter是servlet的一種特殊），這就導致了二者的機制不同，這裏就牽涉到servlet和filter的區別了。
6、SpringMVC集成了Ajax，使用非常方便，只需一個註解@ResponseBody就可以實現，然後直接返回響應文本即可，而Struts2攔截器集成了Ajax，在Action中處理時一般必須安裝插件或者自己寫代碼集成進去，使用起來也相對不方便。
7、SpringMVC驗證支持JSR303，處理起來相對更加靈活方便，而Struts2驗證比較繁瑣，感覺太煩亂。
8、Spring MVC和Spring是無縫的。從這個項目的管理和安全上也比Struts2高（當然Struts2也可以通過不同的目錄結構和相關配置做到SpringMVC一樣的效果，但是需要xml配置的地方不少）。
9、 設計思想上，Struts2更加符合OOP的編程思想， SpringMVC就比較謹慎，在servlet上擴展。
10、SpringMVC開發效率和性能高於Struts2。
11、SpringMVC可以認爲已經100%零配置。