为什么 WSL2 里 /mnt/c 下的文件操作慢？

因为从 WSL2 的 Linux 内核访问 Windows 一侧的文件系统，要经过跨越操作系统边界的文件共享。对 Linux 文件系统（ext4 虚拟磁盘）的操作很快，因此原则是把项目文件放在操作它们的工具同一操作系统一侧。

vmmem 进程内存用量很大是泄漏吗？

多数情况下不是泄漏。WSL2 内存随使用增减，进程已释放的内存在默认启用的 pageReporting 设置下会还给 Windows。文件缓存页也由现行 WSL 经 .wslconfig 的 autoMemoryReclaim（默认是 dropCache）自动回收。在这些设置被关闭的环境，或较旧的 WSL 上，内存可能一直留到虚拟机退出；那种情况下用 memory 设置上限，或用 wsl --shutdown 归还。

Windows Sandbox 怎么能用几百兆磁盘启动完整的 Windows？

通过称为动态基础映像的机制。它共享主机上已安装 Windows 的不可变操作系统文件，只为少量可变文件保留干净副本。这样就能在不保存完整 Windows 副本的情况下组装出可启动的完整映像。

容器比虚拟机更安全吗？

取决于隔离模式。进程隔离容器与主机共享内核，Microsoft 不把它视为坚固的安全边界。处理敌对代码时，需要 Hyper-V 隔离，让每个容器拥有专用内核。

Windows 虚拟化的深层(第3回) ── 数秒启动的虚拟机：WSL2、Windows Sandbox 与容器为何这么轻

2026年08月22日 04:00 · Go Komura · Windows, 虚拟化, WSL2, Windows Sandbox, 容器, Hyper-V

在 Hyper-V 管理器里创建 Windows 虚拟机，启动要几十秒，并独占数 GB 内存。可是同一台 PC 上，输入 wsl 几秒内就返回 Linux 外壳，Windows Sandbox 也在几秒内打开一次性桌面。¹

两者都建立在同一套 Windows 虚拟机监控程序上（第1回，「你的 Windows 实际在哪里运行？」）。第2回我们看到，这一基础可以创建比内核更强的隔离。那么为什么一边重、一边轻？

系列最终回要回答的问题只有一个。

完整虚拟机很重——那 WSL2 和 Windows Sandbox 为什么这么轻？

目标读者是把 WSL2、Windows Sandbox 和 Windows 容器用于开发和验证、希望从机制上理解其轻与约束的开发者和运维人员。前提环境是 Windows 10/11；走完 Windows Sandbox 一节需要 Pro、Enterprise 或 Education 版本（Home 和 Windows Server 没有这一功能）。背景知识是第1回的分区概念。难度为中级。

1. 先说结论

轻量虚拟机保住隔离线（专用内核和虚拟机监控程序边界），并减轻「完整客户机操作系统的副本」。Sandbox 共享主机的 Windows 本身；WSL2 把客户机换成小而专用的 Linux；两者的内存都不是固定预留，而是与主机动态借贷。

完整虚拟机重量的来源不是隔离本身，而是复制。磁盘上再多一份操作系统映像，RAM 上再多一份操作系统的页，每次启动再来一次完整引导。轻量虚拟机用两条方针削减复制：「可以安全共享的就共享」（Sandbox）和「不能共享就做小重做」（WSL2）。

flowchart TB
    accTitle: 支撑轻量虚拟机的三种共享
    accDescr: 完整虚拟机曾经复制的操作系统映像，由 Sandbox 的共享和 WSL2 的缩小来削减；默认固定分配的内存（动态内存是例外）变成与主机的动态借贷；启动被轻内核和最小设置替换；只留下隔离边界
    heavy["完整虚拟机：复制"] --> d1["磁盘：操作系统映像副本"]
    heavy --> more{"内存还是启动？"}
    more --> d2["内存：默认固定"]
    more --> d3["启动：完整引导"]
    d1 -->|替换为| s1["共享（Sandbox）"]
    s1 -.-> s1b["或缩小（WSL2）"]
    d2 -->|替换为| s2["与主机动态借贷"]
    d3 -->|替换为| s3["轻内核 + 最小设置"]

图 1: 「同一虚拟机监控程序，却轻」的答案骨架是：他们停下了复制，而不是停下了隔离。

