懵懂红黑树_弱点

写在前

今天是2020-06-06,我想系统的学习红黑树，之前或多或少了解了一些红黑树的概念，它是一种数据结构，是由二叉树衍生的平衡二叉树，节点估计是红黑交替的，红黑树会旋转。也仅仅如此的模糊印象，一探究竟，揭开神秘面纱。
找了一篇讲的比较好的文章：
https://www.jianshu.com/p/e136ec79235c
参考着学习，并做一些笔记

一、红黑规则

1.概念

定义：红黑树是一种含有红黑结点并能自平衡的二叉查找树。
说明：红黑树也是二叉查找树，我们知道，二叉查找树这一数据结构并不难，而红黑树之所以难是难在它是自平衡的二叉查找树，在进行插入和删除等可能会破坏树的平衡的操作时，需要重新自处理达到平衡状态。
而自平衡需要遵循以下原则：

• 每个节点不是红色的就是黑色的
• 根总是黑色的
• 如果节点是红色的，则它的子节点必须是黑色的
• 从根节点到叶节点的每条路径，必须包含相同数目的黑色节点

二、黑色完美平衡

红黑树并不是一个完美平衡二叉查找树，从图1可以看到，根结点P的左子树显然比右子树高，但左子树和右子树的黑结点的层数是相等的，也即任意一个结点到到每个叶子结点的路径都包含数量相同的黑结点。所以我们叫红黑树这种平衡为黑色完美平衡。

图1

要实现黑色完美平衡，需要自平衡处理，将不符合红黑规则的树纠正为红黑树，通过以下方式：

• 改变节点的颜色
• 执行旋转（左旋、右旋）操作

变色：结点的颜色由红变黑或由黑变红。
左旋：以某个结点作为支点(旋转结点)，其右子结点变为旋转结点的父结点，右子结点的左子结点变为旋转结点的右子结点，左子结点保持不变。如图2。
右旋：以某个结点作为支点(旋转结点)，其左子结点变为旋转结点的父结点，左子结点的右子结点变为旋转结点的左子结点，右子结点保持不变。如图3。

图2

图3

上面所说的旋转结点也即旋转的支点，图2和图3中的P结点。
我们先忽略颜色，可以看到旋转操作不会影响旋转结点的父结点，父结点以上的结构还是保持不变的。
左旋只影响旋转结点和其右子树的结构，把右子树的结点往左子树挪了。
右旋只影响旋转结点和其左子树的结构，把左子树的结点往右子树挪了。

所以旋转操作是局部的。另外可以看出旋转能保持红黑树平衡的一些端详了：当一边子树的结点少了，那么向另外一边子树“借”一些结点；当一边子树的结点多了，那么向另外一边子树“租”一些结点。

但要保持红黑树的性质，结点不能乱挪，还得靠变色了。现在只需要记住红黑树总是通过旋转和变色达到自平衡。

三、红黑树构建

1.红黑树查找

因为红黑树是一颗二叉平衡树，并且查找不会破坏树的平衡，所以查找跟二叉平衡树的查找无异：

1.从根结点开始查找，把根结点设置为当前结点；
2.若当前结点为空，返回null；
3.若当前结点不为空，用当前结点的key跟查找key作比较；
4.若当前结点key等于查找key，那么该key就是查找目标，返回当前结点；
5.若当前结点key大于查找key，把当前结点的左子结点设置为当前结点，重复步骤2；
6.若当前结点key小于查找key，把当前结点的右子结点设置为当前结点，重复步骤2；

图4
非常简单，而且效率很高。jdk8之后的HashMap底层就是用红黑树优化了链表(之前是有序数组+链表)，正由于红黑树总保持黑色完美平衡，所以它的查找最坏时间复杂度为O(2lgN)，也即整颗树刚好红黑相隔的时候。能有这么好的查找效率得益于红黑树自平衡的特性，而这背后的付出，红黑树的插入、删除操作功不可没～

2.红黑树插入

插入操作包括两部分工作：一查找插入的位置；二插入后自平衡。查找插入的父结点很简单，跟查找操作区别不大：

1.从根结点开始查找；
2.若根结点为空，那么插入结点作为根结点，结束。
3.若根结点不为空，那么把根结点作为当前结点；
4.若当前结点为null，返回当前结点的父结点，结束。
5.若当前结点key等于查找key，那么该key所在结点就是插入结点，更新结点的值，结束。
6.若当前结点key大于查找key，把当前结点的左子结点设置为当前结点，重复步骤4；
7.若当前结点key小于查找key，把当前结点的右子结点设置为当前结点，重复步骤4；

图5
插入位置已经找到，把插入结点放到正确的位置就可以啦，但插入结点是应该是什么颜色呢？答案是红色。理由很简单，红色在父结点（如果存在）为黑色结点时，红黑树的黑色平衡没被破坏，不需要做自平衡操作。但如果插入结点是黑色，那么插入位置所在的子树黑色结点总是多1，必须做自平衡。

