【史上最全】J2EE 知識點匯總（j2*j2）
一、前言
對于后端開發求職者來說，J2EE是必備技能，此篇博文通過梳理工作過程中常用、面試時高頻面點相關內容，特輸出此文，希望能夠幫助求職者往前邁進一步。
二、Java 基礎
2.1 jdk 1.8 新特性（核心是Lambda 表達式）
接口的默認方法（給接口添加一個非抽象的方法實現，只需default關鍵字即可）。采用接口的默認方法，還是為了解決java不能多繼承的原因。
Lambda 表達式（使代碼變得異常簡潔）
Lambda 表達式其實是一種函數值編程，都是直接調用函數，而且編譯器可以自動推導出參數的類型。
Collections.sort(names, (a, b) -> b.compareTo(a)); //字符串按字母從后往前排
使用 :: 關鍵字來傳遞方法或者構造函數引用。
Converter
可以直接在lambda表達式訪問外層的局部變量
final int num = 1; Converter
2.2 java 存在內存泄露和內存溢出的應用場景
靜態集合類，使用Set、Vector、HashMap等集合類的時候要特別注意，當這些類被定義成靜態的時候，由于他們的生命周期跟應用程序一樣長，這時候就有可能發生內存泄露。
class StaticTest { private static Vector v = new Vector(10); public void init() { for (int i=1; i< 100; i++) { Object obj = new Object(); v.add(obj); obj = null; } } }
在上面的代碼中，循環申請object對象，并添加到Vector中，然后設置object=null（就是清除棧中引用變量object）,但是這些對象被vector引用著，必然不能被GC回收，造成內存泄露。因此要釋放這些對象，還需要將它們從vector中刪除，最簡單的方法就是將vector=null,清空集合類中的引用。
-：在java編程中，我們都需要和-打交道，通常一個應用中會用到很多-，我們會調用一個控件，諸如addxxxListener()等方法來增加-，但往往釋放的時候卻沒有去刪除這些-，從而增加內存泄露的機會。
注意??：對于物理連接，一般把這些代碼放在spring容器中，避免內存泄露。
2.3 匿名內部類是什么？如何訪問在其外面定義的變量？
匿名內部類是什么？
匿名內部類沒有訪問修飾符；
當所在方法的形參需要被匿名內部類使用，那么這個形參類型就必須為final；
匿名內部類沒有構造方法，因為它連名字都沒有何來構造方法；
如何訪問在其外面定義的變量？
當所在方法的形參需要被匿名內部類使用，那么這個形參類型就必須為final。
三、J2EE 基礎
3.1 servlet 生命周期
Servlet接口定義了5個方法，其中前三個方法與servlet生命周期有關：
void init(ServletConfig config);
Void service(ServletRequest req, ServletResponse resp);
Void destory();
java.lang.String getServletInfo();
ServletConfig getServletConfig();
Web容器加載servlet并將其實例化后，servlet生命周期開始，容器運行其init()方法進行servlet的初始化；請求到達時調用servlet的service()方法，service()方法會根據需要調用與請求對應的doGet或doPost等方法；當服務器關閉或項目被卸載時，服務器會將servlet實例銷毀，此時會調用servlet的destroy()方法。
Servlet的生命周期分為5個階段：加載、創建、初始化、處理客戶請求、卸載。
加載：容器通過類加載器使用servlet類對應的文件加載servlet;
創建：通過調用servlet構造函數創建一個servlet對象;
初始化：調用init方法初始化;
處理客戶請求：每當有一個客戶請求，容器會創建一個線程來處理客戶請求;
卸載：調用destroy()方法讓servlet自己釋放其占用的資源;
3.2 保存會話狀態方式，有哪些區別？
由于http協議本身是無狀態的，服務器為了區分不同的用戶，就需要對用戶會話進行跟蹤，簡單的說就是為用戶進行登記，為用戶分配唯一的id,下一次用戶在請求中包含此id,服務器據此判斷到底是哪一個用戶。
URL重寫：在url中添加用戶會話信息作為請求參數，或者將唯一的會話id添加到url結尾以標識一個會話。
設置表單隱藏域：將和會話跟蹤相關的字段添加到隱藏表單域中，這些信息不會在瀏覽器中顯示但是提交表單時會提交給服務器。
這兩種方式很難處理跨越多個頁面的信息傳遞，因為如果每次都要修改url或則在頁面中添加隱式表單域來存儲用戶會話相關信息，事情將變得非常麻煩。
html5中可以使用web storage技術通過javaScript來保存數據，例如可以使用localStorage和sessionStroage來保存用戶會話的信息，也能夠實現會話跟蹤。
3.3 cookie 和 session 的區別
session在服務器端，cookie在客戶端（瀏覽器）;
Session的運行依賴session id, 而session id是存在cookie中的，也就是說，如果瀏覽器禁止了cookie，同時session也會失效（但是可以通過其它方式實現，比如在url中傳遞session id）;
Session可以放在文件、數據庫或內存中都可以;
用戶驗證一般會用session;
Cookie不是很安全，別人可以分析存在本地的cookie并進行cookie欺騙，考慮到安全應當使用session;
Session會在一定時間內保存在服務器上，當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie;
單個cookie保存的數據不能超過4k，很多瀏覽器都限制一個站點最多保存20個cookie。
3.4 web.xml中標簽加載順序
加載順序：context-param -> listener -> filter -> servlet
（1）tomcat加載應用程序都是從讀取web.xml文件開始的。讀web.xml的核心就是從讀節點開始listener>filter>servlet。其實還有一個
context-param 加載上下文的配置文件（主要是java bean）
listener-
通過-的通配符，將配置信息加載到spring容器中。還有一般事務寫在spring（業務邏輯層），事務的啟動也是靠listener。
filter過濾器
Struts就是依靠過濾器來實現action的訪問。
servlet是我們的后臺程序java類。
3.5 頁面傳值方法
表單傳值，通過request根據參數取值；
直接在地址欄輸入頁面的地址，在后面加？，然后把要傳的參數及值寫在后面，若有多個用&隔開；
在form中還可以用hidden（隱藏）；
四、SSH三大框架
4.1 Struts
用戶發出http請求；
tomcat讀取web.xml配置文件；
通過過濾器讀取Struts.xml配置文件至內存；
根據web.xml配置，該請求被核心控制器FilterDispatcher接收（攔截這些請求交由Struts.xml處理）；
struts.xml配置接收到這些請求，找到需要調用的action類和方法，并通過依賴注入方式，將值注入action（到對應的servlet中進行處理）；
action調用業務邏輯組件處理業務邏輯，比如基本的數據增刪改查、其他的業務處理；
action執行完畢，根據struts.xml中的配置找到對應的返回結果result,并跳轉到相應頁面；
從action類上分析:
1.Struts1要求Action類繼承一個抽象基類。Struts1的一個普遍問題是使用抽象類編程而不是接口。
Struts 2 Action類可以實現一個Action接口，也可實現其他接口，使可選和定制的服務成為可能。Struts2提供一個ActionSupport基類去實現常用的接口。Action接口不是必須的，任何有execute標識的POJO對象（就是簡單的javabean）都可以用作Struts2的Action對象。
從Servlet依賴分析:
Struts1 Action 依賴于Servlet API ,因為當一個Action被調用時，HttpServletRequest 和HttpServletResponse 被傳遞給execute方法。
Struts 2 Action不依賴于容器，允許Action脫離容器單獨被測試。如果需要，Struts2 Action仍然可以訪問初始的request和response。但是，其他的元素減少或者消除了直接訪問HttpServetRequest 和 HttpServletResponse的必要性。
從action線程模式分析:
Struts1 Action是單例模式并且必須是線程安全的，因為僅有Action的一個實例來處理所有的請求。單例策略限制了Struts1 Action能做的事，并且要在開發時特別小心。Action資源必須是線程安全的或同步的。
Struts2 Action對象為每一個請求產生一個實例，因此不存在線程安全問題。（實際上，servlet容器給每個請求產生許多可丟棄的對象，并且不會導致性能和垃圾回收問題）
4.2 Spring
IOC容器的加載過程？
創建IOC配置文件的抽象資源;
創建一個BeanFactory;
把讀取配置信息的BeanDefinitionReader，這里是XmlBeanDefinitionReader配置給BeanFactory;
從定義好的資源位置讀入配置信息，具體的解析過程由XmlBeanDefinitionReade來完成，這樣完成整個載入bean定義的過程;
說明
XmlBeanFactory，ClasspathXmlApplicationContext是IOC容器實現的兩種方式，XmlBeanFactory是基本的IOC容器的實現，ApplicationContext實現的IOC容器可以提供很多個高級特性（IOC容器的加載主要以ApplicationContext實現。）
SpringIOC容器管理了我們定義的各種Bean對象及其相互關系，Bean對象在Spring實現中是以BeanDefinition來描述;
IOC 容器的初始化過程(定義各種bean對象以及bean對象間的關系)，整個過程分成resource的定位、載入和解析。
IOC容器的依賴注入，Bean的名字通過ApplicationContext容器,getbean獲得對應的bean。
傳統創建對象的缺陷:
傳統創建對象，通過關鍵字new獲得。但是如果在不同的地方創建很多相同的對象，不僅占用很大的內存，同時影響性能。
改進思路:
仿造工廠模式，需要什么對象，直接拿過來，按照用戶需求，組裝相應的產品。以后不再通過new獲取對象，而是需要什么對象，就在spring容器中取就行了。這就是將創建對象這個行為，進行控制反轉，交由容器去完成。什么時候需要這些對象，再通過依賴注入的方式去獲取這些對象。
依賴注入的幾種方式
注解方式注入
// 等價于
注:項目較大時，按照模塊進行劃分,模塊中再按層劃分，而非按層(MVC)進行劃分；中小型項目按層劃分。
2. Setter方法注入
applicationContext.xml
public class UserAction{ private UserService userService; public String login(){ userService.valifyUser(xxx); } public void setUserService(UserService userService){ this.userService = userService; } }
3. 構造方法注入
public class UserAction{ private final UserService userService; public String login(){ userService.valifyUser(xxx); } public UserAction(UserService userService){ this.userService = userService; } }
三種注入方式對比
注解方式注入：適用于中小型項目，不適合大型項目。因為大型項目中存在很多的包、類，書寫較復雜，且不易明白項目的整體結構。
Setter 注入：對于習慣了傳統 javabean 開發的程序員，通過 setter方法設定依賴關系更加直觀。如果依賴關系較為復雜，那么構造子注入模式的構造函數也會相當龐大，而此時注入模式則更為簡潔。
構造器注入：在構造期間完成一個完整的、合法的對象。 所有依賴關系在構造函數中集中呈現。依賴關系在構造時由容器一次性設定，組件被創建之后一直處于相對“不變”的穩定狀態。只有組件的創建者關心其內部依賴關系，對調用者而言，該依賴關系處于“黑盒”之中。如果用到了第三方類庫，可能要求我們的組件提供一個默認的構造函數，此時構造器注入模式也不適用。
很多項目上相應的業務處理上上需要事務和日志的管理，然而許多業務上的事務、日志代碼又都是一樣的，這樣就造成了代碼重復。
改進思路：
讓這些重復的代碼抽取出來，讓專門的一個類進行管理。
AOP的實現：
在需要的地方加上通知（可以在目標代碼前后執行），將相同的業務交由代理類去執行（比如日志、事務），然后再執行目標類，實現了代碼復用。
靜態代理的缺陷：
相同的業務交由代理類去處理，那么需要日志管理，就要創建一個日志代理類，需要事務管理，就要創建事務代理類……，這樣會造成代理類的無限膨脹。
改進措施：
根據這些類，動態創建代理類。所以在這個過程，要實現兩個步驟：
1.通過反射機制產生代理類；
2. 代理類要實現一個統一的接口，該接口可對目標類實現額外功能的附加，如在目標類前面加日志、事務等。
基于注解的AOP實現邏輯如下：
package org.zttc.itat.spring.proxy; import org.aspectj.lang.JoinPoint; import org.aspectj.lang.ProceedingJoinPoint; import org.aspectj.lang.annotation.After; import org.aspectj.lang.annotation.Around; import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before; import org.springframework.stereotype.Component; @Component("logAspect")//讓這個切面類被Spring所管理 @Aspect//申明這個類是一個切面類 public class LogAspect { /** * execution(* org.zttc.itat.spring.dao.*.add*(..)) * 第一個*表示任意返回值 * 第二個*表示 org.zttc.itat.spring.dao包中的所有類 * 第三個*表示以add開頭的所有方法 * (..)表示任意參數 */ @Before("execution(* org.zttc.itat.spring.dao.*.add*(..))||" + "execution(* org.zttc.itat.spring.dao.*.delete*(..))||" + "execution(* org.zttc.itat.spring.dao.*.update*(..))") public void logStart(JoinPoint jp) { //得到執行的對象 System.out.println(jp.getTarget()); //得到執行的方法 System.out.println(jp.getSignature().getName()); Logger.info("加入日志"); } /** * 函數調用完成之后執行 * @param jp */ @After("execution(* org.zttc.itat.spring.dao.*.add*(..))||" + "execution(* org.zttc.itat.spring.dao.*.delete*(..))||" + "execution(* org.zttc.itat.spring.dao.*.update*(..))") public void logEnd(JoinPoint jp) { Logger.info("方法調用結束加入日志"); } /** * 函數調用中執行 * @param pjp * @throws Throwable */ @Around("execution(* org.zttc.itat.spring.dao.*.add*(..))||" + "execution(* org.zttc.itat.spring.dao.*.delete*(..))||" + "execution(* org.zttc.itat.spring.dao.*.update*(..))") public void logAround(ProceedingJoinPoint pjp) throws Throwable { Logger.info("開始在Around中加入日志"); pjp.proceed();//執行程序 Logger.info("結束Around"); } }
動態代理主要實現了兩個功能：
實現InvocationHandler接口中的invoke方法（主要是被代理類實例、方法、方法參數），該方法就是對被代理對象加的額外操作，如添加日志、權限等。
在運行時產生一個代理實例（通過反射）。
代碼實現如下：
Proxy.newProxyInstance(ClassLoad loader, Class[] interfaces,InvocationHandler h) // 要代理的真實對象 RealSubject rs = new RealSubject(); // 要代理哪個真實對象，就將該對象傳進去，最后是通過該真實對象來調用其方法 InvocationHandler invocationHandler = new DynamicSubject(rs); Class cl = rs.getClass(); Subject subject = (Subject) Proxy.newProxyInstance(cl.getClassLoader(), cl.getInterfaces(), invocationHandler); // 代理對象執行方法 subject.request();
過程如下：
通過被代理類實例反射獲得類類型；
然后將這個類類型進行加載（ClassLoad loader），實現代理類的接口方法（Class[] interfaces），實現代理的invoke方法；
總結：其實動態代理就是通過反射產生代理實例（Proxy.newProxyInstance），然后通過invoke實現額外功能的附加和代理方法的聚合。通過被代理類動態生成代理類解決了上面為各個被代理類創建相應的代理類，造成類膨脹的問題。
動態代理實現步驟：
創建一個實現接口InvocationHandler的類，它必須實現invoke方法；
創建被代理的類以及接口（通過被代理類的實例進行反射獲得）；
調用Proxy的靜態方法，創建一個代理類new ProxyInstance(ClassLoad loader, Class[] interfaces,InvocationHandler h)。
通過代理類返回的實例，去調用被代理類的方法；
1. jdk動態代理
只能代理實現了接口InvocationHandler的類;
沒有實現InvocationHandler接口的類不能實現jdk的動態代理;
2. CGlib動態代理（通過繼承實現）
針對類實現代理;
對指定目標類產生一個子類，通過方法攔截技術攔截所有父類方法的調用。（其實就是覆寫父類的方法，可見final修飾的類都不可能實現GCLIB代理）
4.3 Hibernate
應用程序先調用Configuration類,該類讀取Hibernate配置文件（鏈接數據庫）及映射文件（java對象個數據庫表中對象的一一映射）中的信息;
并用這些信息生成一個SessionFactory對象;
然后從SessionFactory對象生成一個Session對象;
并用Session對象生成Transaction對象;
hibernate的session提供了一級緩存的功能，默認總是有效的，當應用程序保持持久化實體，修改持久化實體時，session并不會立即把這種改變提交到數據庫，而是緩存在當前的session中，除非顯示調用了session的flush()方法或通過close()方法關閉session。通過一級緩存，可以減少程序與數據庫的交互，從而提高數據庫訪問的性能。
sessionFactory級別的二級緩存是全局性的，所有的session可以共享這個二級緩存。不過二級緩存默認是關閉的，需要顯示開啟并指定需要使用哪種二級緩存實現類（可以使用第三方提供的實現）。一旦開啟了二級緩存并設置了需要使用二級緩存的實體類，sessionFactory就會緩存訪問過的該實體類的每個對象，除非緩存的數據超出了指定的緩存空間。
采用合理的緩存策略（二級緩存、查詢緩存）；
采用合理的session管理機制；
盡量使用延遲加載特性（mybatis的延遲加載）；
設定合理的批處理參數；
如果可以，選用UUID作為主鍵生成器；
如果可以，選用基于版本號的樂觀鎖代替悲觀鎖；
在開發過程中，開啟Hibernate_show_sql選項查看生成的sql,從而了解低層的狀況；開發完成后關閉此選項；
考慮數據庫本身的優化，合理的索引，恰當的數據分區策略等都會對持久層的性能帶來可觀的提升，但是這些需要專業的DBA(數據庫管理員)提供支持。
get和load方法是根據id去獲得對應數據。區別如下：
執行get()方法時就發送sql語句（不支持延遲加載），并且查詢的數據存在內存中，在數據庫中查不到記錄時不會拋出異常，返回一個null。
hibernate在查詢數據的時候（數據在內存或緩存中，就不需要在從數據庫中查詢了），數據并不存在內存中而是通過cglib動態產生的一個代理對象，只有對數據進行操作的時候，才加載到內存中，實現了延遲加載，節省了內存開銷，提高服務器性能。用到數據時再發sql語句，在數據庫中查不到記錄會拋異常。
1. translent（瞬時態）
實體對象在內存中的存在，與數據庫中的記錄無關，通過session的save()或saveOrUpdate()方法變成持久態；
2. Persisent（持久態）
該狀態下的實體對象與數據庫中的數據保持一致；
3. Detached(托管狀態)
操作托管態的數據不能影響到數據庫的修改；
五、SSM(Springmvc + spring + mybatis)
5.1 SpringMVC 實現原理
Springmvc工作流程：（面試的時候一定要會畫Springmvc的運行圖，結合圖講比較好）
用戶發起請求到前端控制器DispatcherServlet;
前端控制器請求處理器映射器HandlerMapping查找Handler（通過xml或注解方式查找）;
處理器映射器HandlerMapping向前端控制器返回Handler;
前端控制器調用處理器適配器HadlerAdapter去執行Handler;
處理器適配器去執行Handler ；
Handler執行完成給適配器返回ModelAndView;
處理器適配器向前端控制器返回ModelAndView;
前端控制器請求視圖解析器去進行視圖解析（將邏輯視圖轉化成完整的視圖地址）;
然后進行視圖渲染填充到request域展現給用戶；
5.2 mybatis 實現原理
應用程序到mybatis的全局配置文件sqlMapConfig.xml讀取配置信息（如：別名設定、包、全局變量定義、mapper掃描（把mapper.xml和mapper.java放在同一個目錄下，就不需要配置了））
然后創建會話工廠（鏈接數據庫）;
通過會話工廠打開會話，dao層和數據庫就實現了通道;
通過類的反射加載類的實例，然后就可實現對數據的操作;
六、兩大框架對比
6.1 SSH 與 Spring+SpringMVC+mybatis 的區別
Spring+SpringMVC+Mybatis是以spring為主體，實現了springmvc與spring的無縫連接，在層次處理上比SSH更具優勢。
兩者都是基于ORM框架;
Hibernate的ORM實現POJO和數據庫表之間的映射，以及sql自動生成和執行;
Mybatis著力點在于POJO與sql之間的映射關系（主要是輸入輸出映射）。然后通過映射配置文件。將sql所需的參數，以及返回的結果字段映射到指定POJO。
Mybatis優勢：
可以進行更為細致的sql優化，可以減少查詢字段;
Mybatis較Hibernate容易掌握;
Hibernate優勢：
Hibernate的DAO層開發比mybatis簡單，因為mybatis需要維護sql和結果映射;
hibernate對對象的維護和緩存比mybatis好，對增刪改查的對象維護也方便。
hibernate數據庫移植性要比mybatis好，因為mybatis對不同的數據庫要寫不同的sql語句;
hibernate有更好的二級緩存機制，還可以使用第三方緩存。Mybatis本身提供的緩存機制不佳。
6.2 struts2 與springmvc 的實現原理，以及兩者的區別？
核心控制器：springmvc是servlet, 而struts2是filter(處理所有的請求,對特殊請求進行統一處理);
控制器實例：struts2是基于對象的，每一次請求都會實例化一個action，每個action都會注入屬性，而springmvc是基于方法設計就像servlet一樣，只有一個實例（采用的是單例模式）;
管理方式：大部分公司的核心框架采用的是spring，而springmvc又是spring的一個模塊，所以管理起來更加簡單，而且提供了全注解方式進行管理。Struts2采用xml很多的配置參數來管理;
Servlet Spring 容器
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