下面按 WSL2、Windows Sandbox、容器的顺序，看各自削减了哪一种复制。

2. 完整虚拟机在扛什么

作为比较基线，传统虚拟机扛着这些。

独立的操作系统映像。它在虚拟磁盘里持有客户机操作系统的每一个文件。即便主机有同一份 Windows，也不共享。
粗粒度的内存分配。传统虚拟机的默认是按静态大小分配主机内存。Hyper-V 动态内存等机制可以在配置范围内增减分配，但按需求变化调整的手段有限。²
通用完整引导。固件、引导加载程序和服务集合按与物理机相同的顺序启动。

flowchart TB
    accTitle: 完整虚拟机扛着的三项负荷
    accDescr: 完整虚拟机扛着独立的操作系统映像、默认静态的内存分配，以及通用完整引导，这些在磁盘、RAM 和启动时间上表现为成本
    fullvm["完整虚拟机"] --> b1["独立的操作系统映像"]
    fullvm --> more{"内存还是引导？"}
    more --> b2["默认静态内存"]
    more --> b3["通用引导"]
    b1 -.-> c1["副本多占磁盘"]
    b2 -.-> c2["也占着未用的 RAM"]
    b3 -.-> c3["要几十秒"]

图 2: 完整虚拟机成本的拆解，付的不是隔离，而是通用性和复制。

这些不是缺陷；它们是「客户机里可以放任何东西」这一通用性的代价。对在 Windows Server 旁边跑旧 Linux 这类用途，那一通用性就是价值。但对「我想立刻、为开发或验证跑与主机相同（或预定）的操作系统」这类用途，其中大部分是多余行李。轻量虚拟机通过收窄用途把行李放下。

3. WSL2 ── 带专用内核的实用虚拟机

3.1. 结构：被管理的虚拟机与其中的发行版

WSL2 是在轻量实用虚拟机里运行真正 Linux 内核的机制。³ 有三点。

内核是真的，但是特化产品。它是 Microsoft 从 Stable 分支构建的 Linux 内核，已为 WSL2 在大小和性能上调过。在当前标准的、经 Microsoft Store 分发的 WSL 上，内核随 WSL 包本身更新，并用 wsl --update 应用（较旧的收件箱分发则经 Windows Update）。⁴ 因为是真正的内核，系统调用兼容性完整，Docker 等工具可以原样运行。
虚拟机在背后。创建、启动、停止虚拟机由 WSL 管理；用户只是打开外壳。没有虚拟机设置画面，也没有可感知的启动等待。⁴
发行版是虚拟机里的容器。Ubuntu、Debian 等发行版作为隔离容器运行在一台被管理的虚拟机里。它们共享网络命名空间和内核，而 PID、挂载、用户等命名空间被分开。³

flowchart TB
    accTitle: WSL2 架构
    accDescr: 主机 Windows 与轻量实用虚拟机并排坐在虚拟机监控程序上；Microsoft 构建的 Linux 内核在虚拟机里运行；各发行版作为隔离容器运行在其中
    hv["虚拟机监控程序"] --> host["主机 Windows"]
    hv --> uvm["轻量实用虚拟机"]
    uvm --> lk["Linux 内核（Microsoft 构建；随 wsl --update 更新）"]
    lk --> u1["Ubuntu（容器）"]
    lk --> u2["Debian（容器）"]
    host <-->|"互操作（命令、文件、网络）"| uvm

图 3: 「WSL2 是虚拟机吗？」的答案是「是，但是被管理的、在背后的虚拟机」，即便安装多个发行版也仍是一台虚拟机。

输入 wsl 的那一刻，背后是这样的。

flowchart TB
    accTitle: 从运行 wsl 命令到几秒内返回外壳
    accDescr: 若执行 wsl 时实用虚拟机未运行，则启动轻量虚拟机和 Linux 内核；若已在运行则复用；外壳在发行版的容器中返回
    cmd["运行 wsl"] --> vmq{"实用虚拟机已在运行吗？"}
    vmq -->|否| bootvm["启动轻量虚拟机和 Linux 内核（几秒）"]
    vmq -->|是| reuse["复用已在运行的虚拟机"]
    bootvm --> shell["外壳在容器内返回"]
    reuse --> shell

图 4: 等待只是最小的虚拟机启动，放下完整引导行李的效果就出现在这里。