所有插入情景如图6所示

图6
8种插入情景！但情景1、2和3的处理很简单，而情景4.2和情景4.3只是方向反转而已，懂得了一种情景就能推出另外一种情景。
另外，根据二叉树的性质，除了情景2，所有插入操作都是在叶子结点进行的。这点应该不难理解，因为查找插入位置时，我们就是在找子结点为空的父结点的。
在开始每个情景的讲解前，我们还是先来约定下，如图7所示。

图7
图7的字母并不代表结点Key的大小。I 表示插入结点，P表示插入结点的父结点，S表示插入结点的叔叔结点，PP表示插入结点的祖父结点。

插入情景1：红黑树为空树

最简单的一种情景，直接把插入结点作为根结点就行，但注意，根据红黑树性质2：根节点是黑色。还需要把插入结点设为黑色。

处理：

• 把插入结点作为根结点，并把结点设置为黑色。

插入情景2：插入结点的Key已存在

插入结点的Key已存在，既然红黑树总保持平衡，在插入前红黑树已经是平衡的，那么把插入结点设置为将要替代结点的颜色，再把结点的值更新就完成插入。

处理：

• 把I设为当前结点的颜色
• 更新当前结点的值为插入结点的值

插入情景3：插入结点的父结点为黑结点

由于插入的结点是红色的，当插入结点的黑色时，并不会影响红黑树的平衡，直接插入即可，无需做自平衡。

处理：直接插入。

插入情景4：插入结点的父结点为红结点

再次回想下红黑树的性质2：根结点是黑色。如果插入的父结点为红结点，那么该父结点不可能为根结点，所以插入结点总是存在祖父结点。这点很重要，因为后续的旋转操作肯定需要祖父结点的参与。

情景4又分为很多子情景，下面将进入重点部分，各位看官请留神了。

插入情景4.1：叔叔结点存在并且为红结点

从红黑树性质4可以，祖父结点肯定为黑结点，因为不可以同时存在两个相连的红结点。那么此时该插入子树的红黑层数的情况是：黑红红。显然最简单的处理方式是把其改为：红黑黑。如图8和图9所示。

处理：

• 将P和S设置为黑色
• 将PP设置为红色
• 把PP设置为当前插入结点
  
  图8
  
  图9
  可以看到，我们把PP结点设为红色了，如果PP的父结点是黑色，那么无需再做任何处理（一个是红黑颜色不矛盾；一个是各支路黑色个数不会变，虽然黑色总数加1，但将根节点的黑拆成了两路子节点的黑仍平衡）；但如果PP的父结点是红色，根据性质4（红节点儿子不能为红节点），此时红黑树存在红红情况，已不平衡了，所以还需要把PP当作新的插入结点，继续做插入操作自平衡处理，直到平衡为止。（此处不明白，不会插了，辈分乱了。。。）

试想下PP刚好为根结点时，那么根据性质2，我们必须把PP重新设为黑色，那么树的红黑结构变为：黑黑红。换句话说，从根结点到叶子结点的路径中，黑色结点增加了。这也是唯一一种会增加红黑树黑色结点层数的插入情景。

我们还可以总结出另外一个经验：红黑树的生长是自底向上的。这点不同于普通的二叉查找树，普通的二叉查找树的生长是自顶向下的。

插入情景4.2：叔叔结点不存在或为黑结点，并且插入结点的父亲结点是祖父结点的左子结点

单纯从插入前来看，也即不算情景4.1自底向上处理时的情况，叔叔结点非红即为叶子结点(Nil)。因为如果叔叔结点为黑结点，而父结点为红结点，那么叔叔结点所在的子树的黑色结点就比父结点所在子树的多了，这不满足红黑树的性质5。后续情景同样如此，不再多做说明了。

前文说了，需要旋转操作时，肯定一边子树的结点多了或少了，需要租或借给另一边。插入显然是多的情况，那么把多的结点租给另一边子树就可以了。

插入情景4.2.1：插入结点是其父结点的左子结点

处理：

• 将P设为黑色
• 将PP设为红色
• 对PP进行右旋
  
  图10
  由图10可得，左边两个红结点，右边不存在，那么一边一个刚刚好，并且因为为红色，肯定不会破坏树的平衡。

咦，可以把P设为红色，I和PP设为黑色吗？答案是可以！看过《算法：第4版》的同学可能知道，书中讲解的就是把P设为红色，I和PP设为黑色。但把P设为红色，显然又会出现情景4.1的情况，需要自底向上处理，做多了无谓的操作，既然能自己消化就不要麻烦祖辈们啦～

插入情景4.2.2：插入结点是其父结点的右子结点

这种情景显然可以转换为情景4.2.1，如图11所示，不做过多说明了。

