深刻探究immutable.js的实现机制（一）

Immutable.js 采用了持久化数据结构和结构共享，保证每个对象都是不可变的，任何添加、修改、删除等操做都会生成一个新的对象，且经过结构共享等方式大幅提升性能。
网上已经有不少文章简单介绍了 Immutable.js 的原理，但基本都是浅尝辄止，我也是搜了好久没找到针对 Immutable.js 原理的相对深刻详细的文章，中英文都没有，针对 Clojure 或 Go 中持久化数据结构实现的文章却是有一些。本文会集合多方资料以及我本身的一些理解，深刻一些探究 Immutable.js 实现机制。文章可能会分2-3篇完成。

Immutable.js 部分参考了 Clojure 中的 PersistentVector的实现方式，并有所优化和取舍，本文的一些内容也是基于它，想了解的能够阅读 这里（共五篇，这是第一篇）

简单的例子

在深刻研究前，咱们先看个简单的例子：

let map1 = Immutable.Map({});

for (let i = 0; i < 800; i++) {
  map1 = map1.set(Math.random(), Math.random());
}

console.log(map1);

这段代码前后往map里写入了800对随机生成的key和value。咱们先看一下控制台的输出结果，对它的数据结构有个大体的认知（粗略扫一眼就好了）：

能够看到这是一个树的结构，子节点以数组的形式放在nodes属性里，nodes的最大长度彷佛是32个。这里的bitmap涉及到对于树宽度的压缩，这些后面会说。
其中一个节点层层展开后长这样：

这个ValueNode存的就是一组值了，entry[0]是key，entry[1]是value。

大体看个形状就好了，下面来由浅入深研究一下。

基本原理

咱们先看下维基对于持久化数据结构的定义：

In computing, a persistent data structure is a data structure that always preserves the previous version of itself when it is modified.

通俗点解释就是，对于一个持久化数据结构，每次修改后咱们都会获得一个新的版本，且旧版本能够无缺保留。

Immutable.js 用树实现了持久化数据结构，先看下图这颗树：

假如咱们要在g下面插入一个节点h，如何在插入后让原有的树保持不变？最简单的方法固然是从新生成一颗树：

但这样作显然是很低效的，每次操做都须要生成一颗全新的树，既费时又费空间，于是有了以下的优化方案：

咱们新生成一个根节点，对于有修改的部分，把相应路径上的全部节点从新生成，对于本次操做没有修改的部分，咱们能够直接把相应的旧的节点拷贝过去，这其实就是结构共享。这样每次操做一样会得到一个全新的版本（根节点变了，新的a!==旧的a），历史版本能够无缺保留，同时也节约了空间和时间。
至此咱们发现，用树实现持久化数据结构仍是比较简单的，Immutable.js提供了多种数据结构，好比回到开头的例子，一个map如何成为持久化数据结构呢？

Vector Trie

实际上对于一个map，咱们彻底能够把它视为一颗扁平的树，与上文实现持久化数据结构的方式同样，每次操做后生成一个新的对象，把旧的值全都依次拷贝过去，对须要修改或添加的属性，则从新生成。这其实就是Object.assign，然而这样显然效率很低，有没有更好的方法呢？
在实现持久化数据结构时，Immutable.js 参考了Vector Trie这种数据结构（其实更准确的叫法是persistent bit-partitioned vector trie或bitmapped vector trie，这是Clojure里使用的一种数据结构，Immutable.js 里的相关实现与其很类似），咱们先了解下它的基本结构。
假如咱们有一个 map ，key 全都是数字（固然你也能够把它理解为数组）{0: 'banana', 1: 'grape', 2: 'lemon', 3: 'orange', 4: 'apple'}，为了构造一棵二叉Vector Trie，咱们能够先把全部的key转换为二进制的形式：{'000': 'banana', '001': 'grape', '010': 'lemon', '011': 'orange', '100': 'apple'}，而后以下图构建Vector Trie：

