这一章呢我们来了解下另一个能够创建进程的函数：vfork函数。
vfork函数的作用基本和fork函数类似，调用流程和返回值与fork函数完全相同。
那么fork和vfork有什么区别呢？
我们来看一下下面这几段程序：
我们可以从中看到：
1、 vfork创建的子进程会先运行，可以说子进程和附近陈的结果是确定的，fork先运行那个不能确定
2、 vfork创建的进程中父进程和子进程共享了全部变量（k）和局部变量（i）的数据
3、 因为vfork是子进程先运行，父进程挂起，可以看到直至子进程调用exec或则exit之后父子进程的执行次序不再有限制，因此，如果在子进程调用exec或exit之前需要父进程的进一步活动，就会造成死锁
4、 可以看到在不调用exec或exit时，局部变量在父进程中会出现不可预料的结果
5、 在子进程调用了exec或exit后，子进程后面的代码并没有运行
3种地址：虚拟地址、物理地址、逻辑地址物理地址：内存的电路地址，对应内存地址线上的高低电平，物理可见的。
虚拟地址： 分页机制 的产物，也叫线性地址，是进程能看见的地址。
逻辑地址： 分段机制 的产物，属于inter cpu的历史遗留问题，linux可以当做不存在。
3种地址的转换：进程访问逻辑地址，linux内核根据分段机制装换成虚拟地址，然后把进程的页表和虚拟地址都告诉cpu，cpu就可以根据分页机制将虚拟地址装换成物理地址，然后访问内存。
linux内核中巧妙地屏蔽里分段机制，就是逻辑地址等于虚拟地址，访问内存只需要利用分页机制把虚拟地址转换成物理地址。
linux会为每个进程创建自己的虚拟地址空间，就是进程地址空间，64位系统就是128T的内存空间。需要注意的是，虚拟地址就是假的，一开始不和物理地址对应，也就是说不占用物理内存，只有当虚拟地址有写入 *** 作是，内核会触发缺页，分配真实的物理地址给虚拟地址。物理地址的管理可参考 内核内存管理
从进程空间看，用户态闲置内存有3块，Stack、Memory Mapping Region、Heap，Stack是程序函数调用运行时需要的，不可控，能自由分配的内存就剩Memory Mapping Region、Heap了，linux系统提供的内存分配函数就是针对这两个区域的。
Heap *** 作函数：int brk(void *addr)、void *sbrk(intptr_t increment)
Memory Mapping Region *** 作函数：mmap()、munmap()
当然进程可以直接使用系统调用去申请内存，但是如果不管理的话，经过大量的申请和释放，会把进程空间切割的乱七八糟，导致不能申请大块的连续空间，为此就出现了内存管理模块，封装了系统调用，对进程提供malloc和free等高级函数。实际上，除了一些特殊程序，我们也很少用系统调用，一般都是使用内存管理模块提供的malloc和free，关系如下图：
内存管理模块用各种好处，例如不会每次 *** 作都去执行系统调用，减少内存碎片的产生等等。
当然也有很多实现方式，例如常用的glibc的Ptmalloc，google的tcmalloc，facebook的jemalloc等。各有各的应用场景，blablabla....
使用时，gcc默认会链接glibc的，如果想使用其他lib，gcc链接时指定就能覆盖掉glibc的。
我们重点讲Ptmalloc，从而启发程序员在写程序时多考虑下内存分配情况，可以选择或自己实现适合自己程序的内存管理lib。
Ptmalloc的历史发展，blablabla......，Ptmalloc采取内存池管理，进程malloc时，通过brk（小于128K的内存）、mmap（大内存）从系统获取地址空间，给进程使用，进程free时，不会立即通过brk、munmap将地址空间还给系统，会自己维护起来，叫做空闲内存，这些空闲内存在进程再次malloc时，还会被分出去，并且空闲内存会在特定条件下合并起来还给系统。
内存分配区，管理了一片内存，对外分发和回收，可以理解为一个内存池，分main arena和non main arena。
main arena：最早的分配区，管理着所有可分配的内存，通过brk，mmap等系统调用向系统申请内存。注意只有main arena可以 *** 作Heap。
non main arena：由于多线程的出现，如果多有线程都 *** 作main arena就会有竞争，需要加锁控制，所以出现了non main arena，通过mmap向main arena申请一大块内存，然后自己管理，可以理解为内存分销商。
只有主线程在main arena上申请内存，子线程在non main arena上，non main arena的个数是有上限的，所以non main arena允许多个子线程共用，这样就涉及到加锁，所以程序涉及应避免子线程个数太多。
进程申请到的一块内存叫做一个内存片，arena内部使用chunk数据结构来描述内存片，包括进程正在使用的内存片，和进程free掉的空闲内存片
A：是否main arena内存
M：使用mmap内存
P：上一块是否被使用
size of previous chunk：上一块没有被使用时，表示上块长度，被使用时是上块用来存User data的。
Size of chunk：就是下一块的size of previous chunk，释放时填上本块长度，供下块合并用。
分给进程的内存片arena可以不管，但是进程free回来的，arena需要通过一定方式组织起来，方便进程再次使用。组织方式有下面几种：
bins是个数组，包含128个bin，每个bin是个链表，分small bin和large bin两种，各64个，small bin中chunk大小固定，两个相邻的small bin中的chunk大小相差8bytes，large bin中chunk大小是一定范围内的，其中的chunk按大小排列。
空闲chunk按大小选择合适的bin，按新旧顺序挂到链表上，优先分配旧的chunk。
不大于max_fast （默认值为64B）的chunk被释放后，首先会被放到fast bins 中，fast bins中的chunk并不改变它的使用标志P。这样也就无法将它们合并，当需要给用户分配的chunk小于或等于max_fast时，ptmalloc首先会在fast bins中查找相应的空闲块。在特定的时候，ptmalloc会遍历fast bins中的chunk，将相邻的空闲chunk进行合并，并将合并后的chunk加入unsorted bin中。
进行malloc时，如果在fast bins中没有找到合适的chunk，则ptmalloc会先在unsorted bin中查找合适的空闲chunk，如果unsorted bin不能满足分配要求。malloc便会将unsorted bin中的chunk加入bins中。然后再从bins中继续进行查找和分配过程。从这个过程可以看出来，unsorted bin可以看做是bins的一个缓冲区，增加它只是为了加快分配的速度。
前面的bin中都是回收回来的内存，top chunk才是内存的初始来源，每个arena都有一个top chunk，用来管理Heap的，Heap会在arena第一次分配内存时初始化，会分配一块(chunk_size + 128K) align 4K的空间（132K）作为初始的Heap，top chunk占据整个空间，每次分配会在低地址出切出一片，如下图：
回收时，只有和top chunk相连的内存才能和top chunk合并，才能进而还给系统。
子线程Heap：在main arena中mmap出64M的空间，叫做sub-heap，再在sub-heap上初始化Heap。
主线程的Heap才是真Heap，使用进程Heap，使用brk申请内存。
子线程的heap不够用时，会在申请新的sub-heap，和老的sub-heap单向链表连起来，top chunk会搬到新sub-heap上。
描述mmap出来的内存，单独管理，free时按阈值来决定是否munmap，有动态调整阈值功能，防止太频繁的mmap和munmap。本文不关注。
即最后一次small request中因分割而得到的剩余部分，它有利于改进引用局部性，也即后续对 small chunk 的 malloc 请求可能最终被分配得彼此靠近。
当用户请求 small chunk而无法从small bin和unsorted bin得到时，会在large bin中找最合适的chunk，然后做切割，返回给用户的User chunk，剩下的是Remainder chunk添加到unsorted bin中。这一Remainder chunk就将成为last remainder chunk。
下一块为高地址，前一块为低地址。
Glibc内存管理 华庭（庄明强）
linux下进程间通信的几种主要手段简介：
一般文件的I/O函数都可以用于管道，如close、read、write等等。
实例1：用于shell
管道可用于输入输出重定向，它将一个命令的输出直接定向到另一个命令的输入。比如，当在某个shell程序（Bourne shell或C shell等）键入who│wc -l后，相应shell程序将创建who以及wc两个进程和这两个进程间的管道。
实例二：用于具有亲缘关系的进程间通信
管道的主要局限性正体现在它的特点上：
有名管道的创建
小结：
管道常用于两个方面：（1）在shell中时常会用到管道（作为输入输入的重定向），在这种应用方式下，管道的创建对于用户来说是透明的；（2）用于具有亲缘关系的进程间通信，用户自己创建管道，并完成读写 *** 作。
FIFO可以说是管道的推广，克服了管道无名字的限制，使得无亲缘关系的进程同样可以采用先进先出的通信机制进行通信。
管道和FIFO的数据是字节流，应用程序之间必须事先确定特定的传输"协议"，采用传播具有特定意义的消息。
要灵活应用管道及FIFO，理解它们的读写规则是关键。
信号生命周期
信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。
可以从两个不同的分类角度对信号进行分类：（1）可靠性方面：可靠信号与不可靠信号；（2）与时间的关系上：实时信号与非实时信号。
(1) 可靠信号与不可靠信号
不可靠信号 ：Linux下的不可靠信号问题主要指的是信号可能丢失。
可靠信号 ：信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()。
对于目前linux的两个信号安装函数:signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数（对所有信号这一点都成立），而经过signal安装的信号却不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。
(2) 实时信号与非实时信号
前32种信号已经有了预定义值，每个信号有了确定的用途及含义，并且每种信号都有各自的缺省动作。如按键盘的CTRL ^C时，会产生SIGINT信号，对该信号的默认反应就是进程终止。后32个信号表示实时信号，等同于前面阐述的可靠信号。这保证了发送的多个实时信号都被接收。实时信号是POSIX标准的一部分，可用于应用进程。非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号。
发送信号的主要函数有：kill()、raise()、 sigqueue()、alarm()、setitimer()以及abort()。
调用成功返回 0；否则，返回 -1。
sigqueue()是比较新的发送信号系统调用，主要是针对实时信号提出的（当然也支持前32种），支持信号带有参数，与函数sigaction()配合使用。
sigqueue的第一个参数是指定接收信号的进程ID，第二个参数确定即将发送的信号，第三个参数是一个联合数据结构union sigval，指定了信号传递的参数，即通常所说的4字节值。
sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号。sigqueue()比kill()传递了更多的附加信息，但sigqueue()只能向一个进程发送信号。
inux主要有两个函数实现信号的安装： signal() 、 sigaction() 。其中signal()在可靠信号系统调用的基础上实现, 是库函数。它只有两个参数，不支持信号传递信息，主要是用于前32种非实时信号的安装；而sigaction()是较新的函数（由两个系统调用实现：sys_signal以及sys_rt_sigaction），有三个参数，支持信号传递信息，主要用来与 sigqueue() 系统调用配合使用，当然，sigaction()同样支持非实时信号的安装。sigaction()优于signal()主要体现在支持信号带有参数。
消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的
消息队列的内核持续性要求每个消息队列都在系统范围内对应唯一的键值，所以，要获得一个消息队列的描述字，只需提供该消息队列的键值即可；
消息队列与管道以及有名管道相比，具有更大的灵活性，首先，它提供有格式字节流，有利于减少开发人员的工作量；其次，消息具有类型，在实际应用中，可作为优先级使用。这两点是管道以及有名管道所不能比的。同样，消息队列可以在几个进程间复用，而不管这几个进程是否具有亲缘关系，这一点与有名管道很相似；但消息队列是随内核持续的，与有名管道（随进程持续）相比，生命力更强，应用空间更大。
信号灯与其他进程间通信方式不大相同，它主要提供对进程间共享资源访问控制机制。相当于内存中的标志，进程可以根据它判定是否能够访问某些共享资源，同时，进程也可以修改该标志。除了用于访问控制外，还可用于进程同步。信号灯有以下两种类型：
int semop(int semid, struct sembuf *sops, unsigned nsops) semid是信号灯集ID，sops指向数组的每一个sembuf结构都刻画一个在特定信号灯上的 *** 作。
int semctl(int semid，int semnum，int cmd，union semun arg)
该系统调用实现对信号灯的各种控制 *** 作，参数semid指定信号灯集，参数cmd指定具体的 *** 作类型；参数semnum指定对哪个信号灯 *** 作，只对几个特殊的cmd *** 作有意义；arg用于设置或返回信号灯信息。
进程间需要共享的数据被放在一个叫做IPC共享内存区域的地方，所有需要访问该共享区域的进程都要把该共享区域映射到本进程的地址空间中去。系统V共享内存通过shmget获得或创建一个IPC共享内存区域，并返回相应的标识符。内核在保证shmget获得或创建一个共享内存区，初始化该共享内存区相应的shmid_kernel结构注同时，还将在特殊文件系统shm中，创建并打开一个同名文件，并在内存中建立起该文件的相应dentry及inode结构，新打开的文件不属于任何一个进程（任何进程都可以访问该共享内存区）。所有这一切都是系统调用shmget完成的。
shmget（）用来获得共享内存区域的ID，如果不存在指定的共享区域就创建相应的区域。shmat()把共享内存区域映射到调用进程的地址空间中去，这样，进程就可以方便地对共享区域进行访问 *** 作。shmdt()调用用来解除进程对共享内存区域的映射。shmctl实现对共享内存区域的控制 *** 作。这里我们不对这些系统调用作具体的介绍，读者可参考相应的手册页面，后面的范例中将给出它们的调用方法。
注：shmget的内部实现包含了许多重要的系统V共享内存机制；shmat在把共享内存区域映射到进程空间时，并不真正改变进程的页表。当进程第一次访问内存映射区域访问时，会因为没有物理页表的分配而导致一个缺页异常，然后内核再根据相应的存储管理机制为共享内存映射区域分配相应的页表。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）