前言：

一線大廠一直是互聯網人包括程序員夢寐以求的公司，苦於BAT大廠的進入門檻太高，無奈只能望門興嘆，所以只能苦練技能才能有機會去敲開BAT的大門。下面是一位Java程序員的親身經歷三面美團拿下了offer，特獻上面試真題，以供參考學習。

第一部分. Spring專題

1、Spring怎樣定義類的作用域

通過bean 定義中的scope屬性來定義。

2、Spring支持的幾種bean的作用域

支持以下五種bean的作用域：

• singleton : bean在每個Spring ioc 容器中只有一個實例。（缺省默認）
• prototype：一個bean的定義可以有多個實例。
• request：每次http請求都會創建一個bean，該作用域僅在基於web的Spring ApplicationContext情形下有效。
• session：在一個HTTP Session中，一個bean定義對應一個實例。該作用域僅在基於web的Spring ApplicationContext情形下有效。
• global-session：在一個全局的HTTP Session中，一個bean定義對應一個實例。該作用域僅在基於web的Spring ApplicationContext情形下有效。

3、Spring支持的事務管理類型

• 編程式事務管理：這意味你通過編程的方式管理事務，給你帶來極大的靈活性，但是難維護。
• 聲明式事務管理：這意味著你可以將業務代碼和事務管理分離，你只需用註解和XML配置來管理事務。

4、什麼是控制反轉(IOC)？什麼是依賴注入？

• 控制反轉(IOC) ： 傳統應用程序是由我們自己在對象中主動控制去直接獲取依賴對象，現在由容器幫我們查找及注入依賴對象，對象只是被動的接受依賴對象，所以是控制反轉。
• 依賴注入：組件之間依賴關係由容器在運行期決定，形象的說，即由容器動態的將某個依賴關係注入到組件之中。通過依賴注入機制，我們只需要通過簡單的配置，而無需任何代碼就可指定目標需要的資源，完成自身的業務邏輯，而不需要關心具體的資源來自何處，由誰實現。
• 實現方式：構造器注入、Setter方法注入、接口注入。註解裝配在默認情況下是不開啟的，為了使用註解裝配，我們必須在Spring配置文件中配置 <annotation-config>元素。

5、Spring由幾大核心組件？

• Bean 組件
• Context 組件
• Core 組件

6、Spring MVC核心工作流程 ？

• 用戶向服務器發送request請求，請求被SpringMVC中央控制器DispatcherServlet捕獲；
• DispatcherServlet對請求URL進行解析，得到請求資源標識符（URI）。然後根據該URI，調用HandlerMapping映射處理器，將請求發送給指定的Controller。
• Controller執行完成後，將返回的數據信息封裝到ModelAndView對象中，最後通過ViewResolver視圖解析器選擇一個合適的View 渲染視圖返回界面。

7、spring事務隔離級別（五種面試最好全部說出來）

• DEFAULT 這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別.
• 未提交讀（read uncommited） : 髒讀，不可重複讀，虛讀都有可能發生 。是最低的事務隔離級別，它允許另外一個事務可以看到這個事務未提交的數據。
• 已提交讀 （read commited）: 避免髒讀。但是不可重複讀、虛讀有可能發生 。保證一個事物提交後才能被另外一個事務讀取。另外一個事務不能讀取該事物未提交的數據。Oracle 默認
• 可重複讀 （repeatable read）: 這種事務隔離級別可以防止髒讀，不可重複讀。但是可能會出現幻象讀。它除了保證一個事務不能被另外一個事務讀取未提交的數據之外還避免了以下情況產生（不可重複讀）。Mysql 默認
• 串行化的 （serializable） : 這是花費最高代價、效率差但最可靠的事務隔離級別。事務被處理為順序執行。除了防止髒讀，不可重複讀之外，還避免了幻象讀（避免三種）。

8、Spring事務特性（四種面試最好全部說出來）

• 原子性 （atomicity）: 一個事務中所有對數據庫的操作是一個不可分割的操作序列，要麼全做要麼全不做。
• 一致性 （consistency）: 事務的執行的前後數據的完整性保持一致.
• 隔離性 （isolation）: 一個事務執行的過程中,不應該受到其他事務的干擾
• 持久性（durability） : 一個事物一旦提交，它對數據庫的改變就是永久的

9、Spring事務七個傳播特性（七種面試說一兩個即可）

