目錄

手撕程式碼

堆排序實現

mysql索引？為什麼用B+樹？

與二叉樹相比  二叉樹相比於順序查詢的確減少了查詢次數，但是在最壞情況下，二叉樹有可能退化為順序查詢。而且就二叉樹本身來說，當資料庫的資料量特別大時，其層數也將特別大。二叉樹的高度一般是log_2^n，B樹的高度是log_t^((n+1)/2) + 1，其高度約比B樹大lgt倍。n是節點總數，t是樹的最小度數。

與B樹相比  B樹在提高IO效能的同時，並沒與解決元素遍歷時效率低下的問題，正是為了解決這個問題，B+數應運而生。B+數只需遍歷葉子節點即可實現整棵樹的遍歷，而B樹必須使用中序遍歷按序掃庫，B+樹支援範圍查詢非常方便。這才是資料庫選用B+樹的主要原因。 ---------------------  作者：PetrichorKe  原文：https://blog.csdn.net/qq_38038480/article/details/81738079 

AVL樹

（1）簡介

AVL樹是帶有平衡條件的二叉查詢樹，一般是用平衡因子差值判斷是否平衡並通過旋轉來實現平衡，左右子樹樹高不超過1，和紅黑樹相比，它是嚴格的平衡二叉樹，平衡條件必須滿足（所有節點的左右子樹高度差不超過1）。不管我們是執行插入還是刪除操作，只要不滿足上面的條件，就要通過旋轉來保持平衡，而旋轉是非常耗時的，由此我們可以知道AVL樹適合用於插入刪除次數比較少，但查詢多的情況。 

紅黑樹

（1）簡介

一種二叉查詢樹，但在每個節點增加一個儲存位表示節點的顏色，可以是red或black。通過對任何一條從根到葉子的路徑上各個節點著色的方式的限制，紅黑樹確保沒有一條路徑會比其它路徑長出兩倍。它是一種弱平衡二叉樹(由於是若平衡，可以推出，相同的節點情況下，AVL樹的高度低於紅黑樹)，相對於要求嚴格的AVL樹來說，它的旋轉次數變少，所以對於搜尋、插入、刪除操作多的情況下，我們就用紅黑樹。

（2）性質

1、每個節點非紅即黑；  2、根節點是黑的；  3、每個葉節點(葉節點即樹尾端NULL指標或NULL節點)都是黑的；  4、如果一個節點是紅的,那麼它的兩兒子都是黑的；  5、對於任意節點而言，其到葉子點樹NULL指標的每條路徑都包含相同數目的黑節點；  6、每條路徑都包含相同的黑節點；

B/B+樹

說了上述的三種樹：二叉查詢樹、AVL和紅黑樹，似乎我們還沒有摸到MySQL為什麼要使用B+樹作為索引的實現，不要急，接下來我們就先探討一下什麼是B樹。

（1）簡介

我們在MySQL中的資料一般是放在磁碟中的，讀取資料的時候肯定會有訪問磁碟的操作，磁碟中有兩個機械運動的部分，分別是碟片旋轉和磁臂移動。碟片旋轉就是我們市面上所提到的多少轉每分鐘，而磁碟移動則是在碟片旋轉到指定位置以後，移動磁臂後開始進行資料的讀寫。那麼這就存在一個定位到磁碟中的塊的過程，而定位是磁碟的存取中花費時間比較大的一塊，畢竟機械運動花費的時候要遠遠大於電子運動的時間。當大規模資料儲存到磁碟中的時候，顯然定位是一個非常花費時間的過程，但是我們可以通過B樹進行優化，提高磁碟讀取時定位的效率。

為什麼B類樹可以進行優化呢？我們可以根據B類樹的特點，構造一個多階的B類樹，然後在儘量多的在結點上儲存相關的資訊，保證層數儘量的少，以便後面我們可以更快的找到資訊，磁碟的I/O操作也少一些，而且B類樹是平衡樹，每個結點到葉子結點的高度都是相同，這也保證了每個查詢是穩定的。

