1.redis key刪除策略
　　定期刪除：貪心策略
　　　　1.從過期字典中隨機 20 個 key；
　　　　2.刪除這 20 個 key 中已經過期的 key；
　　　　3.如果過期的 key 比率超過 1/4，那就重複步驟 1；
　　惰性刪除：
　　　　在客戶端訪問這個key的時候，redis對key的過期時間進行檢查，如果過期了就立即刪除，不會給你返回任何東西。

　　定期刪除是集中處理，惰性刪除是零散處理。

3.es 為什麼這麼快，分詞的原理，分頁優化

4.配置載入順序優先順序
　　bootstrap.yml在專案啟動時，就會載入
　　application.yml在springContext載入後進行載入
5.springboot常用註解

　　@SpringBootApplication 包含 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan
　　@ImportResource @Scope @Primary @Lazy @Profile
6.資料庫資料發生變化，如何同步給Redis
　　方案1：直接刪除Redis快取；
　　方案2: 基於MQ非同步同步更新
　　方案3： 基於canal訂閱binlog同步
7.專案高併發解決方案
　　非垂直拆分，水平拆分
　　垂直拆分的話就是，增加伺服器節點，消耗成本，升級CPU
　　水平拆分的話包括
　　　　前端頁面靜態化
　　快取：瀏覽器快取 -> CDN加速 -> Nginx動靜分離，Nginx快取 -> Redis快取 -> DB
　　應用拆分，分散式開發，業務拆分
　　資料庫拆分：垂直拆分和水平拆分
　　資料庫連線池、Redis連線池、執行緒池、訊息佇列
　　採用資料搜尋引擎
　　JVM引數優化
8.秒殺專案會有的問題

　　1.商品超賣
　　2.高併發
　　　　頁面優化，執行緒池、mq、訊號量限制
　　3.重複下單
　　4.秒殺地址暴露
　　5.分散式事務

9.資料庫系統的負載均衡
　　多主、一主一從、一主多從、多級主從
10.專案併發量，多執行緒的應用場景
　　高併發系統的本質就是充分利用硬體資源，提升cpu
11.mysql 分庫分表利弊
　　多主、一主一從、一主多從、多級主從
　　缺點：
　　　　分散式事務、
　　關聯查詢 join、排序、函式 問題、
　　分散式ID問題、
　　資料遷移、擴容問題

12.你們項⽬如何排查JVM問題
　　對於還在正常運⾏的系統：
　　1.可以使⽤jmap來檢視JVM中各個區域的使⽤情況
　　2.可以通過jstack來檢視執行緒的運⾏情況，⽐如哪些執行緒阻塞、 是否出現了死鎖
　　3.可以通過jstat命令來檢視垃圾回收的情況，特別是fullgc，如果發現fullgc⽐較頻繁，那麼就得進⾏調優了
　　4.通過各個命令的結果，或者jvisualvm等⼯具來進⾏分析
　　5.⾸先，初步猜測頻繁傳送fullgc的原因，如果頻繁發⽣fullgc但是⼜⼀直沒有出現記憶體溢位，那麼表示fullgc實際上是回收了很多物件了，所以這些物件最好能在younggc過程中就直接回收掉，避免這些對 象進⼊到⽼年代，對於這種情況，就要考慮這些存活時間不⻓的物件是不是⽐較⼤，導致年輕代放不 下，直接進⼊到了⽼年代，嘗試加⼤年輕代的⼤⼩，如果改完之後，fullgc減少，則證明修改有效
　　6.同時，還可以找到佔⽤CPU最多的執行緒，定位到具體的⽅法，優化這個⽅法的執⾏，看是否能避免某些 物件的建立，從⽽節省記憶體

13.對於已經發⽣了OOM的系統：
　　1.⼀般⽣產系統中都會設定當系統發⽣了OOM時，⽣成當時的dump⽂件（- XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）
　　2.我們可以利⽤jsisualvm等⼯具來分析dump⽂件
　　3.根據dump⽂件找到異常的例項物件，和異常的執行緒（佔⽤CPU⾼），定位到具體的程式碼
　　4.然後再進⾏詳細的分析和除錯

　　總之，調優不是⼀蹴⽽就的，需要分析、 推理、 實踐、 總結、 再分析，最終定位到具體的問題

14.Java死鎖如何避免？
　　造成死鎖的⼏個原因：
　　1.⼀個資源每次只能被⼀個執行緒使⽤
　　2.⼀個執行緒在等待時，不釋放已佔有資源
　　3.⼀個執行緒已經獲得的資源，在未使⽤完之前，不能被強⾏剝奪
　　4.若⼲執行緒形成頭尾相接的迴圈等待資源關係

