@qrobot 最后发现 嗯，eventloop 真香. 我跟你举个例子。

我是不是可以使用多线程来执行代码？ 嗯， 是的可以用多线程，来进行共享内存

Yes ， 我写了一个多线程来来操作内存，但是我发现内存会被其他的进行修改， 我感觉很苦恼
Yes ， 我写了一个 Lock 可以锁住这一块内存， 来控制多线程访问的问题，但是我发现了速度很慢
Yes, 我写了一个 Lock-Free 大幅度提高了锁的性能问题，但是我发现不停的创建线程，销毁线程。 这样消耗很大
Yes ， 我写了一个线程池来解决了线程销毁和创建的问题, 但是我发现，如果 IO 很慢的情况下， 线程就会被占用，导致一个请求就一个 IO 这样程序太慢了。
Yes, 我写了一个微任务解决了这个问题， 这样我可以在一个线程上执行多个任务， 这样线程就不会被 IO 阻塞了，我很开心的解决了这个问题， 并且设计出来了， 我给他取了一个好听的名字叫做 Microtask, 和 Microtask queue 。并且给了一个 Work 来单独的执行其他线程的问题。 但是 Work 的开销太大了， 并且没有多线程，共享内存
YEs, 我写了一个多线程来来操作内存，但是我发现内存会被其他的进行修改， 我感觉很苦恼

@fulvaz 然后你换个其他语言，写到最后发现 嗯，JavaScript 真香

@fulvaz 如果是为了构建 fiber 树，例如做 react 或则 vue 这种框架，本身的 eventloop 性能完全足够. 共享内存本身就是一个非常错误的一种解决方案， 共享内存就存在 lock 的问题。其次日志的问题难道不应该先记录到 indexdb 之后在空闲的时候上传到服务器


performance 就能很好的分析内存泄漏的原因， 通过记录用户的操作方式就可以正确的复现出来对应的内存泄漏问题。 如果一直都复现不出来问题， 建议直接联系客服

其次你要是真的觉得 js 的性能你不满意， 欢迎来到

1. (C/C++) Emscripten
2. Rust
3. Go
4. Kotlin
5. Swift
6. D
7. Pascal
8. Zig
9. Grain
10. C#
11. F#
12. gtk

你会其中一门语言就可以达到你说的， 支持多线程，没有瘸腿的异步任务管理。 这些都是可以运行在浏览器端的

@fulvaz 你这明显没黑到点子上

你说的不支持多线程， 在 web 上本来就有 WebWorker 和 webassembly, 基于 eventloop 来说， 对单线程利用率最高，基本上不存在性能问题， 除非是音频和视频解码和编码，或则需要并发计算的，否则基本上在项目中 eventloop 就够用了， 如果真的很大 WebWorker 就能满足了， 至于你说的 IPC 通信需要时间， 我给你科普一下，在大部分场景下，多线程慢单线程， 因为单线程无需上下文切换， 而多线程会切换上下文

多线程下会消耗以下资源


1. 切换页表全局目录
2. 切换内核态堆栈
3. 切换硬件上下文（进程恢复前，必须装入寄存器的数据统称为硬件上下文）
ip(instruction pointer)：指向当前执行指令的下一条指令
bp(base pointer): 用于存放执行中的函数对应的栈帧的栈底地址
sp(stack poinger): 用于存放执行中的函数对应的栈帧的栈顶地址
cr3:页目录基址寄存器，保存页目录表的物理地址
......

4. 刷新 TLB
5. 系统调度器的代码执行


其次在异步任务管理上， 是可以看到这些代码执行了多久， 打开 f12 选择 performance 即可. OOM 和 卡死的问题直接就可以 通过 performance 查看就好了


你这个黑点完全没黑到地方。 要是我黑肯定是


1. 大多数浏览器不符合 W3C 的标准， 例如以前 sort 的返回值
2. css 在不同浏览器上差异太过于明显
3. 不支持并发计算
4. 没有内置好的时间处理函数
5. 没有内置常见的例如 sha rsa ecc base64 等常用加密算法, 例如 btoa 就不能加密中文， 目前都还没解决这个问题
6. 没有好的布局方式 grid 和 flex 等等布局都不是很满意，因为嵌套太深，andoird LinearLayout 似乎不错

