Loading...

当前位置:资讯中心主页 >Linux >文章内容

  • 内存管理内幕
  • 来源: ChinaUnix博客  作者: 发布时间:2007-01-02 03:44:00
    • 域名注册

    • 域名惊喜价格 cn域名1元注册
    • com域名39.9

      虚拟主机

    • 主机按月支付,低至19元/月
    • 超大流量,可开子站点

      VPS主机

    • 特惠VPS168元/月,4-8M独享带宽保证
    • 独立操作系统,无限开站点

    动态分配的选择、折衷和实现
    级别: 中级
    Jonathan Bartlett

    johnnyb@eskimo.com

    技术总监, New Media Worx
    2004 年 11 月
    本文将对 Linux™ 程式员能使用的内存管理技术进行概述,虽然关注的重点是 C 语言,但同样也适用于其他语言。文中将为你提供怎么管理内存的细节,然后将进一步展示怎么手工管理内存,怎么使用引用计数或内存池来半手工地管理内存,及怎么使用垃圾收集自动管理内存。
    为什么必须管理内存
    内存管理是计算机编程最为基本的领域之一。在非常多脚本语言中,你不必担心内存是怎么管理的,这并不能使得内存管理的重要性有一点点降低。对实际编程来说,理解你的内存管理器的能力和局限性至关重要。在大部分系统语言中,比如 C 和 C++,你必须进行内存管理。本文将介绍手工的、半手工的及自动的内存管理实践的基本概念。
    追溯到在 Apple II 上进行汇编语言编程的时代,那时内存管理还不是个大问题。你实际上在运行整个系统。系统有多少内存,你就有多少内存。你甚至不必费心思去弄明白他有多少内存,因为每一台机器的内存数量都相同。所以,如果内存需要非常固定,那么你只需要选择一个内存范围并使用他即可。
    不过,即使是在这样一个简单的计算机中,你也会有问题,尤其是当你不知道程式的每个部分将需要多少内存时。如果你的空间有限,而内存需求是变化的,那么你需要一些方法来满足这些需求:

    • 确定你是否有足够的内存来处理数据。
    • 从可用的内存中获取一部分内存。
    • 向可用内存池(pool)中返回部分内存,以使其能由程式的其他部分或其他程式使用。


    实现这些需求的程式库称为分配程式(allocators),因为他们负责分配和回收内存。程式的动态性越强,内存管理就越重要,你的内存分配程式的选择也就更重要。让我们来了解可用于内存管理的不同方法,他们的好处和不足,及他们最适用的情形。
    C 风格的内存分配程式
    C 编程语言提供了两个函数来满足我们的三个需求:

    • malloc:该函数分配给定的字节数,并返回一个指向他们的指针。如果没有足够的可用内存,那么他返回一个空指针。
    • free:该函数获得指向由 malloc 分配的内存片段的指针,并将其释放,以便以后的程式或操作系统使用(实际上,一些 malloc 实现只能将内存归还给程式,而无法将内存归还给操作系统)。


    物理内存和虚拟内存
    要理解内存在程式中是怎么分配的,首先需要理解怎么将内存从操作系统分配给程式。计算机上的每一个进程都认为自己能访问所有的物理内存。显然,由于同时在运行多个程式,所以每个进程不可能拥有全部内存。实际上,这些进程使用的是虚拟内存。
    只是作为一个例子,让我们假定你的程式正在访问地址为 629 的内存。不过,虚拟内存系统不必将其存储在位置为 629 的 RAM 中。实际上,他甚至能不在 RAM 中 ?? 如果物理 RAM 已满了,他甚至可能已被转移到硬盘上!由于这类地址不必反映内存所在的物理位置,所以他们被称为虚拟内存。操作系统维持着一个虚拟地址到物理地址的转换的表,以便计算机硬件能正确地响应地址请求。并且,如果地址在硬盘上而不是在 RAM 中,那么操作系统将暂时停止你的进程,将其他内存转存到硬盘中,从硬盘上加载被请求的内存,然后再重新启动你的进程。这样,每个进程都获得了自己能使用的地址空间,能访问比你物理上安装的内存更多的内存。
    在 32-位 x86 系统上,每一个进程能访问 4 GB 内存。目前,大部分人的系统上并没有 4 GB 内存,即使你将 swap 也算上,每个进程所使用的内存也肯定少于 4 GB。因此,当加载一个进程时,他会得到一个取决于某个称为系统中断点(system break)的特定地址的初始内存分配。该地址之后是未被映射的内存 ?? 用于在 RAM 或硬盘中没有分配相应物理位置的内存。因此,如果一个进程运行超出了他初始分配的内存,那么他必须请求操作系统"映射进来(map in)"更多的内存。(映射是个表示一一对应关系的数学术语 ?? 当内存的虚拟地址有一个对应的物理地址来存储内存内容时,该内存将被映射。)
    基于 UNIX 的系统有两个可映射到附加内存中的基本系统调用:

    • brk:brk() 是个非常简单的系统调用。还记得系统中断点吗?该位置是进程映射的内存边界。brk() 只是简单地将这个位置向前或向后移动,就能向进程添加内存或从进程取走内存。
    • mmap:mmap(),或说是"内存映像",类似于 brk(),不过更为灵活。首先,他能映射所有位置的内存,而不单单只局限于进程。其次,他不仅能将虚拟地址映射到物理的 RAM 或 swap,他还能将他们映射到文件和文件位置,这样,读写内存将对文件中的数据进行读写。不过,在这里,我们只关心 mmap 向进程添加被映射的内存的能力。munmap() 所做的事情和 mmap() 相反。


    如你所见,brk() 或 mmap() 都能用来向我们的进程添加额外的虚拟内存。在我们的例子中将使用 brk(),因为他更简单,更通用。
    实现一个简单的分配程式
    如果你原来编写过非常多 C 程式,那么你可能曾多次使用过 malloc() 和 free()。不过,你可能没有用一些时间去思考他们在你的操作系统中是怎么实现的。本节将向你展示 malloc 和 free 的一个最简化实现的代码,来帮助说明管理内存时都涉及到了哪些事情。
    要试着运行这些示例,需要先
    复制本代码清单
    ,并将其粘贴到一个名为 malloc.c 的文件中。接下来,我将一次一个部分地对该清单进行解释。
    在大部分操作系统中,内存分配由以下两个简单的函数来处理:

    • void *malloc(long numbytes):该函数负责分配 numbytes 大小的内存,并返回指向第一个字节的指针。
    • void free(void *firstbyte):如果给定一个由先前的 malloc 返回的指针,那么该函数会将分配的空间归还给进程的"空闲空间"。

    malloc_init 将是初始化内存分配程式的函数。他要完成以下三件事:将分配程式标识为已初始化,找到系统中最后一个有效内存地址,然后建立起指向我们管理的内存的指针。这三个变量都是全局变量:
    清单 1. 我们的简单分配程式的全局变量
    int has_initialized = 0;
    void *managed_memory_start;
    void *last_valid_address;
    如前所述,被映射的内存的边界(最后一个有效地址)常被称为系统中断点或当前中断点。在非常多 UNIX® 系统中,为了指出当前系统中断点,必须使用 sbrk(0) 函数。sbrk 根据参数中给出的字节数移动当前系统中断点,然后返回新的系统中断点。使用参数 0 只是返回当前中断点。这里是我们的 malloc 初始化代码,他将找到当前中断点并初始化我们的变量:
    清单 2. 分配程式初始化函数
    /* Include the sbrk function */
    #include
    void malloc_init()
    {
            /* grab the last valid address from the OS */
            last_valid_address = sbrk(0);
            /* we don’t have any memory to manage yet, so
             *just set the beginning to be last_valid_address
             */
            managed_memory_start = last_valid_address;
            /* Okay, we’re initialized and ready to go */
            has_initialized = 1;
    }
    目前,为了完全地管理内存,我们需要能够追踪要分配和回收哪些内存。在对内存块进行了 free 调用之后,我们需要做的是诸如将他们标记为未被使用的等事情,并且,在调用 malloc 时,我们要能够定位未被使用的内存块。因此,malloc 返回的每块内存的起始处首先要有这个结构:
    清单 3. 内存控制块结构定义
    struct mem_control_block {
            int is_available;
            int size;
    };
    目前,你可能会认为当程式调用 malloc 时这会引发问题 ?? 他们怎么知道这个结构?答案是他们不必知道;在返回指针之前,我们会将其移动到这个结构之后,把他隐藏起来。这使得返回的指针指向没有用于所有其他用途的内存。那样,从调用程式的角度来看,他们所得到的全部是空闲的、开放的内存。然后,当通过 free() 将该指针传递回来时,我们只需要倒退几个内存字节就能再次找到这个结构。
    在讨论分配内存之前,我们将先讨论释放,因为他更简单。为了释放内存,我们必须要做的惟一一件事情就是,获得我们给出的指针,回退 sizeof(struct mem_control_block) 个字节,并将其标记为可用的。这里是对应的代码:
    清单 4. 解除分配函数
    void free(void *firstbyte) {
            struct mem_control_block *mcb;
            /* Backup from the given pointer to find the
             * mem_control_block
             */
            mcb = firstbyte - sizeof(struct mem_control_block);
            /* Mark the block as being available */
            mcb->is_available = 1;
            /* That’s It!  We’re done. */
            return;
    }
    如你所见,在这个分配程式中,内存的释放使用了一个非常简单的机制,在固定时间内完成内存释放。分配内存稍微困难一些。以下是该算法的略述:
    清单 5. 主分配程式的伪代码
    1. If our allocator has not been initialized, initialize it.
    2. Add sizeof(struct mem_control_block) to the size requested.
    3. start at managed_memory_start.
    4. Are we at last_valid address?
    5. If we are:
       A. We didn’t find any existing space that was large enough
          -- ask the operating system for more and return that.
    6. Otherwise:
       A. Is the current space available (check is_available from
          the mem_control_block)?
       B. If it is:
          i)   Is it large enough (check "size" from the
               mem_control_block)?
          ii)  If so:
               a. Mark it as unavailable
               b. Move past mem_control_block and return the
                  pointer
          iii) Otherwise:
               a. Move forward "size" bytes
               b. Go back go step 4
       C. Otherwise:
          i)   Move forward "size" bytes
          ii)  Go back to step 4
    我们主要使用连接的指针遍历内存来寻找开放的内存块。这里是代码:
    清单 6. 主分配程式
    void *malloc(long numbytes) {
            /* Holds where we are looking in memory */
            void *current_location;
            /* This is the same as current_location, but cast to a
             * memory_control_block
             */
            struct mem_control_block *current_location_mcb;
            /* This is the memory location we will return.  It will
             * be set to 0 until we find something suitable
             */
            void *memory_location;
            /* Initialize if we haven’t already done so */
            if(! has_initialized)         {
                    malloc_init();
            }
            /* The memory we search for has to include the memory
             * control block, but the users of malloc don’t need
             * to know this, so we’ll just add it in for them.
             */
            numbytes = numbytes + sizeof(struct mem_control_block);
            /* Set memory_location to 0 until we find a suitable
             * location
             */
            memory_location = 0;
            /* Begin searching at the start of managed memory */
            current_location = managed_memory_start;
            /* Keep going until we have searched all allocated space */
            while(current_location != last_valid_address)
            {
                    /* current_location and current_location_mcb point
                     * to the same address.  However, current_location_mcb
                     * is of the correct type, so we can use it as a struct.
                     * current_location is a void pointer so we can use it
                     * to calculate addresses.
                     */
                    current_location_mcb =
                            (struct mem_control_block *)current_location;
                    if(current_location_mcb->is_available)
                    {
                            if(current_location_mcb->size >= numbytes)
                            {
                                    /* Woohoo!  We’ve found an open,
                                     * appropriately-size location.
                                     */
                                    /* It is no longer available */
                                    current_location_mcb->is_available = 0;
                                    /* We own it */
                                    memory_location = current_location;
                                    /* Leave the loop */
                                    break;
                            }
                    }
                    /* If we made it here, it’s because the Current memory
                     * block not suitable; move to the next one
                     */
                    current_location = current_location +
                            current_location_mcb->size;
            }
            /* If we still don’t have a valid location, we’ll
             * have to ask the operating system for more memory
             */
            if(! memory_location)
            {
                    /* Move the program break numbytes further */
                    sbrk(numbytes);
                    /* The new memory will be where the last valid
                     * address left off
                     */
                    memory_location = last_valid_address;
                    /* We’ll move the last valid address forward
                     * numbytes
                     */
                    last_valid_address = last_valid_address + numbytes;
                    /* We need to initialize the mem_control_block */
                    current_location_mcb = memory_location;
                    current_location_mcb->is_available = 0;
                    current_location_mcb->size = numbytes;
            }
            /* Now, no matter what (well, except for error conditions),
             * memory_location has the address of the memory, including
             * the mem_control_block
             */
            /* Move the pointer past the mem_control_block */
            memory_location = memory_location + sizeof(struct mem_control_block);
            /* Return the pointer */
            return memory_location;
    }
    这就是我们的内存管理器。目前,我们只需要构建他,并在程式中使用他即可。
    运行下面的命令来构建 malloc 兼容的分配程式(实际上,我们忽略了 realloc() 等一些函数,不过,malloc() 和 free() 才是最主要的函数):
    清单 7. 编译分配程式
    gcc -shared -fpic malloc.c -o malloc.so
    该程式将生成一个名为 malloc.so 的文件,他是个包含有我们的代码的共享库。
    在 UNIX 系统中,目前你能用你的分配程式来取代系统的 malloc(),做法如下:
    清单 8. 替换你的标准的 malloc
    LD_PRELOAD=/path/to/malloc.so
    export LD_PRELOAD
    LD_PRELOAD 环境变量使动态链接器在加载所有可执行程式之前,先加载给定的共享库的符号。他还为特定库中的符号赋予优先权。因此,从目前起,该会话中的所有应用程式都将使用我们的 malloc(),而不是只有系统的应用程式能够使用。有一些应用程式不使用 malloc(),不过他们是例外。其他使用 realloc() 等其他内存管理函数的应用程式,或错误地假定 malloc() 内部行为的那些应用程式,非常可能会崩溃。ash shell 似乎能使用我们的新 malloc() 非常好地工作。
    如果你想确保 malloc() 正在被使用,那么你应该通过向函数的入口点添加 write() 调用来进行测试。
    我们的内存管理器在非常多方面都还存在欠缺,但他能有效地展示内存管理需要做什么事情。他的某些缺点包括:

    • 由于他对系统中断点(一个全局变量)进行操作,所以他不能和其他分配程式或 mmap 一起使用。
    • 当分配内存时,在最坏的情形下,他将不得不遍历全部进程内存;其中可能包括位于硬盘上的非常多内存,这意味着操作系统将不得不花时间去向硬盘移入数据和从硬盘中移出数据。
    • 没有非常好的内存不足处理方案(malloc 只假定内存分配是成功的)。
    • 他没有实现非常多其他的内存函数,比如 realloc()。
    • 由于 sbrk() 可能会交回比我们请求的更多的内存,所以在堆(heap)的末端会遗漏一些内存。
    • 虽然 is_available 标记只包含一位信息,但他要使用完整的 4-字节 的字。
    • 分配程式不是线程安全的。
    • 分配程式不能将空闲空间拼合为更大的内存块。
    • 分配程式的过于简单的匹配算法会导致产生非常多潜在的内存碎片。
    • 我确信更有非常多其他问题。这就是为什么他只是个例子!


    其他 malloc 实现
    malloc() 的实现有非常多,这些实现各有好处和缺点。在设计一个分配程式时,要面临许多需要折衷的选择,其中包括:

    • 分配的速度。
    • 回收的速度。
    • 有线程的环境的行为。
    • 内存将要被用光时的行为。
    • 局部缓存。
    • 簿记(Bookkeeping)内存开销。
    • 虚拟内存环境中的行为。
    • 小的或大的对象。
    • 实时确保。


    每一个实现都有其自身的优缺点集合。在我们的简单的分配程式中,分配非常慢,而回收非常快。另外,由于他在使用虚拟内存系统方面较差,所以他最适于处理大的对象。
    更有其他许多分配程式能使用。其中包括:

    • Doug Lea Malloc:Doug Lea Malloc 实际上是完整的一组分配程式,其中包括 Doug Lea 的原始分配程式,GNU libc 分配程式和 ptmalloc。 Doug Lea 的分配程式有着和我们的版本非常类似的基本结构,不过他加入了索引,这使得搜索速度更快,并且能将多个没有被使用的块组合为一个大的块。他还支持缓存,以便更快地再次使用最近释放的内存。ptmalloc 是 Doug Lea Malloc 的一个扩展版本,支持多线程。在本文后面的
      参考资料
      部分中,有一篇描述 Doug Lea 的 Malloc 实现的文章。
    • BSD Malloc:BSD Malloc 是随 4.2 BSD 发行的实现,包含在 FreeBSD 之中,这个分配程式能从预先确实大小的对象构成的池中分配对象。他有一些用于对象大小的 size 类,这些对象的大小为 2 的若干次幂减去某一常数。所以,如果你请求给定大小的一个对象,他就简单地分配一个和之匹配的 size 类。这样就提供了一个快速的实现,不过可能会浪费内存。在
      参考资料
      部分中,有一篇描述该实现的文章。
    • Hoard:编写 Hoard 的目标是使内存分配在多线程环境中进行得非常快。因此,他的构造以锁的使用为中心,从而使所有进程不必等待分配内存。他能显著地加快那些进行非常多分配和回收的多线程进程的速度。在
      参考资料
      部分中,有一篇描述该实现的文章。


    众多可用的分配程式中最有名的就是上述这些分配程式。如果你的程式有特别的分配需求,那么你可能更愿意编写一个制定的能匹配你的程式内存分配方式的分配程式。不过,如果不熟悉分配程式的设计,那么制定分配程式通常会带来比他们解决的问题更多的问题。要获得关于该主题的适当的介绍,请参阅 Donald Knuth 撰写的 The Art of Computer Programming Volume 1: Fundamental Algorithms 中的第 2.5 节"Dynamic Storage Allocation"(请参阅
    参考资料
    中的链接)。他有点过时,因为他没有考虑虚拟内存环境,不过大部分算法都是基于前面给出的函数。
    在 C++ 中,通过重载 operator new(),你能以每个类或每个模板为单位实现自己的分配程式。在 Andrei Alexandrescu 撰写的 Modern C++ Design 的第 4 章("Small Object Allocation")中,描述了一个小对象分配程式(请参阅
    参考资料
    中的链接)。
    基于 malloc() 的内存管理的缺点
    不只是我们的内存管理器有缺点,基于 malloc() 的内存管理器仍然也有非常多缺点,不管你使用的是哪个分配程式。对于那些需要保持长期存储的程式使用 malloc() 来管理内存可能会非常令人失望。如果你有大量的不固定的内存引用,经常难以知道他们何时被释放。生存期局限于当前函数的内存非常容易管理,不过对于生存期超出该范围的内存来说,管理内存则困难得多。而且,关于内存管理是由进行调用的程式还是由被调用的函数来负责这一问题,非常多 API 都不是非常明确。
    因为管理内存的问题,非常多程式倾向于使用他们自己的内存管理规则。C++ 的异常处理使得这项任务更成问题。有时似乎致力于管理内存分配和清理的代码比实际完成计算任务的代码还要多!因此,我们将研究内存管理的其他选择。
    半自动内存管理策略
    引用计数
    引用计数是一种半自动(semi-automated)的内存管理技术,这表示他需要一些编程支持,不过他不必你确切知道某一对象何时不再被使用。引用计数机制为你完成内存管理任务。
    在引用计数中,所有共享的数据结构都有一个域来包含当前活动"引用"结构的次数。当向一个程式传递一个指向某个数据结构指针时,该程式会将引用计数增加 1。实质上,你是在告诉数据结构,他正在被存储在多少个位置上。然后,当你的进程完成对他的使用后,该程式就会将引用计数减少 1。结束这个动作之后,他还会检查计数是否已减到零。如果是,那么他将释放内存。
    这样做的好处是,你不必追踪程式中某个给定的数据结构可能会遵循的每一条路径。每次对其局部的引用,都将导致计数的适当增加或减少。这样能防止在使用数据结构时释放该结构。不过,当你使用某个采用引用计数的数据结构时,你必须记得运行引用计数函数。另外,内置函数和第三方的库不会知道或能使用你的引用计数机制。引用计数也难以处理发生循环引用的数据结构。
    要实现引用计数,你只需要两个函数 ?? 一个增加引用计数,一个减少引用计数并当计数减少到零时释放内存。
    一个示例引用计数函数集可能看起来如下所示:
    清单 9. 基本的引用计数函数
    /* Structure Definitions*/
    /* Base structure that holds a refcount */
    struct refcountedstruct
    {
            int refcount;
    }
    /* All refcounted structures must mirror struct
    * refcountedstruct for their first variables
    */
    /* Refcount maintenance functions */
    /* Increase reference count */
    void REF(void *data)
    {
            struct refcountedstruct *rstruct;
            rstruct = (struct refcountedstruct *) data;
            rstruct->refcount++;
    }
    /* Decrease reference count */
    void UNREF(void *data)
    {
            struct refcountedstruct *rstruct;
            rstruct = (struct refcountedstruct *) data;
            rstruct->refcount--;
            /* Free the structure if there are no more users */
            if(rstruct->refcount == 0)
            {
                    free(rstruct);
            }
    }
    REF 和 UNREF 可能会更复杂,这取决于你想要做的事情。例如,你可能想要为多线程程式增加锁,那么你可能想扩展 refcountedstruct,使他同样包含一个指向某个在释放内存之前要调用的函数的指针(类似于面向对象语言中的析构函数 ?? 如果你的结构中包含这些指针,那么这是必需的)。
    当使用 REF 和 UNREF 时,你需要遵守这些指针的分配规则:

    • UNREF 分配前左端指针(left-hand-side pointer)指向的值。
    • REF 分配后左端指针(left-hand-side pointer)指向的值。


    在传递使用引用计数的结构的函数中,函数需要遵循以下这些规则:

    • 在函数的起始处 REF 每一个指针。
    • 在函数的结束处 UNREF 第一个指针。


    以下是个使用引用计数的生动的代码示例:
    清单 10. 使用引用计数的示例
    /* EXAMPLES OF USAGE */
    /* Data type to be refcounted */
    struct mydata
    {
            int refcount; /* same as refcountedstruct */
            int datafield1; /* Fields specific to this struct */
            int datafield2;
            /* other declarations would go here as appropriate */
    };
    /* Use the functions in code */
    void dosomething(struct mydata *data)
    {
            REF(data);
            /* Process data */
            /* when we are through */
            UNREF(data);
    }
    struct mydata *globalvar1;
    /* Note that in this one, we don’t decrease the
    * refcount since we are maintaining the reference
    * past the end of the function call through the
    * global variable
    */
    void storesomething(struct mydata *data)
    {
            REF(data); /* passed as a parameter */
            globalvar1 = data;
            REF(data); /* ref because of Assignment */
            UNREF(data); /* Function finished */
    }
    由于引用计数是如此简单,大部分程式员都自已去实现他,而不是使用库。不过,他们依赖于 malloc 和 free 等低层的分配程式来实际地分配和释放他们的内存。
    在 Perl 等高级语言中,进行内存管理时使用引用计数非常广泛。在这些语言中,引用计数由语言自动地处理,所以你根本不必担心他,除非要编写扩展模块。由于所有内容都必须进行引用计数,所以这会对速度产生一些影响,但他极大地提高了编程的安全性和方便性。以下是引用计数的益处:

    • 实现简单。
    • 易于使用。
    • 由于引用是数据结构的一部分,所以他有一个好的缓存位置。


    不过,他也有其不足之处:

    • 需求你永远不要忘记调用引用计数函数。
    • 无法释放作为循环数据结构的一部分的结构。
    • 减缓几乎每一个指针的分配。
    • 尽管所使用的对象采用了引用计数,不过当使用异常处理(比如 try 或 setjmp()/longjmp())时,你必须采取其他方法。
    • 需要额外的内存来处理引用。
    • 引用计数占用了结构中的第一个位置,在大部分机器中最快能访问到的就是这个位置。
    • 在多线程环境中更慢也更难以使用。


    C++ 能通过使用智能指针(smart pointers)来容忍程式员所犯的一些错误,智能指针能为你处理引用计数等指针处理细节。不过,如果不得不使用所有先前的不能处理智能指针的代码(比如对 C 库的联接),实际上,使用他们的后果通实比不使用他们更为困难和复杂。因此,他通常只是有益于纯 C++ 项目。如果你想使用智能指针,那么你实在应该去阅读 Alexandrescu 撰写的 Modern C++ Design 一书中的"Smart Pointers"那一章。
    内存池
    内存池是另一种半自动内存管理方法。内存池帮助某些程式进行自动内存管理,这些程式会经历一些特定的阶段,而且每个阶段中都有分配给进程的特定阶段的内存。例如,非常多网络服务器进程都会分配非常多针对每个连接的内存 ?? 内存的最大生存期限为当前连接的存在期。Apache 使用了池式内存(pooled memory),将其连接拆分为各个阶段,每个阶段都有自己的内存池。在结束每个阶段时,会一次释放所有内存。
    在池式内存管理中,每次内存分配都会指定内存池,从中分配内存。每个内存池都有不同的生存期限。在 Apache 中,有一个持续时间为服务器存在期的内存池,更有一个持续时间为连接的存在期的内存池,及一个持续时间为请求的存在期的池,另外更有其他一些内存池。因此,如果我的一系列函数不会生成比连接持续时间更长的数据,那么我就能完全从连接池中分配内存,并知道在连接结束时,这些内存会被自动释放。另外,有一些实现允许注册清除函数(cleanup functions),在清除内存池之前,恰好能调用他,来完成在内存被清理前需要完成的其他所有任务(类似于面向对象中的析构函数)。
    要在自己的程式中使用池,你既能使用 GNU libc 的 obstack 实现,也能使用 Apache 的 Apache Portable Runtime。GNU obstack 的好处在于,基于 GNU 的 Linux 发行版本中默认会包括他们。Apache Portable Runtime 的好处在于他有非常多其他工具,能处理编写多平台服务器软件所有方面的事情。要深入了解 GNU obstack 和 Apache 的池式内存实现,请参阅
    参考资料
    部分中指向这些实现的文件的链接。
    下面的假想代码列表展示了怎么使用 obstack:
    清单 11. obstack 的示例代码
    #include
    #include
    /* Example code listing for using obstacks */
    /* Used for obstack macros (xmalloc is
       a malloc function that exits if memory
       is exhausted */
    #define obstack_chunk_alloc xmalloc
    #define obstack_chunk_free free
    /* Pools */
    /* Only permanent allocations should go in this pool */
    struct obstack *global_pool;
    /* This pool is for per-connection data */
    struct obstack *connection_pool;
    /* This pool is for per-request data */
    struct obstack *request_pool;
    void allocation_failed()
    {
            exit(1);
    }
    int main()
    {
            /* Initialize Pools */
            global_pool = (struct obstack *)
                    xmalloc (sizeof (struct obstack));
            obstack_init(global_pool);
            connection_pool = (struct obstack *)
                    xmalloc (sizeof (struct obstack));
            obstack_init(connection_pool);
            request_pool = (struct obstack *)
                    xmalloc (sizeof (struct obstack));
            obstack_init(request_pool);
            /* Set the error handling function */
            obstack_alloc_failed_handler = &allocation_failed;
            /* Server main loop */
            while(1)
            {
                    wait_for_connection();
                    /* We are in a connection */
                    while(more_requests_available())
                    {
                            /* Handle request */
                            handle_request();
                            /* Free all of the memory allocated
                             * in the request pool
                             */
                            obstack_free(request_pool, NULL);
                    }
                    /* We’re finished with the connection, time
                     * to free that pool
                     */
                    obstack_free(connection_pool, NULL);
            }
    }
    int handle_request()
    {
            /* Be sure that all object allocations are allocated
             * from the request pool
             */
            int bytes_i_need = 400;
            void *data1 = obstack_alloc(request_pool, bytes_i_need);
            /* Do stuff to process the request */
            /* return */
            return 0;
    }
    基本上,在操作的每一个主要阶段结束之后,这个阶段的 obstack 会被释放。不过,要注意的是,如果一个过程需要分配持续时间比当前阶段更长的内存,那么他也能使用更长期限的 obstack,比如连接或全局内存。传递给 obstack_free() 的 NULL 指出他应该释放 obstack 的全部内容。能用其他的值,不过他们通常不怎么实用。
    使用池式内存分配的益处如下所示:

    • 应用程式能简单地管理内存。
    • 内存分配和回收更快,因为每次都是在一个池中完成的。分配能在 O(1) 时间内完成,释放内存池所需时间也差不多(实际上是 O(n) 时间,不过在大部分情况下会除以一个大的因数,使其变成 O(1))。
    • 能预先分配错误处理池(Error-handling pools),以便程式在常规内存被耗尽时仍能恢复。
    • 有非常易于使用的标准实现。


    池式内存的缺点是:

    • 内存池只适用于操作能分阶段的程式。
    • 内存池通常不能和第三方库非常好地合作。
    • 如果程式的结构发生变化,则不得不修改内存池,这可能会导致内存管理系统的重新设计。
    • 你必须记住需要从哪个池进行分配。另外,如果在这里出错,就非常难捕捉该内存池。

    垃圾收集
    垃圾收集(Garbage collection)是全自动地检测并移除不再使用的数据对象。垃圾收集器通常会在当可用内存减少到少于一个具体的阈值时运行。通常,他们以程式所知的可用的一组"基本"数据 ?? 栈数据、全局变量、寄存器 ?? 作为出发点。然后他们尝试去追踪通过这些数据连接到每一块数据。收集器找到的都是有用的数据;他没有找到的就是垃圾,能被销毁并重新使用这些无用的数据。为了有效地管理内存,非常多类型的垃圾收集器都需要知道数据结构内部指针的规划,所以,为了正确运行垃圾收集器,他们必须是语言本身的一部分。
    收集器的类型

    • 复制(copying): 这些收集器将内存存储器分为两部分,只允许数据驻留在其中一部分上。他们定时地从"基本"的元素开始将数据从一部分复制到另一部分。内存新近被占用的部分目前成为活动的,另一部分上的所有内容都认为是垃圾。另外,当进行这项复制操作时,所有指针都必须被更新为指向每个内存条目的新位置。因此,为使用这种垃圾收集方法,垃圾收集器必须和编程语言集成在一起。
    • 标记并清理(Mark and sweep):每一块数据都被加上一个标签。不定期的,所有标签都被设置为 0,收集器从"基本"的元素开始遍历数据。当他遇见内存时,就将标签标记为 1。最后没有被标记为 1 的所有内容都认为是垃圾,以后分配内存时会重新使用他们。
    • 增量的(Incremental):增量垃圾收集器不必遍历全部数据对象。因为在收集期间的忽然等待,也因为和访问所有当前数据相关的缓存问题(所有内容都不得不被页入(page-in)),遍历所有内存会引发问题。增量收集器避免了这些问题。
    • 保守的(Conservative):保守的垃圾收集器在管理内存时不必知道和数据结构相关的所有信息。他们只查看所有数据类型,并假定他们能全部都是指针。所以,如果一个字节序列能是个指向一块被分配的内存的指针,那么收集器就将其标记为正在被引用。有时没有被引用的内存会被收集,这样会引发问题,例如,如果一个整数域中包含一个值,该值是已分配内存的地址。不过,这种情况极少发生,而且他只会浪费少量内存。保守的收集器的优势是,他们能和所有编程语言相集成。


    Hans Boehm 的保守垃圾收集器是可用的最流行的垃圾收集器之一,因为他是免费的,而且既是保守的又是增量的,能使用 --enable-redirect-malloc 选项来构建他,并且能将他用作系统分配程式的简易替代者(drop-in replacement)(用 malloc/free 代替他自己的 API)。实际上,如果这样做,你就能使用和我们在示例分配程式中所使用的相同的 LD_PRELOAD 技巧,在系统上的几乎所有程式中启用垃圾收集。如果你怀疑某个程式正在泄漏内存,那么你能使用这个垃圾收集器来控制进程。在早期,当 Mozilla 严重地泄漏内存时,非常多人在其中使用了这项技术。这种垃圾收集器既能在 视窗系统® 下运行,也能在 UNIX 下运行。
    垃圾收集的一些好处:

    • 你永远不必担心内存的双重释放或对象的生命周期。
    • 使用某些收集器,你能使用和常规分配相同的 API。


    其缺点包括:

    • 使用大部分收集器时,你都无法干涉何时释放内存。
    • 在多数情况下,垃圾收集比其他形式的内存管理更慢。
    • 垃圾收集错误引发的缺陷难于调试。
    • 如果你忘记将不再使用的指针设置为 null,那么仍然会有内存泄漏。


    结束语
    一切都需要折衷:性能、易用、易于实现、支持线程的能力等,这里只列出了其中的一些。为了满足项目的需求,有非常多内存管理模式能供你使用。每种模式都有大量的实现,各有其优缺点。对非常多项目来说,使用编程环境默认的技术就足够了,不过,当你的项目有特别的需要时,了解可用的选择将会有帮助。下表对比了本文中涉及的内存管理策略。
    表 1. 内存分配策略的对比
    策略
    分配速度
    回收速度
    局部缓存
    易用性
    通用性
    实时可用
    SMP 线程友好
    制定分配程式
    取决于实现
    取决于实现
    取决于实现
    非常难

    取决于实现
    取决于实现
    简单分配程式
    内存使用少时较快
    非常快

    容易



    GNU malloc



    容易



    Hoard



    容易



    引用计数
    N/A
    N/A
    非常好


    是(取决于 malloc 实现)
    取决于实现


    非常快
    极好


    是(取决于 malloc 实现)
    取决于实现
    垃圾收集
    中(进行收集时慢)





    几乎不
    增量垃圾收集






    几乎不
    增量保守垃圾收集



    容易


    几乎不
    参考资料

    • 你能参阅本文在 developerWorks 全球站点上的
      英文原文



    Web 上的文件


    • GNU C Library 手册的 obstacks 部分
      提供了 obstacks 编程接口。

    • Apache Portable Runtime 文件
      描述了他们的池式分配程式的接口。
    基本的分配程式


    • Doug Lea 的 Malloc
      是最流行的内存分配程式之一。

    • BSD Malloc
      用于大部分基于 BSD 的系统中。

    • ptmalloc
      起源于 Doug Lea 的 malloc,用于 GLIBC 之中。

    • Hoard
      是个为多线程应用程式优化的 malloc 实现。

    • GNU Memory-Mapped Malloc(GDB 的组成部分)
      是个基于 mmap() 的 malloc 实现。

    • ElectricFence Malloc Debugger
      是个调试程式中内存问题的 malloc 实现。
    池式分配程式


    • GNU Obstacks
      (GNU Libc 的组成部分)是安装最多的池式分配程式,因为在每一个基于 glibc 的系统中都有他。

    • Apache 的池式分配程式(Apache Portable Runtime 中)
      是应用最为广泛的池式分配程式。

    • Squid
      有其自己的池式分配程式。

    • NetBSD
      也有其自己的池式分配程式。

    • talloc
      是个池式分配程式,是 Samba 的组成部分。
    智能指针和制定分配程式


    • Loki C++ Library
      有非常多为 C++ 实现的通用模式,包括智能指针和一个制定的小对象分配程式。
    垃圾收集器


    • Hahns Boehm Conservative Garbage Collector
      是最流行的开源垃圾收集器,他能用于常规的 C/C++ 程式。
    关于现代操作系统中的虚拟内存的文章

    • Marshall Kirk McKusick 和 Michael J. Karels 合著的
      A New Virtual Memory Implementation for Berkeley UNIX
      讨论了 BSD 的 VM 系统。

    • Mel Gorman’s Linux VM Documentation
      讨论了 Linux VM 系统。
    关于 malloc 的文章

    • Poul-Henning Kamp 撰写的
      Malloc in Modern Virtual Memory Environments
      讨论的是 malloc 及他怎么和 BSD 虚拟内存交互。
    • Berger、McKinley、Blumofe 和 Wilson 合著的
      Hoard -- a Scalable Memory Allocator for Multithreaded Environments
      讨论了 Hoard 分配程式的实现。
    • Marshall Kirk McKusick 和 Michael J. Karels 合著的
      Design of a General Purpose Memory Allocator for the 4.3BSD UNIX Kernel
      讨论了内核级的分配程式。
    • Doug Lea 撰写的
      A Memory Allocator
      给出了一个关于设计和实现分配程式的概述,其中包括设计选择和折衷。
    • Emery D. Berger 撰写的
      Memory Management for High-Performance Applications
      讨论的是制定内存管理及他怎么影响高性能应用程式。
    关于制定分配程式的文章

    • Doug Lea 撰写的
      Some Storage Management Techniques for Container Classes
      描述的是为 C++ 类编写制定分配程式。
    • Berger、Zorn 和 McKinley 合著的
      Composing High-Performance Memory Allocators
      讨论了怎么编写制定分配程式来加快具体工作的速度。
    • Berger、Zorn 和 McKinley 合著的
      Reconsidering Custom Memory Allocation
      再次提及了制定分配的主题,看是否真正值得为其费心。
    关于垃圾收集的文章

    • Paul R. Wilson 撰写的
      Uniprocessor Garbage Collection Techniques
      给出了垃圾收集的一个基本概述。
    • Benjamin Zorn 撰写的
      The Measured Cost of Garbage Collection
      给出了关于垃圾收集和性能的硬数据(hard data)。
    • Hans-Juergen Boehm 撰写的
      Memory Allocation Myths and Half-Truths
      给出了关于垃圾收集的神话(myths)。
    • Hans-Juergen Boehm 撰写的
      Space Efficient Conservative Garbage Collection
      是一篇描述他的用于 C/C++ 的垃圾收集器的文章。
    Web 上的通用参考资料


    • 内存管理参考
      中有非常多关于内存管理参考资料和技术文章的链接。

    • 关于内存管理和内存层级的 OOPS Group Papers
      是非常好的一组关于此主题的技术文章。

    • C++ 中的内存管理
      讨论的是为 C++ 编写制定的分配程式。

    • Programming Alternatives: Memory Management
      讨论了程式员进行内存管理时的一些选择。

    • 垃圾收集 FAQ
      讨论了关于垃圾收集你需要了解的所有内容。

    • Richard Jones 的 Garbage Collection Bibliography
      有指向所有你想要的关于垃圾收集的文章的链接。

    • 用于动态存储分配和内存管理的调试工具
      非常好地列出了用于在程式中寻找内存问题的 malloc 实现。
    书籍

    • Michael Daconta 撰写的
      C++ Pointers and Dynamic Memory Management
      介绍了关于内存管理的非常多技术。
    • Frantisek Franek 撰写的
      Memory as a Programming Concept in C and C++
      讨论了有效使用内存的技术和工具,并给出了在计算机编程中应当引起注意的内存相关错误的角色。
    • Richard Jones 和 Rafael Lins 合著的
      Garbage Collection: Algorithms for Automatic Dynamic Memory Management
      描述了当前使用的最常见的垃圾收集算法。
    • 在 Donald Knuth 撰写的 The Art of Computer Programming 第 1 卷
      Fundamental Algorithms
      的第 2.5 节"Dynamic Storage Allocation"中,描述了实现基本的分配程式的一些技术。
    • 在 Donald Knuth 撰写的 The Art of Computer Programming 第 1 卷
      Fundamental Algorithms
      的第 2.3.5 节"Lists and Garbage Collection"中,讨论了用于列表的垃圾收集算法。
    • Andrei Alexandrescu 撰写的
      Modern C++ Design
      第 4 章"Small Object Allocation"描述了一个比 C++ 标准分配程式效率高得多的一个高速小对象分配程式。
    • Andrei Alexandrescu 撰写的
      Modern C++ Design
      第 7 章"Smart Pointers"描述了在 C++ 中智能指针的实现。
    • Jonathan 撰写的
      Programming from the Ground Up
      第 8 章"Intermediate Memory Topics"中有本文使用的简单分配程式的一个汇编语言版本。
    来自 developerWorks


    • 自我管理数据缓冲区内存
      (developerWorks,2004 年 1 月)略述了一个用于管理内存的自管理的抽象数据缓存器的伪 C (pseudo-C)实现。

    • A framework for the user defined malloc replacement feature
      (developerWorks,2002 年 2 月)展示了怎么利用 AIX 中的一个工具,使用自己设计的内存子系统取代原有的内存子系统。

    • 掌控 Linux 调试技术
      (developerWorks,2002 年 8 月)描述了能使用调试方法的 4 种不同情形:段错误、内存溢出、内存泄漏和挂起。

    • 处理 Java 程式中的内存漏洞
      (developerWorks,2001 年 2 月)中,了解导致 Java 内存泄漏的原因,及何时需要考虑他们。

    • developerWorks Linux 专区
      中,能找到更多为 Linux 研发人员准备的参考资料。
    • 从 developerWorks 的
      Speed-start your Linux app
      专区中,能下载运行于 Linux 之上的 IBM 中间件产品的免费测试版本,其中包括 WebSphere® Studio Application Developer、WebSphere Application Server、DB2® Universal Database、Tivoli® Access Manager 和 Tivoli Directory Server,查找 how-to 文章和技术支持。
    • 通过参和
      developerWorks blogs
      加入到 developerWorks 社区。
    • 能在 Developer Bookstore Linux 专栏中定购
      打折出售的 Linux 书籍



    关于作者
    Jonathan Bartlett 是
    Programming from the Ground Up
    一书的作者,这本书介绍的是 Linux 汇编语言编程。Jonathan Bartlett 是 New Media Worx 的总研发师,负责为客户研发 Web、视频、kiosk 和桌面应用程式。你能通过
    johnnyb@eskimo.com
    和 Jonathan 联系。


  • 以上内容由 华夏名网 搜集整理,如转载请注明原文出处,并保留这一部分内容。

      “华夏名网” http://www.sudu.cn 和 http://www.bigwww.com 是成都飞数科技有限公司的网络服务品牌,专业经营虚拟主机,域名注册,VPS,服务器租用业务。公司创建于2002年,经过6年的高速发展,“华夏名网”已经成为我国一家知名的互联网服务提供商,被国外权威机构webhosting.info评价为25大IDC服务商之一。

    华夏名网网址导航: 虚拟主机 双线主机 主机 域名注册 cn域名 域名 服务器租用 酷睿服务器 vps vps主机

  • (阅读次数:206)
  • 上一篇: linux内核分析--中断(转自某位大哥网上的笔记)    下一篇: 内核模块是如何被调入内核工作的?
  • [收藏] [推荐] [评论] [打印本页] [返回上一页][关闭窗口]
  • 昵称: (为空则显示guest)
  • 评论分数: ★ ★ ★★★ ★★★★ ★★★★★
  • 评论内容:(不能超过250字,需审核后才会公布,请自觉遵守互联网相关政策法规。