Java EE面試題整理（持續更新）

Java EE面試題整理

● 請談一談Spring中自動裝配的方式有哪些？

• no：不進行自動裝配，手動設置Bean的依賴關係。
• byName：根據Bean的名字進行自動裝配。
• byType：根據Bean的類型進行自動裝配。
• constructor：類似於byType，不過是應用於構造器的參數，如果正好有一個Bean與構造器的參數類型相同則可以自動裝配，否則會導致錯誤。
• autodetect：如果有默認的構造器，則通過constructor的方式進行自動裝配，否則使用byType的方式進行自動裝配。

自動裝配沒有自定義裝配方式那麼精確，而且不能自動裝配簡單屬性（基本類型、字符串等），在使用時應注意。

● 請問Spring中Bean的作用域有哪些？
在Spring的早期版本中，僅有兩個作用域：singleton和prototype，前者表示Bean以單例的方式存在；後者表示每次從容器中調用Bean時，都會返回一個新的實例，prototype通常翻譯爲原型。

設計模式中的創建型模式中也有一個原型模式，原型模式也是一個常用的模式，例如做一個室內設計軟件，所有的素材都在工具箱中，而每次從工具箱中取出的都是素材對象的一個原型，可以通過對象克隆來實現原型模式。Spring 2.x中針對WebApplicationContext新增了3個作用域，分別是：request（每次HTTP請求都會創建一個新的Bean）、session（同一個HttpSession共享同一個Bean，不同的HttpSession使用不同的Bean）和globalSession（同一個全局Session共享一個Bean）。

單例模式和原型模式都是重要的設計模式。一般情況下，無狀態或狀態不可變的類適合使用單例模式。在傳統開發中，由於DAO持有Connection這個非線程安全對象因而沒有使用單例模式；但在Spring環境下，所有DAO類對可以採用單例模式，因爲Spring利用AOP和Java API中的ThreadLocal對非線程安全的對象進行了特殊處理。

● 請問什麼是IoC和DI？並且簡要說明一下DI是如何實現的？
IoC叫控制反轉，是Inversion of Control的縮寫，DI（Dependency Injection）叫依賴注入，是對IoC更簡單的詮釋。控制反轉是把傳統上由程序代碼直接操控的對象的調用權交給容器，通過容器來實現對象組件的裝配和管理。所謂的"控制反轉"就是對組件對象控制權的轉移，從程序代碼本身轉移到了外部容器，由容器來創建對象並管理對象之間的依賴關係。IoC體現了好萊塢原則 - “Don’t call me, we will call you”。依賴注入的基本原則是應用組件不應該負責查找資源或者其他依賴的協作對象。配置對象的工作應該由容器負責，查找資源的邏輯應該從應用組件的代碼中抽取出來，交給容器來完成。DI是對IoC更準確的描述，即組件之間的依賴關係由容器在運行期決定，形象的來說，即由容器動態的將某種依賴關係注入到組件之中。

一個類A需要用到接口B中的方法，那麼就需要爲類A和接口B建立關聯或依賴關係，最原始的方法是在類A中創建一個接口B的實現類C的實例，但這種方法需要開發人員自行維護二者的依賴關係，也就是說當依賴關係發生變動的時候需要修改代碼並重新構建整個系統。如果通過一個容器來管理這些對象以及對象的依賴關係，則只需要在類A中定義好用於關聯接口B的方法（構造器或setter方法），將類A和接口B的實現類C放入容器中，通過對容器的配置來實現二者的關聯。
依賴注入可以通過setter方法注入（設值注入）、構造器注入和接口注入三種方式來實現，Spring支持setter注入和構造器注入，通常使用構造器注入來注入必須的依賴關係，對於可選的依賴關係，則setter注入是更好的選擇，setter注入需要類提供無參構造器或者無參的靜態工廠方法來創建對象。

● 請說明一下Spring中BeanFactory和ApplicationContext的區別是什麼？
概念：