• Propagation.REQUIRED (默認) 面試必須說出來這個。調用方已經存在事務，則加入到同一個事務中運行，否則，自啟一個事務
• Propagation.REQUIRES_NEW。無論何時自身都會開啟新事務
• Propagation.SUPPORTS。調用方存在事務，則加入到同一個事務中運行，若不存在事務，則以非事務的方式運行
• Propagation.NOT_SUPPORTED。調用方存在事務，則會被掛起，直到被調用方運行完畢後，事務恢復。
• Propagation.MANDATORY。調用方存在事務，則加入到同一個事務中運行，若不存在，則拋出異常
• Propagation.NEVER。調用方存在事務，則拋出異常
• Propagation.NESTED。若調用方存在事務，則運行一個嵌套事務，若調用方不存在事務，則以Propagation.REQUIRED的方式運行,即開啟一個新的事務

10、簡述Spring Bean的生命週期

實例化、初始化、使用、銷燬。

關鍵詞：BeanFactoryPostProcessor 、BeanPostProcessor 、init-method/destroy-method

第二部分. Dubbo面試專題

1、Dubbo的容錯機制有哪些？

Dubbo官網提出總共有六種容錯策略

• Failover Cluster模式：失敗自動切換，當出現失敗，重試其它服務器。(默認)
• Failfast Cluster：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
• Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
• Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
• Forking Cluster：並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過forks=”2”來設置最大並行數。
• Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)通常用於通知所有提供者更新緩存或日誌等本地資源信息。

總結：在實際應用中查詢語句容錯策略建議使用默認Failover Cluster，而增刪改建議使用Failfast Cluster或者使用Failover Cluster（retries=”0”）策略防止出現數據重複添加等等其它問題。建議在設計接口時候把查詢接口方法單獨做一個接口提供查詢。

2、使用dubbo遇到過哪些問題？

增加提供服務版本號和消費服務版本號

這個具體來說不算是一個問題，而是一種問題的解決方案，在我們的實際工作中會面臨各種環境資源短缺的問題，也是很實際的問題，剛開始我們還可以提供一個服務進行相關的開發和測試，但是當有多個環境多個版本，多個任務的時候就不滿足我們的需求，這時候我們可以通過給提供方增加版本的方式來區分.這樣能夠剩下很多的物理資源，同時為今後更換接口定義發佈在線時，可不停機發布，使用版本號.引用只會找相應版本的服務，例如：

<serviceinterface>
<referenceid>

3、dubbo reference註解問題？

@Reference只能在SpringBean實例對應的當前類中使用，暫時無法在父類使用；如果確實要在父類聲明一個引用，可通過配置文件配置dubbo：reference，然後在需要引用的地方跟引用SpringBean一樣就可以了.

4、出現RpcException：No provider available for remote service異常怎麼辦？

• 檢查連接的註冊中心是否正確
• 到註冊中心查看相應的服務提供者是否存在
• 檢查服務提供者是否正常運行

5、服務提供者沒掛，但在註冊中心裡看不到？

首先，確認服務提供者是否連接了正確的註冊中心，不只是檢查配置中的註冊中心地址，而且要檢查實際的網絡連接。

其次，看服務提供者是否非常繁忙，比如壓力測試，以至於沒有CPU片段向註冊中心發送心跳，這種情況減小壓力將自動恢復。

6、Dubbo的連接方式有哪些？

Dubbo的客戶端和服務端有三種連接方式，分別是：廣播，直連和使用zookeeper註冊中心。

7、Dubbo廣播

這種方式是dubbo官方入門程序所使用的連接方式，但是這種方式有很多問題。在企業開發中，不使用廣播的方式。taotao-manager服務端配置：

!-- applicationContext-service.xml 文件中 -->

<application>

<dubboprotocol>

<service>

第三部分. Redis專題

1.什麼是Redis？

答：Remote Dictionary Server(Redis)是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。

它通常被稱為數據結構服務器，因為值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等類型。

2.Redis的特點什麼是？

• 支持多種數據結構，如 string(字符串)、 list(雙向鏈表)、dict(hash表)、set(集合)、zset(排序set)、hyperloglog(基數估算)
• 支持持久化操作，可以進行aof及rdb數據持久化到磁盤，從而進行數據備份或數據恢復等操作，較好的防止數據丟失的手段。
• 支持通過Replication進行數據複製，通過master-slave機制，可以實時進行數據的同步複製，支持多級複製和增量複製，master-slave機制是Redis進行HA的重要手段。
• 單進程請求，所有命令串行執行，併發情況下不需要考慮數據一致性問題。

