二叉查詢樹最大的特點就是，支援動態資料集合的快速插入、刪除、查詢操作。
雜湊表也是支援這些操作的，而且雜湊表的這些操作比二叉查詢樹更高效，時間複雜度是 o(1)。
既然雜湊表如此高效，那麼雜湊表是不是可以完全替代二叉樹呢。
或者說有沒有什麼地方用雜湊表是做不了的，必須用二叉樹呢？
雜湊表的插入、刪除、查詢操作的時間複雜度可以做到常量級的 o(1)，非常高效。
而二叉查詢樹在比較平衡的情況下，插入、刪除、查詢操作時間複雜度才是 o(logn)。
但是為什麼我們不能完全用雜湊表去替代二叉樹呢？
雜湊表中的資料是無序儲存的，如果要輸出有序的資料，需要先進行排序。
而對於二叉查詢樹來說，我們只需要中序遍歷，就可以在 o(n) 的時間複雜度內，輸出有序的資料序列。
雜湊表擴容耗時很多，而且當遇到雜湊衝突時，效能不穩定。
儘管二叉查詢樹的效能也不穩定，但是在工程中，最常用的平衡二叉查詢樹的效能非常穩定，時間複雜度穩定在 o(logn)。
儘管雜湊表的查詢等操作的時間複雜度是常量級的，但因為雜湊衝突的存在，這個常量不一定比 logn 小，所以實際的查詢速度可能不一定比 o(logn) 快。加上雜湊函式的耗時，也不一定就比平衡二叉查詢樹的效率高。
雜湊表的構造比二叉查詢樹要複雜，需要考慮的東西很多。比如雜湊函式的設計、衝突解決辦法、擴容、縮容等。
平衡二叉查詢樹只需要考慮平衡性這乙個問題，而且這個問題的解決方案比較成熟、固定。
為了避免過多的雜湊衝突，雜湊表裝載因子不能太大，特別是基於開放定址法解決衝突的雜湊表，不然會浪費一定的儲存空間。綜合這幾點，平衡二叉查詢樹在某些方面還是優於雜湊表的。
所以，這兩者的存在並不衝突。我們在實際的使用過程中，需要結合具體的需求來選擇使用哪乙個。
有了互斥量，為什麼還需要條件變數？
一。互斥量和條件變數簡介 互斥量 mutex 從本質上說是一把鎖，在訪問共享資源前對互斥量進行加鎖，在訪問完成後釋放互斥量上的鎖。對互斥量進行加鎖以後，任何其他試圖再次對互斥鎖加鎖的執行緒將會阻塞直到當前執行緒釋放該互斥鎖。如果釋放互斥鎖時有多個執行緒阻塞，所有在該互斥鎖上的阻塞執行緒都會變成可執行...
為什麼有了IP位址還需要MAC位址？
長話短說，理由有三點。二.分層實現如果在ip包頭 header 中增加了 下一跳ip位址 這個字段，在邏輯上來說，如果ip位址夠用，交換機也支援根據ip位址 現在的二層交換機不支援這樣做 其實mac位址並不是必要的。但用mac位址和ip位址兩個位址，用於分別表示實體地址和邏輯位址是有好處的。這樣分層...
既然有了HBase，為什麼還需要Kudu呢？
那既然有了hbase，為什麼還需要kudu呢？簡單的說，就是嫌棄hbase在olap 聯機分析處理 場合，sql mr類的批量檢索場景中，效能不夠好。通常這種海量資料olap場景，要不走預處理的路，比如像ebay麒麟這樣走cube管理的，或者像谷歌mesa這樣按業務需求走預定義聚合操作。再有就是自己...