菜鸟笔记
提升您的技术认知

操作系统笔记

进程,线程,协程与并行,并发进程线程协程的区别死锁进程,线程,多线程i 的线程安全性同步和异步孤儿进程和僵尸进程/proc进程信息linux中的分段和分页互斥量 mutex线程进程间通信进程创建进程优先级进程的基础知识进程与线程的区别(面试题)线程的控制(创建,终止,等待,分离)可重入 vs 线程安全死锁的概念一级缓存和二级缓存的理解一句话解说内存屏障 memory barrierbrk(), sbrk() 用法详解malloc/free函数的简单实现一文讲透 “进程、线程、协程”linux进程状态线程池的陷阱linux内核学习之进程和线程进程与线程的区别和联系内存寻址linux io子系统和文件系统读写流程page cache和buffer cache的区别与联系漫谈linux文件io多线程和多进程的区别内存泄漏字节、字、位、比特的概念和关系如何避免死锁ansi是什么编码?cpu寻址范围(寻址空间)cpu 使用率低高负载的原因创建多少个线程合适操作系统下spinlock锁解析、模拟及损耗分析线程堆栈堆和栈的内存分配堆和栈的概念和区别堆和栈的区别,申请方式,程序的内存分配什么是 pod 数据类型linux内存分配小结--malloc、brk、mmap系统调用与内存管理(sbrk、brk、mmap、munmap)进程描述和控制cpu执行程序的原理编译的基本概念linux虚拟地址空间布局一个程序从源代码到可执行程序的过程程序的运行机制——cpu、内存、指令的那些事分页内存管理——虚拟地址到物理地址的转换深刻理解linux进程间通信fork之后父子进程的内存关系fork之后,子进程继承了父进程哪些内容关于协程及其锁的一些认识对协程的一点理解std::thread join和detach区别cas和aba问题cas算法锁和无锁无锁队列的实现lock-free 编程锁开销优化以及cas进程、线程和协程之间的区别和联系多线程的同步与互斥(互斥锁、条件变量、读写锁、自旋锁、信号量)linux 原来是这么管理内存的线程上下文切换怎么玩儿进程和线程通信原理cpu密集型 和 io密集型cas原理以及atomic原子类分析改变线程状态的八个方法六种进程间通信方式

malloc/free函数的简单实现-ag真人游戏

阅读 : 1097

  用于内存管理的malloc/free这对函数,对于使用c语言的程序员应该很熟悉。前段时间听说有的it公司以“实现一个简单功能的malloc”作为面试题,正好最近在复习k&r,上面有所介绍,因此花了些时间仔细研究了一下。毕竟把题目做出来是次要的,了解实现思想、提升技术才是主要的。本文主要是对malloc/free实现思路的介绍,蓝色部分文字是在个人思考中觉得比较核心的东西;另外对于代码的说明,有一些k&r上的解释,使用绿色加亮。

  在研究k&r第八章第七节的实现之前,不妨先看看其第五章第四节的alloc/afree实现,虽然这段代码主要目的是展示地址运算。

alloc实现