BeanFactory：
BeanFactory是spring中比較原始，比較古老的Factory。因爲比較古老，所以BeanFactory無法支持spring插件，例如：AOP、Web應用等功能。

ApplicationContext
ApplicationContext是BeanFactory的子類，因爲古老的BeanFactory無法滿足不斷更新的spring的需求，於是ApplicationContext就基本上代替了BeanFactory的工作，以一種更面向框架的工作方式以及對上下文進行分層和實現繼承，並在這個基礎上對功能進行擴展：
<1>MessageSource, 提供國際化的消息訪問
<2>資源訪問（如URL和文件）
<3>事件傳遞
<4>Bean的自動裝配
<5>各種不同應用層的Context實現

區別：

<1>如果使用ApplicationContext，如果配置的bean是singleton，那麼不管你有沒有或想不想用它，它都會被實例化。好處是可以預先加載，壞處是浪費內存。
<2>BeanFactory，當使用BeanFactory實例化對象時，配置的bean不會馬上被實例化，而是等到你使用該bean的時候（getBean）纔會被實例化。好處是節約內存，壞處是速度比較慢。多用於移動設備的開發。
<3>沒有特殊要求的情況下，應該使用ApplicationContext完成。因爲BeanFactory能完成的事情，ApplicationContext都能完成，並且提供了更多接近現在開發的功能。

● 請說明一下springIOC原理是什麼？如果你要實現IOC需要怎麼做？請簡單描述一下實現步驟？
①IoC（Inversion of Control，控制倒轉）。這是spring的核心，貫穿始終。所謂IoC，對於spring框架來說，就是由spring來負責控制對象的生命週期和對象間的關係。

IoC的一個重點是在系統運行中，動態的向某個對象提供它所需要的其他對象。這一點是通過DI（Dependency Injection，依賴注入）來實現的。比如對象A需要操作數據庫，以前我們總是要在A中自己編寫代碼來獲得一個Connection對象，有了 spring我們就只需要告訴spring，A中需要一個Connection，至於這個Connection怎麼構造，何時構造，A不需要知道。在系統運行時，spring會在適當的時候製造一個Connection，然後像打針一樣，注射到A當中，這樣就完成了對各個對象之間關係的控制。A需要依賴 Connection才能正常運行，而這個Connection是由spring注入到A中的，依賴注入的名字就這麼來的。那麼DI是如何實現的呢？ Java 1.3之後一個重要特徵是反射（reflection），它允許程序在運行的時候動態的生成對象、執行對象的方法、改變對象的屬性，spring就是通過反射來實現注入的。

舉個簡單的例子，我們找女朋友常見的情況是，我們到處去看哪裏有長得漂亮身材又好的女孩子，然後打聽她們的興趣愛好、qq號、電話號、ip號、iq號………，想辦法認識她們，投其所好送其所要，這個過程是複雜深奧的，我們必須自己設計和麪對每個環節。傳統的程序開發也是如此，在一個對象中，如果要使用另外的對象，就必須得到它（自己new一個，或者從JNDI中查詢一個），使用完之後還要將對象銷燬（比如Connection等），對象始終會和其他的接口或類藕合起來。

②實現IOC的步驟

定義用來描述bean的配置的Java類

解析bean的配置，將bean的配置信息轉換爲上面的BeanDefinition對象保存在內存中，spring中採用HashMap進行對象存儲，其中會用到一些xml解析技術

遍歷存放BeanDefinition的HashMap對象，逐條取出BeanDefinition對象，獲取bean的配置信息，利用Java的反射機制實例化對象，將實例化後的對象保存在另外一個Map中即可。

● 請簡單說明一下依賴注入的方式有哪幾種？以及這些方法如何使用？
1、Set注入 2、構造器注入 3、接口注入

