JS 对象神侃软硬链接与文件拷贝的区别
在 Linux 或 MacOS 系统中, ln
命令是一个重要的命令,它的功能是为某一个文件在另外一个位置建立一个同步的链接。对于前端来说,ln 命令被应用最多的地方就是, 就是全局安装并创建一个 npm 命令
npm i -g xxx(nrm)
当敲下回车,上面的安装执行完成后,在输出中,会看到这样一串字符:
/usr/local/bin/nrm -> /usr/local/lib/node_modules/nrm/cli.js
这串字符背后的意思就是系统建立了 node_modules/nrm/cli.js
的软链接 /bin/nrm
,其实 bin 文件夹中的可执行命令,基本都是以软链接的形式存在。更多关于 ln
的使用,可参考 菜鸟教程
下面会围绕路径 A 和 B 这两个实例来讲软硬链接和文件拷贝的区别:
- 路径 A: /user/wam/A/request.js
- 路径 B: /user/wam/B/request.js
request.js 内容
import utils from './utils'; console.log('res:', utils.res());
目录与文件
在开始前,简单回顾一下大学没学过,可能在那里看到过的文件系统,这里围绕简单易理解的 Linux 为例。
大部分的 Linux 文件系统(如 ext2、ext3)规定,一个文件由目录、节点(inode)和数据块(block)组成
- 目录项:包括文件名和 inode 节点号。
- inode:又称文件索引节点,包含文件的基础信息以及数据块的位置。
- block:包含文件的具体内容。
当我们随便打开我们某个开发项目,命令行输入 ls -li
, 就可看到目录与 inode
的对应信息,下图第一行就是目录对应的 inode。
由于一个文件块(block)的大小有限(通常为 4kb),所有常常一个文件需要存储在多个文件块中,这样 inode 就需要存储多个 block 的位置信息(如最上图所示), 而一个 inode 本身只有 128 Btyes 的存储空间,所以存储文件 block 位置也是间接通过 block 来做的, 所以 block 可以理解为分两种: 文件内容 block 与 inode 信息 block,搞懂这些就可以往下了。
参考资料
软链接
软链接(soft link) 又被称为符号链接,相当于 Window 系统中的快捷方式。
eg: 建立 A 为 B 的软链接
ln -s /user/wam/B/request.js /user/wam/A/request.js
建立软链接 其实质 就是某为路径的建立一个超链接
(在这表现为 A 为 B 的超链接),其不具有文件实体。当我们尝试打开 A 路径所在的文件,其最终在编辑器打开的是路径 B 的文件,所以其文件内的相对路径引用文件也是相对路径 B 来计算的,即 utils 文件路径为:
/user/wam/B/utils.js
当删除 B 文件,再去访问 A, 会发现索引不存在,无法访问。
硬链接
硬链接(hard link), 是为源文件建立另一个索引。
eg: 建立 A 为 B 的硬链接
// 少一个 -s 选项 ln /user/wam/B/request.js /user/wam/A/request.js
建立硬链接 其实质就是 为文件实体创建另一个可访问的路径索引
。所以当我们尝试打开 A 路径所在的文件,与软链接区别的是:其最终在编辑器打开的是路径 A 自己,所以其文件内的 相对路径引用文件 也是相对 路径 A
来计算的, 即 utils 文件路径为:
/user/wam/A/utils.js
但值得一提的是,由于 A 与 B 路径都指向同一个源文件,所以在 A 路径对文件内容所做的编辑都会反映在 B 路径文件,即两边文件的变动是相互同步影响的。
当删除路径 B 时,源文件不会被垃圾回收,因为路径 A 仍保持对源文件的索引。
硬链接和软链接还有一个区别是:因为系统的限制,硬链接要求路径是在文件维度,而软链接既可以是文件,也可以是文件夹。
文件拷贝
这个应该用过电脑的人都懂。
eg: 拷贝文件 B 到路径 A
// 少一个 -s 选项 cp -f /user/wam/B/request.js /user/wam/A/request.js
文件拷贝,是日常我们最常见的操作,只是更常见的形式是用 ctrl + c/v
,而非 cp
命令(实际上 cp 也能实现 ln
链接的操作), 其实质就是 拷贝一份文件实体并创建一个可访问的路径索引
。所以当我们尝试打开 A 路径所在的文件,其指向的实体是不同于 B 的(克隆体),所以其文件内的相对路径引用文件也是相对路径 A 来计算的即 utils 文件路径为,与建立硬链接一致:
/user/wam/A/utils.js
由于 A 路径 与 B 路径 都分别指向自己的实体,所以 A/B 各自是独立的,当删除 B 时,B 对应的源文件会被回收,A 不受任何影响。
神侃 JS 对象与硬软链接
作为前端我们都知道,JS 对象(object)是引用类型。
引用类型的值是保存在内存中的对象。JS 不允许直接访问内存中的位置,即不能直接操作对象的内存空间。在操作对象时,实际上是在操作对象的引用而不是实际的对象。为此,引用类型的值是按引用访问的。(摘抄自红宝书 P87)
你品,你细品。是不是感觉 引用类型 和我们上面讲到文件链接与源文件很像。
const B = { a: 1 };
所以当执行下面这种操作:
const C = B; C.a = 2; console.log('B.a:', B.a); // 2 B.a = 3; console.log('C.a:', C.a); // 3
从上面的执行输出,我们可以很容易看出,原来 JS 中的引用类型变量赋值和 硬链接
是一回事。接着我们引入一个 lodash 的深拷贝(cloneDeep)函数:
import { cloneDeep } from 'lodash'; const C = cloneDeep(B); C.a = 2; console.log('B.a:', B.a); // B.a: 1 B.a = 3; console.log('C.a:', C.a); // C.a: 2
从上面的执行输出,我们可以很容易看出,原来 JS 中的深拷贝和 文件拷贝
是一回事。哪 软链接
怎么用 JS 来描述呢? Proxy ?
Proxy 中文译作 代理
,在表现上其实是与硬链接一致的,而硬链接与软链接从表现上最大的区别就是:B(母体) 被删除后,A(超链接)就不可访问了,所以这并不是正确的答案。
而正确答案是: WeakRef
,弱引用. 当下处于 proposal 阶段 ,不过在 Chrome 与 Firefox 最新的版本都对其做了实现,看个 demo:
let B = { a: 1 }; const C = new WeakRef(B); const registry = new FinalizationRegistry(heldValue => { console.log('GC worked:', heldValue); // GC worked: B // 当 B 所指向的值被垃圾回收后,这个回调将被执行 console.log('C.a:', C.deref()?.a); //C.a: undefined }); // 注册 B 所指向的值被垃圾回收的监听 registry.register(B, "B"); console.log('C.a:', C.deref().a); // C.a: 1 C.deref().a = 2; // 通过索引改变值 console.log('B.a:', B.a); // B.a: 2 B.a = 3; console.log('C.a:', C.deref().a); // C.a: 3 // 切断对值得索引, 观察上面的 GC 回调 B = null; // console.log('after C.a:', C.deref()?.a);
貌似上面的 JS 代码能勉强阐述软链接的原理,但离理想确实还有距离,这个神侃更多的是想让大家对 ES 新提案中的 WeakRef
与 FinalizationRegistry
有一个感性的认识。更多关于 WeakRef
请阅读:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论