linux下exit()和_exit()区别

    平时一直在用exit()函数，但是今天看源码时竟然看到了_exit()函数，想知道它们的区别，所以就查查资料，写了下来！

  #include<stdlib.h>  void exit(int status);

    不像fork那么难理解，从exit的名字就能看出，这个系统调用是用来终止一个进程的。无论在程序中的什么位置，只要执行到exit系统调用，进程就会停止剩下的所有操作，清除包括PCB在内的各种数据结构，并终止本进程的运行。请看下面的程序：

#include<stdlib.h>#include <stdio.h>main() {   printf("this process will exit!\n");   exit(0);//程序在次退出，不会再向下执行。   printf("never be displayed!\n");}

运行结果：

      我们可以看到，程序并没有打印后面的"never be displayed!\n"，因为在执行到exit(0)时，进程就已经终止了，不会再向下执行，直接退出。exit 系统调用带有一个整数类型的参数status，我们可以利用这个参数传递进程结束时的状态：
    （1） 0表示没有意外的正常结束；
    （2）其他的数值表示出现了错误，进程非正常结束。

      我们在实际编程时，可以用wait系统调用接收子进程的返回值，从而针对不同的情况进行不同的处理。

      linux下exit()和_exit()的用法及区别：

       exit和_exit作为系统调用而言，_exit和exit是一对孪生兄弟。通常我们会认为，他们之间没有什么区别：但是没有区别会有两个函数，你要知道程序猿虽然苦但不笨，这种事儿发生的概率比较低，所以答案是否定的。这种区别主要体现在它们在函数库中的定义，_exit在Linux函数库中的原型是：

  #include<unistd.h>  void _exit(int status);

      （1）exit()函数定义在 stdlib.h中；而_exit()定义在unistd.h中，
      （2）_exit()函数的作用最为简单：直接使进程停止运行，清除其使用的内存空间，并销毁其在内核中的各种数据结构；exit()函数则在这些基础上作了一些包装，在执行退出之前加了若干道工序，也是因为这个原因，有些人认为exit已经不能算是纯粹的系统调用。
      因此，exit()函数与_exit()函数最大的区别就在于：exit()函数在调用exit系统调用之前要检查文件的打开情况，把文件缓冲区中的内容写回文件，就是“清理I/O缓冲”，而_exit()则是直接退出，不管缓冲区的数据，直接停止，容易造成数据的丢失。 
      在Linux 的标准函数库中，有一套称作“高级I/O”的函数，我们熟知的printf()、fopen()、fread()、fwrite()都在此列，它们也被称作“缓冲I/O（buffered I/O）”，其特征是对应每一个打开的文件，在内存中都有一片缓冲区，每次读文件时，会多读出若干条记录，这样下次读文件时就可以直接从内存的缓冲区中读取，每次写文件的时候，也仅仅是写入内存中的缓冲区，等满足了一定的条件（达到一定数量，或遇到特定字符，如换行符\n和文件结束符EOF），再将缓冲区中的内容一次性写入文件，这样就大大增加了文件读写的速度，但也为我们编程带来了一点点麻烦。如果有一些数据，我们认为已经写入了文件，实际上因为没有满足特定的条件，它们还只是保存在缓冲区内，这时我们用_exit()函数直接将进程关闭，缓冲区中的数据就会丢失，反之，如果想保证数据的完整性，就一定要使用exit()函数。
    请看以下例程：

#include<stdlib.h>int main(){   printf("output begin\n");   printf("content in buffer\n");   exit(0);//输出前两句，程序在次退出；}

运行结果：

 从运行结果来看，exit(0)是函数正常的退出；

#include<unistd.h>int main() {    printf("output begin\n");    printf("content in buffer");    _exit(0);//直接清空缓存空间，可能造成数据损失，不善后处理；}

运行结果：

       此时可以看出，_exit(0)函数直接退出清空数据，硬退出，而没有管缓冲区的数据，也没有写会文件或者对缓冲区的数据做善后处理，只输出了一句，第二句的数据丢失了，相反exit(0)则会对缓冲区的数据进行处理后终止，例如写会文件，打印等等一些后续。