3.2. 文件 I/O：放在哪一侧会变成另一回事

谈 WSL2 性能时总会出现的话题，是文件放在哪里。

对 Linux 一侧文件（ext4 虚拟磁盘） 的操作很快。因为 Linux 内核直接与自己的文件系统对话，相对 WSL1，tarball 解压最高 20 倍、git clone 和 npm install 2–5 倍的加速已被报告。⁴
对 Windows 一侧文件（/mnt/c 等） 的操作变慢，因为要经过跨越操作系统边界的文件共享。跨操作系统文件系统性能是 WSL2 比 WSL1 差的一项主要项。⁴

因此原则是：「把项目文件放在操作它们的工具同一操作系统一侧」。⁴ 用 Linux 构建工具处理的仓库放 Linux 一侧；在 Visual Studio 里构建的解决方案放 Windows 一侧。

flowchart TB
    accTitle: WSL2 文件 I/O 路径的分叉
    accDescr: 对 Linux 一侧 ext4 虚拟磁盘的访问从 Linux 内核直接进行因此快；对 Windows 一侧文件的访问经过跨越操作系统边界的文件共享因此慢
    io["WSL2 内的文件操作"] --> place{"文件在哪一侧？"}
    place -->|"Linux 一侧（home 等）"| ext4["对 ext4 虚拟磁盘的直接 I/O"]
    place -->|"Windows 一侧（/mnt/c 等）"| p9["经跨越操作系统边界的共享"]
    ext4 --> fast["快（相对 WSL1 最高 20 倍的例子）"]
    p9 --> slow["往往较慢"]
    slow -.-> fix["修正：把文件放在使用它的操作系统上"]

图 5: 慢的是路径，不是 WSL2，因此改放文件位置常常让性能问题消失。

3.3. 内存：会增会减，但不总是全部还回去

WSL2 的内存用量（在任务管理器里看成 vmmem 进程）不是固定预留；它随使用增减。进程已释放的内存在默认启用的 pageReporting 设置下自动还给 Windows。⁵ 作为文件缓存持有的页，过去要到虚拟机退出才还给 Windows。⁴ 在现行 WSL 中，实验性 .wslconfig 设置 autoMemoryReclaim（默认是 dropCache）也会自动回收缓存。⁵ 在该设置为 disabled 的环境，或较旧的 WSL 上，长会话的缓存可能一直留到虚拟机退出，并挤压主机内存。

flowchart TB
    accTitle: WSL2 内存如何增减与归还
    accDescr: WSL2 内部需求增长会提高虚拟机内存用量；进程释放的页在默认启用的 pageReporting 下还给 Windows；文件缓存默认由 autoMemoryReclaim 自动回收；但在关闭设置或较旧 WSL 上会留到虚拟机退出，wsl --shutdown 归还全部
    grow["WSL2 内部内存需求增长"] --> vm["vmmem 用量增长"]
    vm --> freed{"那一页已被释放吗？"}
    freed -->|"进程已释放（pageReporting 开时）"| ret["自动还给 Windows"]
    freed -->|作为文件缓存持有| amr["autoMemoryReclaim 自动回收（默认）"]
    amr -.-> old2["关闭设置或较旧 WSL 上，留到虚拟机退出"]
    old2 --> sd["wsl --shutdown 归还全部"]

图 6: 看起来「只会涨」的，主要是缓存（以及 pageReporting 关闭时进程释放的页），所以先知道归还路径，再断定是泄漏。

若想要明确上限，%UserProfile%\.wslconfig 可以控制虚拟机的总体内存、CPU 数和交换。⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

改设置后，用 wsl --shutdown 重启虚拟机才会生效。这种「上限是设置，实际用量跟需求走」的动态分配，在下一个话题 Windows Sandbox 里走得更远。

4. Windows Sandbox ── 复用主机的 Windows

4.1. 动态基础映像：500 MB 里的完整 Windows

Windows Sandbox 是由虚拟机监控程序隔离的一次性 Windows 桌面。关掉它，一切消失；下一次，从干净状态在几秒内启动。¹

第一个谜是磁盘。它能启动完整的 Windows，可 Sandbox 的基础映像安装后大约只有 500 MB，分发时压缩约 30 MB。² 秘密是动态基础映像。