能够看到，Vector Trie的每一个节点是一个数组，数组里有0和1两个数，表示一个二进制数，全部值都存在叶子节点上，好比咱们要找001的值时，只需顺着0 0 1找下来，便可获得grape。那么想实现持久化数据结构固然也不难了，好比咱们想添加一个5: 'watermelon'：

可见对于一个 key 全是数字的map，咱们彻底能够经过一颗Vector Trie来实现它，同时实现持久化数据结构。若是key不是数字怎么办呢？转成数字就好了。 Immutable.js 实现了一个hash函数，能够把一个值转换成相应数字。
这里为了简化，每一个节点数组长度仅为2，这样在数据量大的时候，树会变得很深，查询会很耗时，因此能够扩大数组的长度，Immutable.js 选择了32。为何不是31？40？其实数组长度必须是2的整数次幂，这里涉及到实现Vector Trie时的一个优化，接下来咱们先研究下这点。

数字分区（Digit partitioning）

数字分区指咱们把一个 key 做为数字对应到一棵前缀树上，正如上节所讲的那样。
假如咱们有一个 key 9128，以 7 为基数，即数组长度是 7，它在Vector Trie里是这么表示的：

须要5层数组，咱们先找到3这个分支，再找到5，以后依次到0。为了依次获得这几个数字，咱们能够预先把9128转为7进制的35420，但其实没有这个必要，由于转为 7 进制形式的过程就是不断进行除法并取余获得每一位上的数，咱们无须预先转换好，相似的操做能够在每一层上依次执行。
运用进制转换相关的知识，咱们能够采用这个方法key / radixlevel - 1 % radix获得每一位的数（为了简便，本文除代码外全部/符号皆表示除法且向下取整），其中radix是每层数组的长度，即转换成几进制，level是当前在第几层，即第几位数。好比这里key是9128，radix是7，一开始level是5，经过这个式子咱们能够获得第一层的数3。
代码实现以下：

const RADIX = 7;

function find(key) {
  let node = root; // root是根节点，在别的地方定义了

  // depth是当前树的深度。这种计算方式跟上面列出的式子是等价的，但能够避免屡次指数计算
  for (let size = Math.pow(RADIX, (depth - 1)); size > 1; size /= RADIX) {
    node = node[Math.floor(key / size) % RADIX];
  }

  return node[key % RADIX];
}

位分区（Bit Partitioning）

显然，以上数字分区的方法是有点耗时的，在每一层咱们都要进行两次除法一次取模，显然这样并不高效，位分区就是对其的一种优化。
位分区其实是数字分区的一个子集，全部以2的整数次幂（2，4，8，16，32...）为基数的数字分区前缀树，均可以转为位分区。基于一些位运算相关的知识，咱们就能避免一些耗时的计算。
数字分区把 key 拆分红一个个数字，而位分区把 key 分红一组组 bit。好比一个 32 路的前缀树，数字分区的方法是把 key 以 32 为基数拆分（实际上就是32进制），而位分区是把它以 5bit 拆分，实际上就是把 32 进制数的每一位看作 5 个 bit ，或者说把 32 进制数看作2进制进行操做，这样本来的不少计算就能够用更高效的位运算的方式代替。由于如今基数是 32，即radix为 32，因此前面的式子如今是key / 32level - 1 % 32，而 32 又能够写做25，那么该式子能够转成这样key / 25 × (level - 1) % 25。根据位运算相关的知识咱们知道a / 2n === a >>> n 、a % 2n === a & 2n-1。
其实举个例子最好理解：好比数字666666的二进制形式是10100 01011 00001 01010，这是一个20位的二进制数。若是咱们要获得第二层那五位数01011，咱们能够先把它右移>>>(左侧补0)10位，获得00000 00000 10100 01011，再&一下00000 00000 00000 11111，就获得了01011。
这样咱们能够获得下面的代码：

const SHIFT = 5;
const WIDTH = 1 << SHIFT, //  32
const MASK = WIDTH - 1; // 31，即11111

function find(key) {
  let node = root; 

  for (let shift = (depth - 1) * SHIFT; shift > 0; shift -= SHIFT) {
    node = node[(key >>> shift) & MASK];
  }

  return node[key & MASK];
}

