CodeSnippet.Cn
代码片段
Csharp
架构设计
.NetCore
西班牙语
kubernetes
MySql
Redis
Algorithm
Ubuntu
Linux
Other
.NetMvc
VisualStudio
Git
pm
Python
WPF
java
Plug-In
分布式
CSS
微服务架构
JavaScript
DataStructure
Shared
啥是跳表？
0
Algorithm
小笨蛋
发布于：2021年11月15日
更新于：2021年11月15日
128
#custom-toc-container
大家好，我的名字是跳表。没有听说过的，心里肯定莫名其妙，这是什么鬼名字？且容我慢慢道来。 ### 说说我的家族 相信你一定知道单向链表和双向链表，还有可能知道循环链表。为什么要提这些链表呢？因为我就是属于链表家族的。 我的家族最让人诟病的是，不支持随机访问（RandomAccess），因为它通常对外只暴露一个头（head）节点，只能一次一个的向后迭代访问。 所以随着链表长度的增加，访问元素需要迭代的次数也在增加。所以时间复杂度就是O(n)。这里的n就是链表的长度。 我的家族最让人称赞的是，可以在任意地方快速的插入/删除元素，而且只需要常量时间，即时间复杂度是O(1)，因为只是修改了几个指针的指向而已。 这里的1表示是一个固定的时间，且该时间不随链表长度的增加而发生改变。这些都是基本的数据结构，相信每个人早已耳熟能详。所以我就不画图啦。 但是，在实际使用中却未必如此。虽然插入/删除元素只需要常量时间，可是它有一个大前提，就是已经定位到了插入点/删除点，这样才可以操作指针的指向。 可是这个定位（插入/删除）节点的过程难道就不是一个元素访问了吗？当然是了，所以仍需要O(n)时间。如果把这个考虑进去，插入/删除元素的总时间其实也是O(n)，因为首先要找到它。 而且在插入元素时，还需要分配内存，可能也需要消耗一点点时间，等等。关于链表更多的内容，请参考我之前的文章《一篇图文彻底搞懂单链表，嗯，是有可能的》《List家族遗产继承PK赛（一）》《List家族遗产继承PK赛（二）》。 因此，对于我的家族来说，提高元素的访问速度非常重要，因为它同时对插入/删除元素也是有利的，可以降低花费的总时间。 ### 提高访问速度的大前提 我的主人经常说，当要处理一个不熟悉的事物时，优先从身边熟悉的事物入手，仔细思考并逐步演化、类比。 书对于任何人来说都再熟悉不过了，而且几乎所有的人都看过书，基本上所有的书都会标页码。 标页码的真正目的是什么，其实我也不知道。但至少有一个作用，就是可以快速的定位到某一页。 不过这依然有一个大前提，那就是页码必须是有序的，无论升序降序都行。注意，不一定非得是连续的。 这样我们就不用一页一页的翻，可以一下子翻几十页或上百页，定位速度自然会快很多。 设想一下，如果页码是杂乱无序的，可能200多页在100多页的前面，那此时页码就没有快速定位的功能了。 只能回到最原始的方式，一页一页的翻，速度奇慢无比。这就是不按套路出牌，就像狄仁杰里的天字二号房间旁边并不是天字一号房间一样。 但是在编程方面，最好还是按套路走，毕竟铁打的公司流水的码农，总要有后人来接手你的代码，整太多“超常规”的话，后生会太痛苦的。 书的页码是一页接一页的，链表的元素也是一个接一个的，所以它们的本质其实比较相似。页码是有序的，所以链表的元素也必须是有序的。 因此，要想提高对链表元素的访问速度，元素之间必须是有序的才行。如果是无序的、杂乱无章的，那基本没有提高的可能性。 ### 提高访问速度方法的探索 还是从书说起。如果一本书有500页，如何才能快速的找到250页左右呢？这个其实对于不爱看书的人也很容易。 那就是让书的侧面对着自己的眼睛，目测一下书的厚度，从中间劈开即可，绝对是250页左右。 如果要找300页呢？当然300页离250页不远，其实就是从中间稍往后偏一点即可。 那如果要找400页呢？如果要找100页呢？采用同样的方法，是不是精确度就要低一些了，因此花费的时间就要多一些。 假如书的总页数是1000页，要找700页，是不是难度就进一步加大了。如果要找730页，难度会更大。 这又该如何搞定呢？我们从熟悉的英文词典入手，由于英文有26个字母，所以所有单词的首字母也只能是26个中的一个。 这样把单词按首字母划分（分组），分为26组，有些词典就把每组印刷成一个颜色，这样从侧面很容易看到颜色交界处。 这些就是特殊的地方（页码），因为首字母在这里发生了变化。还可以把每个字母印刷到侧面上，使用字母加颜色来实现快速定位。 这就给了我们一个启发，要想在一本厚书里快速定位，必须找出特殊的页码。比如100页、200页。。。800页、900页等等，这些特殊地方。 我们可以在每整百页的地方夹上一个纸条，一端露在外面，并写上对应的整百数字。这样再找700页的时候直接找到这个整百纸条即可，速度超快的。 如果我要找770页的话，依然是找到700对应的纸条和800对应的纸条，因为770一定在它们中间而且是靠近800的。 可能有人会想，我干脆也把50页、150页。。。850页、950页等等，这些整五十页的地方也夹上纸条不就得了。 这样在定位770的时候精度更高些，直接找到750和800，在它们之间寻找肯定比在700和800之间要快些。 这种想法（思路）是对的，虽然区间越小越精确，但是不要忘记了，这将使特殊页码变的更多，继而夹的纸条就更多，这样一来看这些纸条反而成了越来越大的负担。 想象一下，如果在每一页上都夹一个纸条，那和压根儿不夹纸条又有什么区别呢？ 所以这是一个权衡的问题，其实就是一个颗粒度的问题。实际是可以根据相关参数计算出来的。 ### 快快快，该我上场了 哎呀，终于轮到我了，为了使大家更容易读懂我，还是以循序渐进的方式展开吧。 首先准备一个有序链表，如下图01：  其中`H`表示头节点，N表示NULL。 假如要查询节点11，那么需要经过11次才能找到。因为我们只能拿到头节点，而头节点只指向了第一个节点。 链表的访问特点是无法改变的，只能通过指针一次次向后迭代。所以如果要想更快的找到节点11，唯一的方法就是改变切入点。 即不从第一个节点开始向后遍历，而直接从中间的某个节点开始向后遍历，可问题是我们没有指向中间某个节点的指针啊。 这好办，那就加一个呗，我们让头节点除了指向第一个节点外，再额外的指向中间的某个节点，如下图02：  可以认为两个头节点是同一个节点，两个NULL节点也是同一个，两个6节点也是同一个。 所以这个图表达的含义就是，我们又增加了一个指针，它指向了节点6。这样一来这个链表就有了两个指针了。 此时从头节点开始，一下子就可以到节点6，接着再向后遍历到节点11，这样一共需要6次，比上回少了5次。 这就相当于在一本书的正中间加了一个书签，可以一步定位到正中间。可是加了一个书签后，人们并不满足。 于是他们就在前半部分的中间和后半部分的中间再各加一个书签，这样三个书签等于把书平均分成四份了。 那么对应到链表中，就是再用两个指针分别指向前半部分的中间节点和后半部分的中间节点。如下图03：  竖直方向上的三个H节点其实是一个节点，同理，3节点、6节点、9节点和N节点也是这样子的。 这里的指针需要注意，指向3节点的指针依然是从H节点发出，但是指向9节点的指针则是从6节点发出的。 这样从H节点一步定位到6节点，然后再一步定位到9节点，接着再向后遍历到11节点，这样一共用去4次，比上回又少了2次。 这样的效果随着链表的增长会变得越来越明显，链表越长，减少的次数就会越多。 ### 更加容易的来理解跳表 上面展示的跳表看明白了吗？哈哈，相信大家都看懂了，但是好像又没有get到本质，那就继续吧。 我们先以一个简单好理解的方式来逐步的构建跳表吧。 首先，准备一个有序链表，如下图01：  其次，从这个链表中均匀的抽出部分节点组成一个新的链表，并放到原链表上方，如下图04：  再次，从刚刚的新链表中均匀的抽出部分节点再组成一个新的链表，并放到原链表上方，如下图05：  最后，重复上述过程，如下图06：  这样看来，这个跳表是由四层链表组成的，其中最底层就是原始链表，包含全量的节点。 从底层往上走，每一层新的链表的节点数都在逐步减少，所以最上层的节点数最少。 由于每一层的链表都是从它的下一层构建出来的，所以每一层都是它的下一层的子集。 即每一层的节点必须在它的下一层中也存在，这很好理解，因为这些节点就是从它的下一层中抽出来的嘛。 就这个跳表而言，假如最底层是0级，那么最高层就是3级。下面来做些练习，看看数据的查找过程是怎样的。 下面是查找节点11的过程：  在第3级上，从H节点向右定位到6节点，由于11大于6，所以继续向右，6节点的右边是NULL，所以就沿着6节点向下进入第2级中。 在第2级上，从6节点向右定位到10节点，由于11大于10，所以继续向右，10节点的右边是NULL，所以沿着10节点向下进入第1级中。 在第1级上，10节点的右边是NULL，所以沿着10节点向下进入第0级中。 在第0级上，从10节点向右定位到11节点，于是节点11就找到了。 下面是查找节点5的过程：  在第3级上，从H节点向右定位到6节点，发现6大于5，所以就沿着H节点向下进入第2级中。 在第2级上，从H节点向右定位到2节点，发现2小于5，继续向右定位6节点，发现6大于5，所以沿着2节点向下进入第1级中。 在第1级上，从2节点向右定位到4节点，发现4小于5，继续向右定位6节点，发现6大于5，所以沿着4节点向下进入第0级中。 在第0级上，从4节点向右定位到5节点，于是节点5就找到了。 其实整个工作原理和二叉树差不多，首先从最顶层开始，可以理解为树的根。 如果要查找的节点比当前节点大，那就在右边部分找，如果没有那就进入下一级中，继续在右边找。 如果要查找的节点比当前节点小，则直接进入下一级中，继续在右边找。 只要重复这个过程，就会逐级下降，如果这个节点存在的话，最后一定会找到。 其实除了最底层的原始链表外，其余的上层链表都可以认为是构建的索引，正是利用了这些索引，才加快了查找。 利用索引的效果就是我们可以跳过一些节点来快速定位，因此这就是跳表名称的由来吧。 很明显这是在用空间换取时间，所以查找、插入和删除操作的平均时间复杂度就由O(n)降为O(logn)了。 如果一个链表的长度是n的话，在不考虑头尾节点的情况下，共需要n个指针。 在构建跳表时，如果每一层的节点数目都是它的下一层的一半的话，那么总共需要2n个指针，即翻了一倍。 由于全部层级的元素节点都是共用的，所以节点数目没有变化。因此空间复杂度和抽取节点的比例有关，且只对指针数目产生影响。
这里⇓感觉得写点什么，要不显得有点空，但还没想好写什么...
返回顶部
About
京ICP备13038605号
© 代码片段 2024
Algorithm