踏入C 中的雷区——C 内存管理详解
伟大的Bill Gates 曾经失言：
640K ought to be enough for everybody — Bill Gates 1981
程序员们经常编写内存管理程序，往往提心吊胆。如果不想触雷，唯一的解决办法就是发现所有潜伏的地雷并且排除它们，躲是躲不了的。本文的内容比一般教科书的要深入得多，读者需细心阅读，做到真正地通晓内存管理。
1、内存分配方式
内存分配方式有三种：
（1）从静态存储区域分配。内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static变量。
（2）在栈上创建。在执行函数时，函数内局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。
（3）从堆上分配，亦称动态内存分配。程序在运行的时候用malloc或new申请任意多少的内存，程序员自己负责在何时用free或delete释放内存。动态内存的生存期由我们决定，使用非常灵活，但问题也最多。
2、常见的内存错误及其对策
发生内存错误是件非常麻烦的事情。编译器不能自动发现这些错误，通常是在程序运行时才能捕捉到。而这些错误大多没有明显的症状，时隐时现，增加了改错的难度。有时用户怒气冲冲地把你找来，程序却没有发生任何问题，你一走，错误又发作了。常见的内存错误及其对策如下：
* 内存分配未成功，却使用了它。
编程新手常犯这种错误，因为他们没有意识到内存分配会不成功。常用解决办法是，在使用内存之前检查指针是否为NULL。如果指针p是函数的参数，那么在函数的入口处用assert(p!=NULL)进行
检查。如果是用malloc或new来申请内存，应该用if(p==NULL) 或if(p!=NULL)进行防错处理。
* 内存分配虽然成功，但是尚未初始化就引用它。
犯这种错误主要有两个起因：一是没有初始化的观念；二是误以为内存的缺省初值全为零，导致引用初值错误（例如数组）。内存的缺省初值究竟是什么并没有统一的标准，尽管有些时候为零值，我们宁可信其无不可信其有。所以无论用何种方式创建数组，都别忘了赋初值，即便是赋零值也不可省略，不要嫌麻烦。
* 内存分配成功并且已经初始化，但操作越过了内存的边界。
例如在使用数组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中，循环次数很容易搞错，导致数组操作越界。
* 忘记了释放内存，造成内存泄露。
含有这种错误的函数每被调用一次就丢失一块内存。刚开始时系统的内存充足，你看不到错误。终有一次程序突然死掉，系统出现提示：内存耗尽。
动态内存的申请与释放必须配对，程序中malloc与free的使用次数一定要相同，否则肯定有错误（new/delete同理）。
* 释放了内存却继续使用它。
有三种情况：
（1）程序中的对象调用关系过于复杂，实在难以搞清楚某个对象究竟是否已经释放了内存，此时应该重新设计数据结构，从根本上解决对象管理的混乱局面。
（2）函数的return语句写错了，注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁。
（3）使用free或delete释放了内存后，没有将指针设置为NULL。导致产生“野指针”。
【规则1】用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。
【规则2】不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。
【规则3】避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操
作。
【规则4】动态内存的申请与释放必须配对，防止内存泄漏。
【规则5】用free或delete释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。
3、指针与数组的对比
C /C程序中，指针和数组在不少地方可以相互替换着用，让人产生一种错觉，以为两者是等价的。
数组要么在静态存储区被创建（如全局数组），要么在栈上被创建。数组名对应着（而不是指向）一块内存，其地址与容量在生命期内保持不变，只有数组的内容可以改变。
指针可以随时指向任意类型的内存块，它的特征是“可变”，所以我们常用指针来操作动态内存。指针远比数组灵活，但也更危险。
下面以字符串为例比较指针与数组的特性。
3.1 修改内容
示例3-1中，字符数组a的容量是6个字符，其内容为hello。a的内容可以改变，如a[0]= ‘X’。指针p指向常量字符串“world”（位于静态存储区，内容为world），常量字符串的内容是不可以被修改的。从语法上看，编译器并不觉得语句p[0]= ‘X’有什么不妥，但是该语句企图修改常量字符串的内容而导致运行错误。
3.2 内容复制与比较
不能对数组名进行直接复制与比较。示例7-3-2中，若想把数组a的内容复制给数组b，不能用语句 b = a ，否则将产生编译错误。应该用标准库函数strcpy进行复制。同理，比较b和a的内容是否相同，不能用if(b==a) 来判断，应该用标准库函
数strcmp进行比较。
语句p = a 并不能把a的内容复制指针p，而是把a的地址赋给了p。要想复制a 的内容，可以先用库函数malloc为p申请一块容量为strlen(a) 1个字符的内存，再用strcpy进行字符串复制。同理，语句if(p==a) 比较的不是内容而是地址，应该用库函数strcmp来比较。
3.3 计算内存容量
用运算符sizeof可以计算出数组的容量（字节数）。示例7-3-3（a）中，sizeof(a)的值是12（注意别忘了’’）。指针p指向a，但是sizeof(p)的值却是4。这是因为sizeof(p)得到的是一个指针变量的字节数，相当于sizeof(char*)，而不是p所指的内存容量。C /C语言没有办法知道指针所指的内存容量，除非在申请内存时记住它。
注意当数组作为函数的参数进行传递时，该数组自动退化为同类型的指针。示例7-3-3（b）中，不论数组a的容量是多少，sizeof(a)始终等于sizeof(char *)。
示例3.3（b）数组退化为指针
4、指针参数是如何传递内存的？
如果函数的参数是一个指针，不要指望用该指针去申请动态内存。示例7-4-1中，Test函数的语句GetMemory(str, 200)并没有使str获得期望的内存，str依旧是NULL，为什么？
示例4.1 试图用指针参数申请动态内存
毛病出在函数GetMemory中。编译器总是要为函数的每个参数制作临时副本，指针参数p的副本是 _p，编译器使 _p = p。如果函数体内的程序修改了_p的内容，就导致参数p的内容作相应的修改。这就是指针可以用作输出参数的原因。在本例中，_p申请了新的内存，只是把_p所指的内存地址改变了，但是p丝毫未变。所以函数GetMemory并不能输出任何东西。事实上，每执行一次GetMemory就会泄露一块内存，因为没有用free释放内存。
如果非得要用指针参数去申请内存，那么应该改用“指向指针的指针”，见示例4.2。
示例4.2用指向指针的指针申请动态内存
由于“指向指针的指针”这个概念不容易理解，我们可以用函数返回值来传递动态内存。这种方法更加简单，见示例4.3。
示例4.3 用函数返回值来传递动态内存
用函数返回值来传递动态内存这种方法虽然好用，但是常常有人把return语句用错了。这里强调不要用return语句返回指向“栈内存”的指针，因为该内存在函数结束时自动消亡，见示例4.4。
示例4.4 return语句返回指向“栈内存”的指针
用调试器逐步跟踪Test4，发现执行str = GetString语句后str不再是NULL指针，但是str的内容不是“hello world”而是垃圾。
如果把示例4.4改写成示例4.5，会怎么样？
示例4.5 return语句返回常量字符串
函数Test5运行虽然不会出错，但是函数GetString2的设计概念却是错误的。因为GetString2内的“hello world”是常量字符串，位于静态存储区，它在程序生命期内恒定不变。无论什么时候调用GetString2，它返回的始终是同一个“只读”的内存块。
5、杜绝“野指针”
“野指针”不是NULL指针，是指向“垃圾”内存的指针。人们一般不会错用NULL 指针，因为用if语句很容易判断。但是“野指针”是很危险的，if语句对它不起作用。“野指针”的成因主要有两种：
（1）指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的缺省值是随机的，它会乱指一气。所以，指针变量在创建的同时应当被初始化，要么将指针设置为NULL，要么让它指向合法的内存。例如
（2）指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。
（3）指针操作超越了变量的作用范围。这种情况让人防不胜防，示例程序如下：
函数Test在执行语句p->Func()时，对象a已经消失，而p是指向a的，所以p就成了“野指针”。但奇怪的是我运行这个程序时居然没有出错，这可能与编译器有关。
6、有了malloc/free为什么还要new/delete？
malloc与free是C /C语言的标准库函数，new/delete是C 的运算符。它们都可用于申请动态内存和释放内存。
对于非内部数据类型的对象而言，光用maloc/free无法满足动态对象的要求。对象在创建的同时要自动执行构造函数，对象在消亡之前要自动执行析构函数。由于malloc/free是库函数而不是运算符，不在编译器控制权限之内，不能够把执行构造函数和析构函数的任务强加于malloc/free。
因此C 语言需要一个能完成动态内存分配和初始化工作的运算符new，以及一个能完成清理与释放内存工作的运算符delete。注意new/delete不是库函数。我们先看一看malloc/free和new/delete如何实现对象的动态内存管理，见示例6。
示例6 用malloc/free和new/delete如何实现对象的动态内存管理
类Obj的函数Initialize模拟了构造函数的功能，函数Destroy模拟了析构函数的功能。函数UseMallocFree中，由于malloc/free不能执行构造函数与析构函数，必须调用成员函数Initialize和Destroy来完成初始化与清除工作。函数UseNewDelete则简单得多。
所以我们不要企图用malloc/free来完成动态对象的内存管理，应该用
new/delete。由于内部数据类型的“对象”没有构造与析构的过程，对它们而言malloc/free和new/delete是等价的。
既然new/delete的功能完全覆盖了malloc/free，为什么C 不把malloc/free淘汰出局呢？这是因为C 程序经常要调用C函数，而C程序只能用malloc/free管理动态内存。
如果用free释放“new创建的动态对象”，那么该对象因无法执行析构函数而可能导致程序出错。如果用delete释放“malloc申请的动态内存”，理论上讲程序不会出错，但是该程序的可读性很差。所以new/delete必须配对使用，malloc/free 也一样。
7、内存耗尽怎么办？
如果在申请动态内存时找不到足够大的内存块，malloc和new将返回NULL指针，宣告内存申请失败。通常有三种方式处理“内存耗尽”问题。
（1）判断指针是否为NULL，如果是则马上用return语句终止本函数。例如：
（2）判断指针是否为NULL，如果是则马上用exit(1)终止整个程序的运行。例如：
（3）为new和malloc设置异常处理函数。例如Visual C 可以用_set_new_hander 函数为new设置用户自己定义的异常处理函数，也可以让malloc享用与new相同的异常处理函数。详细内容请参考C 使用手册。
上述（1）（2）方式使用最普遍。如果一个函数内有多处需要申请动态内存，那么方式（1）就显得力不从心（释放内存很麻烦），应该用方式（2）来处理。
很多人不忍心用exit(1)，问：“不编写出错处理程序，让操作系统自己解决行不行？”
不行。如果发生“内存耗尽”这样的事情，一般说来应用程序已经无药可救。如果不用exit(1) 把坏程序杀死，它可能会害死操作系统。道理如同：如果不把歹徒击毙，歹徒在老死之前会犯下更多的罪。
有一个很重要的现象要告诉大家。对于32位以上的应用程序而言，无论怎样使用malloc与new，几乎不可能导致“内存耗尽”。我在Windows 98下用Visual C 编
写了测试程序，见示例7。这个程序会无休止地运行下去，根本不会终止。因为32位操作系统支持“虚存”，内存用完了，自动用硬盘空间顶替。我只听到硬盘嘎吱嘎吱地响，Window 98已经累得对键盘、鼠标毫无反应。
我可以得出这么一个结论：对于32位以上的应用程序，“内存耗尽”错误处理程序毫无用处。这下可把Unix和Windows程序员们乐坏了：反正错误处理程序不起作用，我就不写了，省了很多麻烦。
我不想误导读者，必须强调：不加错误处理将导致程序的质量很差，千万不可因小失大。
示例7试图耗尽操作系统的内存
8、malloc/free 的使用要点
函数malloc的原型如下：
用malloc申请一块长度为length的整数类型的内存，程序如下：
我们应当把注意力集中在两个要素上：“类型转换”和“sizeof”。
* malloc返回值的类型是void *，所以在调用malloc时要显式地进行类型转换，将void * 转换成所需要的指针类型。
* malloc函数本身并不识别要申请的内存是什么类型，它只关心内存的总字节数。我们通常记不住int, float等数据类型的变量的确切字节数。例如int变量在16位系统下是2个字节，在32位下是4个字节；而float变量在16位系统下是4个字节，在32位下也是4个字节。最好用以下程序作一次测试：
在malloc的“()”中使用sizeof运算符是良好的风格，但要当心有时我们会昏了头，写出 p = malloc(sizeof(p))这样的程序来。
* 函数free的原型如下：
为什么free函数不象malloc函数那样复杂呢？这是因为指针p的类型以及它所指的内存的容量事先都是知道的，语句free(p)能正确地释放内存。如果p是NULL指针，那么free对p无论操作多少次都不会出问题。如果p不是NULL指针，那么free对p 连续操作两次就会导致程序运行错误。
9、new/delete 的使用要点
运算符new使用起来要比函数malloc简单得多，例如：
这是因为new内置了sizeof、类型转换和类型安全检查功能。对于非内部数据类型的对象而言，new在创建动态对象的同时完成了初始化工作。如果对象有多个构造函数，那么new的语句也可以有多种形式。例如
如果用new创建对象数组，那么只能使用对象的无参数构造函数。例如
不能写成
在用delete释放对象数组时，留意不要丢了符号‘[]’。例如
后者相当于delete objects[0]，漏掉了另外99个对象。
10、一些心得体会
我认识不少技术不错的C /C程序员，很少有人能拍拍胸脯说通晓指针与内存管理（包括我自己）。我最初学习C语言时特别怕指针，导致我开发第一个应用软件（约1万行C代码）时没有使用一个指针，全用数组来顶替指针，实在蠢笨得过分。躲避指针不是办法，后来我改写了这个软件，代码量缩小到原先的一半。
我的经验教训是：
（1）越是怕指针，就越要使用指针。不会正确使用指针，肯定算不上是合格的程序员。
（2）必须养成“使用调试器逐步跟踪程序”的习惯，只有这样才能发现问题的本质。
操作系统内存管理
操作系统内存管理 1. 内存管理方法 内存管理主要包括虚地址、地址变换、内存分配和回收、内存扩充、内存共享和保护等功能。 2. 连续分配存储管理方式 连续分配是指为一个用户程序分配连续的内存空间。连续分配有单一连续存储管理和分区式储管理两种方式。 2.1 单一连续存储管理 在这种管理方式中，内存被分为两个区域：系统区和用户区。应用程序装入到用户区，可使用用户区全部空间。其特点是，最简单，适用于单用户、单任务的操作系统。CP／M和 DOS 2．0以下就是采用此种方式。这种方式的最大优点就是易于管理。但也存在着一些问题和不足之处，例如对要求内
存空间少的程序，造成内存浪费；程序全部装入，使得很少使用的程序部分也占用—定数量的内存。 2.2 分区式存储管理 为了支持多道程序系统和分时系统，支持多个程序并发执行，引入了分区式存储管理。分区式存储管理是把内存分为一些大小相等或不等的分区，操作系统占用其中一个分区，其余的分区由应用程序使用，每个应用程序占用一个或几个分区。分区式存储管理虽然可以支持并发，但难以进行内存分区的共享。 分区式存储管理引人了两个新的问题：内碎片和外碎片。 内碎片是占用分区内未被利用的空间，外碎片是占用分区之间难以利用的空闲分区(通常是小空闲分区)。 为实现分区式存储管理，操作系统应维护的数据结构为分区表或分区链表。表中各表项一般包括每个分区的起始地址、大小及状态(是否已分配)。
分区式存储管理常采用的一项技术就是内存紧缩(compaction)。 2.2.1 固定分区(nxedpartitioning)。 固定式分区的特点是把内存划分为若干个固定大小的连续分区。分区大小可以相等：这种作法只适合于多个相同程序的并发执行(处理多个类型相同的对象)。分区大小也可以不等：有多个小分区、适量的中等分区以及少量的大分区。根据程序的大小，分配当前空闲的、适当大小的分区。 优点：易于实现，开销小。 缺点主要有两个：内碎片造成浪费；分区总数固定，限制了并发执行的程序数目。 2.2.2动态分区(dynamic partitioning)。 动态分区的特点是动态创建分区：在装入程序时按其初始要求分配，或在其执行过程中通过系统调用进行分配或改变分区大小。与固定分区相比较其优点是：没有内碎
4-4 linux内存管理子系统 4-4-1 linux内存管理（参考课件） 物理地址：cpu地址总线上寻址物理内存的地址信号，是地址变换的最终结果 逻辑地址：程序代码经过编译后，出现在汇编程序中的地址（程序设计时使用的地址） 线性地址：又名虚拟地址，32位cpu架构下4G地址空间 CPU要将一个逻辑地址转换为物理地址，需要两步： 1、首先CPU利用段式内存管理单元，将逻辑地址转换成线性地址； 2、再利用页式内存管理单元，把线性地址最终转换为物理地址 相关公式： 逻辑地址=段基地址+段内偏移量(段基地址寄存器+段偏移寄存器)（通用的） 16位CPU：逻辑地址=段基地址+段内偏移量(段基地址寄存器+段偏移寄存器) 线性地址=段寄存器的值×16+逻辑地址的偏移部分 物理地址=线性地址（没有页式管理） 32位CPU：逻辑地址=段基地址+段内偏移量(段基地址寄存器+段偏移寄存器) 线性地址=段寄存器的值+逻辑地址的偏移部分 物理地址<——>线性地址（mapping转换） ARM32位：逻辑地址=段基地址+段内偏移量(段基地址寄存器+段偏移寄存器) 逻辑地址=段内偏移量（段基地址为0） 线性地址=逻辑地址=段内偏移量（32位不用乘以32） 物理地址<——>线性地址（mapping转换） ************************!!以下都是x86模式下!!********************************* 一、段式管理 1.1、16位CPU：（没有页式管理） 1.1.1、段式管理的由来： 16位CPU内部有20位地址总线，可寻址2的20次方即1M的内存空间，但16位CPU 只有16位的寄存器，因此只能访问2的16次方即64K。因此就采用了内存分段的管理模式，在CPU内部加入了段寄存器，这样1M被分成若干个逻辑段，每个逻辑段的要求如下： 1、逻辑段的起始地址（段地址）必须是16的整数倍，即最后4个二进制位须全是0 (因此不必保存)。 2、逻辑段的最大容量为64K。 1.1.2、物理地址的形成方式： 段地址：将段寄存器中的数值左移4位补4个0（乘以16），得到实际的段地址。 段偏移：在段偏移寄存器中。 1）逻辑地址=段基地址+段内偏移量(段基地址寄存器+段偏移寄存器) 2）由逻辑地址得到物理地址的公式为：（因为没有页式管理，所以这一步就得到了物理地址）物理地址PA=段寄存器的值×16+逻辑地址的偏移部分(注意!!)(段与段可能会重叠)
Solaris 8内存管理机制研究 吴海燕 戚丽 冯珂 摘 要：寻找性能瓶颈是性能分析中的一项重要任务，内存瓶颈的表现并不像CPU或磁盘那样直接，本文通过对Solaris 8内存管理机制的研究，给出了寻找Solaris 8系统内存瓶颈的方法。 关键词：Solaris 8，内存管理，性能优化 一、问题的提出 清华大学计算机与信息管理中心数据中心现有服务器近百台，其中包括了SUN Fire 15000、SUN Enterprise 5500、SUN Enterprise 5000等大型SUN服务器，Solaris 8是主流操作系统。为了对服务器的资源（如CPU、内存、磁盘、网络）的使用情况进行长期监控，建立性能优化（performance tuning）的基准值，我们开发了一套脚本程序定时采集系统运行参数。在长期的监控中，我们发现Solaris 8系统的空闲内存（freemem）呈现一个有趣的变化规律，如图1所示： 图1 空闲内存（freemem）变化图 图1是某Solaris 8系统（在下文中我们称之为15k-a）自2003年2月份以来的freemem 变化情况，横坐标是时间，纵坐标是freemem的数量，以8K字节为单位。15k-a配置是10路Super SPARCIII CPU，10GB物理内存。从上图可以看到在正常运行时，freemem应该是比较稳定的，15k-a主要是运行数据库，数据库在运行时会占用2G内存作为SGA区使用，因此在通常的负载下，freemem保持在6~7G之间是比较正常的。稳定一段时间后，
15k-a的freemem会持续走低，直到最低值，约为18893×8KMB，然后系统开始回收内存，我们就会看到freemem数量急剧上升。freemem的陡降都发生在凌晨1：00之后，检查系统作业发现每天1：00都会有一个数据库备份脚本开始运行：首先是用“exp”命令给数据库做逻辑备份，然后用“cp”命令把备份出来的文件拷贝到后备存储上。这两个命令都是正常退出，没有任何报错。开始时我们曾怀疑是有内存泄漏，当某一天freemem大幅攀升时，此怀疑被解除了，因为如果有内存泄漏，系统是无法将内存回收回来的。 对于一个物理内存为10GB的系统来说，如果空闲内存（freemem）真的减少到不到二百兆，那将存在着严重的问题。但奇怪的是系统的CPU使用率一直很低，所有进程的反应也很快，系统没有任何资源匮乏的迹象。如何解释这些问题呢，为此我们对Solaris 2.x 的内存管理机制进行了研究。 二、Solaris的内存管理机制 Solaris 8的内存管理为虚拟内存管理。[1]简单地说，虚拟内存就是进程看到比它实际使用的物理内存多得多的内存空间，对于64位的Solaris 8操作系统，进程可以通过8K 大小的段寻址访问2的64次方字节的内存空间，这种8K的段被称为页（page）。传统的UNIX通过进程（pagedaemon）完成虚拟地址和物理地址间的转换，在Solaris中这些是通过一个硬件－MMU(Memory Management Unit)－来实现的。在多处理器系统中，每个CPU 都有自己的MMU。Solaris 8的虚拟存储体系由系统寄存器、CPU CACHE、主存（RAM，物理内存）、外存（磁盘、磁带等）构成。 有两个基本的虚拟内存系统管理模型[2]：交换（swapping）和按需换页（demand paged）模型。交换模型的内存管理粒度是用户进程，当内存不足时，最不活跃的进程被交换出内存（swapping out）。按需换页模型的内存管理粒度是页（page），当内存匮乏时，只有最不经常使用的页被换出。Solaris 8结合使用了这两种内存管理模型，在通常情况下使用按需换页模型，当内存严重不足时，使用交换模型来进行内存释放。 与传统UNIX系统相比，Solaris虚拟内存系统的功能要丰富得多，它负责管理所有与I/O和内存相关的对象，包括内核、用户应用程序、共享库和文件系统。传统的UNIX系统V（System V）使用一个单独的缓冲区来加速文件系统的I/O， Solaris 8则使用虚拟内存系统来管理文件系统的缓存，系统的所有空闲内存都可以被用来做为文件I/O缓存，因为RAM的访问速度比磁盘快得多，所以这样做带来的性能提高是可观的。这也意味着在存在大量文件系统I/O的系统上，空闲内存的数量几乎是0。 了解系统内存被分配到了什么地方，系统在什么情况下进行内存整理是系统管理的重
一、 JVM简介 JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM工作原理和特点主要是指操作系统装入JVM是通过jdk中Java.exe来完成, 首先来说一下JVM工作原理中的jdk这个东西, .JVM 在整个jdk中处于最底层,负责于操作系统的交互,用来屏蔽操作系统环境,提供一个完整的Java运行环境,因此也就虚拟计算机. 操作系统装入JVM是通过jdk中Java.exe来完成。 通过下面4步来完成JVM环境. 1.创建JVM装载环境和配置 2.装载JVM.dll 3.初始化JVM.dll并挂界到JNIENV(JNI调用接口)实例 4.调用JNIEnv实例装载并处理class类。 对于JVM自身的物理结构，我们可以从下图了解：
JVM的一个重要的特征就是它的自动内存管理机制，在执行一段Java代码的时候，会把它所管理的内存划分 成几个不同的数据区域，其中包括： 1. 程序计数器，众所周知，JVM的多线程是通过线程轮流切换并 分配CPU执行时间的方式来实现的，那么每一个线程在切换 后都必须记住它所执行的字节码的行号，以便线程在得到CPU 时间时进行恢复，这个计数器用于记录正在执行的字节码指令的地址，这里要强调的是“字节码”，如果执行的是Native方法，那么这个计数器应该为null； 2.
3. Java计算栈，可以说整个Java程序的执行就是一个出栈入栈 的过程，JVM会为每一个线程创建一个计算栈，用于记录线程中方法的调用和变量的创建，由于在计算栈里分配的内存出栈后立即被抛弃，因此在计算栈里不存在垃圾回收，如果线程请求的栈深度大于JVM允许的深度，会抛出StackOverflowError 异常，在内存耗尽时会抛出OutOfMemoryError异常； 4. Native方法栈，JVM在调用操作系统本地方法的时候会使用到 这个栈； 5. Java堆，由于每个线程分配到的计算栈容量有限，对于可能会 占据大量内存的对象，则会被分配到Java堆中，在栈中包含了指向该对象内存的地址；对于一个Java程序来说，只有一个Java堆，也就是说，所有线程共享一个堆中的对象；由于Java堆不受线程的控制，如果在一个方法结束之后立即回收这个方法使用到的对象，并不能保证其他线程是否正在使用该对象；因此堆中对象的回收由JVM的垃圾收集器统一管理，和某一个线程无关；在HotSpot虚拟机中Java堆被划分为三代：o新生代，正常情况下新创建的对象会被分配到新生代，但如果对象占据的内存足够大以致超过了新生代的容量限 制，也可能被分配到老年代；新生代对象的一个特点是最 新、且生命周期不长，被回收的可能性高；
全面介绍Windows内存管理机制及C++内存分配实例 文章整理: https://www.doczj.com/doc/0a17601373.html, 文章来源: 网络- - 本文背景： 在编程中，很多Windows或C++的内存函数不知道有什么区别，更别谈有效使用；根本的原因是，没有清楚的理解操作系统的内存管理机制，本文企图通过简单的总结描述，结合实例来阐明这个机制。 本文目的： 对Windows内存管理机制了解清楚，有效的利用C++内存函数管理和使用内存。本文内容： 本文一共有六节，由于篇幅较多，故按节发表。 1.进程地址空间 1.1地址空间 ?32|64位的系统|CPU 操作系统运行在硬件CPU上，32位操作系统运行于32位CPU 上，64位操作系统运行于64位CPU上；目前没有真正的64位CPU。 32位CPU一次只能操作32位二进制数；位数多CPU设计越复杂，软件设计越简单。 软件的进程运行于32位系统上，其寻址位也是32位，能表示的空间是232=4G，范围从0x0000 0000~0xFFFF FFFF。 ?NULL指针分区 范围：0x0000 0000~0x0000 FFFF 作用：保护内存非法访问 例子：分配内存时，如果由于某种原因分配不成功，则返回空指针0x0000 0000；当用户继续使用比如改写数据时，系统将因为发生访问违规而退出。 那么，为什么需要那么大的区域呢，一个地址值不就行了吗？我在想，是不是因为不让8或16位的程序运行于32位的系统上呢？！因为NULL分区刚好范围是16的进程空间。 ?独享用户分区 范围：0x0001 0000~0x7FFE FFFF 作用：进程只能读取或访问这个范围的虚拟地址；超越这个范围的行为都 会产生违规退出。 例子： 程序的二进制代码中所用的地址大部分将在这个范围，所有exe 和dll文件都加载到这个。每个进程将近2G的空间是独享的。 注意：如果在boot.ini上设置了/3G，这个区域的范围从2G扩大为3G： 0x0001 0000~0xBFFE FFFF。 ?共享内核分区 范围：0x8000 0000~0xFFFF FFFF 作用：这个空间是供操作系统内核代码、设备驱动程序、设备I/O高速缓存、非页面内存池的分配、进程目表和页表等。 例子： 这段地址各进程是可以共享的。
内存分段和请求式分页 在深入i386架构的技术细节之前，让我们先返回1978年，那一年Intel 发布了PC处理器之母：8086。我想将讨论限制到这个有重大意义的里程碑上。如果你打算知道更多，阅读Robert L.的80486程序员参考（Hummel 1992）将是一个很棒的开始。现在看来这有些过时了，因为它没有涵盖Pentium处理器家族的新特性；不过，该参考手册中仍保留了大量i386架构的基本信息。尽管8086能够访问1MB RAM的地址空间，但应用程序还是无法“看到”整个的物理地址空间，这是因为CPU寄存器的地址仅有16位。这就意味着应用程序可访问的连续线性地址空间仅有64KB，但是通过16位段寄存器的帮助，这个64KB大小的内存窗口就可以在整个物理空间中上下移动，64KB逻辑空间中的线性地址作为偏移量和基地址（由16位的段寄存器给处）相加，从而构成有效的20位地址。这种古老的内存模型仍然被最新的Pentium CPU支持，它被称为：实地址模式，通常叫做：实模式。 80286 CPU引入了另一种模式，称为：受保护的虚拟地址模式，或者简单的称之为：保护模式。该模式提供的内存模型中使用的物理地址不再是简单的将线性地址和段基址相加。为了保持与8086和80186的向后兼容，80286仍然使用段寄存器，但是在切换到保护模式后，它们将不再包含物理段的地址。替代的是，它们提供了一个选择器（selector），该选择器由一个描述符表的索引构成。描述符表中的每一项都定义了一个24位的物理基址，允许访问16MB RAM，在当时这是一个很不可思议的数量。不过，80286仍然是16位CPU，因此线性地址空间仍然被限制在64KB。 1985年的80386 CPU突破了这一限制。该芯片最终砍断了16位寻址的锁链，将线性地址空间推到了4GB，并在引入32位线性地址的同时保留了基本的选择器/描述符架构。幸运的是，80286的描述符结构中还有一些剩余的位可以拿来使用。从16位迁移到32位地址后，CPU的数据寄存器的大小也相应的增加了两倍，并同时增加了一个新的强大的寻址模型。真正的32位的数据和地址为程序员带了实际的便利。事实上，在微软的Windows平台真正完全支持32位模型是在好几年之后。Windows NT的第一个版本在1993年7月26日发布，实现了真正意义上的Win32 API。但是Windows 3.x程序员仍然要处理由独立的代码和数据段构成的64KB内存片，Windows NT提供了平坦的4GB地址空间，在那儿可以使用简单的32位指针来寻址所有的代码和数据，而不需要分段。在内部，当然，分段仍然在起作用，就像我在前面提及的那样。不过管理段的所有责任都被移给了操作系统。
本文背景： 在编程中，很多Windows或C++的内存函数不知道有什么区别，更别谈有效使用；根本的原因是，没有清楚的理解操作系统的内存管理机制，本文企图通过简单的总结描述，结合实例来阐明这个机制。 本文目的： 对Windows内存管理机制了解清楚，有效的利用C++内存函数管理和使用内存。 本文内容： 3. 内存管理机制--虚拟内存 (VM) · 虚拟内存使用场合 虚拟内存最适合用来管理大型对象或数据结构。比如说，电子表格程序，有很多单元格，但是也许大多数的单元格是没有数据的，用不着分配空间。也许，你会想到用动态链表，但是访问又没有数组快。定义二维数组，就会浪费很多空间。 它的优点是同时具有数组的快速和链表的小空间的优点。 · 分配虚拟内存 如果你程序需要大块内存，你可以先保留内存，需要的时候再提交物理存储器。在需要的时候再提交才能有效的利用内存。一般来说，如果需要内存大于1M，用虚拟内存比较好。 · 保留 用以下Windows 函数保留内存块
VirtualAlloc (PVOID 开始地址，SIZE_T 大小，DWORD 类型，DWORD 保护 属性) 一般情况下，你不需要指定“开始地址”，因为你不知道进程的那段空间 是不是已经被占用了；所以你可以用NULL。“大小”是你需要的内存字 节；“类型”有MEM_RESERVE（保留）、MEM_RELEASE（释放）和 MEM_COMMIT（提交）。“保护属性”在前面章节有详细介绍，只能用前 六种属性。 如果你要保留的是长久不会释放的内存区，就保留在较高的空间区域， 这样不会产生碎片。用这个类型标志可以达到： MEM_RESERVE|MEM_TOP_DOWN。 C++程序：保留1G的空间 LPVOID pV=VirtualAlloc(NULL,1000*1024*1024,MEM_RESERVE|MEM_TOP_DOWN,PAGE_READW if(pV==NULL) cout<<"没有那么多虚拟空间!"< Windows7内存管理机制Superfetch介绍 Windows seven ：内存占用高并不是不好！（Windows7内存管理机制Superfetch介绍） 读过了“森木”管理员的《windows vista wow》之后，受益匪浅。虽说不是成为了一个“专家”，但也对从vista开始引进的新的内存管理机制Superfetch有了一定的了解。发现了很多人一开始（包括我）对于vista、7的内存的使用的误区。一般来说，从XP升的用户大多都认为系统空闲时内存使用越少越好。而到了7的时代（更准确的说是vista之后），这一个本该转变的观念却还迟迟留在大家的记忆里。今天，我看到一篇说7的内存占用太多而换回使用XP的，对此我认为比较遗憾。所以，我又翻开了那本的《windows vista wow》，仔细再次阅读了关于Superfetch的章节。因为不是人人都有这本书。所以在此介绍给大家。同时也是想改变一下大家的观念。从而使更多的用户可以对7充满积极！ 介绍之前，我也对我们的管理员Sveir表示感谢，他的《windows vista wow》让我更加的了解的vista（当然，了解vista后才能进一步了解7）。同时我也会引用一些书中的例子等。由于书中的句子比较繁杂，不容易理解。我还会使用图片以及生动的比喻告诉给大家。因为我的理解能力有限，且也是从书中获取的知识，如果有什么讲的不对的话，非常欢迎大家的指正和批评。 在了解Superfetch内存管理机制之前。我们要弄清楚一些概念。下面我就来讲解一下什么叫做“工作集”。 一、工作集的概念和作用 首先，我们从内存讲起。我们可以简单的将内存理解为“数据结构”+“工作集”。也就是说，在内存这个大房子里面有两个房间，一个是“数据结构”房间，另一个是“工作集”房间。那么我们就开始讲什么是“工作集”房间。 我们可以将每一个程序的运行占用的内存当做一个员工，而这些员工要工作的话就必须要走进他们的办公室，然后才能开始工作，那么这些“办公室”就可以理解为工作集了。引用森木的话就是“简单的说，应用程序在运行过程中进程所占用的内存中的工作空间就叫做工作集”。 那工作集的作用是什么呢？就如我刚才说的，是各个员工办公的场所，我们可以想象这些员工来自他们的“家”，也就是硬盘，工作集的作用就是让这些员工从家进入到大厦里（也就是内存里），也可以说，在这个大厦里，门口就是工作集房间，员工进入了工作集才能进入大厦。再次引用森木的话就是“工作集的作用是为了应用程序在运行时将硬盘当中对应的文件引入物理内存中”。 可是我们知道，大厦不能只有工作集一个房间，所有的员工在这个房间里面占用的地方并不是整个大厦（内存）。而工作集房间的面积大小就要看你这个大厦有多大了。如果大一 本文分为两个部分： 1，JVM specification s(JVM规范) 对JVM内存的描述 2，Sun的JVM的内存机制。 JVM specification对JVM内存的描述 首先我们来了解JVM specification中的JVM整体架构。如下图： 主要包括两个子系统和两个组件： Class loader(类装载器) 子系统，Execution engine(执行引擎) 子系统；Runtime data area (运行时数据区域)组件， Native interface(本地接口)组件。 Class loader子系统的作用：根据给定的全限定名类名(如 https://www.doczj.com/doc/0a17601373.html,ng.Object)来装载class文件的内容到 Runtime data area中的method area(方法区域)。Javsa程序员可以extends https://www.doczj.com/doc/0a17601373.html,ng.ClassLoader类来写自己的Class loader。 Execution engine子系统的作用：执行classes中的指令。任何JVM specification实现(JDK)的核心是Execution engine，换句话说：Sun 的JDK 和IBM的JDK好坏主要取决于他们各自实现的Execution engine的好坏。每个运行中的线程都有一个Execution engine的实例。 Native interface组件：与native libraries交互，是其它编程语言交互的接口。 Runtime data area 组件：这个组件就是JVM中的内存。下面对这个部分进行详细介绍。 Runtime data area的整体架构图 Runtime data area 主要包括五个部分：Heap (堆), Method Area(方法区域), Java Stack(java的栈), Program Counter(程序计数器), Native method stack(本地方法栈)。Heap 和Method Area是被所有线程的共享使用的；而Java stack, Program counter 和Native method stack是以线程为粒度的，每个线 MMU简介 1.概念 MMU是Memory Management Unit的缩写，中文名是内存管理单元，它是中央处理器（CPU）中用来管理虚拟存储器、物理存储器的控制线路，同时也负责虚拟地址映射为物理地址，以及提供硬件机制的内存访问授权。 虚拟地址映射为物理地址 内存访问授权 另一个概念：内存管理，是指软件运行时对计算机内存资源的分配和使用的技术。其最主要的目的是如何高效，快速的分配，并且在适当的时候释放和回收内存资源。 2.术语 虚拟地址空间——又称逻辑地址空间，CPU看到的使用的地址空间。32位CPU可以使用0~0xFFFFFFFF（4G）的地址空间。 物理地址空间——实际的内存空间，例如一个256M的内存，实际地址空间也就是0~0x0FFFFFFF（256M）。 VA——virtual address，虚拟地址 PA——physical address，物理地址 3.背景 内存有限 内存保护 内存碎片 1）内存有限——交换 程序很大，而内存不够一次装入太大的程序。 在磁盘中分配虚拟内存。进程在内存中执行，可以暂时从内存中交换（swap）出去到备份存储上，当需要时再调回到内存中。 2）内存保护 不同进程使用不同的物理地址空间，必须防止不同进程使用同一块内存产生冲突。 内存保护最基本的思路是操作系统为不同进程分配不同的地址空间。可以是逻辑地址，也可以是实际物理地址。（但如果是实际物理地址，操作系统还要负责实际物理地址的分配调度，任务过重，因此设计MMU减轻操作系统负担，负责逻辑地址到物理地址的映射。） 3）内存碎片 最初操作系统的内存是连续分配的，即进程A需要某一大小的内存空间，如200KB，操作系统就需要找出一块至少200KB的连续内存空间给进程A。随着系统的运行，进程终止时它将释放内存，该内存可以被操作系统分配给输入队列里的其他等待内存资源的进程。 可以想象，随着进程内存的分配和释放，最初的一大块连续内存空间被分成许多小片段，即使总的可用空间足够，但不再连续，因此产生内存碎片。 一个办法是不再对内存空间进行连续分配。这样只要有物理内存就可以为进程进行分配。而实际上，不进行连续分配只是相对的，因为完全这样做的代价太大。现实中，往往定出一个最小的内存单元，内存分配是这最小单元的组合，单元内的地址是连续的，但各个单元不一定连续。这样的内存小单元有页和段。 当然，分段和分页也会产生碎片，但理论上每个碎片的大小不超过内存单元的大小。 另外，操作系统分配给进程的逻辑地址就可以是连续的，通过MMU的映射，就可以充分利用不连续的物理内存。 4.MMU原理 分页 页表查找（映射） 以S3C2440的MMU为例，（ARM920T内核，三星产） MVA——modified virtual address，变换后的虚拟地址。一般是在虚拟地址上再标记上进程号。 4.1分页机制 虚拟地址最终需要转换为物理地址才能读写实际的数据，通过将虚拟地址空间和物理空间划分为同样大小的空间（段或页），然后两个空间建立映射关系。 在虚拟地址空间上划分的空间单元称为页（page，较大的则称为段section）。在物理地址空间上划分的同样大小的空间单元称为页帧（page frame，或叫页框）。Linux上地址空间单元大小为4k。 由于虚拟地址空间远大于物理地址，可能多块虚拟地址空间映射到同一块物理地址空间，或者有些虚拟地址空间没有映射到具体的物理地址空间上去（使用到时再映射）。 S3C2440最多会用到两级页表，以段（Section，1M）的方式进行转换时只用到一级页表，以页（Page）的方式进行转换时用到两级页表。 页的大小有3种：大页（64KB），小页（4KB），极小页（1KB）。 Linux操作系统内存管理 摘要： Linux支持虚拟内存, 就是使用磁盘作为RAM的扩展，使可用内存相应地有效扩大。核心把当前不用的内存块存到硬盘，腾出内存给其他目的。当原来的内容又要使用时，再读回内存。这对用户全透明：运行于Linux的程序只看到大量的可用内存而不甘心哪部分在磁盘上。当然，读写硬盘比真的内存慢(慢千倍)，所以程序运行较慢。用做虚拟内存的这部分硬盘叫对换空间。 Linux可以使用文件系统中的普通文件或单独的分区作为对换空间。对换分区更快，但对换文件更易于改变大小(无须对硬盘重分区)。如果知道要多少对换空间，应该用对换分区；如果不能确认，可以先用对换文件，用一段时间后再根据所需空间建立对换分区。 Linux允许同时使用多个对换分区和/或对换文件。即如果偶尔需要更多的对换空间，可以随时建立一个额外的对换文件。 Linux是一个遵循POSIX（Portable Operating System Interface）标准的操作系统，它继承了UNIX系统优秀的设计思想，拥有简练、容错强、高效而且稳定的内核。此外Linux还具备其他操作系统所不能比拟的优点。①：完全免费； ②：内核源代码完全公开。 Linux内核拥有一个功能完备的内存管理子系统,它增加了对NUMA（非均匀存储结构）体系结构的支持并且使用了基于区(ZONE)的物理内存管理方法,从而保持了物理上连续分布、而逻辑上统一的内存模式和传统的共享内存编程模型,使得系统的性能得以极大的扩展。这样Linux不仅能够满足传统的桌面应用,而且还能满足高端服务器市场的需要。目前，Linux不仅在Internet服务器上表现出色，而且还可以胜任大型数据库系统的服务器。 关键字：虚拟内存，物理内存管理，虚拟内存管理 一、Linux存储管理的基本框架 Linux内核采用虚拟页式存储管理，采用三次映射机制实现从线性地址到物理地址的映射。其中PGD为页面目录，PMD为中间目录，PT为页面表。具体的映射过程为： ⑴从CR3寄存器中找到PGD基地址； ⑵以线性地址的最高位段为下标，在PGD中找到指向PMD的指针； Unity几种动态加载Prefab方式的差异: 其实存在3种加载prefab的方式： 一是静态引用，建一个public的变量，在Inspector里把prefab拉上去，用的时候instantiate 二是Resource.Load，Load以后instantiate 三是AssetBundle.Load,Load以后instantiate 三种方式有细节差异，前两种方式，引用对象texture是在instantiate时加载，而assetBundle.Load会把perfab的全部assets 都加载，instantiate时只是生成Clone。所以前两种方式，除非你提前加载相关引用对象，否则第一次instantiate时会包含加载引用类assets的操作，导致第一次加载的lag。官方论坛有人说Resources.Load和静态引用是会把所有资源都预先加载的，反复测试的结果，静态引用和Resources.Load也是OnDemand的，用到时才会加载。 几种AssetBundle创建方式的差异: CreateFromFile:这种方式不会把整个硬盘AssetBundle文件都加载到内存来，而是类似建立一个文件操作句柄和缓冲区，需要时才实时Load，所以这种加载方式是最节省资源的，基本上AssetBundle本身不占什么内存，只需要Asset对象的内存。可惜只能在PC/Mac Standalone 程序中使用。 CreateFromMemory和www.assetBundle:这两种方式AssetBundle文件会整个镜像于内存中，理论上文件多大就需要多大的内存，之后Load时还要占用额外内存去生成Asset对象。 什么时候才是UnusedAssets? 看一个例子： Object obj = Resources.Load("MyPrefab"); GameObject instance = Instantiate(obj) as GameObject; ......... Destroy(instance); 创建随后销毁了一个Prefab实例，这时候MyPrefab已经没有被实际的物体引用了，但如果这时： Resources.UnloadUnusedAssets(); 内存并没有被释放，原因：MyPrefab还被这个变量obj所引用 这时候： obj = null; Resources.UnloadUnusedAssets(); 这样才能真正释放Assets对象 所以：UnusedAssets不但要没有被实际物体引用，也要没有被生命周期内的变量所引用，才可以理解为Unused(引用计数为0) 所以所以：如果你用个全局变量保存你Load的Assets，又没有显式的设为null，那在这个变量失效前你无论如何UnloadUnusedAssets也释放不了那些Assets的。如果你这些Assets又不是从磁盘加载的，那除了UnloadUnusedAssets或者加载新场景以外没有其他方式可以卸载之。 一个复杂的例子，代码很丑陋实际也不可能这样做，只是为了加深理解 复制代码 1. IEnumeratorOnClick() Java内存管理机制 在C 语言中，如果需要动态分配一块内存，程序员需要负责这块内存的整个生命周期。从申请分配、到使用、再到最后的释放。这样的过程非常灵活，但是却十分繁琐，程序员很容易由于疏忽而忘记释放内存，从而导致内存的泄露。Java语言对内存管理做了自己的优化，这就是垃圾回收机制。Java的几乎所有内存对象都是在堆内存上分配（基本数据类型除外），然后由GC（garbage collection）负责自动回收不再使用的内存。 上面是Java内存管理机制的基本情况。但是如果仅仅理解到这里，我们在实际的项目开发中仍然会遇到内存泄漏的问题。也许有人表示怀疑，既然Java的垃圾回收机制能够自动的回收内存，怎么还会出现内存泄漏的情况呢？这个问题，我们需要知道GC在什么时候回收内存对象，什么样的内存对象会被GC认为是“不再使用”的。 Java中对内存对象的访问，使用的是引用的方式。在Java代码中我们维护一个内存对象的引用变量，通过这个引用变量的值，我们可以访问到对应的内存地址中的内存对象空间。在Java程序中，这个引用变量本身既可以存放堆内存中，又可以放在代码栈的内存中（与基本数据类型相同）。GC线程会从代码栈中的引用变量开始跟踪，从而判定哪些内存是正在使用的。如果GC线程通过这种方式，无法跟踪到某一块堆内存，那么GC就认为这块内存将不再使用了（因为代码中已经无法访问这块内存了）。 通过这种有向图的内存管理方式，当一个内存对象失去了所有的引用之后，GC 就可以将其回收。反过来说，如果这个对象还存在引用，那么它将不会被GC回收，哪怕是Java虚拟机抛出OutOfMemoryError。 Java内存泄露Windows7内存管理机制Superfetch介绍
JVM的内存机制介绍
内存管理以及内存管理单元简介(MMU)
Linux操作系统内存管理
全面理解Unity加载和内存管理机制之二：进一步深入和细节
Java内存管理机制
相关主题
文本预览