摘要：我在前面的文章中也提到了應該怎么做自我介紹與項目介紹，詳情可以查看這篇文章備戰春招秋招系列初出茅廬的程序員該如何準備面試。因此基于事件消息對象驅動的業務架構可以是一系列流程。

一 消息隊列MQ的套路

1.1 介紹一下消息隊列MQ的應用場景/使用消息隊列的好處

①.通過異步處理提高系統性能

②.降低系統耦合性

1.2 那么使用消息隊列會帶來什么問題？考慮過這個問題嗎？

1.3 介紹一下你知道哪幾種消息隊列，該如何選擇呢？

1.4 關于消息隊列其他一些常見的問題展望

二 談談 InnoDB 和 MyIsam 兩者的區別

2.1 兩者的對比

2.2 關于兩者的總結

三 聊聊 Java 中的集合吧！

3.1 Arraylist 與 LinkedList 有什么不同？（注意加上從數據結構分析的內容）

3.2 HashMap的底層實現

① JDK1.8之前

② JDK1.8之后

3.3 既然談到了紅黑樹，你給我手繪一個出來吧，然后簡單講一下自己對于紅黑樹的理解

3.4 紅黑樹這么優秀，為何不直接使用紅黑樹得了？

3.5 HashMap 和 Hashtable 的區別/HashSet 和 HashMap 區別

該文已加入開源文檔：JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識）。地址:https://github.com/Snailclimb...

系列文章：

【備戰春招/秋招系列1】程序員的簡歷就該這樣寫

【備戰春招/秋招系列2】初出茅廬的程序員該如何準備面試？

【備戰春招/秋招系列3】Java程序員必備書單

【備戰春招/秋招系列4】美團面經總結基礎篇 （附詳解答案）

這是我總結的美團面經的進階篇，后面還有終結篇哦！下面只是我從很多份美團面經中總結的在美團面試中一些常見的問題。不同于個人面經，這份面經具有普適性。每次面試必備的自我介紹、項目介紹這些東西，大家可以自己私下好好思考。我在前面的文章中也提到了應該怎么做自我介紹與項目介紹，詳情可以查看這篇文章：【備戰春招/秋招系列2】初出茅廬的程序員該如何準備面試？。

有人私信我讓我對美團面試難度做一個評級，我覺得如果有10級的話，美團面試的難度大概在6級左右吧！部分情況可能因人而異了。

消息隊列/消息中間件應該是Java程序員必備的一個技能了，如果你之前沒接觸過消息隊列的話，建議先去百度一下某某消息隊列入門，然后花2個小時就差不多可以學會任何一種消息隊列的使用了。如果說僅僅學會使用是萬萬不夠的，在實際生產環境還要考慮消息丟失等等情況。關于消息隊列面試相關的問題，推薦大家也可以看一下視頻《Java工程師面試突擊第1季-中華石杉老師》，如果大家沒有資源的話，可以在我的公眾號“Java面試通關手冊”后臺回復關鍵字“1”即可！

面試官一般會先問你這個問題，預熱一下，看你知道消息隊列不，一般在第一面的時候面試官可能只會問消息隊列MQ的應用場景/使用消息隊列的好處、使用消息隊列會帶來什么問題、消息隊列的技術選型這幾個問題，不會太深究下去，在后面的第二輪/第三輪技術面試中可能會深入問一下。

《大型網站技術架構》第四章和第七章均有提到消息隊列對應用性能及擴展性的提升。

如上圖，在不使用消息隊列服務器的時候，用戶的請求數據直接寫入數據庫，在高并發的情況下數據庫壓力劇增，使得響應速度變慢。但是在使用消息隊列之后，用戶的請求數據發送給消息隊列之后立即 返回，再由消息隊列的消費者進程從消息隊列中獲取數據，異步寫入數據庫。由于消息隊列服務器處理速度快于數據庫（消息隊列也比數據庫有更好的伸縮性），因此響應速度得到大幅改善。