● 請簡要說明一下AOP是什麼？
AOP（Aspect Oriented Programming），即面向切面編程，可以說是OOP（Object Oriented Programming，面向對象編程）的補充和完善。OOP引入封裝、繼承、多態等概念來建立一種對象層次結構，用於模擬公共行爲的一個集合。不過OOP允許開發者定義縱向的關係，但並不適合定義橫向的關係，例如日誌功能。日誌代碼往往橫向地散佈在所有對象層次中，而與它對應的對象的核心功能毫無關係對於其他類型的代碼，如安全性、異常處理和透明的持續性也都是如此，這種散佈在各處的無關的代碼被稱爲橫切（cross cutting），在OOP設計中，它導致了大量代碼的重複，而不利於各個模塊的重用。

AOP技術恰恰相反，它利用一種稱爲"橫切"的技術，剖解開封裝的對象內部，並將那些影響了多個類的公共行爲封裝到一個可重用模塊，並將其命名爲"Aspect"，即切面。所謂"切面"，簡單說就是那些與業務無關，卻爲業務模塊所共同調用的邏輯或責任封裝起來，便於減少系統的重複代碼，降低模塊之間的耦合度，並有利於未來的可操作性和可維護性。

● 請問Spring支持的事務管理類型有哪些？以及你在項目中會使用哪種方式？
Spring支持編程式事務管理和聲明式事務管理。許多Spring框架的用戶選擇聲明式事務管理，因爲這種方式和應用程序的關聯較少，因此更加符合輕量級容器的概念。聲明式事務管理要優於編程式事務管理，儘管在靈活性方面它弱於編程式事務管理，因爲編程式事務允許你通過代碼控制業務。

● 請簡單談一下spring框架的優點都有哪些？
Spring是一個輕量級的DI和AOP容器框架，在項目的中的使用越來越廣泛，它的優點主要有以下幾點：

Spring是一個非侵入式框架，其目標是使應用程序代碼對框架的依賴最小化，應用代碼可以在沒有Spring或者其他容器的情況運行。

Spring提供了一個一致的編程模型，使應用直接使用POJO開發，從而可以使運行環境隔離開來。

Spring推動應用的設計風格向面向對象及面向接口編程轉變，提高了代碼的重用性和可測試性。

Spring改進了結構體系的選擇，雖然作爲應用平臺，Spring可以幫助我們選擇不同的技術實現，比如從Hibernate切換到其他的ORM工具，從Struts切換到Spring MVC,儘管我們通常不會這麼做，但是我們在技術方案上選擇使用Spring作爲應用平臺，Spring至少爲我們提供了這種可能性的選擇，從而降低了平臺鎖定風險。

● 請簡單介紹一下spring？
Spring是一個輕量級框架，可以一站式構建你的企業級應用。

Spring的模塊大概分爲6個。分別是：

1、Core Container（Spring的核心）【重要】

2、AOP（面向切面變成）【重要】

3、Messaging（消息發送的支持）

4、Data Access/Integration（數據訪問和集成）

5、Web（主要是SpringWeb內容，包括MVC）【重要】

6、Test（Spring測試支持，包含JUint等測試單元的支持） 7、Instrumentation（設備支持，比如Tomcat的支持）

● 請問持久層設計要考慮的問題有哪些？請談一下你用過的持久層框架都有哪些？
所謂"持久"就是將數據保存到可掉電式存儲設備中以便今後使用，簡單的說，就是將內存中的數據保存到關係型數據庫、文件系統、消息隊列等提供持久化支持的設備中。持久層就是系統中專注於實現數據持久化的相對獨立的層面。

持久層設計的目標包括：

• 數據存儲邏輯的分離，提供抽象化的數據訪問接口。
• 數據訪問底層實現的分離，可以在不修改代碼的情況下切換底層實現。
• 資源管理和調度的分離，在數據訪問層實現統一的資源調度（如緩存機制）。
• 數據抽象，提供更面向對象的數據操作。

持久層框架有：