处理：

• 对P进行左旋
• 把P设置为插入结点，得到情景4.2.1
• 进行情景4.2.1的处理
  
  图11

插入情景4.3：叔叔结点不存在或为黑结点，并且插入结点的父亲结点是祖父结点的右子结点

该情景对应情景4.2，只是方向反转，不做过多说明了，直接看图。

插入情景4.3.1：插入结点是其父结点的右子结点

处理：

• 将P设为黑色
• 将PP设为红色
• 对PP进行左旋
  
  图12

插入情景4.3.2：插入结点是其父结点的左子结点

处理：

• 对P进行右旋
• 把P设置为插入结点，得到情景4.3.1
• 进行情景4.3.1的处理
  
  图13
  好了，讲完插入的所有情景了。可能又同学会想：上面的情景举例的都是第一次插入而不包含自底向上处理的情况，那么上面所说的情景都适合自底向上的情况吗？答案是肯定的。理由很简单，但每棵子树都能自平衡，那么整棵树最终总是平衡的。

3.红黑树删除

红黑树插入已经够复杂了，但删除更复杂，也是红黑树最复杂的操作了。但稳住，胜利的曙光就在前面了！

红黑树的删除操作也包括两部分工作：一查找目标结点；二删除后自平衡。查找目标结点显然可以复用查找操作，当不存在目标结点时，忽略本次操作；当存在目标结点时，删除后就得做自平衡处理了。删除了结点后我们还需要找结点来替代删除结点的位置，不然子树跟父辈结点断开了，除非删除结点刚好没子结点，那么就不需要替代。

二叉树删除结点找替代结点有3种情情景：

情景1：若删除结点无子结点，直接删除
情景2：若删除结点只有一个子结点，用子结点替换删除结点
情景3：若删除结点有两个子结点，用后继结点（大于删除结点的最小结点）替换删除结点

补充说明下，情景3的后继结点是大于删除结点的最小结点，也是删除结点的右子树种最左结点。那么可以拿前继结点（删除结点的左子树最右结点）替代吗？可以的。但习惯上大多都是拿后继结点来替代，后文的讲解也是用后继结点来替代。另外告诉大家一种找前继和后继结点的直观的方法（不知为何没人提过，大家都知道？）：把二叉树所有结点投射在X轴上，所有结点都是从左到右排好序的，所有目标结点的前后结点就是对应前继和后继结点。如图15

图15
接下来，讲一个重要的思路：删除结点被替代后，在不考虑结点的键值的情况下，对于树来说，可以认为删除的是替代结点！话很苍白，我们看图16。在不看键值对的情况下，图17的红黑树最终结果是删除了Q所在位置的结点！这种思路非常重要，大大简化了后文讲解红黑树删除的情景！

图16
基于此，上面所说的3种二叉树的删除情景可以相互转换并且最终都是转换为情景1！

情景2：删除结点用其唯一的子结点替换，子结点替换为删除结点后，可以认为删除的是子结点，若子结点又有两个子结点，那么相当于转换为情景3，一直自顶向下转换，总是能转换为情景1。（对于红黑树来说，根据性质5.1，只存在一个子结点的结点肯定在树末了）
情景3：删除结点用后继结点（肯定不存在左结点），如果后继结点有右子结点，那么相当于转换为情景2，否则转为为情景1。
二叉树删除结点情景关系图如图17所示。

图17
综上所述，删除操作删除的结点可以看作删除替代结点，而替代结点最后总是在树末。有了这结论，我们讨论的删除红黑树的情景就少了很多，因为我们只考虑删除树末结点的情景了。

同样的，我们也是先来总体看下删除操作的所有情景，如图18所示。

图18
哈哈，是的，即使简化了还是有9种情景！但跟插入操作一样，存在左右对称的情景，只是方向变了，没有本质区别。同样的，我们还是来约定下，如图19所示。

图19
图19的字母并不代表结点Key的大小。R表示替代结点，P表示替代结点的父结点，S表示替代结点的兄弟结点，SL表示兄弟结点的左子结点，SR表示兄弟结点的右子结点。灰色结点表示它可以是红色也可以是黑色。

值得特别提醒的是，R是即将被替换到删除结点的位置的替代结点，在删除前，它还在原来所在位置参与树的子平衡，平衡后再替换到删除结点的位置，才算删除完成。

万事具备，我们进入最后的也是最难的讲解。

删除情景1：替换结点是红色结点

我们把替换结点换到了删除结点的位置时，由于替换结点时红色，删除也了不会影响红黑树的平衡，只要把替换结点的颜色设为删除的结点的颜色即可重新平衡。

处理：颜色变为删除结点的颜色

删除情景2：替换结点是黑结点

当替换结点是黑色时，我们就不得不进行自平衡处理了。我们必须还得考虑替换结点是其父结点的左子结点还是右子结点，来做不同的旋转操作，使树重新平衡。