#define allocsize 10000
static char allocbuf[allocsize];    /*storage for alloc*/
static char *allocp = allocbuf;    /*next free position*/
char *alloc(int n) { if(allocbuf allocsize - allocp >= n) { allocp  = n; return alloc - n; } else
        return 0; } void afree(char *p) { if (p >= allocbuf && p allocsize) allocp = p; }

  这种简单实现的缺点

    1.作为代表内存资源的allocbuf,其实是预先分配好的,可能存在浪费。

    2.分配和释放的顺序类似于栈,即“后进先出”,释放时如果不按顺序会造成异常。

  这个实现虽然比较简陋,但是依然提供了一个思路。如果能把这两个缺点消除,就能够实现比较理想的malloc/free。

  仅仅依靠地址运算来进行定位,是限制分配回收灵活性的原因,它要求已使用部分和未使用部分必须通过某个地址分开成两个相邻区域。为了能让这两个区域能够互相交错,甚至其中还包括一些没有分配的地址空间,需要使用指针把同类的内存空间连接起来形成链表,这样就可以处理地址不连续的一系列内存空间。但是为什么只连接了空闲空间而不连接使用中的空间?这么问可能出于在对图中二者类比时的直觉而没有经过思考,这很简单,因为没有必要。前者相互链接是为了能够在内存分配时遍历所有空闲空间,并且在使用free()回收已使用空间时进行重新插入。而对于使用中的空间,由于我们在分配空间时已经知道它们的地址了,回收时可以直接告诉free(),并不用像malloc()时进行遍历。

  既然提到了链表,可能对数据结构稍有了解的人会立刻写下一个struct来代表一个内存区域,其中包含一个指向下一个内存区域的指针,但是这个struct的其他成员该怎么写呢?作为待分配的内存区域,大小是不定的,如果把它声明为struct的成员变量显然不妥;如果声明为一个指向某个其他的区域的指针,这似乎又和上面的直观表示不相符合。(当然,这么做也是可以实现的,它看上去是介于上图的两者之间,把管理结构和实际分配的空间相剥离,在文末我会专门的讨论一下这种实现方法)因此,这里仍然把控制结构和空闲空间相分开,但保持它们在内存地址中相邻,形成下图的形式,而正由这个特点,我们可以利用对控制结构指针的指针运算来定位对应的内存区域:

  对应地,把控制信息定义为header:

typedef long align;/*for alignment to long boundary*/
union header { 
    struct {
        union header *ptr; /*next block if on free list*/
        unsigned size; /*size of this block*/
    } s;
    align x;
};
typedef union header header;

  使用union而不是直接使用struct的原因是为了地址对齐。这里是long对齐,union的x永远不会使用。

  这样,malloc的主要工作就是对这些header和其后的内存块的管理。



malloc()

static header base;
static header *freep = null;
void *malloc(unsigned nbytes)
{
    header *p, *prevp;
    unsigned nunits;
    nunits = (nbytes sizeof(header)-1)/sizeof(header)   1;
    if((prevp = freep) == null) { /* no free list */
        base.s.ptr = freep = prevp = &base;
        base.s.size = 0;
    }
    for(p = prevp->s.ptr; ;prevp = p, p= p->s.ptr) {
        if(p->s.size >= nunits) { /* big enough */
            if (p->s.size == nunits)  /* exactly */
                prevp->s.ptr = p->s.ptr;
            else {
                p->s.size -= nunits;
                p  = p->s.size;
                p->s.size = nunits;
            }
            freep = prevp;
            return (void*)(p 1);
        }
        if (p== freep) /* wrapped around free list */
            if ((p = morecore(nunits)) == null)
                return null; /* none left */
    }
}

  实际分配的空间是header大小的整数倍,并且多出一个header大小的空间用于放置header。但是直观来看这并不是nunits = (nbytes sizeof(header)-1)/sizeof(header) 1啊?如果用(nbytes sizeof(header))/sizeof(header) 1岂不是刚好?其实不是这样,如果使用后者,(nbytes sizeof(header))%sizeof(header) == 0时,又多分配了一个header大小的空间了,因此还要在小括号里减去1,这时才能符合要求。

   malloc()第一次调用时建立一个退化链表base,只有一个大小是0的空间,并指向它自己。freep用于标识空闲链表的某个元素,每次查找时可能发生变化;中间的查找和分配过程是基本的链表操作,在空闲链表中不存在合适大小的空闲空间时调用morecore()获得更多内存空间;最后的返回值是空闲空间的首地址,即header之后的地址,这个接口与库函数一致。



morecore()

