Debugging visual studio在调试时是否显示虚拟地址或物理地址？

在visual studio中使用内存窗口时，我们看到的是该进程的虚拟地址还是RAM的物理地址？

用户级代码总是看到虚拟地址。它无法知道当前哪个物理地址（如果有的话！）对应于这些地址之一。“虚拟”是它生活的唯一世界，也是它唯一知道的世界。对于程序的所有意图和目的，“虚拟就是现实。”

澄清：所有操作系统（MS-DOS等除外…）都在虚拟内存空间中运行用户程序。每个程序对“位置

$12345678

包含的内容”都有自己的看法，而且每个程序的看法对它来说都是正确的。每个程序都可以有不同的编号，并且可以根据自己的喜好进行更改

他们之所以能够做到这一点，是因为没有人真正知道：

• 其中，在物理内存中，“它们的位置

  $12345678

  ”实际驻留。（如果它是……很可能不是！）
• 物理地址中有什么

  $12345678

操作系统使用物理RAM和（如有必要）页面文件和/或交换文件空间的组合为每个进程维护虚拟内存。进程正在积极使用的信息在一个物理RAM位置“按需”提供给它，这个物理RAM位置对进程来说既不知道也不知道。最近未使用过的信息最终会从物理RAM中“窃取”并移动到外部存储。。。直到它再次被引用，触发所谓的“页面错误”

---

调试器提供给您的内存视图是被调试程序感知并对其正确的内存视图：进程虚拟内存中的虚拟地址。

我已在相关链接中共享了该映像。你能不能看一下并详细说明一下？进程的虚拟地址空间有没有最大限制？当我们在linux上使用top命令时，它显示进程的物理内存和虚拟内存。（不断变化）。进程的虚拟内存如何变化应用程序认为它有一个特定大小的（虚拟）内存区域可用。它无法检测尝试访问任何特定位置是否会导致页面错误。它只能通过系统调用从操作系统请求此信息来预先确定其（虚拟）内存分配的大小。之所以从

top

命令中看到不断变化的值，是因为它可以看到操作系统虚拟内存子系统的活动。它可以看到当前在支持任何进程方面花费了多少物理资源：当前的物理RAM占用空间和每个进程使用的交换/页面空间。它可以看到进程希望有多少RAM（其所谓的“工作集大小”），以及它实际得到多少RAM。它可以看到等待的时间。进程争夺物理RAM资源。身体状况不断变化。。。每微秒。