大多数操作系统文件不可变，因此可以原样共享主机的副本。
少量可变文件不能共享，因此在基础映像里为它们保留干净副本。
启动时，主机的不可变文件加上可变文件的本地副本被组合，组装出完整的 Windows 映像。²

也就是说，Sandbox 既不下载也不保存 Windows 的副本；它复用主机上已安装的 Windows 来启动。

flowchart TB
    accTitle: 动态基础映像如何组装
    accDescr: 主机 Windows 的不可变操作系统文件被共享；只有可变文件作为干净副本放在基础映像里；两者组合组装出 Sandbox 的完整 Windows 映像
    hostw["主机的完整 Windows"] --> imm["不可变操作系统文件（多数）"]
    hostw --> mut["可变操作系统文件（少数）"]
    imm -->|原样共享| img["Sandbox 启动映像"]
    mut -->|保留干净副本| img
    img --> boot["作为完整 Windows 启动"]
    img -.-> size["只需保存约 500 MB"]

图 7: 放弃磁盘复制的形态不是「再拥有一份 Windows」，而是「从主机的 Windows 组装出来」。

那一组合使下面的生命周期成为可能。被丢弃的是 Sandbox 内部的本地状态。若你在 .wsb 配置文件中从主机映射了可写文件夹，那里的更改会留在主机上。⁶

flowchart TB
    accTitle: Windows Sandbox 的生命周期
    accDescr: 启动在几秒内准备好干净的 Windows；应用验证或实验后关掉，Sandbox 内部全部状态被丢弃，下一次也从干净启动；但对映射为可写的主机文件夹的更改会留下
    launch["启动（几秒）"] --> clean["干净的 Windows"]
    clean --> work["应用验证或实验"]
    work --> close2["关闭"]
    close2 --> discard["丢弃 Sandbox 内部全部状态"]
    discard -.-> mapped["映射可写文件夹中的更改留在主机上"]
    discard -->|下一次启动| launch

图 8: 每次都能回到干净，是因为可变部分是一次性副本，丢弃它是设计的一部分。

4.2. 直接映射：同一份 ntdll.dll 是同一物理页

不仅磁盘，RAM 也被共享。因为 Sandbox 运行与主机相同的操作系统映像，使用称为「直接映射」的技术，让操作系统二进制使用与主机相同的物理内存页。当 ntdll.dll 在 Sandbox 内加载进内存时，它指向主机上已加载的同一二进制的同一物理页。在不把主机的秘密暴露给危险的前提下，它实现比传统虚拟机小得多的内存占用。²

「在多个用户之间共享同一物理页」——那和内存系列第3回（「节对象与写时复制」）追过的、经节对象的 DLL 共享是同一想法。那一机制是进程之间的共享；Sandbox 跨虚拟机边界做这件事。

flowchart TB
    accTitle: 经直接映射的物理页共享
    accDescr: 主机上的应用和 Sandbox 内的应用对 ntdll 等操作系统二进制共享同一物理内存页，从而减少内存用量
    happ["主机上的应用"] --> hva["主机侧虚拟地址"]
    sapp["Sandbox 内的应用"] --> sva["Sandbox 侧虚拟地址"]
    hva --> phys["同一物理页（ntdll.dll 等操作系统二进制）"]
    sva --> phys
    phys -.-> save["不必复制一整份操作系统的 RAM"]

图 9: 直接映射是进程之间一直在用的页共享想法，应用到虚拟机边界之外。

4.3. 借贷内存：更像进程而不是虚拟机

相对传统虚拟机的静态内存分配，Sandbox 所坐的容器技术与主机协作动态决定资源分配。若主机内存短缺，它可以像从普通进程回收那样从容器回收内存。² Hyper-V 动态内存也会在配置范围内增减虚拟机分配，但 Sandbox 走得更远：差别在于它在与主机内存管理同一场地上借贷。

flowchart TB
    accTitle: 主机与 Sandbox 之间的内存协作
    accDescr: 传统虚拟机的默认是静态大小的独占分配，调整手段有限；Sandbox 响应主机内存压力成为回收目标，并在与普通进程同一场地上借贷内存
    pressure["主机内存压力上升"] --> from{"从哪里回收？"}
    from --> proc["普通进程的工作集"]
    from --> sbx["Sandbox（容器）的用量"]
    proc --> relief["空闲内存被确保"]
    sbx --> relief
    relief -.-> contrast["传统虚拟机的调整手段有限"]

