C语言程序开发中的内存分配究竟是如何进行的?为什么calloc() 函数的效率比 malloc()+memset() 函数更高?

在C语言程序开发中,提到动态内存分配时,基本上每个程序员都明白 calloc() 和 malloc() 库函数的区别——calloc() 函数不仅分配内存,还会将分配后的内存清零,而 malloc() 函数则对分配好的内存不做任何操作。

calloc() 函数的效率比 malloc()+memset() 函数更高?

很多C语言程序员常把 calloc() 函数看作是 malloc() + memset() 函数的组合。不过,今天我在一个很偶然的测试中发现 calloc() 函数和 malloc() + memset() 组合函数的效率差异还是很大的。请看:

#include<stdio.h>
#include<stdlib.h>
#define BLOCK_SIZE 1024*1024*256
int main()
{
        int i=0;
        char *buf[10];
        while(i<10)
        {
                buf[i] = (char*)calloc(1,BLOCK_SIZE);
                i++;
        }
    return 0;
}

这段C语言代码调用了 calloc() 函数分配了一段内存,并且重复 10 次,编译并执行之(time 命令可以查看C语言程序运行消耗的时间),得到如下结果:

# gcc t.c
# time ./a.out  
**real 0m0.287s**  
user 0m0.095s  
sys 0m0.192s 

现在将 calloc() 函数改为 malloc() + memset() 函数,修改后的C语言代码如下,请看:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#define BLOCK_SIZE 1024*1024*256
int main()
{
        int i=0;
        char *buf[10];
        while(i<10)
        {
                buf[i] = (char*)malloc(BLOCK_SIZE);
                memset(buf[i],'\0',BLOCK_SIZE);
                i++;
        }.
        return 0;
}

编译并执行这段C语言代码,同样使用 time 命令查看程序运行消耗时间,得到如下结果,请看:

# gcc t.c
# time ./a.out   
**real 0m2.693s**  
user 0m0.973s  
sys 0m1.721s 

应该清楚,这两段C语言代码的工作是一致的,都是分配一段长度为 BLOCK_SIZE 的内存并且清零,但是二者消耗的时间却相差非常大,这就有一个值得深思的问题:calloc() 函数做了相同的工作,但是效率却高得多,这是怎么回事呢?

弄清楚这一点,对于我们以后开发更高效率的C语言程序肯定有所帮助。

解析

在展开讨论之前,应该明白的是以后如果希望申请一段内容为 0 的内存,则应该使用效率更高的 calloc() 函数,而不是 malloc() + memset() 函数的组合。

因为 calloc() 函数在内部实现中,会自行判断分配后的内存是否需要清零,如果某段分配好的内存原本就是零,那么清零动作就免去了。而 malloc() + memset() 函数的组合则全额做了“分配+清零”的动作,效率自然是有所差异的。

一般来说,C语言程序员应该明白四大点:程序,标准库,内核以及页表

像 malloc() 和 calloc() 这样的内存分配函数主要用于分配数百字 KB 以下的内存分配,这样的分配一般是直接从内存池(memory pool)中分配的。当内存池被用完后,或者某段C语言代码一次性请求分配的内存超过剩余内存池容量时,malloc() 和 calloc() 将直接向内核请求内存。

内核管理每个进程的实际 RAM,并确保不同进程不会干扰彼此的内存,这就是所谓的操作系统“内存保护”机制。有了这样的机制,一个进程的崩溃不会导致其他进程跟着崩溃,系统的稳定性会得到保障。

因此,在操作系统内核的管理下,当某段C语言代码需要使用一段内存时,它不能直接使用物理内存,而只能通过 mmap() 以及 sbrk() 等系统调用向内核申请,由内核修改页表为每个进程提供 RAM。

页表将内存地址映射到实际的物理 RAM,在 32 位系统上,进程地址(0x00000000到0xffffffff)不是实际的内存地址,而是虚拟内存地址,处理器将这些地址分为 4KiB 个页,通过页表,可以将每个内存页对应到不同的物理 RAM 上。

一些C语言程序员认为,calloc() 等内存分配函数是这样工作的

