操作系统有虚拟内存与物理内存的概念。在很久以前，还没有虚拟内存概念的时候，程序寻址用的都是物理地址。程序能寻址的范围是有限的，这取决于CPU的地址线条数。比如在32位平台下，寻址的范围是2^32也就是4G。并且这是固定的，如果没有虚拟内存，且每次开启一个进程都给4G的物理内存，就可能会出现很多问题：

    因为我的物理内存时有限的，当有多个进程要执行的时候，都要给4G内存，很显然你内存小一点，这很快就分配完了，于是没有得到分配资源的进程就只能等待。当一个进程执行完了以后，再将等待的进程装入内存。这种频繁的装入内存的操作是很没效率的
	
    由于指令都是直接访问物理内存的，那么我这个进程就可以修改其他进程的数据，甚至会修改内核地址空间的数据，这是我们不想看到的
	
    因为内存时随机分配的，所以程序运行的地址也是不正确的。
于是针对上面会出现的各种问题，虚拟内存就出来了。

在之前一篇文章中进程分配资源介绍过一个进程运行时都会得到4G的虚拟内存。这个虚拟内存你可以认为，每个进程都认为自己拥有4G的空间，这只是每个进程认为的，但是实际上，在虚拟内存对应的物理内存上，可能只对应的一点点的物理内存，实际用了多少内存，就会对应多少物理内存。

进程得到的这4G虚拟内存是一个连续的地址空间（这也只是进程认为），而实际上，它通常是被分隔成多个物理内存碎片，还有一部分存储在外部磁盘存储器上，在需要时进行数据交换。

进程开始要访问一个地址，它可能会经历下面的过程

    每次我要访问地址空间上的某一个地址，都需要把地址翻译为实际物理内存地址
	
    所有进程共享这整一块物理内存，每个进程只把自己目前需要的虚拟地址空间映射到物理内存上
	
    进程需要知道哪些地址空间上的数据在物理内存上，哪些不在（可能这部分存储在磁盘上），还有在物理内存上的哪里，这就需要通过页表来记录
	
    页表的每一个表项分两部分，第一部分记录此页是否在物理内存上，第二部分记录物理内存页的地址（如果在的话）
	
    当进程访问某个虚拟地址的时候，就会先去看页表，如果发现对应的数据不在物理内存上，就会发生缺页异常
	
    缺页异常的处理过程，操作系统立即阻塞该进程，并将硬盘里对应的页换入内存，然后使该进程就绪，如果内存已经满了，没有空地方了，那就找一个页覆盖，至于具体覆盖的哪个页，就需要看操作系统的页面置换算法是怎么设计的了。
 

关于虚拟内存与物理内存的联系，下面这张图可以帮助我们巩固。



页表的工作原理如下图



    我们的cpu想访问虚拟地址所在的虚拟页(VP3)，根据页表，找出页表中第三条的值.判断有效位。 如果有效位为1，DRMA缓存命中，根据物理页号，找到物理页当中的内容，返回。

    若有效位为0，参数缺页异常，调用内核缺页异常处理程序。内核通过页面置换算法选择一个页面作为被覆盖的页面，将该页的内容刷新到磁盘空间当中。然后把VP3映射的磁盘文件缓存到该物理页上面。然后页表中第三条，有效位变成1，第二部分存储上了可以对应物理内存页的地址的内容。

    缺页异常处理完毕后，返回中断前的指令，重新执行，此时缓存命中，执行1。

    将找到的内容映射到告诉缓存当中，CPU从告诉缓存中获取该值，结束。

 

再来总结一下虚拟内存是怎么工作的

当每个进程创建的时候，内核会为进程分配4G的虚拟内存，当进程还没有开始运行时，这只是一个内存布局。实际上并不立即就把虚拟内存对应位置的程序数据和代码（比如.text .data段）拷贝到物理内存中，只是建立好虚拟内存和磁盘文件之间的映射就好（叫做存储器映射）。这个时候数据和代码还是在磁盘上的。当运行到对应的程序时，进程去寻找页表，发现页表中地址没有存放在物理内存上，而是在磁盘上，于是发生缺页异常，于是将磁盘上的数据拷贝到物理内存中。

另外在进程运行过程中，要通过malloc来动态分配内存时，也只是分配了虚拟内存，即为这块虚拟内存对应的页表项做相应设置，当进程真正访问到此数据时，才引发缺页异常。

可以认为虚拟空间都被映射到了磁盘空间中（事实上也是按需要映射到磁盘空间上，通过mmap，mmap是用来建立虚拟空间和磁盘空间的映射关系的）

 