图 10: 在内存借贷上，Sandbox 站在进程一侧而不是虚拟机一侧，主机有困难时献出内存。

第1回我们说过「虚拟机的性能也取决于主机一侧」，但轻量虚拟机再进一步：内存分配本身就是与主机的共同工作。Sandbox 能以「另一个应用」而不是「沉重的虚拟化产品」的感觉被使用，原因就是这一协作。

用 Sandbox 验证业务应用的具体步骤，见较早的「用 Windows Sandbox 加快应用验证的方法」。本文是其下的机制。

5. 容器 ── 隔离线画在哪里

5.1. 进程隔离与 Hyper-V 隔离

Windows 容器在运行时有两种隔离模式。映像共享；启动时用标志选择。⁷

进程隔离：多个容器与主机共享内核，通过对文件系统、注册表、网络端口、进程 ID 空间、对象管理器命名空间等按命名空间虚拟化来隔离。本质上与 Linux 容器同一做法。
Hyper-V 隔离：每个容器运行在高度优化的虚拟机里，拥有实际上的专用内核。虚拟机的存在在容器与主机之间放入硬件级隔离。⁷

经命名空间的隔离，可以描述成注册表虚拟化文章（「Windows 上的注册表重定向与虚拟化」）里见过的技术——「在同一 API 下展示不同现实」——的彻底版本。

flowchart TB
    accTitle: 进程隔离与 Hyper-V 隔离
    accDescr: 进程隔离下，容器与主机共享内核并经命名空间隔离；Hyper-V 隔离下，每个容器在优化的虚拟机里拥有专用内核
    subgraph pi ["进程隔离"]
        c1["容器 A"] --> sk1["与主机共享的内核"]
        c2["容器 B"] --> sk1
    end
    subgraph hi ["Hyper-V 隔离"]
        c3["容器 C"] --> k3["专用内核（优化虚拟机内）"]
        c4["容器 D"] --> k4["专用内核（优化虚拟机内）"]
    end
    sk1 ~~~ c3

图 11: 即便是同一容器映像，是把隔离线画在内核之上，还是拆开内核本身，是启动时做的选择。

5.2. 哪一种可以称为「安全边界」

这两种模式的差别不只是性能故事。Microsoft 不把进程隔离容器视为坚固的安全边界。作为安全边界维护（含漏洞响应）的容器是虚拟机监控程序隔离的容器，在敌对多租户场景中应选择 Hyper-V 隔离。⁸

第2回见过的 VBS 也是按「内核可能被突破」来设计、退到虚拟机监控程序边界的。同一标准适用于容器世界。圈住不受信任代码的线，画在虚拟机监控程序边界，而不是共享内核的内侧。

flowchart TB
    accTitle: 按对代码的信任程度选择隔离
    accDescr: 若工作负载可信，用进程隔离换密度和性能；若代码不受信任或是别人的，选择虚拟机监控程序边界，例如 Hyper-V 隔离容器、禁用网络的加固 Windows Sandbox，或隔离虚拟机
    trust{"能信任那段代码吗？"} -->|能| dens["进程隔离（优先密度和速度）"]
    trust -->|不能 / 别人的代码| bound["选择虚拟机监控程序边界"]
    bound --> opt1["Hyper-V 隔离容器"]
    bound --> opt2["加固的 Sandbox 或隔离虚拟机"]

图 12: 隔离模式首先是安全故事，然后才是性能故事，信任决定线画在哪里。

顺便说，在 Hyper-V 虚拟机里运行 Hyper-V 隔离容器，会让虚拟机监控程序叠两层——嵌套虚拟化。一层嵌套在满足条件的环境上受生产支持（带 Windows 10 / Windows Server 2016 或更新主机的 Intel 处理器，或带 Windows 11 / Windows Server 2022 或更新主机的 AMD 处理器，以及各自对应的虚拟机配置版本），进一步的前提是向外侧虚拟机公开虚拟化扩展的设置（Hyper-V 中 Set-VMProcessor 上的 ExposeVirtualizationExtensions）。在虚拟机里运行 WSL2 同样受支持。⁹ 能否在云上的开发虚拟机里使用 WSL2 或 Docker，也由该虚拟机大小和配置是否公开嵌套虚拟化决定。