#define nalloc 1024    /* minimum #units to request */
static header *morecore(unsigned nu)
{
    char *cp;
    header *up;
    if(nu < nalloc)
        nu = nalloc;
    cp = sbrk(nu * sizeof(header));
    if(cp == (char *)-1)    /* no space at all*/
        return null;
    up = (header *)cp;
    up->s.size = nu;
    free((void *)(up 1));
    return freep;
}

  morecore()从系统申请更多的可用空间,并加入。由于调用了sbrk(),系统开销比较大,为避免morecore()本身的调用次数,设定了一个nalloc,如果每次申请的空间小于nalloc,就申请nalloc大小的空间,使得后续malloc()不必每次都需要调用morecore()。对于sbrk(),在后面会有介绍。

  这里有个让人惊讶的地方:malloc()调用了morecore(),morecore()又调用了free()!第一次看到这里时可能会觉得不可思议,因为按照惯性思维,malloc()和free()似乎应该是相互分开的,各司其职啊?但请再思考一下,free()是把空闲链表进行扩充,而malloc()在空闲链表不足时,从系统申请到更多内存空间后,也要先把它们转化成空闲链表的一部分,再进行利用。这样,malloc()调用free()完成后面的工作也是顺理成章了。根据这个思想,后面是free()的实现。在此之前,还有几个morecore()自身的细节:

  1.如果系统也没有空间可以分配,sbrk()返回-1。cp是char *类型,在有的机器上char无符号,这里需要一次强制类型转换。

  2.morecore()调用的返回值看上去比较奇怪,别担心,freep会在free()中修改的。使用这个返回值也是为了在malloc()里的判断、p = freep的再次赋值的语句能够紧凑。



free()

void free(void *ap)
{
    header *bp,*p;
    bp = (header *)ap -1; /* point to block header */
    for(p=freep;!(bp>p && bp< p->s.ptr);p=p->s.ptr)
        if(p>=p->s.ptr && (bp>p || bps.ptr))
            break;    /* freed block at start or end of arena*/
    if (bp bp->s.size==p->s.ptr) {    /* join to upper nbr */
        bp->s.size  = p->s.ptr->s.size;
        bp->s.ptr = p->s.ptr->s.ptr;
    } else
        bp->s.ptr = p->s.ptr;
    if (p p->s.size == bp) {     /* join to lower nbr */
        p->s.size  = bp->s.size;
        p->s.ptr = bp->s.ptr;
    } else
        p->s.ptr = bp;
    freep = p;
}

   free()首先定位要释放的ap对应的bp与空闲链表的相对位置,找到它的的最近的上一个和下一个空闲空间,或是当它在整个空闲空间的前面或后面时找到空闲链表的首尾元素。注意,由于malloc()的分配方式和free()的回收时的合并方式(下文马上要提到),可以保证整个空闲空间的链表总是从低地址逐个升高,在最高地址的空闲空间回指向低地址第一个空闲空间。

  定位后,根据要释放的空间与附近空间的相邻性,进行合并,也即修改对应空间的header。两个if并列可以使得bp可以同时与高地址和低地址空闲空间结合(如果都相邻),或者进行二者之一的合并,或者不合并。

  完成了这三部分代码后(注意放到同一源文件中,sbrk()需要#include ),就可以使用了。当然要注意,命名和stdlib.h中的同名函数是冲突的,可以自行改名。

  第一次审视源码,会发现很多实现可能原先并没有想到:header的结构和对齐填充、空间的取整、链表的操作和初始化(边界情况)、malloc()对free()的调用、由malloc()和free()暗中保证的链表地址有序等等,确实很值得玩味。另外再附上前文中提到的两个问题还有一些补充问题的简单思考

1.header与空闲空间相剥离,header中包含一个指向其空闲空间的指针

  这样做未必不可,相应地算法需要改动。同时,由于header和空闲空间不再相邻,sbrk()获得的空间也应该包含header的部分,内存的分布可能会更加琐碎。当然,这也可能带来好处,即用其他数据结构对链表进行管理,比如按大小进行hash,这样查找起来更快。

2.关于sbrk()

  sbrk()也是库函数,它能使堆往栈的方向增长,具体可以参考:brk(), sbrk() 用法详解

3.可以改进的方

  空闲空间的寻找是线性的,查找过程在内存分配中可以看作是循环首次适应算法,在某些情况下可能很慢;如果再建立一个数据结构,如hash表,对不同大小的空间进行索引,肯定可以加快查找本身,并且能实现一些算法,比如最佳匹配。但查找加快的代价是,修改这个索引会占用额外的时间,这是需要权衡的。

  morecore()中的最小分配空间是宏定义,在实际使用中完全可以作为参数传递,根据需要设定最小分配下限。

4.这个malloc()和系统提供的malloc()的差别?

  其实库函数的malloc在参数为0时可以返回一个null,而以上写malloc在头部分配成功后总不会返回null。这是差别之一,换句话说,二者实现还是不同的,这里只是为了演示malloc的原理,并非真正的库函数。

网站地图