面試題總結-框架篇

這兩天一直忙着面試了，記錄一下提問概率較大的面試題。

Struts2的工做流程。

請求在Struts2框架中的處理大概分爲如下幾個步驟：
1 客戶端初始化一個指向Servlet容器的請求；
2 這個請求通過一系列的過濾器（Filter）（這些過濾器中有一個叫作ActionContextCleanUp的可選過濾器，這個過濾器對於Struts2和其餘框架的集成頗有幫助，例如：SiteMesh Plugin）
3 接着FilterDispatcher被調用，FilterDispatcher詢問ActionMapper來決定這個請是否須要調用某個Action
4 若是ActionMapper決定須要調用某個Action，FilterDispatcher把請求的處理交給ActionProxy
5 ActionProxy經過Configuration Manager詢問框架的配置文件，找到須要調用的Action類
6 ActionProxy建立一個ActionInvocation的實例。
7 ActionInvocation實例使用命名模式來調用，在調用Action的過程先後，涉及到相關攔截器（Intercepter）的調用。
8 一旦Action執行完畢，ActionInvocation負責根據struts.xml中的配置找到對應的返回結果。返回結果一般是（但不老是，也可 能是另外的一個Action鏈）一個須要被表示的JSP或者FreeMarker的模版。

SpringMVC的工做原理。

一、  用戶發送請求至前端控制器DispatcherServlet

二、  DispatcherServlet收到請求調用HandlerMapping處理器映射器。

三、  處理器映射器根據請求url找到具體的處理器，生成處理器對象及處理器攔截器(若是有則生成)一併返回給DispatcherServlet。

四、  DispatcherServlet經過HandlerAdapter處理器適配器調用處理器

五、  執行處理器(Controller，也叫後端控制器)。

六、  Controller執行完成返回ModelAndView

七、  HandlerAdapter將controller執行結果ModelAndView返回給DispatcherServlet

八、  DispatcherServlet將ModelAndView傳給ViewReslover視圖解析器

九、  ViewReslover解析後返回具體View

十、              DispatcherServlet對View進行渲染視圖（即將模型數據填充至視圖中）。

十一、              DispatcherServlet響應用戶

說說你對Spring IOC /AOP的理解。

Ioc—Inversion of Control，即「控制反轉」，不是什麼技術，而是一種設計思想。在Java開發中，Ioc意味着將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。如何理解好Ioc呢？理解好Ioc的關鍵是要明確「誰控制誰，控制什麼，爲什麼是反轉（有反轉就應該有正轉了），哪些方面反轉了」，那咱們來深刻分析一下：

誰控制誰，控制什麼：傳統Java SE程序設計，咱們直接在對象內部經過new進行建立對象，是程序主動去建立依賴對象；而IoC是有專門一個容器來建立這些對象，即由Ioc容器來控制對 象的建立；誰控制誰？固然是IoC 容器控制了對象；控制什麼？那就是主要控制了外部資源獲取（不僅是對象包括好比文件等）。

爲什麼是反轉，哪些方面反轉了：有反轉就有正轉，傳統應用程序是由咱們本身在對象中主動控制去直接獲取依賴對象，也就是正轉；而反轉則是由容器來幫忙建立及注入依賴對象；爲什麼是反轉？由於由容器幫咱們查找及注入依賴對象，對象只是被動的接受依賴對象，因此是反轉；哪些方面反轉了？依賴對象的獲取被反轉了。

AOP是面向切面編程，語言、框架的發展都是一步步的分離、解耦的過程，來下降程序之間的依賴性和耦合性，使其達到標準、易維護、易理解、易複用等目的。
java中通常會說這樣的一句話：「一個方法只作一件事情」。這樣易複用、易理解、易維護。可是如今不少方法沒法作到只作一件事情，咱們的方法除了包含業務邏輯代碼外還須要加例如日誌、事務等相關操做的代碼或代碼引用。這樣咱們一個方法就不是作一件事情，而是作了業務邏輯、日誌、事務三件事情。因而咱們想辦法把日誌、事務定義成一個切面，這樣能夠在代碼須要日誌和事務的時候切入程序。來達到一個方法只作一件事情的目的。

 

Hibernate與MyBatis的區別。

Hibernate 簡介

Hibernate對數據庫結構提供了較爲完整的封裝，Hibernate的O/R Mapping實現了POJO 和數據庫表之間的映射，以及SQL 的自動生成和執行。程序員每每只需定義好了POJO 到數據庫表的映射關係，便可經過Hibernate 提供的方法完成持久層操做。程序員甚至不須要對SQL 的熟練掌握， Hibernate/OJB 會根據制定的存儲邏輯，自動生成對應的SQL 並調用JDBC 接口加以執行。

MyBatis簡介

iBATIS 的着力點，則在於POJO 與SQL之間的映射關係。而後經過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。 相對Hibernate「O/R」而言，iBATIS 是一種「Sql Mapping」的ORM實現。