flowchart TB
    accTitle: 嵌套虚拟化的结构
    accDescr: 云虚拟机坐在物理主机的虚拟机监控程序上，其中再跑一层虚拟机监控程序（受支持的嵌套是一层）以支持 WSL2 和 Hyper-V 隔离容器
    phys3["物理主机的虚拟机监控程序"] --> cvm["云虚拟机（开发机）"]
    cvm --> nhv["虚拟机内的虚拟机监控程序（嵌套 1 层）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V 隔离容器"]
    nhv -.-> limit["受支持的嵌套是一层"]

图 13: 云虚拟机里 wsl 能跑的原因，是嵌套虚拟化只对一层得到正式支持。

5.3. 隔离与轻的谱系

把至此的角色排在一条轴上，是这样的。

flowchart TB
    accTitle: 隔离强度与轻的谱系
    accDescr: 进程隔离容器最轻但共享内核；WSL2、Sandbox 和 Hyper-V 隔离容器是带专用内核的轻量虚拟机（Sandbox 靠共享变轻，WSL2 靠专用内核）；完整虚拟机最重但通用
    ax["轻 ← → 重"] ~~~ p1
    p1["进程隔离容器（共享内核）"] --> p2["WSL2、Sandbox、Hyper-V 隔离（带专用内核的轻量虚拟机）"]
    p2 --> p3["完整虚拟机（什么都能跑；持有完整副本）"]
    p1 -.-> n1["边界：命名空间"]
    p2 -.-> n2["边界：虚拟机监控程序"]
    p3 -.-> n3["边界：虚拟机监控程序 + 完全独立"]

图 14: 轻量虚拟机一组是保住虚拟机监控程序边界并削减复制的中间解；削减方式分成 Sandbox 的共享和 WSL2 的专用内核。

6. 自己看一看

轻和共享，可以在眼前的机器上观察到。

启动时间与内存的涨落（WSL2）。打开任务管理器，试下面这些。

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

若在 WSL2 里做大型构建或文件操作，vmmem 会涨，并且可以观察到用 wsl --shutdown 一次性归还。

文件放置带来的速度差（WSL2）。把同一仓库放在 Linux 一侧（~/repo）和 Windows 一侧（/mnt/c/repo），比较 git status 或解压的时间，第 3.2 节的差别就会变成数字。

直接映射的背景（Sandbox）。启动 Sandbox，看主机任务管理器里内存的增量。增量远小于「再来一份 Windows」会让人想象的，就是共享在讲故事。要进一步挖主机侧内存拆解，讲 RAMMap 和 VMMap 用法的 Sysinternals 工具文章（「Process Explorer / Handle / VMMap 实战」）有用。不过这些是看主机侧进程和物理内存分类的工具；它们并不直接观察与客户机的共享本身。

容器隔离模式（Docker / Windows 容器）。若有 Windows 容器环境，用 docker run --isolation=process 和 --isolation=hyperv 启动同一映像，比较启动时间和任务管理器里的样子（进程隔离下，容器内进程出现在主机的进程列表中），就能感觉隔离线坐在哪里。⁷ 不过进程隔离的前提是主机与映像版本匹配，在客户端操作系统上限于开发测试用途。Hyper-V 隔离允许更宽的组合，因此在兼容的一对上做比较。¹⁰

7. 实务中要避免的三种误读

7.1. 「WSL2 很慢」

慢的不是 WSL2，而是跨越操作系统边界的文件 I/O 路径。很多情况下，只是把项目移到 Linux 一侧，体感就变成另一回事。⁴ 反过来，把 Windows 工具会碰的文件放在 Linux 一侧，同样因同一原因不利。按「放在使用它的那一侧同一操作系统上」判断。

7.2. 「vmmem 变大就是内存泄漏」

WSL2 内存随需求增减，已释放部分会被归还。在现行 WSL 上，文件缓存也由 autoMemoryReclaim（默认是 dropCache）自动回收，因此「一直很大」往往随时间解消。⁵ 若仍留下，确认 autoMemoryReclaim 没有被设为 disabled，以及负责归还已释放部分的 pageReporting 没有被关掉（或你不是在较旧的 WSL 上），然后要么用 .wslconfig 的 memory 明确上限，要么在会话边界用 wsl --shutdown 全部归还。区分泄漏与非泄漏的思路，与内存系列入门篇「Windows的「内存使用量」究竟表示什么」相同。