这样咱们每次查找的速度就会获得提高。能够看一张图进行理解，为了简化展现，假设咱们只有2位分区即4路的前缀树，对于626，咱们的查找过程以下：

626的二进制形式是10 01 11 00 10，因此经过以上的位运算，咱们便依次获得了10、01...

源码

说了这么多，咱们看一下 Immutable.js 的源码吧。虽然具体的代码较长，但主要看一下查找的部分就够了，这是Vector Trie的核心。

get(shift, keyHash, key, notSetValue) {
  if (keyHash === undefined) {
    keyHash = hash(key);
  }
  const idx = (shift === 0 ? keyHash : keyHash >>> shift) & MASK;
  const node = this.nodes[idx];
  return node
    ? node.get(shift + SHIFT, keyHash, key, notSetValue)
    : notSetValue;
}

能够看到， Immutable.js 也正是采用了位分区的方式，经过位运算获得当前数组的 index 选择相应分支。
不过它的实现方式与上文所讲的有一点不一样，上文中对于一个 key ，咱们是“正序”存储的，好比上图那个626的例子，咱们是从根节点往下依次按照10 01 11 00 10去存储，而 Immutable.js 里则是“倒序”，按照10 00 11 01 10存储。因此经过源码这段你会发现 Immutable.js 查找时先获得的是 key 末尾的 SHIFT 个 bit ，而后再获得它们以前的 SHIFT 个 bit ，依次往前下去，而前面咱们的代码是先获得 key 开头的 SHIFT 个 bit，依次日后。
至于为何这么作，我一开始也没理解，但仔细想一想这的确是最好的一种方式了，用这种方式的根本缘由是key的大小（二进制长度）不固定，不固定的缘由又是为了减少计算量，同时也能减少空间占用并让树更“平衡”。仔细思考一下的话，你应该能理解。关于这块内容，若是有时间我会放到以后的文章里说。

时间复杂度

由于采用了结构共享，在添加、修改、删除操做后，咱们避免了将 map 中全部值拷贝一遍，因此特别是在数据量较大时，这些操做相比Object.assign有明显提高。
然而，查询速度彷佛减慢了？咱们知道 map 里根据 key 查找的速度是O(1)，这里因为变成了一棵树，查询的时间复杂度变成了O(log N)，准确说是O(log32 N)。
等等， 32 叉树？这棵树可不是通常地宽啊，Javascript里对象能够拥有的key的最大数量通常不会超过232个（ECMA-262第五版里定义了JS里因为数组的长度自己是一个 32 位数，因此数组长度不该大于 2³² - 1 ，JS里对象的实现相对复杂，但大部分功能是创建在数组上的，因此在大部分场景下对象里 key 的数量不会超过 2³² - 1。相关讨论见这里），这样就能够把查找的时间复杂度当作是“O(log32 232)”，差很少就是“O(log 7)”，因此咱们能够认为在实际运用中，5bit (32路)的 Vector Trie 查询的时间复杂度是常数级的，32 叉树就是用了空间换时间。
空间...这个 32 叉树占用的空间也太大了吧？即使只有三层，咱们也会有超过32 × 32 × 32 = 32768个节点。固然 Immutable.js 在具体实现时确定不会傻乎乎的占用这么大空间，它对树的高度和宽度都作了“压缩”，此外，还对操做效率进行了其它一些优化，好比对 list 进行了“tail优化”。相关内容下一篇再讨论。

若是文章里有什么问题欢迎指正。

该文章是我正在更新的深刻探究immutable.js系列的第一篇，我花了很多功夫才完成这篇文章，若是对你有帮助，但愿能点个赞~

而后也请期待下一篇吧~预计一共会分2-3篇写完。该文章里有不懂的地方不要紧，以后的文章会讨论更多内容，同时会有助于对该文章的理解。

第二篇更新到这里了：https://juejin.im/post/5ba4a6...

参考：
https://hypirion.com/musings/...
https://io-meter.com/2016/09/...
https://cdn.oreillystatic.com...
https://michael.steindorfer.n...
https://github.com/facebook/i...