本文转载自：http://blog.csdn.net/bytxl/article/details/40920165

二叉查找树(Binary Search Tree)

很显然，二叉查找树的发现完全是因为静态查找结构在动态插入，删除结点所表现出来的无能为力(需要付出极大的代价)。

BST 的操作代价分析：

    (1) 查找代价： 任何一个数据的查找过程都需要从根结点出发，沿某一个路径朝叶子结点前进。因此查找中数据比较次数与树的形态密切相关。

         当树中每个结点左右子树高度大致相同时，树高为logN。则平均查找长度与logN成正比，查找的平均时间复杂度在O(logN)数量级上。

         当先后插入的关键字有序时，BST退化成单支树结构。此时树高n。平均查找长度为(n+1)/2，查找的平均时间复杂度在O(N)数量级上。

    (2) 插入代价： 新结点插入到树的叶子上，完全不需要改变树中原有结点的组织结构。插入一个结点的代价与查找一个不存在的数据的代价完全相同。

    (3) 删除代价： 当删除一个结点P，首先需要定位到这个结点P，这个过程需要一个查找的代价。然后稍微改变一下树的形态。如果被删除结点的左、右子树只有一个存在，则改变形态的代价仅为O(1)。如果被删除结点的左、右子树均存在，只需要将当P的左孩子的右孩子的右孩子的…的右叶子结点与P互换，在改变一些左右子树即可。因此删除操作的时间复杂度最大不会超过O(logN)。

    BST效率总结 :  查找最好时间复杂度O(logN)，最坏时间复杂度O(N)。

                            插入删除操作算法简单，时间复杂度与查找差不多

AVL树

二叉查找树在最差情况下竟然和顺序查找效率相当，这是无法仍受的。事实也证明，当存储数据足够大的时候，树的结构对某些关键字的查找效率影响很大。当然，造成这种情况的主要原因就是BST不够平衡(左右子树高度差太大)。

既然如此，那么我们就需要通过一定的算法，将不平衡树改变成平衡树。因此，AVL树就诞生了。

AVL树得名于它的发明者 G.M. Adelson-Velsky 和 E.M. Landis，他们在 1962 年的论文 “An algorithm for the organization of information” 中发表了它。

AVL树是最早的自平衡二叉树，相比于后来出现的（自）平衡二叉树（红黑树，treap，splay树）而言，它现在应用较少，但研究AVL树对于了解后面出现的常用（自）平衡二叉树具有重要意义。

在AVL树中任何节点的两个儿子子树的高度最大差别为一，所以它也被称为高度平衡树。查找、插入和删除在平均和最坏情况下都是O(log n)。增加和删除可能需要通过一次或多次树旋转来重新平衡这个树。

引入AVL树的目的是为了提高二叉树的搜索的效率,减少树的平均搜索长度.为此,就必须每向二叉树插入一个结点时调整树的结构,使得二叉树搜索保持平衡,从而可能降低树的高度,减少的平均树的搜索长度. 

AVL树的定义: 
一棵AVL树满足以下的条件: 
1>它的左子树和右子树都是AVL树 
2>左子树和右子树的高度差不能超过1 
从条件1可能看出是个递归定义,如GNU一样. 

性质: 
1>一棵n个结点的AVL树的其高度保持在0(log2(n)),不会超过3/2log2(n+1) 
2>一棵n个结点的AVL树的平均搜索长度保持在0(log2(n)). 
3>一棵n个结点的AVL树删除一个结点做平衡化旋转所需要的时间为0(log2(n)). 

从1这点来看红黑树是牺牲了严格的高度平衡的优越条件为 代价。