　　這是造成死鎖必須要達到的4個條件，如果要避免死鎖，只需要不滿⾜其中某⼀個條件即可。 ⽽其中前3個條件是作為鎖要符合的條件，所以要避免死鎖就需要打破第4個條件，不出現迴圈等待鎖的關係。

　　在開發過程中：
　　　　1.要注意加鎖順序，保證每個執行緒按同樣的順序進⾏加鎖
　　　　2.要注意加鎖時限，可以針對所設定⼀個超時時間
　　　　3.要注意死鎖檢查，這是⼀種預防機制，確保在第⼀時間發現死鎖並進⾏解決

15.訊息佇列如何保證訊息可靠傳輸
　　訊息可靠傳輸代表了兩層意思，既不能多也不能少。
　　1.為了保證訊息不能多，也就是訊息不能重複
　　　　a.⾸先要確保訊息不多發，這個不常出現，也⽐較難控制，因為如果出現了多發，很⼤的原因是⽣產 者⾃⼰的原因，如果要避免出現問題，就需要在消費端做控制
　　　　b.要避免不重複消費，最保險的機制就是消費者實現冪等性，保證就算重複消費，也不會有問題，通 過冪等性，也能解決⽣產者重複傳送訊息的問題
　　2.訊息不能少，意思就是訊息不能丟失
　　　　a.⽣產者傳送訊息時，要確認訊息投遞成功，⽐如RabbitMQ的transaction機制和confirm機制，Kafka的ack機制都可以保證⽣產者能正確的將訊息傳送給broker
　　　　b.broker：確認broker確實收到並持久化了這條訊息，將佇列的持久化標識durable設定為true
　　　　c.消費端手動ack機制，消費者接收到⼀條訊息後，如果確認沒問題了，就可以給broker傳送⼀個ack，broker接收到ack後才會刪除訊息

16.訊息堆積的解決方案
　　1、訊息傳送的速率遠遠大於訊息消費的速率。
　　　　通過關閉某些不重要的業務，減少傳送的資料量
　　2、消費者出現了問題，導致無法消費。
　　　　a.先修改consumer的問題，確保其恢復消費速度
　　　　b.臨時啟用多個消費者，通過擴容消費端的例項數來提升總體的消費能力。
　　　　c.消費者引數優化，在初始化的時候提高併發消費者的個數

17.合適的執行緒數量是多少？CPU 核心數和執行緒數的關係？
　　執行緒數 = CPU 核心數 *（1+平均等待時間/平均工作時間）

18. 如何讓你來設計訊息佇列中介軟體，如何設計？
　　1、MQ得支援可伸縮性
　　2、就是需要的時候增加吞吐量和容量？
　　3、考慮MQ的資料持久化
　　4、考慮MQ的可用性。
19. 如何保證訊息的順序性
　　a. 使用單執行緒消費來保證訊息的順序性，保證生產者 - MQServer - 消費者是一對一對一的關係
　　b. 對訊息進行編號，消費者處理時根據編號來判斷順序

20. 什麼是沾包拆包
　　TCP以流方式傳輸，是沒有界限的一串資料，並沒有訊息邊界。
　　　　- TCP傳輸資料時，會根據底層的TCP快取區實際情況進行資料包劃分：
　　　　- 1.業務上定義的完整資料(比方說一個完整的json串)，可能會被TCP拆分成多個數據包進行傳送(拆包)。
　　　　- 2.業務上特殊含義的獨立資料，也有可能因為大小或者緩衝區原因，被TCP封裝成一個大資料包傳送(粘包)。
21. 怎麼解決沾包拆包問題
　　1.在傳送端每個資料包首部新增資料包長度欄位，在接收端接收到訊息後，通過讀取首部的長度欄位，便可知道資料包的實際長度了
　　2.傳送端的每個資料包封裝為固定長度（不夠的部分補0填充），這樣接收端就自然而然的把每個資料包拆分開
　　3.設定資料包之間的邊界，如設定特殊符號

22. 一般不建議使用System.gc，為什麼還要有這個方法
　　一般不建議使用system.gc()去顯示地要求進行垃圾回收，一般每一次顯示的呼叫system.gc()都會進行一次full gc,而full gc會導致應用的暫停，如果頻繁地full gc會導致應用長時間暫停，也就無法正常運行了。

23. mysql資料庫刪除重複的資料保留一條
　　解答一：
　　　　delete from Person where Id not in (
　　　　　　select t.min_id from ( select min(Id) as min_id from Person group by Email) as t );

　　解答二：
　　　　delete p1 from Person as p1,Person as p2 where p1.Email=p2.Email and p1.Id > p2.Id;