跳表這一數(shù)據(jù)結(jié)構(gòu)，已經(jīng)成為了Redis面試的高頻考點。前兩年沒這么卷的時候，可能大家從開始學習，到拿到大廠offer這一過程，都可能沒聽說過跳表這一數(shù)據(jù)結(jié)構(gòu)。

那什么是跳表呢？它是用來干啥的？AVL樹紅黑樹知道吧，對，跳表跟他干的事情差不多。我舉個例子大家就明白了。假設目前有一個有序數(shù)列：

［2， 11，22， 33， 44， 52， 63］

我們想基于單鏈表的思想，設計一個數(shù)據(jù)結(jié)構(gòu)，實現(xiàn)查找時間復雜度為O（logn）。單鏈表的話，它的結(jié)構(gòu)長這個樣子。

當然這個結(jié)構(gòu)，查找時間復雜度妥妥的O（n），那咋改呢？

那換個問法：一般做算法題，手撕代碼面試的時候，當咱寫了個時間復雜度為O（n）的解法，面試官搖搖頭，問你有沒有更好的方法，你會怎么做？

常見復雜度O（nlogn） O（n） O（logn） O（1），要優(yōu)化，一步步來的話，只能上O（logn）了，那復雜度logn最常見的算法是哪個？當然是二分！

思路對了，那對著鏈表，咋把二分思想融合進去呢？

要不單鏈表指針這邊動動刀子？讓指針除了指向后面元素，還能越過幾個節(jié)點，指向更后面元素？類似二叉查找樹？先來看看這個數(shù)組對應的二叉查找樹長什么樣。

當然，由于我們的結(jié)構(gòu)是單鏈表，所以只能有由小值，指向大值，這個二叉樹得改改。

好像有點意思在里面了，再把原先單鏈表的性質(zhì)加上。

走線有點凌亂，按單鏈表的布局顯示方式改改：（值得注意的是，我們需要新建一個數(shù)組項，每個數(shù)組項存儲一個指針，指向剛剛二叉搜索樹每一層最左側(cè)的節(jié)點）

（咋感覺越看越像B+樹了（霧））

來看個查找邏輯吧：

當查找到的結(jié)點保存的數(shù)，比要查找的數(shù)小時，跳表就會繼續(xù)訪問該層上的下一個結(jié)點。

當不滿足時，跳表就會用到當前查找到的結(jié)點的指針數(shù)組的下一層指針，然后沿著下一層指針繼續(xù)查找。對于這種數(shù)據(jù)結(jié)構(gòu)，我們需要從上往下依次查詢?nèi)齻€鏈表，比如我們想查大于35的數(shù)字。

首先按左側(cè)數(shù)組第一個找，發(fā)現(xiàn)中間節(jié)點是33，比較一下比35小。

發(fā)現(xiàn)33比35小，跳下一個節(jié)點。

發(fā)現(xiàn)該節(jié)點是Null，跳33的下一層節(jié)點。

發(fā)現(xiàn)52比35大，再跳下一層節(jié)點。

發(fā)現(xiàn)44比35大，跳下一層節(jié)點，但由于這是最后一層節(jié)點，即44是第一個比33大的數(shù)，滿足最終條件，就找到了第一個比35大的數(shù)字。

我們知道，二叉平衡樹，如果設計插入操作，會特別特別麻煩。對于由二叉平衡樹思想改的跳表也是如此，對于我們這邊的情況，每增加，或者減少一個新節(jié)點，每個節(jié)點的高度都需要變化。。那有沒有高人改進呢？

既然把二叉平衡樹改成這四不像了，為啥再不改改，能不能讓他不平衡的同時，還能保證查找效率？

說實話，還真可以，來看看這種跳表。

雖然這個跳表跟咱剛剛講的跳表比起來，奇形怪狀的，但按剛剛的查找思路，還是能做比較好的查詢工作的。

而且既然表都長這么奇形怪狀了，那添加或者刪新元素，其他節(jié)點高度不變問題也不大了。

而且驚人的是，如果我們對新插入節(jié)點的高度進行隨機產(chǎn)生（每次隨機大于p，接著往上加高度，小于p停下來），然后別的節(jié)點高度保持不變，查找效率還是為O（logn），不會出現(xiàn)像二叉查找樹那種直接退化成O（logn）的情況。

責任編輯：haq