AVL 的操作代价分析：

    (1) 查找代价： AVL是严格平衡的BST（平衡因子不超过1）。那么查找过程与BST一样，只是AVL不会出现最差情况的BST(单支树)。因此查找效率最好，最坏情况都是O(logN)数量级的。

    (2) 插入代价： AVL必须要保证严格平衡(|bf|<=1)，那么每一次插入数据使得AVL中某些结点的平衡因子超过1就必须进行旋转操作。事实上，AVL的每一次插入结点操作最多只需要旋转1次(单旋转或双旋转)。因此，总体上插入操作的代价仍然在O(logN)级别上(插入结点需要首先查找插入的位置)。

    (3) 删除代价：AVL删除结点的算法可以参见BST的删除结点，但是删除之后必须检查从删除结点开始到根结点路径上的所有结点的平衡因子。因此删除的代价稍微要大一些。每一次删除操作最多需要O(logN)次旋转。因此，删除操作的时间复杂度为O(logN)+O(logN)=O(2logN)

    AVL 效率总结 :  查找的时间复杂度维持在O(logN)，不会出现最差情况

                            AVL树在执行每个插入操作时最多需要1次旋转，其时间复杂度在O(logN)左右。

                            AVL树在执行删除时代价稍大，执行每个删除操作的时间复杂度需要O(2logN)。

红黑树(Red-Black Tree ) 

二叉平衡树的严格平衡策略以牺牲建立查找结构(插入，删除操作)的代价，换来了稳定的O(logN) 的查找时间复杂度。但是这样做是否值得呢？

能不能找一种折中策略，即不牺牲太大的建立查找结构的代价，也能保证稳定高效的查找效率呢？ 答案就是：红黑树。

        红黑树并不追求“完全平衡”——它只要求部分地达到平衡要求，降低了对旋转的要求，从而提高了性能。

红黑树能够以O(log₂ n) 的时间复杂度进行搜索、插入、删除操作。此外，由于它的设计，任何不平衡都会在三次旋转之内解决。当然，还有一些更好的，但实现起来更复杂的数据结构，能够做到一步旋转之内达到平衡。但红黑树能够给我们一个比较“便宜”的解决方案。红黑树的算法时间复杂度和AVL相同，但统计性能比AVL树更高。

        当然，红黑树并不适应所有应用树的领域。如果数据基本上是静态的，那么让他们待在他们能够插入，并且不影响平衡的地方会具有更好的性能。如果数据完全是静态的，例如，做一个哈希表，性能可能会更好一些。

在实际的系统中，例如，需要使用动态规则的防火墙系统，使用红黑树而不是散列表被实践证明具有更好的伸缩性。

典型的用途是实现关联数组

RBT 的操作代价分析：

     (1) 查找代价：由于红黑树的性质(最长路径长度不超过最短路径长度的2倍)，可以说明红黑树虽然不像AVL一样是严格平衡的，但平衡性能还是要比BST要好。其查找代价基本维持在O(logN)左右，但在最差情况下(最长路径是最短路径的2倍少1)，比AVL要略逊色一点。

    (2) 插入代价：RBT插入结点时，需要旋转操作和变色操作。但由于只需要保证RBT基本平衡就可以了。因此插入结点最多只需要2次旋转，这一点和AVL的插入操作一样。虽然变色操作需要O(logN)，但是变色操作十分简单，代价很小。

    (3) 删除代价：RBT的删除操作代价要比AVL要好的多，删除一个结点最多只需要3次旋转操作。

    RBT 效率总结 : 查找 效率最好情况下时间复杂度为O(logN)，但在最坏情况下比AVL要差一些，但也远远好于BST。

                           插入和删除操作改变树的平衡性的概率要远远小于AVL（RBT不是高度平衡的）。因此需要的旋转操作的可能性要小，而且一旦需要旋转，插入一个结点最多只需要旋转2次，删除最多只需要旋转3次(小于AVL的删除操作所需要的旋转次数)。虽然变色操作的时间复杂度在O(logN)，但是实际上，这种操作由于简单所需要的代价很小。

B~树/B+树 (B-Tree ) 

