![[学习C++]内存管理](https://img.doczj.com/img47/025i1uhocdbh3qvl3a8z-71.webp)
![[学习C++]内存管理](https://img.doczj.com/img47/025i1uhocdbh3qvl3a8z-b2.webp)
c++中涉及到的内存的管理问题可以归结为两方面：正确地得到它和有效地使用它。好的程序员会理解这两个问题为什么要以这样的顺序列出。因为执行得再快、体积再小的程序如果它不按你所想象地那样去执行，那也一点用处都没有。“正确地得到”的意思是正确地调用内存分配和释放程序；而“有效地使用”是指写特定版本的内存分配和释放程序。这里，“正确地得到”显得更重要一些。
然而说到正确性，c++其实从c继承了一个很严重的头疼病，那就是内存泄露隐患。虚拟内存是个很好的发明，但虚拟内存也是有限的，并不是每个人都可以最先抢到它。
在c中，只要用malloc分配的内存没有用free返回，就会产生内存泄露。在
c++中，肇事者的名字换成了new和delete，但情况基本上是一样的。当然，因为有了析构函数的出现，情况稍有改善，因为析构函数为所有将被摧毁的对象提供了一个方便的调用delete的场所。但这同时又带来了更多的烦恼，因为new 和delete是隐式地调用构造函数和析构函数的。而且，因为可以在类内和类外自定义new和delete操作符，这又带来了复杂性，增加了出错的机会。下面的条款(还有条款m8)将告诉你如何避免产生那些普遍发生的问题。
5：对应的new和delete要采用相同的形式
下面的语句有什么错？
string *stringarray = new string[100];
...
delete stringarray;
一切好象都井然有序——一个new对应着一个delete——然而却隐藏着很大的错误：程序的运行情况将是不可预测的。至少，stringarray指向的100个string 对象中的99个不会被正确地摧毁，因为他们的析构函数永远不会被调用。
用new的时候会发生两件事。首先，内存被分配(通过operator new 函数，详见条款7-10和条款m8)，然后，为被分配的内存调用一个或多个构造函数。用delete的时候，也有两件事发生：首先，为将被释放的内存调用一个或多个析构函数，然后，释放内存(通过operator delete 函数，详见条款8和m8)。对于 delete来说会有这样一个重要的问题：内存中有多少个对象要被删除？答案决定了将有多少个析构函数会被调用。
这个问题简单来说就是：要被删除的指针指向的是单个对象呢，还是对象数组？这只有你来告诉delete。如果你在用delete时没用括号，delete就会认为指向的是单个对象，否则，它就会认为指向的是一个数组：
string *stringptr1 = new string;
string *stringptr2 = new string[100];
...
delete stringptr1;// 删除一个对象
delete [] stringptr2;// 删除对象数组
如果你在stringptr1前加了"[]"会怎样呢？答案是：那将是不可预测的；如果你没在stringptr2前没加上"[]"又会怎样呢？答案也是：不可预测。而且对于象int这样的固定类型来说，结果也是不可预测的，即使这样的类型没有析构函数。所以，解决这类问题的规则很简单：如果你调用new时用了[]，调用delete 时也要用[]。如果调用new时没有用[]，那调用delete时也不要用[]。
在写一个包含指针数据成员，并且提供多个构造函数的类时，牢记这一规则尤其重要。因为这样的话，你就必须在所有初始化指针成员的构造函数里采用相同的new的形式。否则，析构函数里将采用什么形式的delete呢？关于这一话题的进一步阐述，参见条款11。
这个规则对喜欢用typedef的人来说也很重要，因为写typedef的程序员必须告诉别人，用new创建了一个typedef定义的类型的对象后，该用什么形式的delete来删除。举例如下：
typedef string addresslines[4]; //一个人的地址，共4行，每行一个string
//因为addresslines是个数组，使用new: string *pal = new addresslines; // 注意"new addresslines"返回string*, 和
// "new string[4]"返回的一样
delete时必须以数组形式与之对应：
delete pal;// 错误!
delete [] pal;// 正确
为了避免混乱，最好杜绝对数组类型用typedefs。这其实很容易，因为标准c++库(见条款49)包含有stirng和vector模板，使用他们将会使对数组的需求减少到几乎零。举例来说，addresslines可以定义为一个字符串(string)的向量(vector)，即addresslines可定义为vector
6：析构函数里对指针成员调用delete
大多数情况下，执行动态内存分配的的类都在构造函数里用new分配内存，然后在析构函数里用delete释放内存。最初写这个类的时候当然不难做，你会记得最后对在所有构造函数里分配了内存的所有成员使用delete。
然而，这个类经过维护、升级后，情况就会变得困难了，因为对类的代码进行修改的程序员不一定就是最早写这个类的人。而增加一个指针成员意味着几乎都要进行下面的工作：
·在每个构造函数里对指针进行初始化。对于一些构造函数，如果没有内存要分配给指针的话，指针要被初始化为0(即空指针)。
·删除现有的内存，通过赋值操作符分配给指针新的内存。
·在析构函数里删除指针。
如果在构造函数里忘了初始化某个指针，或者在赋值操作的过程中忘了处理它，问题会出现得很快，很明显，所以在实践中这两个问题不会那么折磨你。但是，如果在析构函数里没有删除指针，它不会表现出很明显的外部症状。相反，它可能只是表现为一点微小的内存泄露，并且不断增长，最后吞噬了你的地址空间，导致程序夭折。因为这种情况经常不那么引人注意，所以每增加一个指针成员到类里时一定要记清楚。
另外，删除空指针是安全的(因为它什么也没做)。所以，在写构造函数，赋值操作符，或其他成员函数时，类的每个指针成员要么指向有效的内存，要么就指向空，那在你的析构函数里你就可以只用简单地delete掉他们，而不用担心他们是不是被new过。
当然对本条款的使用也不要绝对。例如，你当然不会用delete去删除一个没有用new来初始化的指针，而且，就象用智能指针对象时不用劳你去删除一样，你也永远不会去删除一个传递给你的指针。换句话说，除非类成员最初用了new,否则是不用在析构函数里用delete的。
说到智能指针，这里介绍一种避免必须删除指针成员的方法，即把这些成员用智能指针对象来代替，比如c++标准库里的auto_ptr。想知道它是如何工作的，看看条款m9和m10。
7：预先准备好内存不够的情况
operator new在无法完成内存分配请求时会抛出异常(以前的做法一般是返回0，一些旧一点的编译器还这么做。你愿意的话也可以把你的编译器设置成这样。关于这个话题我将推迟到本条款的结尾处讨论)。大家都知道，处理内存不够所产生的异常真可以算得上是个道德上的行为，但实际做起来又会象刀架在脖子上那样痛苦。所以，你有时会不去管它，也许一直没去管它。但你心里一定还是深深地隐藏着一种罪恶感：万一new真的产生了异常怎么办？
你会很自然地想到处理这种情况的一种方法，即回到以前的老路上去，使用预处理。例如，c的一种常用的做法是，定义一个类型无关的宏来分配内存并检查分配是否成功。对于c++来说，这个宏看起来可能象这样：
#define new(ptr, type) \
try { (ptr) = new type; } \
catch (std::bad_alloc&) { assert(0); }
（“慢！std::bad_alloc是做什么的？”你会问。bad_alloc是operator new 不能满足内存分配请求时抛出的异常类型，std是bad_alloc所在的名字空间(见条款28)的名称。“好！”你会继续问，“assert又有什么用？”如果你看看标准c头文件
new宏不但有着上面所说的通病，即用assert去检查可能发生在已发布程序里的状态(然而任何时候都可能发生内存不够的情况)，同时，它还在c++里有另外一个缺陷：它没有考虑到new有各种各样的使用方式。例如，想创建类型t对象，一般有三种常见的语法形式，你必须对每种形式可能产生的异常都要进行处理：
new t;
new t(constructor arguments);
new t[size];
这里对问题大大进行了简化，因为有人还会自定义(重载)operator new，所以程序里会包含任意个使用new的语法形式。
那么，怎么办？如果想用一个很简单的出错处理方法，可以这么做：当内存分配请求不能满足时，调用你预先指定的一个出错处理函数。这个方法基于一个常规，即当operator new不能满足请求时，会在抛出异常之前调用客户指定的一个出错处理函数——一般称为new-handler函数。(operator new实际工作起来要复杂一些，详见条款8)
指定出错处理函数时要用到set_new_handler函数，它在头文件
typedef void (*new_handler)();
new_handler set_new_handler(new_handler p) throw();
可以看到，new_handler是一个自定义的函数指针类型，它指向一个没有输入参数也没有返回值的函数。set_new_handler则是一个输入并返回new_handler类型的函数。
set_new_handler的输入参数是operator new分配内存失败时要调用的出错处理函数的指针，返回值是set_new_handler没调用之前就已经在起作用的旧的出错处理函数的指针。
可以象下面这样使用set_new_handler：
// function to call if operator new can't allocate enough memory
void nomorememory()
{
cerr << "unable to satisfy request for memory\n";
abort();
}
int main()
{
set_new_handler(nomorememory);
int *pbigdataarray = new int[100000000];
...
}
假如operator new不能为100,000,000个整数分配空间，nomorememory将会被调用，程序发出一条出错信息后终止。这就比简单地让系统内核产生错误信息来结束程序要好。(顺便考虑一下，假如cerr在写错误信息的过程中要动态分配内存，那将会发生什么...)
operator new不能满足内存分配请求时，new-handler函数不只调用一次，而是不断重复，直至找到足够的内存。实现重复调用的代码在条款8里可以看到，这里我用描述性的的语言来说明：一个设计得好的new-handler函数必须实现下面功能中的一种。
·产生更多的可用内存。这将使operator new下一次分配内存的尝试有可能获得成功。实施这一策略的一个方法是：在程序启动时分配一个大的内存块，然后在第一次调用new-handler时释放。释放时伴随着一些对用户的警告信息，如内存数量太少，下次请求可能会失败，除非又有更多的可用空间。
·安装另一个不同的new-handler函数。如果当前的new-handler函数不能产生更多的可用内存，可能它会知道另一个new-handler函数可以提供更多的资源。这样的话，当前的new-handler可以安装另一个new-handler来取代它(通过调用set_new_handler)。下一次operator new调用new-handler时，会使用最近安装的那个。(这一策略的另一个变通办法是让new-handler可以改变它自己的运行行为，那么下次调用时，它将做不同的事。方法是使new-handler可以修改那些影响它自身行为的静态或全局数据。)
·卸除new-handler。也就是传递空指针给set_new_handler。没有安装new-handler，operator new分配内存不成功时就会抛出一个标准的
std::bad_alloc类型的异常。
·抛出std::bad_alloc或从std::bad_alloc继承的其他类型的异常。这样的异常不会被operator new捕捉，所以它们会被送到最初进行内存请求的地方。(抛出别的不同类型的异常会违反operator new异常规范。规范中的缺省行为是
调用abort，所以new-handler要抛出一个异常时，一定要确信它是从
std::bad_alloc继承来的。想更多地了解异常规范，参见条款m14。) ·没有返回。典型做法是调用abort或exit。abort/exit可以在标准c库中找到(还有标准c++库，参见条款49)。
上面的选择给了你实现new-handler函数极大的灵活性。
处理内存分配失败的情况时采取什么方法，取决于要分配的对象的类：
class x {
public:
static void
outofmemory();
...
};
class y {
public:
static void outofmemory();
...
};
x* p1 = new x; // 若分配成功，调用x::outofmemory
y* p2 = new y; // 若分配不成功，调用y::outofmemory
c++不支持专门针对于类的new-handler函数，而且也不需要。你可以自己来实现它，只要在每个类中提供自己版本的set_new_handler和operator new。类的set_new_handler可以为类指定new-handler(就象标准的set_new_handler 指定全局new-handler一样)。类的operator new则保证为类的对象分配内存时用类的new-handler取代全局new-handler。
假设处理类x内存分配失败的情况。因为operator new对类型x的对象分配内存失败时，每次都必须调用出错处理函数，所以要在类里声明一个new_handler 类型的静态成员。那么类x看起来会象这样：
class x {
public:
static new_handler set_new_handler(new_handler p);
static void * operator new(size_t size);
private:
static new_handler currenthandler;
};
类的静态成员必须在类外定义。因为想借用静态对象的缺省初始化值0，所以定义x::currenthandler时没有去初始化。
new_handler x::currenthandler; //缺省设置currenthandler为0(即null)
类x中的set_new_handler函数会保存传给它的任何指针，并返回在调用它之前所保存的任何指针。这正是标准版本的set_new_handler所做的：
new_handler x::set_new_handler(new_handler p)
{
new_handler oldhandler = currenthandler;
currenthandler = p;
return oldhandler;
}
最后看看x的operator new所做的：
1. 调用标准set_new_handler函数，输入参数为x的出错处理函数。这使得x 的new-handler函数成为全局new-handler函数。注意下面的代码中，用了"::"符号显式地引用std空间(标准set_new_handler函数就存在于std空间)。
2. 调用全局operator new分配内存。如果第一次分配失败，全局operator new 会调用x的new-handler，因为它刚刚(见1.)被安装成为全局new-handler。如果全局operator new最终未能分配到内存，它抛出std::bad_alloc异常，x的operator new会捕捉到它。x的operator new然后恢复最初被取代的全局new-handler函数，最后以抛出异常返回。
3. 假设全局operator new为类型x的对象分配内存成功，, x的operator new 会再次调用标准set_new_handler来恢复最初的全局出错处理函数。最后返回分配成功的内存的指针。
c++是这么做的：
void * x::operator new(size_t size)
{
new_handler globalhandler = // 安装x的new_handler std::set_new_handler(currenthandler);
void *memory;
try { // 尝试分配内存
memory = ::operator new(size);
}
catch (std::bad_alloc&) { // 恢复旧的new_handler
std::set_new_handler(globalhandler);
throw; // 抛出异常
}
std::set_new_handler(globalhandler); // 恢复旧的new_handler
return memory;
}
如果你对上面重复调用std::set_new_handler看不顺眼，可以参见条款m9来除去它们。
使用类x的内存分配处理功能时大致如下：
void nomorememory();// x的对象分配内存失败时调用的new_handler函数的声明
x::set_new_handler(nomorememory);
// 把nomorememory设置为x的
// new-handling函数
x *px1 = new x;
// 如内存分配失败，
// 调用nomorememory
string *ps = new string;
// 如内存分配失败，调用全局new-handling函数
x::set_new_handler(0);
// 设x的new-handling函数为空
x *px2 = new x;
// 如内存分配失败，立即抛出异常
// (类x没有new-handling函数)
你会注意到，处理以上类似情况，如果不考虑类的话，实现代码是一样的，这就很自然地想到在别的地方也能重用它们。正如条款41所说明的，继承和模板可以用来设计可重用代码。在这里，我们把两种方法结合起来使用，从而满足了你的要求。
你只要创建一个“混合风格”(mixin-style)的基类，这种基类允许子类继承它某一特定的功能——这里指的是建立一个类的new-handler的功能。之所以设计一个基类，是为了让所有的子类可以继承set_new_handler和operator new功
能，而设计模板是为了使每个子类有不同的currenthandler数据成员。这听起来很复杂，不过你会看到代码其实很熟悉。区别只不过是它现在可以被任何类重用了。
template
class newhandlersupport { // 混合风格”的基类
public:
static new_handler set_new_handler(new_handler p);
static void * operator new(size_t size);
private:
static new_handler currenthandler;
};
template
new_handler newhandlersupport
{
new_handler oldhandler = currenthandler;
currenthandler = p;
return oldhandler;
}
template
void * newhandlersupport
{
new_handler globalhandler =
std::set_new_handler(currenthandler);
void *memory;
try {
memory = ::operator new(size);
}
catch (std::bad_alloc&) {
std::set_new_handler(globalhandler);
throw;
}
std::set_new_handler(globalhandler);
return memory;
}
// this sets each currenthandler to 0
template
new_handler newhandlersupport
有了这个模板类，对类x加上set_new_handler功能就很简单了：只要让x从newhandlersupport
// note inheritance from mixin base class template. (see
// my article on counting objects for information on why
// private inheritance might be preferable here.)
class x: public newhandlersupport
... // as before, but no declarations for
}; // set_new_handler or operator new
使用x的时候依然不用理会它幕后在做些什么；老代码依然工作。这很好！那些你常不去理会的东西往往是最可信赖的。
使用set_new_handler是处理内存不够情况下一种方便，简单的方法。这比把每个new都包装在try模块里当然好多了。而且，newhandlersupport这样的模板使得向任何类增加一个特定的new-handler变得更简单。“混合风格”的继承不可避免地将话题引入到多继承上去，在转到这个话题前，你一定要先阅读条款43。
1993年前，c++一直要求在内存分配失败时operator new要返回0，现在则是要求operator new抛出std::bad_alloc异常。很多c++程序是在编译器开始支持新规范前写的。c++标准委员会不想放弃那些已有的遵循返回0规范的代码，所以他们提供了另外形式的operator new(以及operator new[]——见条款8)以继续提供返回0功能。这些形式被称为“无抛出”，因为他们没用过一个throw，而是在使用new的入口点采用了nothrow对象：
class widget { ... };
widget *pw1 = new widget;// 分配失败抛出std::bad_alloc if
if (pw1 == 0) ... // 这个检查一定失败
widget *pw2 = new (nothrow) widget; // 若分配失败返回0
if (pw2 == 0) ... // 这个检查可能会成功
不管是用“正规”(即抛出异常)形式的new还是“无抛出”形式的new，重要的是你必须为内存分配失败做好准备。最简单的方法是使用set_new_handler，因为它对两种形式都有用。
8: 写operator new和operator delete时要遵循常规
自己重写operator new时(条款10解释了为什么有时要重写它)，很重要的一点是函数提供的行为要和系统缺省的operator new一致。实际做起来也就是：要有正确的返回值；可用内存不够时要调用出错处理函数(见条款7)；处理好0字节内存请求的情况。此外，还要避免不小心隐藏了标准形式的new，不过这是条款9的话题。
有关返回值的部分很简单。如果内存分配请求成功，就返回指向内存的指针；如果失败，则遵循条款7的规定抛出一个std::bad_alloc类型的异常。
但事情也不是那么简单。因为operator new实际上会不只一次地尝试着去分配内存，它要在每次失败后调用出错处理函数，还期望出错处理函数能想办法释放别处的内存。只有在指向出错处理函数的指针为空的情况下，operator new才抛出异常。
另外，c++标准要求，即使在请求分配0字节内存时，operator new也要返回一个合法指针。(实际上，这个听起来怪怪的要求确实给c++语言其它地方带来了简便)
这样，非类成员形式的operator new的伪代码看起来会象下面这样：
void * operator new(size_t size) // operator new还可能有其它参数
{
if (size == 0) { // 处理0字节请求时，
size = 1; // 把它当作1个字节请求来处理 }
while (1) {
分配size字节内存;
if (分配成功)
return (指向内存的指针);
// 分配不成功，找出当前出错处理函数
new_handler globalhandler = set_new_handler(0);
set_new_handler(globalhandler);
if (globalhandler) (*globalhandler)();
else throw std::bad_alloc();
}
}
处理零字节请求的技巧在于把它作为请求一个字节来处理。这看起来也很怪，但简单，合法，有效。而且，你又会多久遇到一次零字节请求的情况呢？
你又会奇怪上面的伪代码中为什么把出错处理函数置为0后又立即恢复。这是因为没有办法可以直接得到出错处理函数的指针，所以必须通过调用
set_new_handler来找到。办法很笨但也有效。
条款7提到operator new内部包含一个无限循环，上面的代码清楚地说明了这一点——while (1)将导致无限循环。跳出循环的唯一办法是内存分配成功或出错处理函数完成了条款7所描述的事件中的一种：得到了更多的可用内存；安装了一个新的new-handler(出错处理函数)；卸除了new-handler；抛出了一个std::bad_alloc或其派生类型的异常；或者返回失败。现在明白了为什么
new-handler必须做这些工作中的一件。如果不做，operator new里面的循环就不会结束。
很多人没有认识到的一点是operator new经常会被子类继承。这会导致某些复杂性。上面的伪代码中，函数会去分配size字节的内存(除非size为0)。size 很重要，因为它是传递给函数的参数。但是大多数针对类所写的operator new(包括条款10中的那种)都是只为特定的类设计的，不是为所有的类，也不是为它所有的子类设计的。这意味着，对于一个类x的operator new来说，函数内部的行为在涉及到对象的大小时，都是精确的sizeof(x)：不会大也不会小。但由于存在继承，基类中的operator new可能会被调用去为一个子类对象分配内存：class base {
public:
static void * operator new(size_t size);
...
};
class derived: public base // derived类没有声明operator new { ... }; //
derived *p = new derived; // 调用base::operator new
如果base类的operator new不想费功夫专门去处理这种情况——这种情况出现的可能性不大——那最简单的办法是把这个“错误”数量的内存分配请求转给标准operator new来处理，象下面这样：
void * base::operator new(size_t size)
{
if (size != sizeof(base)) // 如果数量“错误”，让标准operator new
return ::operator new(size); // 去处理这个请求
//
... // 否则处理这个请求
}
“停!”我听见你在叫，“你忘了检查一种虽然不合理但是有可能出现的一种情况——size有可能为零!”是的，我没检查，但拜托下次再叫出声的时候不要这么文绉绉的。:)但实际上检查还是做了，只不过融合到size != sizeof(base)语句中了。c++标准很怪异，其中之一就是规定所以独立的(freestanding)类的大小都是非零值。所以sizeof(base)永远不可能是零(即使base类没有成员)，如果size为零，请求会转到::operator new，由它来以一种合理的方式对请求进行处理。(有趣的是，如果base不是独立的类，sizeof(base)有可能是零，详细说明参见"my article on counting objects")。
如果想控制基于类的数组的内存分配，必须实现operator new的数组形式——operator new[](这个函数常被称为“数组new”，因为想不出"operator new[]")该怎么发音)。写operator new[]时，要记住你面对的是“原始”内存，不能对数组里还不存在的对象进行任何操作。实际上，你甚至还不知道数组里有多少个对象，因为不知道每个对象有多大。基类的operator new[]会通过继承的方式被用来为子类对象的数组分配内存，而子类对象往往比基类要大。所以，不能想当然认为base::operator new[]里的每个对象的大小都是sizeof(base)，也就是说，数组里对象的数量不一定就是(请求字节数)/sizeof(base)。关于operator new[]的详细介绍参见条款m8。
重写operator new(和operator new[])时所有要遵循的常规就这些。对于operator delete(以及它的伙伴operator delete[])，情况更简单。所要记住的只是，c++保证删除空指针永远是安全的，所以你要充分地应用这一保证。下面是非类成员形式的operator delete的伪代码：
void operator delete(void *rawmemory)
{
if (rawmemory == 0) return; file://如/果指针为空，返回
//
释放rawmemory指向的内存;
return;
}
这个函数的类成员版本也简单，只是还必须检查被删除的对象的大小。假设类的operator new将“错误”大小的分配请求转给::operator new，那么也必须将“错误”大小的删除请求转给::operator delete：
class base { // 和前面一样，只是这里声明了public: // operator delete
static void * operator new(size_t size);
static void operator delete(void *rawmemory, size_t size);
...
};
void base::operator delete(void *rawmemory, size_t size)
{
if (rawmemory == 0) return; // 检查空指针
if (size != sizeof(base)) { // 如果size"错误"，
::operator delete(rawmemory); // 让标准operator来处理请求
return;
}
释放指向rawmemory的内存;
return;
}
可见，有关operator new和operator delete(以及他们的数组形式)的规定不是那么麻烦，重要的是必须遵守它。只要内存分配程序支持new-handler函数并正确地处理了零内存请求，就差不多了；如果内存释放程序又处理了空指针，那就没其他什么要做的了。至于在类成员版本的函数里增加继承支持，那将很快就可以完成。
9: 避免隐藏标准形式的new
因为内部范围声明的名称会隐藏掉外部范围的相同的名称，所以对于分别在类的内部
和全局声明的两个相同名字的函数f来说，类的成员函数会隐藏掉全局函数：void f(); // 全局函数
class x {
public:
void f(); // 成员函数
};
x x;
f(); // 调用 f
x.f(); // 调用 x::f
这不会令人惊讶，也不会导致混淆，因为调用全局函数和成员函数时总是采用不同的
语法形式。然而如果你在类里增加了一个带多个参数的operator new函数，结果就有
可能令人大吃一惊。
class x {
public:
void f();
// operator new的参数指定一个
// new-hander(new的出错处理)函数
static void * operator new(size_t size, new_handler p);
};
void specialerrorhandler(); // 定义在别的地方
x *px1 =
new (specialerrorhandler) x; // 调用x::operator new
x *px2 = new x; // 错误!
在类里定义了一个称为“operator new”的函数后，会不经意地阻止了对标准new的访
问。条款50解释了为什么会这样，这里我们更关心的是如何想个办法避免这个问题。
一个办法是在类里写一个支持标准new调用方式的operator new，它和标准new 做同样
的事。这可以用一个高效的内联函数来封装实现。
class x {
public:
void f();
static void * operator new(size_t size, new_handler p);
static void * operator new(size_t size)
{ return ::operator new(size); }
};
x *px1 =
new (specialerrorhandler) x; // 调用 x::operator
// new(size_t, new_handler)
x* px2 = new x; // 调用 x::operator
// new(size_t)
另一种方法是为每一个增加到operator new的参数提供缺省值(见条款24)：
class x {
public:
void f();
static
void * operator new(size_t size, // p缺省值为0
new_handler p = 0); //
};
x *px1 = new (specialerrorhandler) x; // 正确
x* px2 = new x; // 也正确
无论哪种方法，如果以后想对“标准”形式的new定制新的功能，只需要重写这个函数。
调用者重新编译链接后就可以使用新功能了。
10: 如果写了operator new就要同时写operator delete
让我们回过头去看看这样一个基本问题：为什么有必要写自己的operator new 和operator delete？
答案通常是：为了效率。缺省的operator new和operator delete具有非常好的通用性，它的这种灵活性也使得在某些特定的场合下，可以进一步改善它的性能。尤其在那些需要动态分配大量的但很小的对象的应用程序里，情况更是如此。
例如有这样一个表示飞机的类：类airplane只包含一个指针，它指向的是飞机对象的实际描述(此技术在条款34进行说明)：
class airplanerep { ... }; // 表示一个飞机对象
//
class airplane {
public:
...
private:
airplanerep *rep; // 指向实际描述
};
一个airplane对象并不大，它只包含一个指针（正如条款14和m24所说明的，如果airplane类声明了虚函数，会隐式包含第二个指针）。但当调用operator new来分配一个airplane对象时，得到的内存可能要比存储这个指针（或一对指针）所需要的要多。之所以会产生这种看起来很奇怪的行为，在于operator new 和operator delete之间需要互相传递信息。
因为缺省版本的operator new是一种通用型的内存分配器，它必须可以分配任意大小的内存块。同样，operator delete也要可以释放任意大小的内存块。operator delete想弄清它要释放的内存有多大，就必须知道当初operator new 分配的内存有多大。有一种常用的方法可以让operator new来告诉operator delete当初分配的内存大小是多少，就是在它所返回的内存里预先附带一些额外信息，用来指明被分配的内存块的大小。也就是说，当你写了下面的语句，
airplane *pa = new airplane;
你不会得到一块看起来象这样的内存块：
pa——> airplane对象的内存
而是得到象这样的内存块：
pa——> 内存块大小数据 + airplane对象的内存
对于象airplane这样很小的对象来说，这些额外的数据信息会使得动态分配对象时所需要的的内存的大小翻番（特别是类里没有虚拟函数的时候）。
如果软件运行在一个内存很宝贵的环境中，就承受不起这种奢侈的内存分配方案了。为airplane类专门写一个operator new，就可以利用每个airplane的大小都相等的特点，不必在每个分配的内存块上加上附带信息了。
具体来说，有这样一个方法来实现你的自定义的operator new：先让缺省operator new分配一些大块的原始内存，每块的大小都足以容纳很多个airplane 对象。airplane对象的内存块就取自这些大的内存块。当前没被使用的内存块被组织成链表——称为自由链表——以备未来airplane使用。听起来好象每个对象都要承担一个next域的开销（用于支持链表），但不会：rep域的空间也被用来存储next指针（因为只是作为airplane对象来使用的内存块才需要rep 指针；同样，只有没作为airplane对象使用的内存块才需要next指针），这可以用union来实现。
具体实现时，就要修改airplane的定义，从而支持自定义的内存管理。可以这么做：
class airplane { // 修改后的类—支持自定义的内存管理public: //
static void * operator new(size_t size);
...
private:
union {
airplanerep *rep; // 用于被使用的对象
airplane *next; // 用于没被使用的（在自由链表中）对象
};
// 类的常量，指定一个大的内存块中放多少个
// airplane对象，在后面初始化
static const int block_size;
static airplane *headoffreelist;
};
上面的代码增加了的几个声明：一个operator new函数，一个联合（使得rep 和next域占用同样的空间），一个常量（指定大内存块的大小），一个静态指针（跟踪自由链表的表头）。表头指针声明为静态成员很重要，因为整个类只有一个自由链表，而不是每个airplane对象都有。
下面该写operator new函数了：
void * airplane::operator new(size_t size)
{
// 把“错误”大小的请求转给::operator new()处理;
// 详见条款8
if (size != sizeof(airplane))
return ::operator new(size);
airplane *p = // p指向自由链表的表头
headoffreelist; //
// p 若合法，则将表头移动到它的下一个元素
//
if (p)
headoffreelist = p->next;
else {
// 自由链表为空，则分配一个大的内存块，
// 可以容纳block_size个airplane对象
airplane *newblock =
static_cast
sizeof(airplane)));
// 将每个小内存块链接起来形成一个新的自由链表
// 跳过第0个元素，因为它要被返回给operator new的调用者
//
for (int i = 1; i < block_size-1; ++i)
newblock[i].next = &newblock[i+1];
// 用空指针结束链表
newblock[block_size-1].next = 0;
// p 设为表的头部，headoffreelist指向的
// 内存块紧跟其后
p = newblock;
headoffreelist = &newblock[1];
}
return p;
}
如果你读了条款8，就会知道在operator new不能满足内存分配请求时，会执行一系列与new-handler函数和例外有关的例行性动作。上面的代码没有这些步骤，这是因为operator new管理的内存都是从::operator new分配来的。这意味着只有::operator new失败时，operator new才会失败。而如果::operator new 失败，它会去执行new-handler的动作（可能最后以抛出异常结束），所以不需要airplane的operator new也去处理。换句话说，其实new-handler的动作都还在，你只是没看见，它隐藏在::operator new里。
有了operator new，下面要做的就是给出airplane的静态数据成员的定义：
airplane *airplane::headoffreelist;
const int airplane::block_size = 512;
没必要显式地将headoffreelist设置为空指针，因为静态成员的初始值都被缺省设为0。block_size决定了要从::operator new获得多大的内存块。
这个版本的operator new将会工作得非常好。它为airplane对象分配的内存要比缺省operator new更少，而且运行得更快，可能会快2次方的等级。这没什么奇怪的，通用型的缺省operator new必须应付各种大小的内存请求，还要处理内部外部的碎片；而你的operator new只用操作链表中的一对指针。抛弃灵活性往往可以很容易地换来速度。
下面我们将讨论operator delete。还记得operator delete吗？本条款就是关于operator delete的讨论。但直到现在为止，airplane类只声明了operator new，还没声明operator delete。想想如果写了下面的代码会发生什么:
airplane *pa = new airplane; // 调用
// airplane::operator new
...
delete pa; // 调用 ::operator delete
读这段代码时，如果你竖起耳朵，会听到飞机撞毁燃烧的声音，还有程序员的哭泣。问题出在operator new（在airplane里定义的那个）返回了一个不带头信息的内存的指针，而operator delete（缺省的那个）却假设传给它的内存包含头信息。这就是悲剧产生的原因。
这个例子说明了一个普遍原则：operator new和operator delete必须同时写，这样才不会出现不同的假设。如果写了一个自己的内存分配程序，就要同时写一个释放程序。（关于为什么要遵循这条规定的另一个理由，参见article on counting objects一文的the sidebar on placement章节）
因而，继续设计airplane类如下：
class airplane { // 和前面的一样，只不过增加了一个
public: // operator delete的声明
...
static void operator delete(void *deadobject,
size_t size);
};
// 传给operator delete的是一个内存块, 如果
// 其大小正确，就加到自由内存块链表的最前面
//
void airplane::operator delete(void *deadobject,
size_t size)
{
if (deadobject == 0) return; // 见条款 8
if (size != sizeof(airplane)) { // 见条款 8
::operator delete(deadobject);
return;
}
操作系统内存管理
操作系统内存管理 1. 内存管理方法 内存管理主要包括虚地址、地址变换、内存分配和回收、内存扩充、内存共享和保护等功能。 2. 连续分配存储管理方式 连续分配是指为一个用户程序分配连续的内存空间。连续分配有单一连续存储管理和分区式储管理两种方式。 2.1 单一连续存储管理 在这种管理方式中，内存被分为两个区域：系统区和用户区。应用程序装入到用户区，可使用用户区全部空间。其特点是，最简单，适用于单用户、单任务的操作系统。CP／M和 DOS 2．0以下就是采用此种方式。这种方式的最大优点就是易于管理。但也存在着一些问题和不足之处，例如对要求内
存空间少的程序，造成内存浪费；程序全部装入，使得很少使用的程序部分也占用—定数量的内存。 2.2 分区式存储管理 为了支持多道程序系统和分时系统，支持多个程序并发执行，引入了分区式存储管理。分区式存储管理是把内存分为一些大小相等或不等的分区，操作系统占用其中一个分区，其余的分区由应用程序使用，每个应用程序占用一个或几个分区。分区式存储管理虽然可以支持并发，但难以进行内存分区的共享。 分区式存储管理引人了两个新的问题：内碎片和外碎片。 内碎片是占用分区内未被利用的空间，外碎片是占用分区之间难以利用的空闲分区(通常是小空闲分区)。 为实现分区式存储管理，操作系统应维护的数据结构为分区表或分区链表。表中各表项一般包括每个分区的起始地址、大小及状态(是否已分配)。
分区式存储管理常采用的一项技术就是内存紧缩(compaction)。 2.2.1 固定分区(nxedpartitioning)。 固定式分区的特点是把内存划分为若干个固定大小的连续分区。分区大小可以相等：这种作法只适合于多个相同程序的并发执行(处理多个类型相同的对象)。分区大小也可以不等：有多个小分区、适量的中等分区以及少量的大分区。根据程序的大小，分配当前空闲的、适当大小的分区。 优点：易于实现，开销小。 缺点主要有两个：内碎片造成浪费；分区总数固定，限制了并发执行的程序数目。 2.2.2动态分区(dynamic partitioning)。 动态分区的特点是动态创建分区：在装入程序时按其初始要求分配，或在其执行过程中通过系统调用进行分配或改变分区大小。与固定分区相比较其优点是：没有内碎
两种常见的内存管理方法：堆和内存池 本文导读 在程序运行过程中，可能产生一些数据，例如，串口接收的数据，ADC采集的数据。若需将数据存储在内存中，以便进一步运算、处理，则应为其分配合适的内存空间，数据处理完毕后，再释放相应的内存空间。为了便于内存的分配和释放，AWorks提供了两种内存管理工具：堆和内存池。 本文为《面向AWorks框架和接口的编程（上）》第三部分软件篇——第9章内存管理——第1~2小节：堆管理器和内存池。 本章导读 在计算机系统中，数据一般存放在内存中，只有当数据需要参与运算时，才从内存中取出，交由CPU运算，运算结束再将结果存回内存中。这就需要系统为各类数据分配合适的内存空间。 一些数据需要的内存大小在编译前可以确定。主要有两类：一类是全局变量或静态变量，这部分数据在程序的整个生命周期均有效，在编译时就为这些数据分配了固定的内存空间，后续直接使用即可，无需额外的管理；一类是局部变量，这部分数据仅在当前作用域中有效（如函数中），它们需要的内存自动从栈中分配，也无需额外的管理，但需要注意的是，由于这一部分数据的内存从栈中分配，因此，需要确保应用程序有足够的栈空间，尽量避免定义内存占用较大的局部变量（比如：一个占用数K内存的数组），以避免栈溢出，栈溢出可能破坏系统关键数据，极有可能造成系统崩溃。 一些数据需要的内存大小需要在程序运行过程中根据实际情况确定，并不能在编译前确定。例如，可能临时需要1K内存空间用于存储远端通过串口发过来的数据。这就要求系统具有对内存空间进行动态管理的能力，在用户需要一段内存空间时，向系统申请，系统选择一段合适的内存空间分配给用户，用户使用完毕后，再释放回系统，以便系统将该段内存空间回收再利用。在AWorks中，提供了两种常见的内存管理方法：堆和内存池。9.1 堆管理器
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。 了解系统内存被分配到了什么地方，系统在什么情况下进行内存整理是系统管理的重
一页式管理 1 页式管理的基本原理将各进程的虚拟空间划分成若干个长度相等的页(page)，页式管理把内存空间按页的大小划分成片或者页面（page frame），然后把页式虚拟地址与内存地址建立一一对应页表，并用相应的硬件地址变换机构，来解决离散地址变换问题。页式管理采用请求调页或预调页技术实现了内外存存储器的统一管理。 它分为 1 静态页式管理。静态分页管理的第一步是为要求内存的作业或进程分配足够的页面。系统通过存储页面表、请求表以及页表来完成内存的分配工作。静态页式管理解决了分区管理时的碎片问题。但是，由于静态页式管理要求进程或作业在执行前全部装入内存，如果可用页面数小于用户要求时，该作业或进程只好等待。而且作业和进程的大小仍受内存可用页面数的限制。 2 动态页式管理。动态页式管理是在静态页式管理的基础上发展起来的。它分为请求页式管理和预调入页式管理。 优点：没有外碎片，每个内碎片不超过页大小。一个程序不必连续存放。便于改变程序占用空间的大小（主要指随着程序运行而动态生成的数据增多，要求地址空间相应增长，通常由系统调用完成而不是操作系统自动完成）。 缺点：程序全部装入内存。 要求有相应的硬件支持。例如地址变换机构，缺页中断的产生和选择淘汰页面等都要求有相应的硬件支持。这增加了机器成本。增加了系统开销，例如缺页中断处理机，请求调页的算法如选择不当，有可能产生抖动现象。虽然消除了碎片，但每个作业或进程的最后一页内总有一部分空间得不到利用果页面较大，则这一部分的损失仍然较大。 二段式管理的基本思想 把程序按内容或过程（函数）关系分成段，每段有自己的名字。一个用户作业或进程所包含的段对应一个二维线形虚拟空间，也就是一个二维虚拟存储器。段式管理程序以段为单位分配内存，然后通过地址影射机构把段式虚拟地址转换为实际内存物理地址。 程序通过分段(segmentation)划分为多个模块，如代码段、数据段、共享段。其优点是：可以分别编写和编译。可以针对不同类型的段采取不同的保护。可以按段为单位来进行共享，包括通过动态链接进行代码共享。 三段页式管理的实现原理 1 虚地址的构成 一个进程中所包含的具有独立逻辑功能的程序或数据仍被划分为段，并有各自的段号s。这反映相继承了段式管理的特征。其次，对于段s中的程序或数据，则按照一定的大小将其划分为不同的页。和页式系统一样，最后不足一页的部分仍占一页。这反映了段页式管理中的页式特征。从而，段页式管理时的进程的虚拟地址空间中的虚拟地址由三部分组成：即段号s，页号P和页内相对地址d。虚拟空间的最小单位是页而不是段，从而内存可用区也就被划分成为着干个大小相等的页面，且每段所拥有的程序和数据在内存中可以分开存放。分段的大小也不再受内存可用区的限制。 2 段表和页表
一、 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新生代，正常情况下新创建的对象会被分配到新生代，但如果对象占据的内存足够大以致超过了新生代的容量限 制，也可能被分配到老年代；新生代对象的一个特点是最 新、且生命周期不长，被回收的可能性高；
第7章内存管理 复习题： 7.1.内存管理需要满足哪些需求？ 答：重定位、保护、共享、逻辑组织和物理组织。 7.2.为什么需要重定位进程的能力？ 答：通常情况下，并不能事先知道在某个程序执行期间会有哪个程序驻留在主存中。 此外还希望通过提供一个巨大的就绪进程池，能够把活动进程换入和换出主存，以便使处理器的利用率最大化。在这两种情况下，进程在主存中的确切位置是不可预知的。 7.3.为什么不可能在编译时实施内存保护？ 答：由于程序在主存中的位置是不可预测的，因而在编译时不可能检查绝对地址来确保保护。并且，大多数程序设计语言允许在运行时进行地址的动态计算（例如，通过计算数组下标或数据结构中的指针）。因此，必须在运行时检查进程产生的所有存储器访问，以便确保它们只访问了分配给该进程的存储空间。 7.4.允许两个或多个进程访问进程的某一特定区域的原因是什么？ 答：如果许多进程正在执行同一程序，则允许每个进程访问该程序的同一个副本要比让每个进程有自己单独的副本更有优势。同样，合作完成同一任务的进程可能需要共享访问同一个数据结构。 7.5.在固定分区方案中，使用大小不等的分区有什么好处？ 答：通过使用大小不等的固定分区：1.可以在提供很多分区的同时提供一到两个非常大的分区。大的分区允许将很大的进程全部载入主存中。2.由于小的进程可以被放入小的分区中，从而减少了内部碎片。 7.6.内部碎片和外部碎片有什么区别？ 答：内部碎片是指由于被装入的数据块小于分区大小而导致的分区内部所浪费的空间。外部碎片是与动态分区相关的一种现象，它是指在所有分区外的存储空间会变成越来越多的碎片的。 7.7.逻辑地址、相对地址和物理地址间有什么区别？ 答：逻辑地址是指与当前数据在内存中的物理分配地址无关的访问地址，在执行对内存的访问之前必须把它转化成物理地址。相对地址是逻辑地址的一个特例，是相对于某些已知点（通常是程序的开始处）的存储单元。物理地址或绝对地址是数据在主存中的实际位置。 7.8.页和帧之间有什么区别？ 答：在分页系统中，进程和磁盘上存储的数据被分成大小固定相等的小块，叫做页。 而主存被分成了同样大小的小块，叫做帧。一页恰好可以被装入一帧中。 7.9.页和段之间有什么区别？ 答：分段是细分用户程序的另一种可选方案。采用分段技术，程序和相关的数据被划分成一组段。尽管有一个最大段长度，但并不需要所有的程序的所有段的长度都相等。习题： 7.1. 2.3节中列出了内存管理的5个目标，7.1节中列出了5中需求。请说明它们是一致 的。 答: 重定位≈支持模块化程序设计; 保护≈保护和访问控制以及进程隔离; 共享≈保护和访问控制; 逻辑组织≈支持模块化程序设计; 物理组织≈长期存储及自动分配和管理.
全面介绍Windows内存管理机制及C++内存分配实例 文章整理: https://www.doczj.com/doc/4b9341854.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高速缓存、非页面内存池的分配、进程目表和页表等。 例子： 这段地址各进程是可以共享的。
Windows内存管理机制 在编程中，很多Windows或C++的内存函数不知道有什么区别，更别谈有效使用；根本的原因是，没有清楚的理解操作系统的内存管理机制，本文企图通过简单的总结描述，结合实例来阐明这个机制。 本文目的： 对Windows内存管理机制了解清楚，有效的利用C++内存函数管理和使用内存。 本文内容： 本文一共有六节，由于篇幅较多，故按节发表。其他章节请看本人博客的Windows内存管理及C++内存分配实例（一）（二）（三）（四）和（五）。 1. 进程地址空间 2.内存状态查询函数 3.内存管理机制--虚拟内存 (VM) 4.内存管理机制--内存映射文件 (Map) 5.内存管理机制--堆 (Heap) 使用场合 操作系统为每个线程都建立一个默认堆栈，大小为1M。这个堆栈是供函数调用时使用，线程内函数里的各种静态变量都是从这个默认堆栈里分配的。
堆栈结构 默认1M的线程堆栈空间的结构举例如下，其中，基地址为0x0004 0000，刚开始时，CPU的堆栈指针寄存器保存的是栈顶的第一个页面地址 0x0013 F000。第二页面为保护页面。这两页是已经分配物理存储器的可用页面。 随着函数的调用，系统将需要更多的页面，假设需要另外5页，则给这5页提交内存，删除原来页面的保护页面属性，最后一页赋予保护页面属性。 当分配倒数第二页0x0004 1000时，系统不再将保护属性赋予它，相反，它会产生堆栈溢出异常STATUS_STACK_OVERFLOW，如果程序没有处理它，则线程将退出。最后一页始终处于保留状态，也就是说可用堆栈数是没有1M的，之所以不用，是防止线程破坏栈底下面的内存（通过违规访问异常达到目的）。
内存分段和请求式分页 在深入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位指针来寻址所有的代码和数据，而不需要分段。在内部，当然，分段仍然在起作用，就像我在前面提及的那样。不过管理段的所有责任都被移给了操作系统。
存储管理的基本原理 内存管理方法 内存管理主要包括内存分配和回收、地址变换、内存扩充、内存共享和保护等功能。 下面主要介绍连续分配存储管理、覆盖与交换技术以及页式与段式存储管理等基本概念和原理。 1．连续分配存储管理方式 连续分配是指为一个用户程序分配连续的内存空间。连续分配有单一连续存储管理和分区式储管理两种方式。 (1)单一连续存储管理 在这种管理方式中，内存被分为两个区域：系统区和用户区。应用程序装入到用户区，可使用用户区全部空间。其特点是，最简单，适用于单用户、单任务的操作系统。CP／M和DOS 2．0以下就是采用此种方式。这种方式的最大优点就是易于管理。但也存在着一些问题和不足之处，例如对要求内存空间少的程序，造成内存浪费；程序全部装入，使得很少使用的程序部分也占用—定数量的内存。 (2)分区式存储管理 为了支持多道程序系统和分时系统，支持多个程序并发执行，引入了分区式存储管理。分区式存储管理是把内存分为一些大小相等或不等的分区，操作系统占用其中一个分区，其余的分区由应用程序使用，每个应用程序占用一个或几个分区。分区式存储管理虽然可以支持并发，但难以进行内存分区的共享。 分区式存储管理引人了两个新的问题：内碎片和外碎片。前者是占用分区内未被利用的空间，后者是占用分区之间难以利用的空闲分区(通常是小空闲分区)。为实现分区式存储管理，操作系统应维护的数据结构为分区表或分区链表。表中各表项一般包括每个分区的起始地址、大小及状态(是否已分配)。 分区式存储管理常采用的一项技术就是内存紧缩(compaction)：将各个占用分区向内存一端移动，然后将各个空闲分区合并成为一个空闲分区。这种技术在提供了某种程度上的灵活性的同时，也存在着一些弊端，例如：对占用分区进行内存数据搬移占用CPU~t寸间；如果对占用分区中的程序进行“浮动”，则其重定位需要硬件支持。 1)固定分区(nxedpartitioning)。 固定式分区的特点是把内存划分为若干个固定大小的连续分区。分区大小可以相等：这种作法只适合于多个相同程序的并发执行(处理多个类型相同的对象)。分区大小也可以不等：有多个小分区、适量的中等分区以及少量的大分区。根据程序的大小，分配当前空闲的、适当大小的分区。这种技术的优点在于，易于实现，开销小。缺点主要有两个：内碎片造成浪费；分区总数固定，限制了并发执行的程序数目。 2)动态分区(dynamic partitioning)。 动态分区的特点是动态创建分区：在装入程序时按其初始要求分配，或在其执行过程中通过系统调用进行分配或改变分区大小。与固定分区相比较其优点是：没有内碎片。但它却引入了另一种碎片——外碎片。动态分区的分区分配就是寻找某个空闲分区，其大小需大于或等于程序
本文背景： 在编程中，很多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<<"没有那么多虚拟空间!"< 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）。内存管理以及内存管理单元简介(MMU)
相关主题
文本预览