Hibernate和Mybatis都是orm對象關係映射框架，都是用於將數據持久化的框架技術。
Hiberante較深度的封裝了jdbc，對開發者寫sql的能力要求的不是那麼的高，咱們只要經過hql語句操做對象便可完成對數據持久化的操做了。
另外hibernate可移植性好，如一個項目開始使用的是mysql數據庫，可是隨着業務的發展，現mysql數據庫已經沒法知足當前的繡球了，如今決定使用Oracle數據庫，雖然sql標準定義的數據庫間的sql語句差距不大，可是不一樣的數據庫sql標準仍是有差距的，那麼咱們手動修改起來會存在很大的困難，使用hibernate只需改變一下數據庫方言便可搞定。用hibernate框架，數據庫的移植變的很是方便。
可是hibernate也存在着諸多的不足，好比在實際開發過程當中會生成不少沒必要要的sql語句耗費程序資源，優化起來也不是很方便，且對存儲過程支持的也不夠太強大。可是針對於hibernate它也提供了一些優化策略，好比說懶加載、緩存、策略模式等都是針對於它的優化方案。
Mybatis 也是對jdbc的封裝，可是封裝的沒有hibernate那麼深，咱們能夠再配置文件中寫sql語句，能夠根據需求定製sql語句，數據優化起來較hibernate容易不少。
Mybatis要求程序員寫sql的能力要相對使用hibernate的開發人員要高的多，且可移植性也不是很好。
涉及到大數據的系統使用Mybatis比較好，由於優化較方便。涉及的數據量不是很大且對優化沒有那麼高，可使用hibernate

爲何要使用持久化框架而不用JDBC。

一、  數據庫連接建立、釋放頻繁形成系統資源浪費從而影響系統性能，若是使用數據庫連接池可解決此問題。

二、  Sql語句在代碼中硬編碼，形成代碼不易維護，實際應用sql變化的可能較大，sql變更須要改變java代碼。

三、  使用preparedStatement向佔有位符號傳參數存在硬編碼，由於sql語句的where條件不必定，可能多也可能少，修改sql還要修改代碼，系統不易維護。

四、  對結果集解析存在硬編碼（查詢列名），sql變化致使解析代碼變化，系統不易維護，若是能將數據庫記錄封裝成pojo對象解析比較方便。

寫出你熟悉的開源框架以及各自的做用(項目中爲何使用SSH)

答：框架：hibernate,spring,struts1/struts2.
Hibernate主要用於數據持久化；封裝了JDBC操做；還提供了一個易用的、高效率的對象關係映射框架；
Spring 的控制反轉能起到解耦合的做用；
Struts 主要用於請求處理的流程控制；struts是基於MVC模式的,很好的將應用程序進行了分層，使開發者更關注於業務邏輯的實現；struts有着豐富的taglib,如能靈活運用，則能大大提升開發效率。

 Struts（表示層）+Spring（業務層）+Hibernate（持久層）

如何對hibernate進行優化？

1. 使用雙向一對多關聯，不使用單向一對多
2. 靈活使用單向一對多關聯
3. 不用一對一，用多對一取代
4. 配置對象緩存，不使用集合緩存
5. 一對多集合使用Bag,多對多集合使用Set
6. 繼承類使用顯式多態
7. 表字段要少，表關聯不要怕多，有二級緩存

spring 的優勢都有哪些？

1.下降了組件之間的耦合性 ，實現了軟件各層之間的解耦
2.可使用容易提供的衆多服務，如事務管理，消息服務等
3.容器提供單例模式支持
4.容器提供了AOP技術，利用它很容易實現如權限攔截，運行期監控等功能
5.容器提供了衆多的輔助類，能加快應用的開發
6.spring對於主流的應用框架提供了集成支持，如hibernate，JPA，Struts等
7.spring屬於低侵入式設計，代碼的污染極低
8.獨立於各類應用服務器
9.spring的DI機制下降了業務對象替換的複雜性
10.Spring的高度開放性，並不強制應用徹底依賴於Spring，開發者能夠自由選擇spring的部分或所有

Spring事物的傳播屬性和隔離級別

PROPAGATION_REQUIRED–支持當前事務，若是當前沒有事務，就新建一個事務。這是最多見的選擇。 
PROPAGATION_SUPPORTS–支持當前事務，若是當前沒有事務，就以非事務方式執行。 
PROPAGATION_MANDATORY–支持當前事務，若是當前沒有事務，就拋出異常。 
PROPAGATION_REQUIRES_NEW–新建事務，若是當前存在事務，把當前事務掛起。 
PROPAGATION_NOT_SUPPORTED–以非事務方式執行操做，若是當前存在事務，就把當前事務掛起。 
PROPAGATION_NEVER–以非事務方式執行，若是當前存在事務，則拋出異常。 
PROPAGATION_NESTED–若是當前存在事務，則在嵌套事務內執行。若是當前沒有事務，則進行與PROPAGATION_REQUIRED相似的操做。

  ISOLATION_DEFAULT： 這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別.      另外四個與JDBC的隔離級別相對應 ISOLATION_READ_UNCOMMITTED： 這是事務最低的隔離級別，它充許令外一個事務能夠看到這個事務未提交的數據。      這種隔離級別會產生髒讀，不可重複讀和幻像讀。 ISOLATION_READ_COMMITTED： 保證一個事務修改的數據提交後才能被另一個事務讀取。另一個事務不能讀取該事務未提交的數據 ISOLATION_REPEATABLE_READ： 這種事務隔離級別能夠防止髒讀，不可重複讀。可是可能出現幻像讀。      它除了保證一個事務不能讀取另外一個事務未提交的數據外，還保證了避免下面的狀況產生(不可重複讀)。 ISOLATION_SERIALIZABLE 這是花費最高代價可是最可靠的事務隔離級別。事務被處理爲順序執行。      除了防止髒讀，不可重複讀外，還避免了幻像讀。