利用虚拟内存机制的优点

    既然每个进程的内存空间都是一致而且固定的（32位平台下都是4G），所以链接器在链接可执行文件时，可以设定内存地址，而不用去管这些数据最终实际内存地址，这交给内核来完成映射关系

    当不同的进程使用同一段代码时，比如库文件的代码，在物理内存中可以只存储一份这样的代码，不同进程只要将自己的虚拟内存映射过去就好了，这样可以节省物理内存

    在程序需要分配连续空间的时候，只需要在虚拟内存分配连续空间，而不需要物理内存时连续的，实际上，往往物理内存都是断断续续的内存碎片。这样就可以有效地利用我们的物理内存

————————————————

版权声明：本文为CSDN博主「TLpigff」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/lvyibin890/article/details/82217193

   《程序员的自我修养》第一章14页对这部分讲的就很清楚，建议有需要的去看一下，我这里简单做下总结和笔记：

   引用一句大佬的话：

   “计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”

   那么直接用物理地址出现了什么问题？而怎加了虚拟地址这个中间件为什么可以解决它们？
问题引出：
   没有有效的内存管理机制时，直接使用物理地址有以下三个问题：

   1. 地址空间不隔离：

   物理地址是连续的，直接使用物理地址，所有程序使用的内存在一个空间内，当一个程序内存溢出，很容易影响其他程序的正常运行，导致其他程序崩溃。

   2.内存使用效率低：

   假设计算机有129M内存，已经有两个程序在运行，程序A需要10M，程序B需要100M，当程序C需要20M，执行时，调入内存，由于程序需要的空间是连续的，所以直接换出A可能释放空间不够，只能换出B，过程中有大量数据在内存和磁盘间交互，效率并不高。

   3.程序运行地址不确定：

   程序编写时，很多时候访问数据和指令跳转的目标地址是固定的，而直接使用物理地址，不能保证每次装入都放在同一块区域，就给程序编写带来了一定的麻烦。
问题解决：
   针对问题1：

   虚拟地址保证每个进程都有自己独立的虚拟空间，而且进程空间只能访问自己的地址空间，这样就做到了进程隔离。

   针对问题3：

   以程序A为例，虚拟空间总是0到100M的连续空间，可以以分段的形式一对一的映射到物理空间上一段100M的空间内，这样即使每次分配的物理空间不固定，但程序看到的虚拟空间地址是固定的，大大方便了编程。

   针对问题2：

   解决效率的方法，是分页，我们把进程的虚拟空间按页分割，叫虚拟页，常用的装载到内存中，不常用的代码和数据保存到磁盘里，需要的时候再读入，相应的物理内存分页叫物理页，两者映射，可以大大增加内存的使用效率。
ps:CPU发出的和，程序看到的都是虚拟地址，需要一个叫MMU（在cpu内部）的部件做映射，转化成物理地址。

问题：请问在printf打印函数中一般用什么形式打印变量的内存地址？
 
解析：这个题目是C语言编程中应用十分普遍的一个基础知识。最常用的打印方式有%p和%x两种。代码如下：



#include<stdio.h>

int main()
{    
	int a;

	printf("%p\n",&a);
	printf("0x%X\n",&a);

	getchar();
}


上述代码的输出结果：
0057F84C
0x57F84C
总结：
1. %p和%x的区别：
%p：打印的地址上自动在地址前加入0x前缀；
%x：仅仅是用十六进制打印，并不会自动加0x。

突然想到Python的可变类型和不可变类型，在复习数据结构与算法时，用的C++，想看一下两种语言的变量地址有什么不同

在Python中，可以发现不可变类型，比如int类型，元组，当给变量赋值不同的值时，变量的地址会变化，这也说明这些变量在Python的管理器（也不知道叫啥，虚拟机？管理器？）中是缓存的。如下代码：

In [1]: a=1

In [2]: id(a)
Out[2]: 140706035789568

In [3]: a=2

In [4]: id(a)
Out[4]: 140706035789600

In [5]: type(a)
Out[5]: int

In [6]: b=(1,2)

In [7]: id(b)
Out[7]: 1932103472136

In [8]: b=(2,3)

In [9]: id(b)
Out[9]: 1932103502728

再补充一下，下图中a,b都为1，可以发现 a,b的地址一样，所以python中的不可变元素也是提前缓存的，和C/C++的指针地址比较就能悟出其中的道理。



在C/C++中，变量的值改变，地址并不改变，也使我更加理解了指针这个东西：

#include<iostream>
using namespace std;
int main(){
    int i=0;
    cout<<&i<<endl;
    i=2;
    cout<<&i<<endl;
}

输出以下结果：

[Running] cd "d:\WorkPlace\VCSWorkPlace\c_c++\" && g++ test.cpp -o test && "d:\WorkPlace\VCSWorkPlace\c_c++\"test
0x6dfefc
0x6dfefc