删除情景2.1：替换结点是其父结点的左子结点
删除情景2.1.1：替换结点的兄弟结点是红结点
若兄弟结点是红结点，那么根据性质4，兄弟结点的父结点和子结点肯定为黑色，不会有其他子情景，我们按图21处理，得到删除情景2.1.2.3（后续讲解，这里先记住，此时R仍然是替代结点，它的新的兄弟结点SL和兄弟结点的子结点都是黑色）。

处理：

将S设为黑色
将P设为红色
对P进行左旋，得到情景2.1.2.3
进行情景2.1.2.3的处理

图20
删除情景2.1.2：替换结点的兄弟结点是黑结点
当兄弟结点为黑时，其父结点和子结点的具体颜色也无法确定（如果也不考虑自底向上的情况，子结点非红即为叶子结点Nil，Nil结点为黑结点），此时又得考虑多种子情景。

删除情景2.1.2.1：替换结点的兄弟结点的右子结点是红结点，左子结点任意颜色
即将删除的左子树的一个黑色结点，显然左子树的黑色结点少1了，然而右子树又又红色结点，那么我们直接向右子树“借”个红结点来补充黑结点就好啦，此时肯定需要用旋转处理了。如图22所示。

处理：

将S的颜色设为P的颜色
将P设为黑色
将SR设为黑色
对P进行左旋

图21
平衡后的图怎么不满足红黑树的性质？前文提醒过，R是即将替换的，它还参与树的自平衡，平衡后再替换到删除结点的位置，所以R最终可以看作是删除的。另外图2.1.2.1是考虑到第一次替换和自底向上处理的情况，如果只考虑第一次替换的情况，根据红黑树性质，SL肯定是红色或为Nil，所以最终结果树是平衡的。如果是自底向上处理的情况，同样，每棵子树都保持平衡状态，最终整棵树肯定是平衡的。后续的情景同理，不做过多说明了。

删除情景2.1.2.2：替换结点的兄弟结点的右子结点为黑结点，左子结点为红结点
兄弟结点所在的子树有红结点，我们总是可以向兄弟子树借个红结点过来，显然该情景可以转换为情景2.1.2.1。图如23所示。

处理：

将S设为红色
将SL设为黑色
对S进行右旋，得到情景2.1.2.1
进行情景2.1.2.1的处理

图22
删除情景2.1.2.3：替换结点的兄弟结点的子结点都为黑结点
好了，此次兄弟子树都没红结点“借”了，兄弟帮忙不了，找父母呗，这种情景我们把兄弟结点设为红色，再把父结点当作替代结点，自底向上处理，去找父结点的兄弟结点去“借”。但为什么需要把兄弟结点设为红色呢？显然是为了在P所在的子树中保证平衡（R即将删除，少了一个黑色结点，子树也需要少一个），后续的平衡工作交给父辈们考虑了，还是那句，当每棵子树都保持平衡时，最终整棵总是平衡的。

处理：

将S设为红色
把P作为新的替换结点
重新进行删除结点情景处理

图23
删除情景2.2：替换结点是其父结点的右子结点
好啦，右边的操作也是方向相反，不做过多说明了，相信理解了删除情景2.1后，肯定可以理解2.2。

删除情景2.2.1：替换结点的兄弟结点是红结点
处理：

将S设为黑色
将P设为红色
对P进行右旋，得到情景2.2.2.3
进行情景2.2.2.3的处理

图24
删除情景2.2.2：替换结点的兄弟结点是黑结点
删除情景2.2.2.1：替换结点的兄弟结点的左子结点是红结点，右子结点任意颜色
处理：

将S的颜色设为P的颜色
将P设为黑色
将SL设为黑色
对P进行右旋

图25
删除情景2.2.2.2：替换结点的兄弟结点的左子结点为黑结点，右子结点为红结点
处理：

将S设为红色
将SR设为黑色
对S进行左旋，得到情景2.2.2.1
进行情景2.2.2.1的处理

图26
删除情景2.2.2.3：替换结点的兄弟结点的子结点都为黑结点
处理：

将S设为红色
把P作为新的替换结点
重新进行删除结点情景处理

图27
综上，红黑树删除后自平衡的处理可以总结为：

自己能搞定的自消化（情景1）
自己不能搞定的叫兄弟帮忙（除了情景1、情景2.1.2.3和情景2.2.2.3）
兄弟都帮忙不了的，通过父母，找远方亲戚（情景2.1.2.3和情景2.2.2.3）
哈哈，是不是跟现实中很像，当我们有困难时，首先先自己解决，自己无力了找兄弟姐妹帮忙，如果连兄弟姐妹都帮不上，再去找远方的亲戚了。这里记忆应该会好记点～

哇！恐怖如斯！