7.3. 「放进容器就安全」

进程隔离容器共享内核，按 Microsoft 的标准它不是安全边界。⁸ 运行不受信任的代码或样本时，选择带虚拟机监控程序边界的隔离，例如 Hyper-V 隔离容器、Windows Sandbox 或专用虚拟机。不过虚拟机监控程序边界不是一揽子豁免。Windows Sandbox 的默认设置启用了网络连接，可能把不受信任的应用暴露给内部网络。¹ 若用它跑样本，在 .wsb 配置文件中禁用网络和剪贴板重定向以加强隔离，或使用隔离网络上的专用虚拟机。

8. 小结 ── 收束系列

第3回的要点。

轻量虚拟机的轻，是「停下复制」的结果，不是「削弱隔离」的结果。
WSL2 在被管理的轻量实用虚拟机里运行真正的 Linux 内核，发行版作为该虚拟机内的容器被隔离。³ 性能原则是把文件放在使用它的操作系统上，内存动态增减，上限可在 .wslconfig 中控制。⁴⁵
Windows Sandbox 经动态基础映像共享主机的不可变操作系统文件，并经直接映射共享目标操作系统二进制的物理页，因此不持有完整 Windows 的副本。² 可变文件仍需要约 500 MB，加上里面运行的应用自身的内存。
容器隔离模式在启动时选择，可以称为安全边界的一侧是 Hyper-V 隔离。⁷⁸

若把整个系列放在一页上，是这样的。

第1回：Windows 下面有虚拟机监控程序层，主机操作系统自身作为根分区运行。CPU 和内存（SLAT）的仲裁由这一层直接做，合成设备的 I/O 由 VMBus 另一端的根分区（VSP）调解。
第2回：那一层不仅用来隔离虚拟机彼此，也用来在同一操作系统内部画比内核更强的边界（VTL）。Windows 11 的默认安全建立在这之上。
第3回：在同一层上，削减复制使「数秒启动的虚拟机」成为可能。隔离线被保住，它成了日常工具。

flowchart TB
    accTitle: 整个系列的一张图
    accDescr: 直接在硬件上的虚拟机监控程序是第1回；主机 Windows 内部 VTL0 与 VTL1 的分裂是第2回；同一层上 WSL2、Sandbox 与 Hyper-V 隔离的轻是第3回；进程隔离容器共享主机内核；Sandbox 靠共享变轻，WSL2 靠专用内核
    hw3["硬件"] --> hv3["虚拟机监控程序（第1回）"]
    hv3 --> rp3["主机 Windows（VTL 隔离是第2回）"]
    hv3 --> lw3["WSL2、Sandbox、Hyper-V 隔离（第3回）"]
    rp3 --> pc3["进程隔离容器（共享内核）"]
    lw3 -.-> mech3["Sandbox 共享；WSL2 用专用内核变轻"]

图 15: 把三回叠起来，就是现行 Windows 脚下的全貌。

虚拟化不再是机房技术，也不再只是搭虚拟机的人的技术。在你的 Windows 脚下，它安静地同时支撑安全性和开发体验——那就是我们现在的位置。

参考链接

