bound_error（"overlappingregionsinmemcpy（）"）;
returnmemcpy（dst,src,size）;
}
从调试器的角度
现在有OS的支持，实现一个调试器变得非常简单，至少原理不再神秘。
这里我们简要介绍一下win32和linux中的调试器实现原理。
在Win32下，实现调试器主要通过两个函数：
WaitForDebugEvent和ContinueDebugEvent。
下面是一个调试器的基本模型（源于:
《DebuggingApplicationsforMicrosoft.NETandMicrosoftWindows》）
voidmain（void）
{
CreateProcess（...,DEBUG_ONLY_THIS_PROCESS,...）;
while（1==WaitForDebugEvent（...））
{
if（EXIT_PROCESS）
{
break;
}
ContinueDebugEvent（...）;
}
}
由调试器起动被调试的进程，并指定DEBUG_ONLY_THIS_PROCESS标志。
按Win32下事件驱动的一贯原则，由被调试的进程主动上报调试事件，调试器然后做相应的处理。
在linux下，实现调试器只要一个函数就行了：
ptrace。
下面是个简单示例：
（源于《Playingwithptrace》）。
#include
#include
#include
#include
#include/*Foruser_regs_struct
etc.*/
intmain（intargc,char*argv[]）
{pid_ttraced_process;
structuser_regs_structregs;
longins;
if（argc!
=2）{
printf（"Usage:
%s\n",
argv[0],argv[1]）;
exit
（1）;
}
traced_process=atoi（argv[1]）;
ptrace（PTRACE_ATTACH,traced_process,
NULL,NULL）;
wait（NULL）;
ptrace（PTRACE_GETREGS,traced_process,
NULL,®s）;
ins=ptrace（PTRACE_PEEKTEXT,traced_process,
regs.eip,NULL）;
printf（"EIP:
%lxInstructionexecuted:
%lx\n",
regs.eip,ins）;
ptrace（PTRACE_DETACH,traced_process,
NULL,NULL）;
return0;
}
由于篇幅有限，这里对于调试器的实现不作深入讨论，主要是给新手指一个方向。
以后若有时间，再写个专题来介绍linux下的调试器和ptrace本身的实现方法。
大内高手—惯用手法
《POSA》中根据模式粒度把模式分为三类：
架构模式、设计模式和惯用手法。
其中把分层模式、管道过滤器和微内核模式等归为架构模式，把代理模式、命令模式和出版-订阅模式等归为设计模式，而把引用计数等归为惯用手法。
这三类模式间的界限比较模糊，在特定的情况，有的设计模式可以作为架构模式来用，有的把架构模式也作为设计模式来用。
在通常情况下，我们可以说架构模式、设计模式和惯用手法，三者的重要性依次递减，毕竟整体决策比局部决策的影响面更大。
但是任何整体都是局部组成的，局部的决策也会影响全局。
惯用手法的影响虽然是局部的，其作用仍然很重要。
它不但在提高软件的质量方面，而且在加快软件开发进度方面都有很大贡献。
本文介绍几种关于内存的惯用手法，这些手法对于老手来说已经习以为常，对于新手来说则是必修秘技。
1.预分配
假想我们实现了一个动态数组（vector）时，当向其中增加元素时，它会自动扩展（缩减）缓冲区的大小，无需要调用者关心。
扩展缓冲区的大小的原理都是一样的：
l先分配一块更大的缓冲区。
l把数据从老的缓冲区拷贝到新的缓冲区。
l释放老的缓冲区。
如果你使用realloc来实现，内存管理器可能会做些优化：
如果老的缓冲区后面有连续的空闲空间，它只需要简单的扩展老的缓冲区，而跳过后面两个步骤。
但在大多数情况下，它都要通过上述三个步骤来完成扩展。
以此可见，扩展缓冲区对调用者来说虽然是透明的，但决不是免费的。
它得付出相当大的时间代价，以及由此产生的产生内存碎片问题。
如果每次向vector中增加一个元素，都要扩展缓冲区，显然是不太合适的。
此时我们可以采用预分配机制，每次扩展时，不是需要多大就扩展多大，而是预先分配一大块内存。
这一大块可以供后面较长一段时间使用，直到把这块内存全用完了，再继续用同样的方式扩展。
预分配机制比较常见，多见于一些带buffer的容器实现中，比如像vector和string等。
2.对象引用计数
在面向对象的系统中，对象之间的协作关系非常复杂。
所谓协作其实就调用对象的函数或者向对象发送消息，但不管调用函数还是发送消息，总是要通过某种方式知道目标对象才行。
而最常见的做法就是保存目标对象的引用（指针），直接引用对象而不是拷贝对象，提高了时间和空间上的效率，也避免了拷贝对象的麻烦，而且有的地方就是要对象共享才行。
对象被别人引用了，但自己可能并不知道。
此时麻烦就来了，如果对象被释放了，对该对象的引用就变成了野针，系统随时可能因此而崩溃。
不释放也不行，因为那样会出现内存泄露。
怎么办呢？
此时我们可以采用对象引用计数，对象有一个引用计数器，不管谁要引用这个对象，就要把对象的引用计数器加1，如果不再该引用了，就把对象的引用计数器减1。
当对象的引用计数器被减为0时，说明没有其它对象引用它，该对象就可以安全的释放了。
这样，对象的生命周期就得到了有效的管理。
对象引用计数运用相当广泛。
像在COM和glib里，都是作为对象系统的基本设施之一。
即使在像JAVA和C#等现代语言中，对象引用计数也是非常重要的，它是实现垃圾回收（GC）的基本手段之一。
代码示例:
（atlcom.h:
CcomObject）
STDMETHOD_（ULONG,AddRef）（）{returnInternalAddRef（）;}
STDMETHOD_（ULONG,Release）（）
{
ULONGl=InternalRelease（）;
if（l==0）
deletethis;
returnl;
}
3.写时拷贝（COW）
OS内核创建子进程的过程是最常见而且最有效的COW例子：
创建子进程时，子进程要继承父进程内存空间中的数据。
但继承之后，两者各自有独立的内存空间，修改各自的数据不会互相影响。
要做到这一点，最简单的办法就是直接把父进程的内存空间拷贝一份。
这样做可行，但问题在于拷贝内容太多，无论是时间还是空间上的开销都让人无法接受。
况且，在大多数情况下，子进程只会使用少数继承过来的数据，而且多数是读取，只有少量是修改，也就说大部分拷贝的动作白做了。
怎么办呢？
此时可以采用写时拷贝（COW），COW代表CopyonWrite。
最初的拷贝只是个假象，并不是真正的拷贝，只是把引用计数加1，并设置适当的标志。
如果双方都只是读取这些数据，那好办，直接读就行了。
而任何一方要修改时，为了不影响另外一方，它要把数据拷贝一份，然后修改拷贝的这一份。
也就是说在修改数据时，拷贝动作才真正发生。
当然，在真正拷贝的时候，你可以选择只拷贝修改的那一部分，或者拷贝全部数据。
在上面的例子中，由于内存通常是按页面来管理的，拷贝时只拷贝相关的页面，而不是拷贝整个内存空间。
写时拷贝（COW）对性能上的贡献很大，差不多任何带MMU的OS都会采用。
当然它不限于内核空间，在用户空间也可以使用，比如像一些String类的实现也采用了这种方法。
代码示例（MFC:
strcore.cpp）：
拷贝时只是增加引用计数：
CString:
:
CString（constCString&stringSrc）
{
ASSERT（stringSrc.GetData（）->nRefs!
=0）;
if（stringSrc.GetData（）->nRefs>=0）
{
ASSERT（stringSrc.GetData（）!
=_afxDataNil）;
m_pchData=stringSrc.m_pchData;
InterlockedIncrement（&GetData（）->nRefs）;
}
else
{
Init（）;
*this=stringSrc.m_pchData;
}
}
修改前才拷贝：
voidCString:
:
MakeUpper（）
{
CopyBeforeWrite（）;
_tcsupr（m_pchData）;
}
voidCString:
:
MakeLower（）
{
CopyBeforeWrite（）;
_tcslwr（m_pchData）;
}
拷贝动作：
voidCString:
:
CopyBeforeWrite（）
{
if（GetData（）->nRefs>1）
{
CStringData*pData=GetData（）;
Release（）;
AllocBuffer（pData->nDataLength）;
memcpy（m_pchData,pData->data（）,（pData->nDataLength+1）*sizeof（TCHAR））;
}
ASSERT（GetData（）->nRefs<=1）;
}
4.固定大小分配
频繁的分配大量小块内存是内存管理器的挑战之一。
首先是空间利用率上的问题：
由于内存管理本身的需要一些辅助内存，假设每块内存需要8字节用作辅助内存，那么即使只要分配4个字节这样的小块内存，仍然要浪费8字节内存。
一块小内存不要紧，若存在大量小块内存，所浪费的空间就可观了。
其次是内存碎片问题：
频繁分配大量小块内存，很容易造成内存碎片问题。
这不但降低内存管理器的效率，同时由于这些内存不连续，虽然空闲却无法使用。
此时可以采用固定大小分配，这种方式通常也叫做缓冲池（pool）分配。
缓冲池（pool）先分配一块或者多块连续的大块内存，把它们分成N块大小相等的小块内存，然后进行二次分配。
由于这些小块内存大小是固定的，管理大开销非常小，往往只要一个标识位用于标识该单元是否空闲，或者甚至不需要任何标识位。
另外，缓冲池（pool）中所有这些小块内存分布在一块或者几块连接内存上，所以不会有内存碎片问题。
固定大小分配运用比较广泛，差不多所有的内存管理器都用这种方法来对付小块内存，比如glibc、STLPort和linux的slab等。
5.会话缓冲池分配（SessionPool）
服务器要长时间运行，内存泄露是它的威胁之一，任何小概率的内存泄露，都可能会累积到具有破坏性的程度。
从它们的运行模式来看，它们总是不断的重复某个过程，而在这个过程中，又要分配大量（次数）内存。
比如像WEB服务器，它不断的处理HTTP请求，我们把一次HTTP请求，称为一次会话。
一次会话要经过很多阶段，在这个过程要做各种处理，要多次分配内存。
由于处理比较复杂，分配内存的地方又比较多，内存泄露可以说防不甚防。
针对这种情况，我们可以采用会话缓冲池分配。
它基于多次分配一次释放的策略，在过程开始时创建会话缓冲池（SessionPool），这个过程中所有内存分配都通过会话缓冲池（SessionPool）来分配，当这个过程完成时，销毁掉会话缓冲池（SessionPool），即释放这个过程中所分配的全部内存。
因为只需要释放一次，内
升级会员 