内存黑洞悄悄启动

6月11日, 科技类媒体发布文章进行曝光, 微软所拥有的Visual Studio Code编辑器, 在Windows 10以及Windows 11系统之上, 存在十分严重的内存占用方面的问题。只要用户于VS Code当中使用过微软的Copilot聊天功能, 或者智能体模式, 程序便会自动开启一个1.8GB的Hyper-V虚拟机。这个虚拟机进程, 于任务管理器里显示作Vmmem, 其CPU占用率是0%, 而内存占用却有着高达1.8GB的情况, 从而成为了完完全全不折不扣的内存黑洞。

用户反馈数月无果

依照相关页面所呈现的情况来看, 用户在今年2月就已然向微软递交了有关该问题的反馈, 不过直至如今仍旧未曾获取到任何修复。有用户于开发者社区里宣称, 自己历经多次尝试去联系微软技术支撑过程, 所得到的回复均是“已记录问题, 请等待后续更新”。这样一种漫长的等待致使许多用户心生失望之情, 部分用户已然选择径直卸载VS Code, 转而选用其他代码编辑器。此问题已经持续了四个月之久, 然而依旧没有得到解决。

正常聊天也不放过

更令用户感到头疼不已的是, 此问题所涉及的影响范围竟远远超出了预先的估计, 用户在后续阶段, 就算仅仅是开启极为普通的聊天模式, 然而在每次启动VS Code之后, 程序都会自动生成那个容量为1.8GB的Hyper-V虚拟机进程, 这意味着, 哪怕用户只期望借助Copilot询问一个非常简单的问题, 诸如“这个函数的参数是什么”, 系统也会悄然无声地为用户准备好1.8GB的内存占用, 众多的开发者纷纷倾诉道, 他们自身的电脑内存仅仅只有8GB或者16GB, 如此这般的消耗实在是让人难以承受。

用户期望的合理行为

有不少用户在反馈当中明确地指出, 那个Vmmem进程理应仅仅在用户进行显式调用Agent模式之后才启动, 并且在使用完毕之后自动清理会话文件。他们持有这样的观点, 聊天模式与智能体模式应当具备不一样的资源管理策略。聊天模式仅仅需要轻微量级的API调用, 全然不需要启动一整个完整的虚拟机。用户期望微软能够区分这两种使用场景, 防止出现不必要的资源浪费。当前这种不分情况一概而论的做法使得很多人觉得不满。

仅限桌面版的问题

要明确指出的是, 此问题对CLI（命令行界面）以及别的平台的使用不存在影响。在Linux系统或者macOS系统上运用VS Code的用户未曾碰到类似的状况。另外, 借助VS Code的远程开发功能连接至远程服务器的用户也不会被这个内存占用问题所干扰。这表明问题极有可能出在Windows版VS Code与Hyper – V虚拟机的集成机制里头, 需微软针对Windows平台开展专门的优化与修复。

呼吁微软尽快行动

当下, 遭受影响的用户数目仍在持续不断地增长, 然而微软那一方依旧未曾给出确切不移的修复时间安排表。开发者们发出呼吁, 期望微软能够以严肃认真的态度直面这个问题, 尽快推出更新去解决1.8GB的内存占用难题。与此同时, 用户也提议微软在资源管理方面做到更精细准确, 防止因为一个辅助功能致使整个编辑器的运行速度被拖慢。毕竟, VS Code本身是一款出色卓越的编辑器, 不应当因这般低级的问题而致使用户流失。

你于运用VS Code之际, 可曾碰到过相像的内存占用方面的问题? 欢迎于评论区域分享你的经历, 点赞并且转发, 使得更多人能够瞧见这个问题, 一同去督促微软赶快修复！