通過以上分析我們可以得出消息隊列具有很好的削峰作用的功能——即通過異步處理，將短時間高并發產生的事務消息存儲在消息隊列中，從而削平高峰期的并發事務。 舉例：在電子商務一些秒殺、促銷活動中，合理使用消息隊列可以有效抵御促銷活動剛開始大量訂單涌入對系統的沖擊。如下圖所示：

因為用戶請求數據寫入消息隊列之后就立即返回給用戶了，但是請求數據在后續的業務校驗、寫數據庫等操作中可能失敗。因此使用消息隊列進行異步處理之后，需要適當修改業務流程進行配合，比如用戶在提交訂單之后，訂單數據寫入消息隊列，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之后，甚至出庫后，再通過電子郵件或短信通知用戶訂單成功，以免交易糾紛。這就類似我們平時手機訂火車票和電影票。

我們知道模塊分布式部署以后聚合方式通常有兩種：1.分布式消息隊列和2.分布式服務。

先來簡單說一下分布式服務：

目前使用比較多的用來構建SOA（Service Oriented Architecture面向服務體系結構）的分布式服務框架是阿里巴巴開源的Dubbo.如果想深入了解Dubbo的可以看我寫的關于Dubbo的這一篇文章：《高性能優秀的服務框架-dubbo介紹》：https://juejin.im/post/5acadeb1f265da2375072f9c

再來談我們的分布式消息隊列：

我們知道如果模塊之間不存在直接調用，那么新增模塊或者修改模塊就對其他模塊影響較小，這樣系統的可擴展性無疑更好一些。

我們最常見的事件驅動架構類似生產者消費者模式，在大型網站中通常用利用消息隊列實現事件驅動結構。如下圖所示：

消息隊列使利用發布-訂閱模式工作，消息發送者（生產者）發布消息，一個或多個消息接受者（消費者）訂閱消息。 從上圖可以看到消息發送者（生產者）和消息接受者（消費者）之間沒有直接耦合，消息發送者將消息發送至分布式消息隊列即結束對消息的處理，消息接受者從分布式消息隊列獲取該消息后進行后續處理，并不需要知道該消息從何而來。對新增業務，只要對該類消息感興趣，即可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展性設計。

消息接受者對消息進行過濾、處理、包裝后，構造成一個新的消息類型，將消息繼續發送出去，等待其他消息接受者訂閱該消息。因此基于事件（消息對象）驅動的業務架構可以是一系列流程。

另外為了避免消息隊列服務器宕機造成消息丟失，會將成功發送到消息隊列的消息存儲在消息生產者服務器上，等消息真正被消費者服務器處理后才刪除消息。在消息隊列服務器宕機后，生產者服務器會選擇分布式消息隊列服務器集群中的其他服務器發布消息。

備注： 不要認為消息隊列只能利用發布-訂閱模式工作，只不過在解耦這個特定業務環境下是使用發布-訂閱模式的，比如在我們的ActiveMQ消息隊列中還有點對點工作模式，具體的會在后面的文章給大家詳細介紹，這一篇文章主要還是讓大家對消息隊列有一個更透徹的了解。

這個問題一般會在上一個問題問完之后，緊接著被問到。“使用消息隊列會帶來什么問題？”這個問題要引起重視，一般我們都會考慮使用消息隊列會帶來的好處而忽略它帶來的問題！

系統可用性降低：系統可用性在某種程度上降低，為什么這樣說呢？在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之后你就需要去考慮了！

系統復雜性提高： 加入MQ之后，你需要保證消息沒有被重復消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！

一致性問題： 我上面講了消息隊列可以實現異步，消息隊列帶來的異步確實可以提高系統響應速度。但是，萬一消息的真正消費者并沒有正確消費消息怎么辦？這樣就會導致數據不一致的情況了!

