面試整理

SpringMVC 和Struts2的區別 
1. 機制：
spring mvc的入口是servlet，而struts2是filter，這樣就導致了二者的機制不同。   
2. 性能：
spring會稍微比struts快。spring mvc是基于方法的設計，而sturts
是基于類，每次發一次請求都會實例一個action，每個action都會被注
入屬性，而spring基于方法，粒度更細，但要小心把握像在servlet控
制數據一樣。spring3 mvc是方法級別的攔截，攔截到方法后根據參數
上的注解，把request數據注入進去，在spring3 mvc中，一個方法對應
一個request上下文。而struts2框架是類級別的攔截，每次來了請求就
創建一個Action，然后調用setter getter方法把request中的數據注
入；struts2實際上是通 setter getter方法與request打交道的；
struts2中，一個Action對象對應一個request上下文。   
3. 參數傳遞：
struts是在接受參數的時候，可以用屬性來接受參數，這就說明參數是讓多個方法共享的。   
4. 設計思想上：
struts更加符合oop(面向對象編程)的編程思想， spring就比較謹慎，在servlet上擴展。
5. intercepter的實現機制：
struts有自己的interceptor機制，spring mvc用的是獨立的AOP方式
。這樣導致struts的配置文件量還是比spring mvc大，雖然struts的配
置能繼承，所以我覺得論使用上來講，spring mvc使用更加簡潔，開發
效率Spring MVC確實比struts2高。spring mvc是方法級別的攔截，一
個方法對應一個request上下文，而方法同時又跟一個url對應，所以說
從架構本身上spring3 mvc就容易實現restful url。struts2是類級別
的攔截，一個類對應一個request上下文；實現restful url要費勁，因
為struts2 action的一個方法可以對應一個url；而其類屬性卻被所有
方法共享，這也就無法用注解或其他方式標識其所屬方法了。spring3 
mvc的方法之間基本上獨立的，獨享request response數據，請求數據
通過參數獲取，處理結果通過ModelMap交回給框架方法之間不共享變量
，而struts2搞的就比較亂，雖然方法之間也是獨立的，但其所有
Action變量是共享的，這不會影響程序運行，卻給我們編碼，讀程序時帶來麻煩。 
6. 另外，spring3 mvc的驗證也是一個亮點，支持JSR303，處理ajax
的請求更是方便，只需一個注解@ResponseBody ，然后直接返回響應文本即可。

MyBatis與hibernate區別
1. hibernate是全自動，而mybatis是半自動。
hibernate完全可以通過對象關系模型實現對數據庫的操作，擁有完整
的JavaBean對象與數據庫的映射結構來自動生成sql。而mybatis僅有基
本的字段映射，對象數據以及對象實際關系仍然需要通過手寫sql來實現和管理。
2. hibernate數據庫移植性遠大于mybatis。
hibernate通過它強大的映射結構和hql語言，大大降低了對象與數據庫
（oracle、MySQL等）的耦合性，而mybatis由于需要手寫sql，因此與
數據庫的耦合性直接取決于程序員寫sql的方法，如果sql不具通用性而
用了很多某數據庫特性的sql語句的話，移植性也會隨之降低很多，成
本很高。
3. hibernate擁有完整的日志系統，mybatis則欠缺一些。
hibernate日志系統非常健全，涉及廣泛，包括：sql記錄、關系異常、
優化警告、緩存提示、臟數據警告等；而mybatis則除了基本記錄功能
外，功能薄弱很多。
4. mybatis相比hibernate需要關心很多細節
hibernate配置要比mybatis復雜的多，學習成本也比mybatis高。但也
正因為mybatis使用簡單，才導致它要比hibernate關心很多技術細節。
mybatis由于不用考慮很多細節，開發模式上與傳統jdbc區別很小，因
此很容易上手并開發項目，但忽略細節會導致項目前期bug較多，因而
開發出相對穩定的軟件很慢，而開發出軟件卻很快。hibernate則正好
與之相反。但是如果使用hibernate很熟練的話，實際上開發效率絲毫
不差于甚至超越mybatis。
5. sql直接優化上，mybatis要比hibernate方便很多
由于mybatis的sql都是寫在xml里，因此優化sql比hibernate方便很多
。而hibernate的sql很多都是自動生成的，無法直接維護sql；雖有hql
，但功能還是不及sql強大，見到報表等變態需求時，hql也歇菜，也就
是說hql是有局限的；hibernate雖然也支持原生sql，但開發模式上卻
與orm不同，需要轉換思維，因此使用上不是非常方便。總之寫sql的靈活度上hibernate不及mybatis。

