红黑树存在的合理性
寫在前面
? 主要描述為什么有了二叉查找樹/平衡樹還需要紅黑樹
1、二叉查找樹的缺點
二叉查找樹,相信大家都接觸過,二叉查找樹的特點就是左子樹的節點值比父親節點小,而右子樹的節點值比父親節點大,如圖
基于二叉查找樹的這種特點,我們在查找某個節點的時候,可以采取類似于二分查找的思想,快速找到某個節點。n 個節點的二叉查找樹,正常的情況下,查找的時間復雜度為 O(logn)。
之所以說是正常情況下,是因為二叉查找樹有可能出現一種極端的情況,例如
?
?這種情況也是滿足二叉查找樹的條件,然而,此時的二叉查找樹已經近似退化為一條鏈表,這樣的二叉查找樹的查找時間復雜度頓時變成了 O(n),可想而知,我們必須不能讓這種情況發生,為了解決這個問題,于是我們引申出了平衡二叉樹。
2、平衡二叉樹
平衡二叉樹就是為了解決二叉查找樹退化成一顆鏈表而誕生了,平衡樹具有如下特點
1、具有二叉查找樹的全部特性。
2、每個節點的左子樹和右子樹的高度差至多等于1。
例如:圖一就是一顆平衡樹了,而圖二則不是(節點右邊標的是這個節點的高度)
?
對于圖二,因為節點9的左孩子高度為2,而右孩子高度為0。他們之間的差值超過1了。
平衡樹基于這種特點就可以保證不會出現大量節點偏向于一邊的情況了。關于平衡樹如何構建、插入、刪除、左旋、右旋等操作這里不在說明,具體可以看我之前寫的一篇文章:【漫畫】以后在有面試官問你AVL樹,你就把這篇文章扔給他。
于是,通過平衡樹,我們解決了二叉查找樹的缺點。對于有 n 個節點的平衡樹,最壞的查找時間復雜度也為 O(logn)。
為什么有了平衡樹還需要紅黑樹?
雖然平衡樹解決了二叉查找樹退化為近似鏈表的缺點,能夠把查找時間控制在 O(logn),不過卻不是最佳的,因為平衡樹要求每個節點的左子樹和右子樹的高度差至多等于1,這個要求實在是太嚴了,導致每次進行插入/刪除節點的時候,幾乎都會破壞平衡樹的第二個規則,進而我們都需要通過左旋和右旋來進行調整,使之再次成為一顆符合要求的平衡樹。
顯然,如果在那種插入、刪除很頻繁的場景中,平衡樹需要頻繁著進行調整,這會使平衡樹的性能大打折扣,為了解決這個問題,于是有了紅黑樹,紅黑樹具有如下特點:
1、具有二叉查找樹的特點。
2、根節點是黑色的;
3、每個葉子節點都是黑色的空節點(NIL),也就是說,葉子節點不存數據。
4、任何相鄰的節點都不能同時為紅色,也就是說,紅色節點是被黑色節點隔開的。
5、每個節點,從該節點到達其可達的葉子節點是所有路徑,都包含相同數目的黑色節點。
例如下面的圖片(注意,圖片中黑色的、空的葉子節點沒有畫出)(圖片來自極客時間)
正是由于紅黑樹的這種特點,使得它能夠在最壞情況下,也能在 O(logn) 的時間復雜度查找到某個節點。至于為什么就能夠保證時間復雜度為 O(logn),我這里就不細講了,后面的文章可能會講。
? 不過,與平衡樹不同的是,紅黑樹在插入、刪除等操作,不會像平衡樹那樣,頻繁著破壞紅黑樹的規則,所以不需要頻繁著調整,這也是我們為什么大多數情況下使用紅黑樹的原因。
不過,如果你要說,單單在查找方面的效率的話,平衡樹比紅黑樹快。
所以,我們也可以說,紅黑樹是一種不大嚴格的平衡樹。也可以說是一個折中發方案。
總結
所以,最后的答案是,平衡樹是為了解決二叉查找樹退化為鏈表的情況,而紅黑樹是為了解決平衡樹在插入、刪除等操作需要頻繁調整的情況。
不過,紅黑樹還有挺多其他的知識點可以考,例如紅黑樹有哪些應用場景?向集合容器中 HashMap,TreeMap 等,內部結構就用到了紅黑樹了。還有構建一棵節點個數為 n 的紅黑樹,時間復雜度是多少?紅黑樹與哈希表在不同應該場景的選擇?紅黑樹有哪些性質?紅黑樹各種操作的時間復雜度是多少?
?
轉載于:https://www.cnblogs.com/chihirotan/p/11525400.html
總結
- 上一篇: 基于知识图谱的直升机飞行指挥模型研究
- 下一篇: formSelects-v4.js 基于