了解下面這個問題是為了我們更好的進行技術選型！該部分摘自：《Java工程師面試突擊第1季-中華石杉老師》，如果大家沒有資源的話，可以在我的公眾號“Java面試通關手冊”后臺回復關鍵字“1”即可！

這部分內容，我這里不給出答案，大家可以自行根據自己學習的消息隊列查閱相關內容，我可能會在后面的文章中介紹到這部分內容。另外，下面這些問題在視頻《Java工程師面試突擊第1季-中華石杉老師》中都有提到，如果大家沒有資源的話，可以在我的公眾號“Java面試通關手冊”后臺回復關鍵字“1”即可！

引入消息隊列之后如何保證高可用性

如何保證消息不被重復消費呢？

如何保證消息的可靠性傳輸（如何處理消息丟失的問題）？

我該怎么保證從消息隊列里拿到的數據按順序執行？

如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百萬消息持續積壓幾小時，說說怎么解決？

如果讓你來開發一個消息隊列中間件，你會怎么設計架構？

1) count運算上的區別： 因為MyISAM緩存有表meta-data（行數等），因此在做COUNT(*)時對于一個結構很好的查詢是不需要消耗多少資源的。而對于InnoDB來說，則沒有這種緩存。

2) 是否支持事務和崩潰后的安全恢復： MyISAM 強調的是性能，每次查詢具有原子性,其執行數度比InnoDB類型更快，但是不提供事務支持。但是InnoDB 提供事務支持事務，外部鍵等高級數據庫功能。 具有事務(commit)、回滾(rollback)和崩潰修復能力(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型表。

3)是否支持外鍵： MyISAM不支持，而InnoDB支持。

MyISAM更適合讀密集的表，而InnoDB更適合寫密集的的表。 在數據庫做主從分離的情況下，經常選擇MyISAM作為主庫的存儲引擎。

一般來說，如果需要事務支持，并且有較高的并發讀取頻率(MyISAM的表鎖的粒度太大，所以當該表寫并發量較高時，要等待的查詢就會很多了)，InnoDB是不錯的選擇。如果你的數據量很大（MyISAM支持壓縮特性可以減少磁盤的空間占用），而且不需要支持事務時，MyISAM是最好的選擇。

1. 是否保證線程安全： ArrayList 和 LinkedList 都是不同步的，也就是不保證線程安全；

2. 底層數據結構： Arraylist 底層使用的是Object數組；LinkedList 底層使用的是雙向鏈表數據結構（注意雙向鏈表和雙向循環鏈表的區別：）；

3. 插入和刪除是否受元素位置的影響： ① ArrayList 采用數組存儲，所以插入和刪除元素的時間復雜度受元素位置的影響。 比如：執行add(E e) 方法的時候， ArrayList 會默認在將指定的元素追加到此列表的末尾，這種情況時間復雜度就是O(1)。但是如果要在指定位置 i 插入和刪除元素的話（add(int index, E element) ）時間復雜度就為 O(n-i)。因為在進行上述操作的時候集合中第 i 和第 i 個元素之后的(n-i)個元素都要執行向后位/向前移一位的操作。 ② LinkedList 采用鏈表存儲，所以插入，刪除元素時間復雜度不受元素位置的影響，都是近似 O（1）而數組為近似 O（n）。

4. 是否支持快速隨機訪問： LinkedList 不支持高效的隨機元素訪問，而 ArrayList 支持。快速隨機訪問就是通過元素的序號快速獲取元素對象(對應于get(int index) 方法)。

5. 內存空間占用： ArrayList的空 間浪費主要體現在在list列表的結尾會預留一定的容量空間，而LinkedList的空間花費則體現在它的每一個元素都需要消耗比ArrayList更多的空間（因為要存放直接后繼和直接前驅以及數據）。

補充內容:RandomAccess接口

public interface RandomAccess {
}