对于在内存中的查找结构而言，红黑树的效率已经非常好了(实际上很多实际应用还对RBT进行了优化)。但是如果是数据量非常大的查找呢？将这些数据全部放入内存组织成RBT结构显然是不实际的。实际上，像OS中的文件目录存储，数据库中的文件索引结构的存储…. 都不可能在内存中建立查找结构。必须在磁盘中建立好这个结构。那么在这个背景下，RBT还是一种好的选择吗？

     在磁盘中组织查找结构，从任何一个结点指向其他结点都有可能读取一次磁盘数据，再将数据写入内存进行比较。大家都知道，频繁的磁盘IO操作，效率是很低下的(机械运动比电子运动要慢不知道多少)。显而易见，所有的二叉树的查找结构在磁盘中都是低效的。因此，B树很好的解决了这一个问题。

    B-Tree的操作代价分析：

    (1) 查找代价： B-Tree作为一个平衡多路查找树(m-叉)。B树的查找分成两种：一种是从一个结点查找另一结点的地址的时候，需要定位磁盘地址(查找地址)，查找代价极高。另一种是将结点中的有序关键字序列放入内存，进行优化查找(可以用折半)，相比查找代价极低。而B树的高度很小，因此在这一背景下，B树比任何二叉结构查找树的效率都要高很多。而且B+树作为B树的变种，其查找效率更高。

    (2)插入代价： B-Tree的插入会发生结点的分裂操作。当插入操作引起了s个节点的分裂时，磁盘访问的次数为h(读取搜索路径上的节点)＋2s(回写两个分裂出的新节点)＋1（回写新的根节点或插入后没有导致分裂的节点）。因此，所需要的磁盘访问次数是h+2s+1，最多可达到3h+1。因此插入的代价是很大的。

    (3)删除代价：B-Tree的删除会发生结点合并操作。最坏情况下磁盘访问次数是3h＝（找到包含被删除元素需要h次
读访问）+（获取第2至h层的最相邻兄弟需要h-1次读访问）+（在第3至h层的合并需要h-2次写
访问）+（对修改过的根节点和第2层的两个节点进行3次写访问）

   B-Tree效率总结： 由于考虑磁盘储存结构，B树的查找、删除、插入的代价都远远要小于任何二叉结构树(读写磁盘次数的降低)。

伸展树

伸展树使用“自调整”的数据结构。时间复杂度比较低低，各种基本操作的平摊时间复杂度为0(log2(n))。

与平衡结构或有明确限制的数据结构相比，自调整的数据结构有以下几个优点：

1、从平摊角度来说，它们忽略常量因子，因此绝对不会差于有明确限制的数据结构。而且由于它们可以根据具体使用情况进行调整，所以在
使用模式不均匀
的情况下更加有效； 

2、由于无需存储平衡信息或者其它限制信息，所以所需的存储空间更小； 

3、它们的查找和更新算法概念和操作都很简单，易于实现。 

当然，自调整结构也有其潜在的缺点： 

1、它们需要更多的局部调整，尤其是在查找期间。而那些有明确限制的数据结构仅需要在更新期间进行调整，查找期间则不用； 

2、一系列查找操作中的某一个可能会耗时较长，这在实时应用程序中可能是一个不足之处。

平衡二叉树AVL VS 红黑树  [AVL  PK  RBT]

      AVL 和RBT 都是二叉查找树的优化。其性能要远远好于二叉查找树。他们之间都有自己的优势，其应用上也有不同。

      结构对比： AVL的结构高度平衡，RBT的结构基本平衡。平衡度AVL > RBT.

      查找对比： AVL 查找时间复杂度最好，最坏情况都是O(logN)。

                      RBT 查找时间复杂度最好为O(logN)，最坏情况下比AVL略差。

      插入删除对比：  1. AVL的插入和删除结点很容易造成树结构的不平衡，而RBT的平衡度要求较低。因此在大量数据插入的情况下，RBT需要通过旋转变色操作来重新达到平衡的频度要小于AVL。

                             2. 如果需要平衡处理时，RBT比AVL多一种变色操作，而且变色的时间复杂度在O(logN)数量级上。但是由于操作简单，所以在实践中这种变色仍然是非常快速的。

                             3. 当插入一个结点都引起了树的不平衡，AVL和RBT都最多需要2次旋转操作。但删除一个结点引起不平衡后，AVL最多需要logN 次旋转操作，而RBT最多只需要3次。因此两者插入一个结点的代价差不多，但删除一个结点的代价RBT要低一些。

                             4. AVL和RBT的插入删除代价主要还是消耗在查找待操作的结点上。因此时间复杂度基本上都是与O(logN) 成正比的。

        总体评价：大量数据实践证明，RBT的总体统计性能要好于平衡二叉树。

