除了优化代码/重启外，你们是如何应对 Bun 内存泄漏问题的 Nodejs

发布于 1周前 作者 htzhanglong 来自 nodejs/Nestjs

这玩意给我漏麻了，Nodejs 跑几个小时不泄漏东西，这玩意直接给我漏 1 个 G 出来，谷歌搜也只搜到个中文推文也在吐槽 Bun 疯狂漏内存这事，请问一下你们有遇到过或者有比较好的解决点子吗？目前已用–smol
除了优化代码/重启外，你们是如何应对 Bun 内存泄漏问题的 Nodejs

Harmonyos Next教程
42 回复

目前用 pm2 能缓解这个问题

pm2 start app.js -i max --max-restarts 1000


回 Node 吧，Node 最近加入了 Typescript 的直接运行支持，除了一些 Typescript 特殊语法 enum 和 namespace 等…

https://github.com/nodejs/node/releases/tag/v22.6.0

手快了，以上话题无关，请忽略

哈哈哈哈，1.0 出来好久了，居然有内存泄露，那还咋上生产呀

不明白都这样了为什么还要用 bun ？尝试不就是为了了解然后做选择吗？

当然是用 nodejs 了,bun 这个包子还不稳定

真是都不敢用

也可以尝试下 Deno

手头有一个项目 Bun+Nuxt ，crontab 定期重启先应付着

这和定期重启 Java 虚拟机有何区别，为啥一定要用它呢

看来是因为没触发泄漏，就这么一直用着，177MB 内存的小服务 uptime 335 天。反正感觉比 node 爽就是一切。

阿里内部 nodejs 项目组对比测试过 nodejs vs bun ， 综合看后者性能并不明显。目前不推荐生产上 bun 。

Bun 使用的是苹果的 JavaScriptCore ，而苹果官方只在 macOS 和 iOS 上有相关产品使用 JavaScriptCore 吧？那稳定性和性能比得过在谷歌开发的、多平台都有产品使用的 V8 吗？

个人觉得 Bun 和之前微软整的把 Node.js 核心换成 ChakraCore 的项目都不靠谱。

不如先把 Bun 用来跑单元测试和开发环境，最直接优化你的开发体验，生产环境其实没必要的

定时查询当前进程内存占用，高过一个值就自杀？ 以前我就是这么干的
node 还有查询当前内存量的 api,不知道 bun 有没有

有个小小的程序在跑，用的 pm2 ，半个月漏 60M

为啥我写的程序没看出啥问题，

我宁愿把时间花在代码转换上, 也不想踩未知的坑.

图他快，结果直接把我整懵逼了

bun 只能看系统那边监测

我也是 Nuxt 项目，请问一下您大概多久重启一次？大概您这边平均能漏多少

问题是测试环境和生产环境的运行时不同，出了故障怎么排除是运行时的问题还是代码问题呢，问题反而更复杂了

能不能分享一下你实测的 bun 哪比 node 快？快多少？

换 node

哪里漏的？ gc 有问题吗？

都 rust 写的了 怎么还能存泄漏(

#26 因为是 zig 写的（

我也遇到了，只能说比女主播还能漏，现在也是定时重启。

我这边是个访问量很小的项目，所以定时每天重启就够了。感觉泄露跟访问量成正比

自己的项目测了一下，node 编译需要 144s ，bun 143s ，访问速度没提升感觉，ssr 速度没提升感觉，果断还是使用 node

#23 没有详细实测过，但是 Nuxt 的话 Nodejs 访问渲染好并且缓存的页面是一百毫秒，Bun 只需要二三十

是的

你这不是问题更多了吗，无脑解决就是杀进程，或者换 deno

bun 是 zig 写的吧，deno 才是 rust 写的

每天看下有没有发布更新😊

java 没这么弱智吧

之前我做过一个 bun 的调研，它的快目前主要来源于功能简陋 (build) + 高性能模块 (uWebSocket)，而不是 zig 或者 jsc

我目前最常用 bun 的场景还是本地跑个小爬虫之类的，一是可以直接跑 ts ，二是 bun 的 file api 设计的还挺简洁方便，三是 node/npm 兼容做的比 deno 好

不过看到楼上说 node22 已经支持 native ts 了，感觉可以直接切到 node 去了

这是一个搞笑故事，兄弟可以去跑一个 hello world 试试，bun 确实比 node 和 deno 都要快，但是后来我找到一个论述，说是 jsc 的运行时优化比较少，所以它启动快

想想也不无道理 :)

https://www.builder.io/blog/bun-vs-node-js

一般出现这种情况, 更新到最新版本就好了…

太逆天了，我就是这么做的。。。然后发现最新的已经修了好几个内存泄露的漏洞

也有可能你的代码有问题。

针对Node.js中的Bun内存泄漏问题，除了优化代码和重启服务器外，还可以采取以下措施：

  1. 增加内存限制：

    Node.js的内存限制可以通过设置--max-old-space-size环境变量来增加。例如，将内存限制设置为8GB，可以运行以下命令：

    node --max-old-space-size=8192 your-app.js

    如果通过npm运行，可以在package.json中设置：

    "scripts": {
  "start": "node --max-old-space-size=8192 your-app.js"
}

  2. 使用内存分析工具：

    利用Heapdump、Memwatch等Node.js内存分析工具，定期检测和分析内存使用情况，帮助定位内存泄漏问题。

  3. 优化资源管理：

    确保及时释放不再使用的资源，如数据库连接、文件句柄等。使用close()或destroy()等方法主动释放资源。

  4. 避免全局变量：

    全局变量在Node.js中容易导致内存泄漏，建议使用局部变量或模块作用域来限制变量的生命周期。

  5. 代码审查和测试：

    定期进行代码审查和测试，检查是否存在可能导致内存泄漏的代码，以及确认是否正确释放了不再需要的资源。

通过上述措施，可以有效应对Node.js中的Bun内存泄漏问题，提高应用程序的稳定性和性能。

回到顶部