查看源碼我們發現實際上 RandomAccess 接口中什么都沒有定義。所以，在我看來 RandomAccess 接口不過是一個標識罷了。標識什么？ 標識實現這個接口的類具有隨機訪問功能。

在binarySearch（）方法中，它要判斷傳入的list 是否RamdomAccess的實例，如果是，調用indexedBinarySearch（）方法，如果不是，那么調用iteratorBinarySearch（）方法

    public static 
    int binarySearch(List> list, T key) {
        if (list instanceof RandomAccess || list.size()
ArraysList 實現了 RandomAccess 接口， 而 LinkedList 沒有實現。為什么呢？我覺得還是和底層數據結構有關！ArraysList 底層是數組，而 LinkedList 底層是鏈表。數組天然支持隨機訪問，時間復雜度為 O（1），所以稱為快速隨機訪問。鏈表需要遍歷到特定位置才能訪問特定位置的元素，時間復雜度為 O（n），所以不支持快速隨機訪問。，ArraysList 實現了 RandomAccess 接口，就表明了他具有快速隨機訪問功能。 RandomAccess 接口只是標識，并不是說 ArraysList 實現 RandomAccess 接口才具有快速隨機訪問功能的！
下面再總結一下 list 的遍歷方式選擇：

實現了RadmoAcces接口的list，優先選擇普通for循環 ，其次foreach,
未實現RadmoAcces接口的ist， 優先選擇iterator遍歷（foreach遍歷底層也是通過iterator實現的），大size的數據，千萬不要使用普通for循環

Java 中的集合這類問題幾乎是面試必問的，問到這類問題的時候，HashMap 又是幾乎必問的問題，所以大家一定要引起重視！
3.2 HashMap的底層實現
① JDK1.8之前
JDK1.8 之前 HashMap 底層是 數組和鏈表 結合在一起使用也就是 鏈表散列。HashMap 通過 key 的 hashCode 經過擾動函數處理過后得到 hash  值，然后通過 (n - 1) & hash 判斷當前元素存放的位置（這里的 n 指的時數組的長度），如果當前位置存在元素的話，就判斷該元素與要存入的元素的 hash 值以及 key 是否相同，如果相同的話，直接覆蓋，不相同就通過拉鏈法解決沖突。
所謂擾動函數指的就是 HashMap 的 hash 方法。使用 hash 方法也就是擾動函數是為了防止一些實現比較差的 hashCode() 方法 換句話說使用擾動函數之后可以減少碰撞。
JDK 1.8 HashMap 的 hash 方法源碼:
JDK 1.8 的 hash方法 相比于 JDK 1.7 hash 方法更加簡化，但是原理不變。
      static final int hash(Object key) {
        int h;
        // key.hashCode()：返回散列值也就是hashcode
        // ^ ：按位異或
        // >>>:無符號右移，忽略符號位，空位都以0補齊
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }
對比一下 JDK1.7的 HashMap 的 hash 方法源碼.
static int hash(int h) {
    // This function ensures that hashCodes that differ only by
    // constant multiples at each bit position have a bounded
    // number of collisions (approximately 8 at default load factor).

    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}
相比于 JDK1.8 的 hash 方法 ，JDK 1.7 的 hash 方法的性能會稍差一點點，因為畢竟擾動了 4 次。
所謂 “拉鏈法” 就是：將鏈表和數組相結合。也就是說創建一個鏈表數組，數組中每一格就是一個鏈表。若遇到哈希沖突，則將沖突的值加到鏈表中即可。

② JDK1.8之后
相比于之前的版本， JDK1.8之后在解決哈希沖突時有了較大的變化，當鏈表長度大于閾值（默認為8）時，將鏈表轉化為紅黑樹，以減少搜索時間。

TreeMap、TreeSet以及JDK1.8之后的HashMap底層都用到了紅黑樹。紅黑樹就是為了解決二叉查找樹的缺陷，因為二叉查找樹在某些情況下會退化成一個線性結構。
問完 HashMap 的底層原理之后，面試官可能就會緊接著問你 HashMap 底層數據結構相關的問題！
3.3 既然談到了紅黑樹，你給我手繪一個出來吧，然后簡單講一下自己對于紅黑樹的理解

紅黑樹特點:

每個節點非紅即黑；
根節點總是黑色的；
每個葉子節點都是黑色的空節點（NIL節點）；
如果節點是紅色的，則它的子節點必須是黑色的（反之不一定）；
從根節點到葉節點或空子節點的每條路徑，必須包含相同數目的黑色節點（即相同的黑色高度）

紅黑樹的應用：
TreeMap、TreeSet以及JDK1.8之后的HashMap底層都用到了紅黑樹。
為什么要用紅黑樹
簡單來說紅黑樹就是為了解決二叉查找樹的缺陷，因為二叉查找樹在某些情況下會退化成一個線性結構。
3.4 紅黑樹這么優秀，為何不直接使用紅黑樹得了？
說一下自己對于這個問題的看法：我們知道紅黑樹屬于（自）平衡二叉樹，但是為了保持“平衡”是需要付出代價的，紅黑樹在插入新數據后可能需要通過左旋，右旋、變色這些操作來保持平衡，這費事啊。你說說我們引入紅黑樹就是為了查找數據快，如果鏈表長度很短的話，根本不需要引入紅黑樹的，你引入之后還要付出代價維持它的平衡。但是鏈表過長就不一樣了。至于為什么選 8 這個值呢？通過概率統計所得，這個值是綜合查詢成本和新增元素成本得出的最好的一個值。
3.5  HashMap 和 Hashtable 的區別/HashSet 和 HashMap 區別
HashMap 和 Hashtable 的區別


線程是否安全： HashMap 是非線程安全的，HashTable 是線程安全的；HashTable 內部的方法基本都經過  synchronized  修飾。（如果你要保證線程安全的話就使用 ConcurrentHashMap 吧！）；

效率： 因為線程安全的問題，HashMap 要比 HashTable 效率高一點。另外，HashTable 基本被淘汰，不要在代碼中使用它；

對Null key 和Null value的支持： HashMap 中，null 可以作為鍵，這樣的鍵只有一個，可以有一個或多個鍵所對應的值為 null。。但是在 HashTable 中 put 進的鍵值只要有一個 null，直接拋出 NullPointerException。

初始容量大小和每次擴充容量大小的不同 ：   ①創建時如果不指定容量初始值，Hashtable 默認的初始大小為11，之后每次擴充，容量變為原來的2n+1。HashMap 默認的初始化大小為16。之后每次擴充，容量變為原來的2倍。②創建時如果給定了容量初始值，那么 Hashtable 會直接使用你給定的大小，而 HashMap 會將其擴充為2的冪次方大小（HashMap 中的tableSizeFor()方法保證，下面給出了源代碼）。也就是說 HashMap 總是使用2的冪作為哈希表的大小,后面會介紹到為什么是2的冪次方。

底層數據結構： JDK1.8 以后的 HashMap 在解決哈希沖突時有了較大的變化，當鏈表長度大于閾值（默認為8）時，將鏈表轉化為紅黑樹，以減少搜索時間。Hashtable 沒有這樣的機制。

HashSet 和 HashMap 區別
如果你看過 HashSet 源碼的話就應該知道：HashSet 底層就是基于 HashMap 實現的。（HashSet 的源碼非常非常少，因為除了 clone() 方法、writeObject()方法、readObject()方法是 HashSet 自己不得不實現之外，其他方法都是直接調用 HashMap 中的方法。）

你若盛開，清風自來。 歡迎關注我的微信公眾號：“Java面試通關手冊”，一個有溫度的微信公眾號。公眾號后臺回復關鍵字“1”，可以免費獲取一份我精心準備的小禮物哦！