• Hibernate
• MyBatis
• TopLink
• Guzz
• jOOQ
• Spring Data
• ActiveJDBC
  ● 請說明一下MyBatis中命名空間（namespace）的作用是什麼？
  在大型項目中，可能存在大量的SQL語句，這時候爲每個SQL語句起一個唯一的標識（ID）就變得並不容易了。爲了解決這個問題，在MyBatis中，可以爲每個映射文件起一個唯一的命名空間，這樣定義在這個映射文件中的每個SQL語句就成了定義在這個命名空間中的一個ID。只要我們能夠保證每個命名空間中這個ID是唯一的，即使在不同映射文件中的語句ID相同，也不會再產生衝突了。

● 請說明一下spring和spring-boot區別是什麼？
總的來說，Spring 就像一個大家族，有衆多衍生產品例如 Boot，Security，JPA等等。但他們的基礎都是Spring 的 IOC 和 AOP，IOC提供了依賴注入的容器，而AOP解決了面向切面的編程，然後在此兩者的基礎上實現了其他衍生產品的高級功能；因爲 Spring 的配置非常複雜，各種xml，properties處理起來比較繁瑣。於是爲了簡化開發者的使用，Spring社區創造性地推出了Spring Boot，它遵循約定優於配置，極大降低了Spring使用門檻，但又不失Spring原本靈活強大的功能。

● 請說明一下Spring MVC註解的優點是什麼？
1、XML配置起來有時候冗長，此時註解可能是更好的選擇，如jpa的實體映射；註解在處理一些不變的元數據時有時候比XML方便的多，比如springmvc的數據綁定，如果用xml寫的代碼會多的多；

2、註解最大的好處就是簡化了XML配置；其實大部分註解一旦確定後很少會改變，所以在一些中小項目中使用註解反而提供了開發效率，所以沒必要一頭走到黑；

3、註解相對於XML的另一個好處是類型安全的，XML只能在運行期才能發現問題。

● 請說明一下EJB的幾種類型分別是什麼？
會話（Session）Bean ，實體（Entity）Bean 消息驅動的（Message Driven）Bean，會話Bean又可分爲有狀態（Stateful）和無狀態（Stateless）兩種，
實體Bean可分爲Bean管理的持續性（BMP）和容器管理的持續性（CMP）兩種。

● 請問EJB與JAVA BEAN的區別是什麼？
Java Bean 是可複用的組件，對Java Bean並沒有嚴格的規範，理論上講，任何一個Java類都可以是一個Bean。但通常情況下，由於Java Bean是被容器所創建（如Tomcat）的，所以Java Bean應具有一個無參的構造器，另外，通常Java Bean還要實現Serializable接口用於實現Bean的持久性。Java Bean實際上相當於微軟COM模型中的本地進程內COM組件，它是不能被跨進程訪問的。EnterpriseJava Bean 相當於DCOM，即分佈式組件。它是基於Java的遠程方法調用（RMI）技術的，所以EJB可以被遠程訪問（跨進程、跨計算機）。但EJB必須被佈署在諸如Webspere、WebLogic這樣的容器中，EJB客戶從不直接訪問真正的EJB組件，而是通過其容器訪問。EJB容器是EJB組件的代理， EJB組件由容器所創建和管理。客戶通過容器來訪問真正的EJB組件。

● 請問在什麼情況下回使用assert？
assertion (斷言)在軟件開發中是一種常用的調試方式，很多開發語言中都支持這種機制。在實現中，assertion就是在程序中的一條語句，它對一個 boolean表達式進行檢查，一個正確程序必須保證這個boolean表達式的值爲true；如果該值爲false，說明程序已經處於不正確的狀態下，系統將給出警告或退出。一般來說，assertion用於保證程序最基本、關鍵的正確性。assertion檢查通常在開發和測試時開啓。爲了提高性能，在軟件發佈後，assertion檢查通常是關閉的。

TCP 爲什麼三次握手而不是兩次握手
爲了實現可靠數據傳輸， TCP 協議的通信雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始值的必經步驟
如果只是兩次握手， 至多隻有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認

● 請講一下瀏覽器從接收到一個URL，到最後展示出頁面，經歷了哪些過程。
1.DNS解析 2.TCP連接 3.發送HTTP請求 4.服務器處理請求並返回HTTP報文 5.瀏覽器解析渲染頁面

