1.ArrayList與LinkedList區別

　　數據結構不同 Arraylist是動態數組的數據結構，LinkedList是鏈表 雙向鏈表的數據結構

　　ArrayList是動態數組有初始容量的，而LinkedList是不需要制定初始容量

　　當隨機訪問List(get set )操作時 ArrayList要比LinkedList效率要快一些，因為動態數組結構是連續性的存儲方式，而LinkedList是線性存儲方式，所以需要從前往后依次查找，ArrayList對于數據查詢比較快，但是在插入或者刪除時就是比較慢，因為需要移動其他元素

　　當添加 和刪除時 LinkedList要更快一些，因為不需要管其他元素 對于LinkedList來言 只有查找的時候時間復雜度是O(i) 這里的i指的是 索引的位置，而刪除時間復雜度是O(1)

2.HashMap為什么需要紅黑樹？

　　在原有的鏈表上增加了一個二分搜索法是可以更高效率的優化查詢速度,為什么選擇紅黑樹而不是AVL樹，那是因為在考慮查詢的基礎上還要考慮添加和刪除的代價，AVL樹的旋轉也很耗時，所以被否定

3.HashMap和LinkedHashMap區別？ 

　　HashMap是無序的，而linkedHashMap是有序的  inkedHashMap繼承了HashMap，在hashMap基礎之上又維護了一個雙向鏈表， 可分為插入順序 和訪問順序兩種 如果是訪問順序 那put和get 操作已經存在的Entry時都會把Entry移動到雙向鏈表的最前面，（linkedHashMap使用了LUR（最少使用算法））

4.hashmap什么時候擴容？

　　當元素的個數超過臨界值時就會自動擴容， 臨界值如何計算呢？  計算公式如下：  臨界值=負載因子(默認0.75) * 容量大小（默認16）

5.TreeMap為什么要實現compare接口？

　　treeMap 根據其key鍵自然順序排序，內部使用的不是hashcode也不是equals 是使用的compare排序

6.RocketMQ的實現 如何保證高可用，高吞吐，消息順序，重復消費，事務消息，延遲消息，死信隊列

　　RocketMq如何保證高可用？ 盡量避免單節點的架構，數據要求高最好是一主多從的方式，數據要求不是很高多主多從

　　死信隊列？ 當一條消息初次消費失敗，消息隊列 RocketMQ 會自動進行消息重試;達到最大重試次數后，若消費依然失敗，則表明消費者在正常情況下無法正 確地消費該消息，此時，消息隊列 RocketMQ 不會立刻將消息丟棄，而是將其發送到該消費者對應的特殊隊列中。
在消息隊列 RocketMQ 中，這種正常情況下無法被消費的消息稱為死信消息(Dead-Letter Message)，存儲死信消息的特殊隊列稱為死信隊列 (Dead-Letter Queue)。

　　如何避免死信隊列？解決私信隊列問題  可以在消費過程中做冪等性的時候做好狀態碼控制
　　RocketMq如何保證高吞吐？ 生產消息需要過濾，例如tag關鍵詞，消費消息要多實例 避免消息堆積

　　RocketMq是推模式還是拉模式？不管是推模式還是拉模式底層都是拉模式 

7.RocketMQ如何保證順序消費？

　　如果我們能保證每次生產數據的順序放入的是同一個隊列就可以保證生產者的順序，因為隊列本身就是先進先出的天然數據結構，我們一般都是按照訂單編號取余數%的方式 把當前訂單的順序狀態發送到同一個隊列里，那么在消費端RocketMQ 也給我們提供了兩種消費模式 一種是并發消費MessageListenerConcurrently，一種是順序消費MessageListenerOrderly  我們只要確保消費使用的是順序消費即可，并且順序消費帶來的是降低吞吐量的代價，如果消費端采用的是多線程消費，那么要使用鎖，或者分布式鎖來控制消費端流程，還要注意的是要控制好消費失敗后最大的重試機制，不能讓隊列阻塞

8.RocketMQ如何保證不重復消費?

　　我個人偏向使用 數據庫的主鍵和狀態機來實現這種方式，一來可以控制重復消費 二來狀態機還可以控制死信隊列，消費成功否等問題，

9.如何在一堆字符串里面去尋找一個字符串？

　　使用字母查找樹最完美 時間復雜度O(M)

10.spring bean的生命周期？

  　　 加載系統環境變量 加載 解析 校驗配置合法性 創建 裝配依賴注入（解決三級緩存）使用，銷毀