3.Redis數據類型有哪些？

答：

• String(字符串)
• Hash(hash表)
• List(鏈表)
• Set(集合)
• SortedSet(有序集合zset)

4. Redis的配置以及持久化方案有幾種？

答：以下兩種

• RDB方式
• AOF方式

第四部分. Zookeeper專題

1. Zookeeper是什麼框架

分佈式的、開源的分佈式應用程序協調服務，原本是Hadoop、HBase的一個重要組件。

應用場景：Zookeeper的功能很強大，應用場景很多，結合我實際工作中使用Dubbo框架的情況，Zookeeper主要是做註冊中心用。

基於Dubbo框架開發的提供者、消費者都向Zookeeper註冊自己的URL，消費者還能拿到並訂閱提供者的註冊URL，以便在後續程序的執行中去調用提供者。而提供者發生了變動，也會通過Zookeeper向訂閱的消費者發送通知。

2. Zookeeper有哪幾種節點類型

• 持久：創建之後一直存在，除非有刪除操作，創建節點的客戶端會話失效也不影響此節點。
• 持久順序：跟持久一樣，就是父節點在創建下一級子節點的時候，記錄每個子節點創建的先後順序，會給每個子節點名加上一個數字後綴。
• 臨時：創建客戶端會話失效（注意是會話失效，不是連接斷了），節點也就沒了。不能建子節點。
• 臨時順序：不用解釋了吧。

3. Zookeeper對節點的watch監聽通知是永久的嗎？

不是。

官方聲明：一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了Watch的客戶端，以便通知它們。

為什麼不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，這太消耗性能了。

一般是客戶端執行getData(“/節點A”,true)，如果節點A發生了變更或刪除，客戶端會得到它的watch事件，但是在之後節點A又發生了變更，而客戶端又沒有設置watch事件，就不再給客戶端發送。

在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的數據即可。

4. Zookeeper集群如果有3臺機器，掛掉一臺集群還能工作嗎？掛掉兩臺呢？

記住一個原則：過半存活即可用。

集群支持動態添加機器嗎？

其實就是水平擴容了，Zookeeper在這方面不太好。兩種方式：

• 全部重啟：關閉所有Zookeeper服務，修改配置之後啟動。不影響之前客戶端的會話。
• 逐個重啟：顧名思義。這是比較常用的方式。

第五部分. 微服務專題

1. 為什麼要使用微服務跟蹤？它解決了什麼問題？

1. 微服務調用的現狀?

• 微服務的現狀:隨著業務的發展，單體架構變為微服務架構，並且系統規模也變得越來越大，各微服務間的調用關係也變得越來越複雜。
• 多服務協同工作:在微服務的應用中，一個由客戶端發起的請求在後端系統中會經過多個不同的微服務調用來協同產生最後的請求結果。
• 複雜的調用鏈條容易出錯:在複雜的微服務架構系統中，幾乎每一個前端請求都會形成一-個複雜的分佈式服務調用鏈路，在每條鏈路中任何一個依賴服務出現延遲超時或者錯誤都有可能引起整個請求最後的失敗。

2. 微服務跟蹤解決了什麼問題?

微服務跟蹤其實是一個工具，它在整個分佈式系統中能跟蹤一個用戶請求的過程(包括數據採集、數據傳輸、數據存儲、數據分析、數據可視化) ,捕獲這些跟蹤數據，就能構建微服務的整個調用鏈的視圖，這是調試和監控微服務的關鍵工具。

Spring Cloud S1euth有4個特點:

• 提供鏈路追蹤:通過sleuth可以很清楚的看出一-個請求都經過了哪些服務。可以很方便的理清服務間的調用關係。
• 性能分析:通過sleuth可以很方便的看出每個採樣請求的耗時，分析出哪些服務調用比較耗時。當服務調用的耗時隨著請求量的增大而增大時，也可以對服務的擴容提供- -定的提醒作用。
• 數據分析，優化鏈路:對於頻繁地調用一個服務，或者並行地調用等，可以針對業務做一些優化措施。
• 可視化錯誤:對於程序未捕捉的異常，可以在zipkin界面上看到。

寫在最後：

限於篇幅，文中只展示了部分的面試題，完整的面試題筆者已經整理成了一份PDF文件，需要的朋友可以幫忙轉發一下；

然後私信我 【學習】 即可免費領取完整面試文件！

以下是部分面試題截圖