● 請你談談DNS的尋址過程。
（1）檢查瀏覽器緩存、檢查本地hosts文件是否有這個網址的映射，如果有，就調用這個IP地址映射，解析完成。

（2）如果沒有，則查找本地DNS解析器緩存是否有這個網址的映射，如果有，返回映射，解析完成。

（3）如果沒有，則查找填寫或分配的首選DNS服務器，稱爲本地DNS服務器。服務器接收到查詢時：

如果要查詢的域名包含在本地配置區域資源中，返回解析結果，查詢結束，此解析具有權威性。

如果要查詢的域名不由本地DNS服務器區域解析，但服務器緩存了此網址的映射關係，返回解析結果，查詢結束，此解析不具有權威性。

（4）如果本地DNS服務器也失效：

如果未採用轉發模式（迭代），本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後，會判斷這個域名（如.com）是誰來授權管理，並返回一個負責該頂級域名服務器的IP，本地DNS服務器收到頂級域名服務器IP信息後，繼續向該頂級域名服務器IP發送請求，該服務器如果無法解析，則會找到負責這個域名的下一級DNS服務器（如http://baidu.com）的IP給本地DNS服務器，循環往復直至查詢到映射，將解析結果返回本地DNS服務器，再由本地DNS服務器返回解析結果，查詢完成。

如果採用轉發模式（遞歸），則此DNS服務器就會把請求轉發至上一級DNS服務器，如果上一級DNS服務器不能解析，則繼續向上請求。最終將解析結果依次返回本地DNS服務器，本地DNS服務器再返回給客戶機，查詢完成。

● 請介紹一下，socket編程的三種通信模型，BIO，NIO，AIO
同步阻塞的BIO、同步非阻塞的NIO、異步非阻塞的AIO。其中BIO是一個連接一個線程。NIO是一個請求一個線程。AIO是一個有效請求一個線程。
阻塞：應用程序在獲取網絡數據的時候，如果網絡傳輸數據很慢，那麼程序就一直等待，直到傳輸完畢爲止。
非阻塞：應用程序直接可以獲取已經準備就緒的數據，無須等待

瞭解RPC與Http以及其兩者的區別
RPC： 即 Remote Procedure Call（遠程過程調用），是一個計算機通信協議。該協議允許運行於一臺計算機的程序調用另一臺計算機的子程序，而程序員無需額外地爲這個交互作用編程。說得通俗一點就是：A計算機提供一個服務，B計算機可以像調用本地服務那樣調用A計算機的服務。
Http協議：超文本傳輸協議，是一種應用層協議。規定了網絡傳輸的請求格式、響應格式、資源定位和操作的方式等。但是底層採用什麼網絡傳輸協議，並沒有規定，不過現在都是採用TCP協議作爲底層傳輸協議。

區別：說到這裏，大家可能覺得，Http與RPC的遠程調用非常像，都是按照某種規定好的數據格式進行網絡通信，有請求，有響應。沒錯，在這點來看，兩者非常相似，但是還是有一些細微差別。

• RPC並沒有規定數據傳輸格式，這個格式可以任意指定，不同的RPC協議，數據格式不一定相同。
• Http中還定義了資源定位的路徑，RPC中並不需要
• 最重要的一點：RPC需要滿足像調用本地服務一樣調用遠程服務，也就是對調用過程在API層面進行封裝。Http協議沒有這樣的要求，因此請求、響應等細節需要我們自己去實現。
  • 優點：RPC方式更加透明，對用戶更方便。Http方式更靈活，沒有規定API和語言，跨語言、跨平臺
  • 缺點：RPC方式需要在API層面進行封裝，限制了開發的語言環境。

例如我們通過瀏覽器訪問網站，就是通過Http協議。只不過瀏覽器把請求封裝，發起請求以及接收響應，解析響應的事情都幫我們做了。如果是不通過瀏覽器，那麼這些事情都需要自己去完成。