@freetree #4L
@bluecube13 #10L


我曾经听到这样一个说法， 我也不知道对还是不对。

婚姻是两个人在一起的冲动行为， 如果在热恋期间，没有进入到婚姻的殿堂，那么后续基本很难在一起结婚。


认识 6 个月 - 2 年左右就是步入婚姻最好的时刻， 超过了这个时间，基本上也很难在走到了一起了， 因为没有了冲动， 彼此之间又太熟悉了。

@des 这个问题非常好查， 看一下代码就好了。nodejs Queue 导致的情况无非就几种情况

有啊，vscode 一搜索一大堆

你可以放个测试用例和最小的可复现的仓库， 我可以帮你分析下

Event loop 等待并不表示 CPU 会占满。 但是 CPU 占满 Event loop 一定会等待

错误的代码导致大量占用 Queue 造成 Event loop 等待， 这是 NodeJS 中新手很容易犯的错误。

@des Queue 不一定会 cpu 占满， 我看到这边堆栈信息好像有大量的 Queue ， 我有很有理由怀疑是这块。epoll 的响应很快的.

@catalysia 是因为技术和材料的问题吗？ 导致只能有设计 Volatile memor 来进行解决速度效率的问题

@catalysia #111L 我非计算机专业, 请教一下， 内存（ Volatile memory ）的作用是什么？ 理论上不需要这个也是可以运行系统的，例如 `linux live cd` 等等

@binfengxy #83L 这就是你把 DDR4 设置成 Disk ， 把 HDD 设置成 RAM 的原因？ [doge]

@justincnn 为啥要换 MAC, 我其实很不太理解

我先说说一下的缺点

1. 键盘 ctrl 按键的问题
2. 系统 /硬件完全不开源
3. 无法自己组装更新对应的硬件信息

如果为了办公效率那肯定选择 `Microsoft Windows`, 如果是为了高性能，高性价比肯定选择 `debian kde/gnome`

1. window 生态强大
2. 可以自己更新对应的硬件，而且价格便宜

mac 这贵的价格，而且这么不自由， 完全就是资本的运作， 你希望你买的产品就算换个电池，Apple 也要求你必须整个 mac 都换掉吗？ 这是极端情况，但是事实是，基本上所有东西都闭源， 甚至 apple 的充电线都会校验是否是 apple 授权的。 这简直太可怕了。 如果一旦 apple 发展起来， 我完全无法想象后面的结果是什么

要么绝对的生产资料（垄断的必需品）， 要么有权。 否则你的工资不会有任何改变

@fanyer #75

你说的 7 年前也就是

npm 3.8.5 是七年前最后一个发布的版本, 因为之后的 3.8.6 是 6 年前发布的， 如果你没说谎, npm 的版本就是 3.8.5


来让我们看看日志啊


你也可以自己打开看


npm-shrinkwrap(1) -- Lock down dependency versions

怕你英语不好， 我帮你翻译下

npm-shrinkwrap(1) -- 锁定依赖版本


- https://github.com/npm/npm/blob/v3.8.5/doc/cli/npm-shrinkwrap.md


人不行，就怪环境不行？ 就算没有 lock ， 操作 `node_modules` 写个 lock 难道很难？ 而且 npm 本身就提供了 npm-shrinkwrap 给你锁版本。

至于你说的第二个问题， 库是即时删除的。verdaccio 7 年前就提供 1.4.0 版本的 npm 私服。

- https://github.com/verdaccio/verdaccio/tree/v1.4.0


我没有 bb, 七年前就方案了。 请问你怎么会觉得没有用？ 还是说你连这个都不知道？ 人不行，就怪路不平？ 水平差就怪 npm 不好用， 设计的有问题？ facebook 觉得 npm 设计不符合他们的想法， 所以做了 yarn, pnpm 觉得 npm 太占磁盘了，所以重写了， 而你做了什么？ 除了抱怨以外，哪怕是给别人提一个 issuse 的事情你做了吗？


你不会，就多问问别人，向别人虚心请教

@des
epoll 性能应该没这么差， 我看堆栈信息上显示好像是大量的占用了 Queue, 具体为什么大量占用 Queue 就要看代码了