共计 3624 个字符，预计需要花费 10 分钟才能阅读完成。
前一段时间群里有小伙伴问 lucifer 我一个问题：”immutablejs 是什么？有什么用？“。我过后的答复是：immutablejs 就是 tree + sharing，解决了数据可变性带来的问题，并顺便优化了性能。明天给大家来具体解释一下这句话。
背景
咱们还是通过一个例子来进行阐明。如下是几个一般地不能再一般的赋值语句:
a = 1;
b = 2;
c = 3;
d = {
name: "lucifer",
age: 17,
location: "西湖",
};
e = ["脑洞前端", "力扣加加"];下面代码的内存构造大略是这样的：
lucifer 小提示：能够看出，变量名（a，b，c，d，e）只是内存地址的别名而已
因为 d 和 e 的值 是援用类型，数据长度不确定，因而实际上数据区域会指向堆上的一块区域。而 a，b，c 因为长度是编译时确定的，因而能够不便地在栈上存储。
lucifer 小提示：d 和 e 的数据长度不确定，但指针的长度是确定的，因而能够在栈上存储指针，指针指向堆上内存即可。
理论开发咱们常常会进行各种赋值操作，比方：
const ca = a;
const cb = b;
const cc = c;
const cd = d;
const ce = e;通过下面的操作，此时的内存结构图：
能够看出，ca，cb，cc，cd，ce 的 内存地址都变了，然而值都没变。起因在于变量名只是内存的别名而已，而赋值操作传递的是 value。
因为目前 JS 对象操作都是 mutable 的，因而就有可能会产生这样的“bug”：
cd.name = "azl397985856";
console.log(cd.name); // azl397985856
console.log(d.name); // azl397985856下面的 cd.name 原地批改 了 cd 的 name 值，这会影响所有指向 ta 的援用。
比方有一个对象被三个指针援用，如果对象被批改了，那么三个指针都会有影响。
你能够把指针看成线程，对象看成过程资源，资源会被线程共享。多指针就是多线程，当多个线程同时对一个对象进行读写操作就可能会有问题。
于是很多人的做法是 copy（shallow or deep）。这样多个指针的对象都是不同的，能够看成多过程。
接下来咱们进行一次 copy 操作。
const sa = a;
const sb = b;
const sc = c;
const sd = {...d};
const se = [...e];
// 有的人还感觉不过瘾
const sxbk = JSON.parse(JSON.stringify(e));旁观者：为啥你代码那么多 copy 啊？
当事人：我也不晓得为啥要 copy 一下，不过这样做使我安心。
此时援用类型的 value 全副产生了变动，此时内存图是这样的：
下面的”bug“胜利解决。
lucifer 小提示：如果你应用的是 shallow copy，其内层的对象 value 是不会变动的。如果此时你对内层对象进行诸如 a.b.c 的操作，也会有”bug“。
残缺内存图：
（看不清能够尝试放大）
问题
如果是 shallow copy 还好，因为你只 copy 一层，然而随着 key 的减少，性能降落还是比拟显著的。
据测量：
- shallow copy 蕴含 1w 个 属性的对象大略要 10 ms。
- deep copy 一个三层的 1w 个属性的对象大略要 50 ms。
而 immutablejs 能够帮忙咱们缩小这种工夫（和内存）开销，这个咱们稍后会讲。
数据仅供参考，大家也能够用本人的我的项目测量一下。
因为一般我的项目很难达到这个量级，因而根本论断是：如果你的我的项目对象不会很大，齐全没必要思考诸如 immutablejs 进行优化，间接手动 copy 实现 immutable 即可。
如果我的我的项目真的很大呢？那么你能够思考应用 immutable 库来帮你。immutablejs 是有数 immutable 库中的一个。咱们来看下 immutablejs 是如何解决这个性能难题的。
immutablejs 是什么
应用 immutablejs 提供的 API 操作数据，每一次操作都会返回一个新的援用，成果相似 deep copy，然而性能更好。
结尾我说了，immutablejs 就是 tree + sharing，解决了数据可变带来的问题，并顺便提供了性能。其中这里的 tree 就是相似 trie 的一棵树。如果对 trie 不相熟的，能够看下我之前写的一篇前缀树专题。
immutablejs 就是通过树实现的 构造共享。举个例子：
const words = ["lucif", "luck"];我依据 words 构建了一个前缀树，节点不存储数据，数据存储在门路上。其中头节点示意的是对象的援用地址。
这样咱们就将两个单词 lucif 和 luck存到了树上：
当初我想要将 lucif 改成 lucie，一般的做法是齐全 copy 一份，之后批改即可。
newWords = [...words];
newWords[1] = "lucie";
（留神这里整棵树都是新的，你看根节点的内存地址曾经变了）
而所谓的状态共享是：
（留神这里整棵树除了新增的一个节点，其余都是旧的，你看根节点的内存地址没有变）
能够看出，咱们 只是减少了一个节点，并扭转了一个指针而已，其余都没有变动，这就是所谓的构造共享。
还是有问题
仔细观察会发现：应用咱们的办法，会造成 words 和 newWords 援用相等（都是 1fe2ab），即 words === newWords。
因而咱们须要沿着门路回溯到根节点，并批改沿路的所有节点（绿色局部）。在这个例子，咱们仅仅少批改两个节点。然而随着树的节点减少，公共前缀也会随着减少，那时性能晋升会很显著。
整个过程相似上面的动图所示：
取舍之间
后面提到了 沿着门路回溯到根节点，并批改沿路的所有节点。因为树的总节点数是固定的，因而当树很高的时候，某一个节点的子节点数目会很少，节点的复用率会很低。设想一个极其的状况，树中所有的节点只有一个子节点，此时进化到链表，每次批改的工夫复杂度为 O(P)，其中 P 为其先人节点的个数。如果此时批改的是叶子节点，那么 P 就等于 N，其中 N 为 树的节点总数。
树很矮的状况，树的子节点数目会减少，因而每次回溯须要批改的指针减少。如图是有四个子节点的状况，相比于下面的两个子节点，须要多创立两个指针。
设想一种极其的状况，树只有一层。还是将 lucif 改成 lucie。咱们此时只能从新建设一个全新的 lucie 节点，无奈利用已有节点，此时和 deep copy 相比没有一点优化。
因而正当抉择树的叉数是一个难点，相对不是简略的二叉树就行了。这个抉择往往须要做很多试验能力得出一个绝对正当的值。
React
React 和 Vue 最大的区别之一就是 React 更加 “immutable”。React 更偏向于数据不可变，而 Vue 则相同。如果你恰好两个框架都应用过，应该明确我的意思。
应用 immutable 的一个益处是 将来的操作不会影响之前创立的对象。因而你能够很轻松地将利用的数据进行长久化，以便发送给后端做调试剖析或者实现时光旅行（感激可预测的单向数据流）。
联合 Redux 等状态治理框架，immutablejs 能够施展更大的作用。这个时候，你的整个 state tree 应该是 immutablejs 对象，不须要应用一般的 JavaScript 对象，并且操作也须要应用 immutablejs 提供的 API 来进行。并且因为有了 immutablejs，咱们能够很不便的应用全等 === 判断。写 SCU 也不便多了。
SCU 是 shouldComponentUpdate 的缩写。
通过我的几年应用教训来看，应用相似 immutablejs 的库，会使得性能有不稳固的晋升。并且因为多了一个库，调试老本或多或少有所增加，并且有肯定的了解和上手老本。因而我的倡议是 技术咱先学着，如果我的项目的确须要应用，团队成员技术也能够 Cover 的话，再接入也不迟，不可过早优化。
总结
因为数据可变性，当多个指针指向同一个援用，其中一个指针批改了数据可能引发”不堪设想“的成果。随着我的项目规模的增大，这种状况会更加广泛。并且因为将来的操作可能会批改之前创立的对象，因而无奈获取两头某一时刻的状态，这样就短少了两头的链路，很难进行调试。数据不可变则是 将来的操作不会影响之前创立的对象，这就缩小了”不堪设想“的景象，并且因为咱们能够晓得任何中间状态，因而调试也会变得轻松。
手动实现”数据不可变“能够应酬大多数状况。在极其状况下，才会有性能问题。immutablejs 就是 tree + sharing，解决了数据可变带来的问题，并顺便优化了性能。它岂但解决了手动 copy 的性能问题，而且能够在 $O(1)$ 的工夫比拟一个对象是否产生了变动。因而搭配 React 的 SCU 优化 React 利用会很香。
最初举荐我个人感觉不错的另外两个 immutable 库 seamless-immutable 和 Immer。
关注我
大家也能够关注我的公众号《脑洞前端》获取更多更陈腐的前端硬核文章，带你意识你不晓得的前端。
知乎专栏【Lucifer – 知乎】
点关注，不迷路！