B~树 VS B+树  [ B~Tree  PK  B+Tree ]

      B+树是B~树的一种变体，在磁盘查找结构中，B+树更适合文件系统的磁盘存储结构。

      结构对比： B~树是平衡多路查找树，所有结点中都包含了待查关键字的有效信息(比如文件磁盘指针)。每个结点若有n个关键字，则有n+1个指向其他结点的指针。

                     B+树严格意义上说已经不是树，它的叶子结点之间也有指针链接。B+树的非终结点中并不含有关键字的信息，需要查找的关键字的全部信息都包含在叶子结点上。非终结点中只作为叶子结点关键字的索引而存在。

      查找对比：1. 在相同数量的待查数据下，B+树查找过程中需要调用的磁盘IO操作要少于普通B~树。由于B树所在的磁盘存储背景下，因此B+树的查找性能要好于B~树。

                     2. B+树的查找效率更加稳定，因为所有叶子结点都处于同一层中，而且查找所有关键字都必须走完从根结点到叶子结点的全部历程。因此同一颗B+树中，任何关键字的查找比较次数都是一样的。而B树就不一定了，可能查找到某一个非终结点就结束了。

      插入删除对比：  B+树与B~树在插入删除操作中的效率是差不多的。

      总体评价：在应用背景下，特别是文件结构存储中。B+树的应用要更多，其效率也要比B~树好。

其它比较

AVL trees are actually easier to implement than RB trees because there are fewer cases. And AVL trees require O(1) rotations on an insertion, whereas red-black trees require O(lg n). 
In practice, the speed of AVL trees versus red-black trees will depend on the data that you’re inserting. If your data is well distributed, so that an unbalanced binary tree would generally be acceptable (i.e. roughly in random order), but you want to handle bad cases anyway, then red-black trees will be faster because they do less unnecessary rebalancing of already acceptable data.On the other hand, if a pathological insertion order (e.g. increasing order of key) is common, then AVL trees will be faster, because the stricter balancing rule will reduce the tree’s height. 
Splay trees might be even faster than either RB or AVL trees,depending on your data access distribution. And if you can use a hash instead of a tree, then that’ll be fastest of all. 

试着翻译一下：

由于AVL树种类较少（应该是AVL树在编程时需要处理的情况较少？），所以比红黑树实际上更容易实现。而且AVL树在旋转插入所需要的复杂度为0(1)，而红黑树则需要的复杂度为0(log2(n))。
实际上插入AVL树和红黑树的速度取决于你所插入的数据。

如果你的数据分布较好，则比较宜于采用AVL树(例如随机产生系列数)(应该是适宜于采用一般搜索二叉树unbalanced binary tree）；

但是如果你想处理比较杂乱的情况（什么叫杂乱的情况？bad cases？），则红黑树是比较快的，因为红黑树对已经处理好的数据重新平衡减少了不必要的操作。

另外一方面，如果是一种非寻常的插入系列，比较常见(比如,插入密钥系列)，则AVL树比较快，因为它的严格的平衡规则将会减少树的高度。
Splay树可能比红黑树和AVL树还要快，这也取决于你所访问的数据分布。

如果你用哈希表来代替一棵树，则在以上所有中，它将是最快的。

红黑树是一个更高效的检索二叉树，因此常常用来实现关联数组。典型地，JDK 提供的集合类 TreeMap 本身就是一个红黑树的实现。

IBM DevelopWorks 上一篇文章讲解非常好，供参考。

TreeMap 和 TreeSet 是 Java Collection Framework 的两个重要成员，其中 TreeMap 是 Map 接口的常用实现类，而 TreeSet 是 Set 接口的常用实现类。虽然 HashMap 和 HashSet 实现的接口规范不同，但 TreeSet 底层是通过 TreeMap 来实现的，因此二者的实现方式完全一样。而 TreeMap 的实现就是红黑树算法。   对于 TreeMap 而言，由于它底层采用一棵“红黑树”来保存集合中的 Entry，这意味这 TreeMap 添加元素、取出元素的性能都比 HashMap 低：当 TreeMap 添加元素时，需要通过循环找到新增 Entry 的插入位置，因此比较耗性能；当从 TreeMap 中取出元素时，需要通过循环才能找到合适的 Entry，也比较耗性能。   但 TreeMap、TreeSet 比 HashMap、HashSet 的优势在于：TreeMap 中的所有 Entry 总是按 key 根据指定排序规则保持有序状态，TreeSet 中所有元素总是根据指定排序规则保持有序状态。