總的來說，B/B+樹是為了磁碟或其它儲存裝置而設計的一種平衡多路查詢樹(相對於二叉，B樹每個內節點有多個分支)，與紅黑樹相比，在相同的的節點的情況下，一顆B/B+樹的高度遠遠小於紅黑樹的高度(在下面B/B+樹的效能分析中會提到)。B/B+樹上操作的時間通常由存取磁碟的時間和CPU計算時間這兩部分構成，而CPU的速度非常快，所以B樹的操作效率取決於訪問磁碟的次數，關鍵字總數相同的情況下B樹的高度越小，磁碟I/O所花的時間越少。

為什麼說B+樹比B樹更適合資料庫索引？

1、 B+樹的磁碟讀寫代價更低：B+樹的內部節點並沒有指向關鍵字具體資訊的指標，因此其內部節點相對B樹更小，如果把所有同一內部節點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多，一次性讀入記憶體的需要查詢的關鍵字也就越多，相對IO讀寫次數就降低了。

2、B+樹的查詢效率更加穩定：由於非終結點並不是最終指向檔案內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查詢必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。

3、由於B+樹的資料都儲存在葉子結點中，分支結點均為索引，方便掃庫，只需要掃一遍葉子結點即可，但是B樹因為其分支結點同樣儲存著資料，我們要找到具體的資料，需要進行一次中序遍歷按序來掃，所以B+樹更加適合在區間查詢的情況，所以通常B+樹用於資料庫索引。

總結  要對查詢的方式進行優化，熟悉的二分查詢，二叉樹可以把速度提升到O(log(n,2))，查詢的瓶頸在於樹的深度，最壞的情況要查詢到二叉樹的最深層，由於，每查詢深一層，就要訪問更深一層的索引檔案。在多達數G的索引檔案中，這將是很大的開銷。所以，儘量把資料結構設計的更為‘矮胖’一點就可以減少訪問的層數。在眾多的解決方案中，B-/B+樹很好的適合。B-樹定義具體可以查閱，簡而言之就是中間節點可以多餘兩個子節點，而且中間的元素可以是一個域。相比B-樹，B+樹的父節點也必須存在於子節點中，是其中最大或者最小元素，B+樹的節點只儲存索引key值，具體資訊的地址存在於葉子節點的地址中。這就使以頁為單位的索引中可以存放更多的節點。減少更多的I/O支出。因此，B+樹成為了資料庫比較優秀的資料結構，MySQL中MyIsAM和InnoDB都是採用的B+樹結構。不同的是前者是非聚集索引，後者主鍵是聚集索引，所謂聚集索引是實體地址連續存放的索引，在取區間的時候，查詢速度非常快，但同樣的，插入的速度也會受到影響而降低。聚集索引的物理位置使用連結串列來進行儲存。

網路IO模型？什麼是多路複用IO？select和epoll的差別？select具體過程？

java類載入機制？雙親委派模型的好處？

程序和執行緒的區別？執行緒是不是越多越好，為什麼？***作系統怎麼排程的，排程演算法？java中cpu排程是執行緒還是程序？

資料庫事務？隔離級別？

java執行緒變數怎麼實現的？記憶體模型？

手撕程式碼

用陣列模擬迴圈連結串列

堆排序實現

資料庫索引？B+樹？為什麼要建索引？什麼樣的欄位需要建索引，建索引的時候一般考慮什麼？索引會不會使插入、刪除***作效率變低，怎麼解決（分表***作）

資料庫事務特點？事務隔離級別？專案中的事務實現？髒讀、不可重複讀、幻讀各舉個例子？

Spring bean的生命週期？預設建立的模式是什麼？不想單例怎麼辦？ 設計模式，單例模式，怎麼保證執行緒安全？鎖效率太低，怎麼提高效率？CAS？CAS本質是什麼？什麼是原子性？Compare and Swap兩步***作，為什麼能保證原子性（涉及到CPU指令）？分散式鎖？

還有什麼設計模式？工廠模式有幾種，都講講？簡單工廠模式和工廠方法有什麼差別？

資料庫表怎麼設計的？資料庫正規化？設計的過程中需要注意什麼？enum型別的值一般怎麼存？如果有一個十幾位的小數為了不丟失精度怎麼存？tinyint幾個位元組，int幾個位元組？

面試