C语言程序调用 calloc() 申请 256KB 内存,于是标准库调用系统调用 mmap() 函数向内核申请,内核找到 256KB 未被使用的 RAM,并通过修改页表的方式将其提供给C语言程序,接着标准库调用 memset() 函数将申请到的内存清零,然后从 calloc() 函数将这段内存返回。

之后,当这段C语言程序退出后,内核会回收分配给它的内存,以便给其他进程使用。

实际上

上述过程在理论上是可行的,但是实际上并不会这样。因为内存总是有限的,内核分配给我们的C语言程序使用的内存可能是之前其他进程使用过的,如果这段内存里有密码,密钥,等其他敏感信息呢?

为了避免出现上述安全隐患,内核总是在将内存交给进程之前将其清理掉。当然了,我们也可以自己调用清零函数将使用过的内存清零,但是不管如何,mmap() 函数保证其返回的新内存是清零后的总是安全的选择。

有一些C语言程序可能很早就向内核申请了一段内存,但是却不会立刻使用它,甚至可能根本不会使用它。因此在设计操作系统内核时,为了效率的最大化,可能内核在收到内存分配请求时,根本不修改页表,也不向我们的程序提供任何实际的 RAM。

内核可能仅会将一些地址空间标记给我们的程序使用,但是却不做实际的分配工作。这样就避免了“分配了内存,却没被使用”带来的不必要的开销了。当然,一旦C语言程序需要读写这些地址空间,就会触发一个缺页异常,内核再将 RAN 真正的分配给这些地址,并恢复程序运行。

简而言之,内核为了避免不必要的开销,实际的内存分配只有在确保真的有C语言代码使用时(有写入动作时)才会进行。

也有些C语言程序分配内存后,可能(不做任何修改)直接就去读这些内存,这时,内核甚至会让这些C语言程序申请的内存指向同一个 4KiB 页表,因为 mmap() 返回的零填充内存都一样。如果某个C语言程序尝试对申请到的内存执行写入操作,那么将触发另一种缺页异常,内核将为该C语言程序分配一个新的内存页使用,该内存页不与其他任何进程共享。

在C语言程序开发中,一次内存分配的实际过程是这样的

C语言程序调用 calloc() 申请 256KB 内存,于是标准库调用系统调用 mmap() 函数向内核申请,内核找到 256KB 未被使用的地址空间,记下该地址空闲现在用于什么,然后返回。

现在标准库知道 mmap() 返回的结果总是用零填充,所以它不需要写入内存,因此不会出现缺页异常,内核不必直接实际分配内存。

最后C语言程序退出,内核不需要回收内存,因为内核根本就没有分配过内存。这样的效率显然很高。

如果使用 memset() 将页面清零,那么 memset() 的写入动作将触发缺页异常,内核将不得不执行分配动作,并执行写入零动作。这是一项巨大的工作,这也解释了为什么 calloc() 比 malloc() + memset() 快的原因。

现在知道原理了,我们就可以预言:如果最后使用了库函数分配的内存,那么 calloc() 函数可能仍然比 malloc()+memset() 快,但是二者之前的区别将不会再那么大。

应该明白

并非所有的操作系统内核都具有分页虚拟内存,因此并非在所有平台上编译C语言代码都会得到相同的结果。calloc() 函数可能并不从内核申请内存,而是从共享内存池里申请,而共享内存池中可能存储了上一次被使用时残留的垃圾数据,calloc() 可以获取到这些内存,并且调用 memset() 将其清零。

不同的操作系统管理内存很可能是不一样的,有些操作系统内核会在空闲时将内存归零,已备以后需要获得归零内存时使用,而有些则不会,例如 Linux 就不会提前将内存清零。

阅读更多:   C语言
添加新评论

icon_redface.gificon_idea.gificon_cool.gif2016kuk.gificon_mrgreen.gif2016shuai.gif2016tp.gif2016db.gif2016ch.gificon_razz.gif2016zj.gificon_sad.gificon_cry.gif2016zhh.gificon_question.gif2016jk.gif2016bs.gificon_lol.gif2016qiao.gificon_surprised.gif2016fendou.gif2016ll.gif