JAVA8 十大新特性
1.Java 8允許給接口添加一個非抽象的方法實現，使用 default關鍵字
2.ambda表達式都對應一個類型，通常是接口類型
3.“函數式接口”是指僅僅只包含一個抽象方法的接口，每一個該類型的lambda表達式都會被匹配到這個抽象方法。因為 默認方法 不算抽象方法，所以你也可以給你的函數式接口添加默認方法。
將lambda表達式當作任意只包含一個抽象方法的接口類型，確保你的接
口一定達到這個要求，你只需要給你的接口添加 @FunctionalInterface 注解，編譯器如果發現你標注了這個注解的接口有多于一個抽象方法的時候會報錯的
4.Java 8 允許你使用 :: 關鍵字來傳遞方法或者構造函數引用，上面的代碼展示了如何引用一個靜態方法，我們也可以引用一個對象的方法
5.直接訪問標記了final的外層局部變量，或者實例的字段以及靜態變量。
6.可以直接在lambda表達式中訪問外層的局部變量，和匿名對象不同的是，這里的變量num可以不用聲明為final
7.lambda內部對于實例的字段以及靜態變量是即可讀又可寫。該行為和匿名對象是一致的
8.JDK 1.8 API包含了很多內建的函數式接口，在老Java中常用到的比
如Comparator或者Runnable接口，這些接口都增加了
@FunctionalInterface注解以便能用在lambda上。
Java 8 API同樣還提供了很多全新的函數式接口來讓工作更加方便，有
一些接口是來自Google Guava庫里的
9.Java 8 在包java.time下包含了一組全新的時間日期API。新的日期API和開源的Joda-Time庫差不多，但又不完全一樣
10.在Java 8中支持多重注解

?

Spring MVC具體步驟：1、 首先用戶發送請求——>DispatcherServlet，前端控制器收到請求后自己不進行處理，而是委托給其他的解析器進行處理，作為統一訪問點，進行全局的流程控制；2、 DispatcherServlet——>HandlerMapping，HandlerMapping 將會把請求映射為 HandlerExecutionChain 對象（包含一個 Handler 處理器（頁面控制器）對象、多個 HandlerInterceptor 攔截器）對象，通過這種策略模式，很容易添加新的映射策略；3、 DispatcherServlet——>HandlerAdapter，HandlerAdapter 將會把處理器包裝為適配器，從而支持多種類型的處理器，即適配器設計模式的應用，從而很容易支持很多類型的處理器；4、 HandlerAdapter——>處理器功能處理方法的調用，HandlerAdapter 將會根據適配的結果調用真正的處理器的功能處理方法，完成功能處理；并返回一個 ModelAndView 對象（包含模型數據、邏輯視圖名）；5、 ModelAndView 的邏輯視圖名——> ViewResolver， ViewResolver 將把邏輯視圖名解析為具體的 View，通過這種策略模式，很容易更換其他視圖技術；6、 View——>渲染，View 會根據傳進來的 Model 模型數據進行渲染，此處的 Model 實際是一個 Map 數據結構，因此很容易支持其他視圖技術；7、 返回控制權給 DispatcherServlet，由 DispatcherServlet 返回響應給用戶，到此一個流程結束。
struts2原型圖
用戶請求-->ActionMapper(Action映射)-->FilterDispatcher(轉發)-->ActionProxy(Action代理)
-->讀取配置文件-->比對struts.xml中配置?-->ActionInvocation(Action核心調度器)
-->經過層層的(Interceptor)過濾-->執行Action中的method方法-->方法執行完后返回Result結果
-->根據返回結果讀取頁面(Template)-->再一次經過層層(Interceptor)過濾-à響應給用戶

Freemarker的使用方法
第一步：把freemarker的jar包添加到工程中
第二步：freemarker的運行不依賴web容器，可以在java工程中運行。創建一個測試方法進行測試。
第三步：創建一個Configration對象,該對象負責管理Freemarker的模板加載路徑，負責生成模板實例
第四步：告訴config對象模板文件存放的路徑。
第五步：設置config的默認字符集。一般是utf-8
第六步：從config對象中獲得模板對象。需要制定一個模板文件的名字。
第七步：創建模板需要的數據集。可以是一個map對象也可以是一個pojo，把模板需要的數據都放入數據集。數據模型就是一個MAP集合
第八步：創建一個Writer對象，指定生成的文件保存的路徑及文件名。
第九步：調用模板對象的process方法生成靜態文件。需要兩個參數數據集和writer對象。
第十步：關閉writer對象。

?