近日,有开发者提交了一个 VSCode 内存泄露的 issues,该问题导致在某些情况下使用 VSCode 会使内存使用率攀升。令人意外的是,VSCode 官方却表示不打算解决此问题,由此在社区引发了争议。

今年十月,有一名开发者发现了 VSCode 中存在内存泄漏的问题,并在官方仓库的 issues 中提交了这个问题:

1. 准备一个大文本文件(Citylots.json为〜190MB):

wget "https://github.com/zemirco/sf-city-lots-json/blob/master/citylots.json" cp citylots.json evenlarger.json cat citylots.json >> evenlarger.json cat citylots.json >> evenlarger.json

3. 滚动。

4. 关闭文件。

5. 通过“ Process Explorer”观察内存使用情况。

6. 即使大约 30 分钟后,内存使用率仍然很高:

即使禁用所有扩展后依然会发生此问题。

随后,这名开发者又注意到这个内存泄漏的 BUG 实际上与大文件无关,他通过打开几个 5-10MB 的文本文件重现了这一问题,即使关闭所有编辑器并等待几分钟后,也无需进行任何操作即可看到内存使用率攀升。该开发者表示,自己遇到这个问题时唯一的解决办法是一旦发现系统内存不足,就只能重新加载 VSCode 窗口,非常麻烦。

而令人意想不到的是,VSCode 官方对此问题的回应竟然是置之不理:

我们已关闭此问题,因为我们不打算在可预见的将来解决此问题。您可以在此处找到有关我们决策过程的更多详细信息。如果您不同意并认为此问题至关重要:我们很乐意倾听并重新考虑。

VSCode 官方的回复很快引发了争议,在这名开发者提交的 issue 下,有很多用户跟帖表示自己遇到了同样的问题,还有的甚至在一年前就遇到了类似的问题,并认为官方这样的做法对社区用户来说是不负责任的表现。

时隔近两个月,导致这一问题的 VSCode 维护者才终于修复了这一问题:

“ 首先,很抱歉出现了这一错误,我们已经添加了修复程序。以下是有关错误和修复的详细信息:

我们有基于文件的推荐功能(FileBasedRecommendations),将可监听文本模型添加到了编辑器中,并根据文件扩展名和语言推荐扩展名。最近,我对此功能进行了改进,以在用户更改文件的语言时提供检查建议(更多详细信息,在此处#102823)。为此,我需要设置监听器监听文本模型的语言更改,我原本仅在处置FileBasedRecommendations类时才调用此监听器,而导致内存泄漏的原因正是因为在处置完模型后监听器仍在工作。

我们通过在处置模型FileBasedRecommendations(onWillDispose)时处置模型监听器的 has 来解决此问题。”

issues 详情:https://github.com/microsoft/vscode/issues/107999

本文转自OSCHINA。

本文标题:VSCode 现内存泄漏 BUG,官方处理方式引社区不满

本文地址:https://www.oschina.net/news/121783/vscode-memory-leakage-issues