Microsoft Learn, Windows Sandbox. 关于 Windows Sandbox 作为一次性虚拟机在几秒内启动，关闭时丢弃一切；用 Microsoft 虚拟机监控程序运行单独内核以与主机隔离；以及网络连接默认启用，可在配置文件中禁用。 ↩ ↩² ↩³
Microsoft Learn, Windows Sandbox architecture. 关于动态基础映像从主机不可变操作系统文件的共享加上可变文件的干净副本组装完整 Windows 映像（安装后约 500 MB）；相对传统虚拟机的静态内存分配，容器与主机协作动态分配，使主机可以回收内存；以及直接映射让 ntdll.dll 等操作系统二进制使用与主机相同的物理页。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, What is the Windows Subsystem for Linux?. 关于 WSL2 在轻量实用虚拟机里运行 Linux 内核；各发行版作为隔离容器运行，共享网络命名空间和内核，同时分开 PID、挂载、用户等命名空间。 ↩ ↩² ↩³
Microsoft Learn, Comparing WSL Versions. 关于 WSL2 内核由 Microsoft 从 Stable 分支构建；Store 分发的 WSL 作为与操作系统映像分离的包接收更新并用 wsl --update 应用（较旧的收件箱分发经 Windows Update）；tarball 解压最高 20 倍等性能例子；跨操作系统文件系统性能上 WSL1 更快，因此文件应放在使用它的操作系统上；以及内存增减、已释放部分被归还，而缓存可能要到虚拟机退出才归还。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Advanced settings configuration in WSL. 关于可以在 .wslconfig 的 [wsl2] 节设置 WSL2 虚拟机的总体内存上限、处理器数、交换和 pageReporting（默认启用；负责检测并归还未使用内存）；以及实验性设置 autoMemoryReclaim 默认为 dropCache，从而自动回收缓存内存。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Use and configure Windows Sandbox. 关于 .wsb 配置文件中的 MappedFolders 可以把主机文件夹以只读或可写方式共享。 ↩
Microsoft Learn, Isolation Modes. 关于 Windows 容器的进程隔离与主机共享内核并经命名空间隔离；Hyper-V 隔离在优化的虚拟机里拥有实际上的专用内核；以及同一映像可以通过启动时的标志以任一模式运行。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Secure Windows containers. 关于只有虚拟机监控程序隔离的容器被当作安全边界；进程隔离容器不被视为坚固的安全边界；以及在敌对多租户场景中应选择虚拟机监控程序隔离。 ↩ ↩² ↩³
Microsoft Learn, What is Nested Virtualization?. 关于在 Hyper-V 虚拟机内运行 Hyper-V 隔离容器（一层嵌套）受生产支持；要求是带 Windows Server 2016 / Windows 10 或更新的 Intel 处理器，或带 Windows Server 2022 / Windows 11 或更新的 AMD 处理器，以及各自对应的虚拟机配置版本；向外侧虚拟机公开虚拟化扩展（ExposeVirtualizationExtensions）是前提；以及在 Hyper-V 虚拟机内运行 WSL2 受支持。 ↩
Microsoft Learn, Windows container version compatibility. 关于进程隔离的前提是主机与容器映像版本匹配；Hyper-V 隔离可以运行与主机不同操作系统版本的映像；以及客户端操作系统上的进程隔离限于开发测试用途。 ↩

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

Windows 应用程序开发

支持包含常驻处理、设备联动、运行日志与可维护结构的 Windows 桌面应用程序。

查看服务联系我们

常见问题

汇总了咨询这一主题时常见的问题。

WSL2 是虚拟机吗？: 是。WSL2 在轻量实用虚拟机里运行 Microsoft 从 Stable 分支构建的真正 Linux 内核。虚拟机由 WSL 在背后管理，因此设计从不让用户去想虚拟机设置或等待启动。每个 Linux 发行版作为隔离容器运行在这台被管理的虚拟机里。
为什么 WSL2 里 /mnt/c 下的文件操作慢？: 因为从 WSL2 的 Linux 内核访问 Windows 一侧的文件系统，要经过跨越操作系统边界的文件共享。对 Linux 文件系统（ext4 虚拟磁盘）的操作很快，因此原则是把项目文件放在操作它们的工具同一操作系统一侧。
vmmem 进程内存用量很大是泄漏吗？: 多数情况下不是泄漏。WSL2 内存随使用增减，进程已释放的内存在默认启用的 pageReporting 设置下会还给 Windows。文件缓存页也由现行 WSL 经 .wslconfig 的 autoMemoryReclaim（默认是 dropCache）自动回收。在这些设置被关闭的环境，或较旧的 WSL 上，内存可能一直留到虚拟机退出；那种情况下用 memory 设置上限，或用 wsl --shutdown 归还。
Windows Sandbox 怎么能用几百兆磁盘启动完整的 Windows？: 通过称为动态基础映像的机制。它共享主机上已安装 Windows 的不可变操作系统文件，只为少量可变文件保留干净副本。这样就能在不保存完整 Windows 副本的情况下组装出可启动的完整映像。
容器比虚拟机更安全吗？: 取决于隔离模式。进程隔离容器与主机共享内核，Microsoft 不把它视为坚固的安全边界。处理敌对代码时，需要 Hyper-V 隔离，让每个容器拥有专用内核。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

查看简介联系我们

公开链接

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

返回博客列表