虚拟内存和物理内存之间有什么区别？
Answers:
除其他事项外，虚拟内存是一种抽象，使程序员可以在系统上拥有无限的可用内存。
虚拟内存映射对应于实际的物理地址。该操作系统创建和这些映射的交易-利用其他的数据结构中的页表，以保持映射。虚拟内存映射始终在页表或某些类似的数据结构中找到（对于其他虚拟内存实现，我们可能不应该将其称为“页表”）。页表也位于物理内存中-通常位于用户程序无法覆盖的内核保留空间中。
虚拟内存通常比物理内存大-如果虚拟内存和物理内存大小相同，则没有太多理由进行虚拟内存映射。
通常，只有程序的所需部分驻留在内存中-这是一个称为“分页”的主题。虚拟内存和分页紧密相关，但不是同一主题。虚拟内存还有其他实现，例如分段。
在这里我可能会认为是错误的，但是我敢打赌，您发现难以解决的问题与虚拟内存的特定实现有关，最有可能是分页。没有一种分页的方法-有很多实现，而您的教科书描述的实现可能与出现在像Linux / Windows这样的真实操作系统中的实现不同-可能存在细微的差异。
我可以大写一千篇关于分页的文章...但是我认为最好留给另一个专门针对该主题的问题。
软件在操作系统上运行的前提非常简单-它们需要内存。设备操作系统以RAM的形式提供它。所需的内存量可能会有所不同-有些软件需要巨大的内存，有些需要微不足道的内存。大多数（如果不是全部）用户同时在OS上运行多个应用程序，并且鉴于内存昂贵（并且设备大小有限），因此可用内存的数量始终受到限制。因此，鉴于所有软件都需要一定数量的RAM，并且所有软件都可以同时运行，因此OS必须注意两件事：
- 该软件始终运行，直到用户中止它为止；即，由于操作系统内存不足，它不应自动中止。
- 上述活动，同时为运行的软件保持了可观的性能。
现在，主要问题归结为如何管理内存。属于给定软件的数据驻留在存储器中的确切位置是什么？
可能的解决方案1：让各个软件明确指定它们将在设备中使用的内存地址。假设Photoshop声明它将始终使用从
0到的内存地址1023（将内存想象成字节的线性数组，因此第一个字节位于location0，1024第一个字节位于location1023）-即占用1 GB内存。同样，VLC宣布它将占用内存范围1244来1876，等
优点：
- 每个应用程序都预先分配了一个内存插槽，因此在安装和执行该应用程序时，它只是将其数据存储在该内存区域中，并且一切正常。
缺点：
这不会扩展。从理论上讲，应用程序在执行某些真正的繁重任务时可能需要大量内存。因此，为确保它永远不会用完内存，分配给它的内存区域必须始终大于或等于该内存量。如果将最大理论内存使用量为
2 GB（因此需要2 GB从RAM分配内存）的软件安装在只有1 GB内存的计算机中，该怎么办？软件应该在启动时中止，说可用RAM小于2 GB吗？还是应该继续下去，并且当所需的内存超过时2 GB，只是通过消息可用内存不足而中止并退出运行？无法防止内存损坏。那里有数百万种软件，即使每个软件仅分配了
1 kB内存，所需的总内存也将超过16 GB，这比大多数设备提供的内存还多。那么，如何为不同的软件分配不侵占彼此区域的内存插槽？首先，没有集中的软件市场可以调节，即当发布新软件时，它必须从这个尚未占用的区域分配大量内存，其次，即使有，也无法执行，因为没有。软件的数量实际上是无限的（因此需要无限的内存来容纳所有软件），任何设备上可用的总RAM不足以容纳所需数量的一小部分，因此不可避免地侵犯了一个软件的内存范围在另一个。因此，当发生了什么的Photoshop分配内存的位置1，以1023和VLC被分配1000到1676？如果Photoshop在location处存储一些数据1008，然后VLC用其自己的数据覆盖该数据，然后再用Photoshop认为它与先前存储在同一数据中有关？可以想象，坏事将会发生。
如您所见，很明显，这个想法很幼稚。
可能的解决方案2：让我们尝试另一种方案-OS将执行大部分内存管理。只要需要任何内存，软件就只会请求操作系统，并且操作系统会相应地适应。假设操作系统确保新进程请求内存时，它将从可能的最低字节地址分配内存（如前所述，RAM可以想象成字节的线性数组，因此对于
4 GBRAM来说，RAM的地址范围从字节0到2^32-1）（如果进程正在启动），否则，如果它是正在运行的进程正在请求内存，它将从该进程仍驻留的最后一个内存位置进行分配。由于软件将在不考虑数据存储位置的实际内存地址的情况下发出地址，因此OS必须针对每个软件维护软件所发出的地址到实际物理地址的映射（注意：这就是我们称之为“概念”的两个原因之一：Virtual Memory软件不在乎存储数据的实际内存地址，它们只是随手吐出地址，而操作系统会找到合适的位置并找到它如果需要，请稍后）。
假设设备刚刚打开，操作系统刚刚启动，现在没有其他进程在运行（忽略操作系统，这也是一个进程！），然后您决定启动VLC。因此，从最低字节地址为VLC分配了RAM的一部分。好。现在，当视频运行时，您需要启动浏览器以查看某些网页。然后，您需要启动记事本来涂鸦一些文本。然后Eclipse进行一些编码。.很快您的内存4 GB全部用完，RAM看起来像这样：
问题1：现在您无法启动任何其他进程，因为所有RAM已用完。因此，必须在编写程序时牢记最大可用内存（实际上，可用内存更少，因为其他软件也将并行运行！）。换句话说，您无法在摇摇欲坠的
1 GBPC上运行高内存消耗的应用程序。
好的，现在您决定不再需要保持Eclipse和Chrome打开状态，而关闭它们以释放一些内存。这些进程在RAM中占用的空间已由OS回收，现在看起来像这样：
假设关闭这两个将释放700 MB空间-（400+ 300）MB。现在，您需要启动Opera，它将占用450 MB空间。好吧，您450 MB总共确实有比可用空间更多的空间，但是...它不是连续的，而是分成单独的块，没有一个块足以容纳450 MB。因此，您想到了一个绝妙的主意，让我们将下面的所有过程都移到尽可能多的上面，这将700 MB在底部的空白处留出空白。这就是所谓的compaction。很好，除了...所有正在运行的进程。移动它们将意味着移动所有内容的地址（请记住，OS维护了软件将内存溢出的内存映射到实际内存地址。想象一下软件吐出的地址为45data 123，而OS已将其存储在位置2012并在地图上创建了一个条目，映射45到2012。如果现在将软件移动到内存中，以前位于该位置的软件2012将不再位于2012，而是位于一个新位置，并且OS必须相应地更新地图以映射45到该软件。新地址，以便该软件123在查询内存位置时可以获得预期的数据（）就45软件而言，它所知道的只是该地址45包含数据123！）！想象一个过程正在引用一个局部变量i。到再次访问它时，其地址已更改，并且将无法再找到它。所有的函数，对象，变量都一样，基本上所有的东西都有一个地址，而移动一个进程将意味着改变所有它们的地址。这导致我们：
问题2：您无法移动进程。该过程中所有变量，函数和对象的值都有硬编码值，编译器会在编译过程中吐出这些值，该过程取决于它们在生命周期中是否位于同一位置，并且更改它们非常昂贵。结果，进程退出
holes时会留下大的“ ”。这称为External Fragmentation。
精细。假设您以某种神奇的方式设法设法使流程向上移动。现在700 MB底部有可用空间：
Opera顺利地位于底部。现在您的RAM如下所示：
好。一切都很好。但是，剩余空间不多，现在您需要再次启动Chrome，这是众所周知的内存消耗！它需要大量的内存来启动，而且几乎没有剩余的空间了……除了..您现在注意到，一些最初占用较大空间的进程现在不需要太多空间。可能是因为您已经停止了VLC中的视频，因此它仍在占用一些空间，但没有达到运行高分辨率视频时所需的空间。对于记事本和照片也是如此。您的RAM现在看起来像这样：
Holes， 再来一次！回到原点！除了以前，孔是由于过程终止而产生的，而现在是由于过程所需的空间比以前要小！同样，您遇到了同样的问题，holes合并产生的空间超过了所需的空间，但是它们分散了，没有太多单独使用的空间。因此，您必须再次移动这些过程，这是一项昂贵的操作，并且非常频繁地这样做，因为在整个生命周期中，这些过程的大小都会经常减小。
问题3：进程在其生命周期内可能会缩小尺寸，留下未使用的空间，如果需要使用这些空间，将需要昂贵的操作来移动许多进程。这称为
Internal Fragmentation。
很好，所以现在，您的操作系统可以执行所需的操作，移动进程并启动Chrome，一段时间后，您的RAM如下所示：
凉。现在，假设您再次恢复在VLC中观看Avatar。它的内存需求将激增！但是...没有足够的空间来增长它，因为记事本位于其底部。因此，同样，所有进程都必须移到下面，直到VLC找到足够的空间！
问题4：如果流程需要增长，那将是一个非常昂贵的操作
精细。现在假定，照片被用于从外部硬盘加载一些照片。访问硬盘会将您从高速缓存和RAM领域带到磁盘领域，这要慢几个数量级。痛苦地，不可挽回地，超然地变慢了。这是一个I / O操作，这意味着它不受CPU限制（相反），这意味着它现在不需要占用RAM。但是，它仍然顽固地占用RAM。如果您要同时启动Firefox，则不能这样做，因为可用内存不足，而如果在I / O绑定活动期间将照片从内存中取出来，它将释放很多内存，其次是（昂贵的）压缩，然后再安装Firefox。
问题5：I / O绑定的作业继续占用RAM，导致RAM利用率不足，而CPU绑定的作业可能同时使用了RAM。
因此，正如我们所看到的，即使使用虚拟内存的方法也存在很多问题。
解决这些问题有两种方法- paging和segmentation。让我们讨论一下paging。在这种方法中，进程的虚拟地址空间以块（称为）的形式映射到物理内存pages。典型page尺寸为4 kB。映射由称为a的东西维护page table，给定一个虚拟地址，现在我们要做的就是找出page该地址属于哪个地址，然后从中page table找到该地址page在实际物理内存中的对应位置（称为frame），并给定该偏移虚拟地址内page是相同的page还有frame，通过增加抵消由返回的地址找到实际地址page table。例如：
左侧是进程的虚拟地址空间。假设虚拟地址空间需要40个内存单元。如果物理地址空间（在右侧）也具有40个内存单元，那么就可以将所有位置从左侧映射到右侧的位置，我们将非常高兴。但是，如果运气不好，不仅物理内存中的可用内存单元更少（此处为24个），而且还必须在多个进程之间共享！好吧，让我们看看我们如何做到这一点。
当该过程开始时，说出了对位置的内存访问请求35。这里的页面大小是8（每个page包含8位置，位置的整个虚拟地址空间40因此包含5页面）。因此，此位置属于页面编号。4（35/8）。在此范围内page，此位置的偏移量为3（35%8）。因此，可以通过元组(pageIndex, offset)= 指定此位置(4,3)。这仅仅是开始，因此该过程的任何部分都没有存储在实际的物理内存中。因此page table，，它维护着左侧页面到右侧实际页面（在此称为页面）之间的映射。frames）当前为空。因此，OS放弃了CPU，让设备驱动程序访问磁盘并获取页面编号。4为此过程（基本上是磁盘上程序的内存块，其地址范围从32至39）。到达后，OS将页面分配到RAM中的某个位置，例如第一帧本身，并且在page table此过程中请注意页面4映射到0RAM中的帧。现在数据终于在物理内存中了。OS再次在页表中查询元组(4,3)，这一次，页表说该页4已经映射到0RAM中的框架。因此，OS只需转到0RAM中的第th帧，以该帧中偏移的位置访问数据3（花点时间了解这一点。整个page从磁盘获取的，已移至frame。因此，无论页面中单个存储位置的偏移量是多少，框架中的偏移量也将相同，因为在page/中frame，存储单元仍相对位于同一位置！），并返回数据！因为在第一次查询本身时未在内存中找到数据，而是不得不从磁盘中提取数据以将其加载到内存中，所以构成了未命中。
精细。现在假设对位置28进行了内存访问。归结为(3,4)。Page table现在只有一个条目，页面映射4到frame 0。因此这又是一个遗漏，进程放弃了CPU，设备驱动程序从磁盘获取了页面，进程再次获得了对CPU的控制，并对其page table进行了更新。现在说页面3已映射到1RAM中的框架。因此(3,4)变为(1,4)，并且返回RAM中该位置的数据。好。这样，假设下一个内存访问是针对location的8，它转换为(1,0)。页面1尚未在内存中，重复相同的过程，并将其page分配到帧2在RAM中。现在，RAM进程映射如上图所示。此时，只有24个可用存储单元的RAM已填满。假设此过程的下一个内存访问请求来自address 30。它映射到(3,6)并page table说该页面3在RAM中，并且映射到frame 1。好极了！因此，数据是从RAM位置获取的(1,6)，并返回了。这构成了一个打击，因为可以直接从RAM中获取所需的数据，因此非常快。同样，未来几年的访问请求，说的地点11，32，26，27都是命中，即通过工艺要求的数据被直接发现在RAM中，而无需到别处。
现在，假设有一个用于位置的内存访问请求3。它将转换为(0,3)，并且page table对于该过程，当前有3个条目，用于页面1，3并4表示该页面不在内存中。与以前的情况一样，它是从磁盘中获取的，但是，与以前的情况不同，RAM已填满！那么现在该怎么办？虚拟内存之美就在于此，RAM中的一个帧被逐出！（各种因素决定着要逐出哪个帧。它可能LRU基于，某个过程中最近访问最少的那个帧将被逐出。它可能是first-come-first-evicted最长时间分配的那个帧被逐出的基础，等等。 。）因此驱逐了某些帧。说出第1帧（只是随机选择）。但是，这frame映射到一些page！（当前，它由页面表映射到3我们唯一的一个进程的页面）。因此，必须将此过程告知这个悲惨的消息，frame不幸的是，一个属于您的人将被逐出RAM，以便为另一个人腾出空间pages。该过程必须确保page table使用此信息更新它，即删除该页面框架二重奏的条目，以便下一次对此请求进行请求时page，它会正确地告诉该过程该信息page不再存储在内存中，并且必须从磁盘中获取。好。因此1，逐出框架，将页面0放入并放置在RAM中，并3删除页面的条目，并替换为0映射到同一框架的页面1。所以现在我们的映射看起来像这样（注意frame右边第二个中的颜色变化）：
看到发生了什么事？进程必须增长，它需要比可用RAM更多的空间，但是与我们之前的方案不同，RAM中的每个进程都必须移动以适应不断增长的进程，这里发生的事情只有一个page替换！这是因为以下事实：进程的内存不再需要是连续的，它可以驻留在块中的不同位置，OS维护有关其位置的信息，并在需要时对其进行适当查询。注意：您可能会想，呵呵，如果在大多数情况下它是miss，并且必须将数据从磁盘不断地加载到内存中该怎么办？是的，理论上是可能的，但是大多数编译器的设计方式如下locality of reference，即，如果使用了来自某个内存位置的数据，则所需的下一个数据将位于非常接近的某个位置，也许是刚加载到内存中page的page那个位置。结果，下一个未命中将在相当长的一段时间后发生，大多数即将到来的内存需求将由刚引入的页面或最近已使用的内存中的页面满足。完全相同的原理也使我们也可以逐出最近最少使用page的逻辑，即一段时间内未使用的逻辑也不太可能同时使用。但是，情况并非总是如此，在特殊情况下，是的，性能可能会受到影响。稍后会更多。
问题4的解决方案：流程现在可以轻松增长，如果遇到空间问题，它所要做的就是进行简单的
page替换，而无需移动任何其他流程。
问题1的解决方案：进程可以访问无限的内存。如果需要的内存大于可用内存，则将磁盘用作备份，将所需的新数据从磁盘加载到内存中，并将最近最少使用的数据
frame（或page）移至磁盘。这可以无限进行，并且由于磁盘空间便宜且实际上是无限的，因此给人一种无限内存的错觉。使用此名称的另一个原因是Virtual Memory，它给您错觉，使您无法真正记忆！
凉。早些时候，我们遇到了一个问题，即使一个进程的大小减小了，空白空间也很难被其他进程回收（因为这将需要昂贵的压缩）。现在很容易，当一个进程变得更小时，它的许多pages不再使用，因此，当其他进程需要更多的内存时，基于简单LRU的驱逐将自动pages从RAM中移出那些较少使用的进程，并将其替换为其他进程（当然page tables还要更新所有这些进程以及现在需要较少空间的原始进程），所有这些都无需任何昂贵的压缩操作！
问题3的解决方案：每当进程大小减小时，其
framesRAM中的RAM就会减少使用，因此基于简单LRU的驱逐可以逐出这些页面，并用pages新进程所需的页面替换它们，从而避免了Internal Fragmentation不必要的操作compaction。
对于问题2，花一点时间来了解这一点，方案本身就被完全删除了！无需移动一个流程来容纳一个新流程，因为现在整个流程不再需要一次适应，只需frames从RAM中逐出就可以适应其中的某些特定页面。一切都以的单位发生pages，因此没有hole现在的概念，因此也没有任何动静的问题！pages由于这项新要求，可能不得不搬家10个，其中有数千个pages没有改动。以前，所有流程（每个流程）都必须移动！
问题2的解决方案：为了适应新流程，必须根据需要逐出其他流程中仅较新使用的部分中的数据，而这种情况以称为的固定大小单位发生
pages。因此，没有hole或没有External Fragmentation这种系统的可能性。
现在，当进程需要执行一些I / O操作时，它可以轻松地放弃CPU！OS只是pages从RAM中驱逐所有内存（也许将其存储在某个缓存中），与此同时，新进程会占用RAM。完成I / O操作后，OS会将它们还原pages到RAM中（当然pages，可以通过从其他进程中替换来代替，可能是从替换原始进程的过程中，也可能是从自身需要执行I / O的过程中恢复）。哦，现在可以放弃记忆了！）
问题5的解决方案：当一个进程在执行I / O操作时，它可以轻松地放弃RAM的使用，而其他进程可以利用它。这导致RAM的正确利用。
当然，现在没有任何进程可以直接访问RAM。每个进程都在访问虚拟内存位置，该位置映射到物理RAM地址并由该page-table进程的维护。映射是由操作系统支持的，操作系统让进程知道哪个框架是空的，以便可以在那里安装进程的新页面。由于此内存分配是由OS本身监督的，因此可以通过仅分配RAM中的空帧，或者通过侵入RAM中的另一个进程的内容，与该进程通信，轻松地确保没有进程侵犯另一个进程的内容。更新它page-table。
原始问题的解决方案：由于整个分配是由OS本身管理的，并且每个进程都在其自己的沙盒虚拟地址空间中运行，因此不可能访问另一个进程的内容。
因此paging（除其他技术外），结合虚拟内存，是当今在OS-es上运行的软件的强大动力！这使软件开发人员不必担心用户设备上的可用内存，存储数据的位置，如何防止其他进程破坏其软件数据等，但是，这当然不是完全可靠的。有缺陷：
Paging最终，通过使用磁盘作为辅助备份，给用户一种无限内存的错觉。从辅助存储中检索数据以适合内存（称为page swap，在RAM中找不到所需页面的事件称为page fault）是昂贵的，因为它是IO操作。这会减慢该过程。连续发生几次这样的页面交换，并且过程变得非常缓慢。曾经见过您的软件运行良好且花哨，突然间它变得如此缓慢以至于几乎挂起，还是让您别无选择地重启它？可能发生了太多的页面交换，使其变慢（称为thrashing）。
所以回到OP，
为什么我们需要虚拟内存来执行进程？-正如答案详细解释的那样，给软件一种具有无限内存的设备/操作系统的错觉，从而可以运行任何大小的软件，而不必担心内存分配或其他进程破坏其数据，即使当并行运行。这是一个概念，实际上是通过各种技术实现的，如此处所述，其中之一就是分页。也可能是Segmentation。
当来自外部硬盘驱动器的进程（程序）被带到主存储器（物理存储器）执行时，该虚拟存储器位于何处？-虚拟内存本身并不存在，它是一种抽象，总是存在的，当启动软件/进程/程序时，会为其创建一个新的页表，并且它包含从该地址吐出的地址的映射处理到RAM中的实际物理地址。由于该过程吐出的地址不是真实地址，因此从某种意义上说，它们实际上是您可以说的the virtual memory。
谁负责虚拟内存，虚拟内存的大小是多少？-它由操作系统和软件共同处理。想象一下您的代码中的一个函数（该函数最终被编译并制成生成该过程的可执行文件），其中包含一个局部变量-an int i。代码执行时，i获取函数堆栈内的内存地址。该函数本身作为对象存储在其他地方。这些地址是编译器生成的（将代码编译为可执行文件的编译器）-虚拟地址。执行时，i至少必须在该功能的有效期间内驻留在实际物理地址中的某个位置（除非它是静态变量！），因此OS会映射编译器生成的虚拟地址i转换为实际的物理地址，以便每当在该函数中某些代码需要的值时i，该进程就可以向操作系统查询该虚拟地址，而操作系统又可以向物理地址查询所存储的值，然后将其返回。
假设RAM的大小为4GB（即2 ^ 32-1地址空间），虚拟内存的大小是多少？-RAM的大小与虚拟内存的大小无关，它取决于操作系统。例如，在32位Windows 16 TB上，它是256 TB。当然，它也受磁盘大小的限制，因为这是备份内存的地方。
参见此处： 物理与虚拟内存
虚拟内存存储在硬盘驱动器上，并在RAM已满时使用。物理内存受限于计算机中安装的RAM芯片的大小。虚拟内存受硬盘驱动器大小的限制，因此虚拟内存具有更多存储的功能。