多线程和多进程的区别（C++）

很想写点关于多进程和多线程的东西，我确实很爱他们。但是每每想动手写点关于他们的东西，却总是求全心理作祟，始终动不了手。

今天终于下了决心，写点东西，以后可以再修修补补也无妨。

一.为何需要多进程（或者多线程），为何需要并发？

这个问题或许本身都不是个问题。但是对于没有接触过多进程编程的朋友来说，他们确实无法感受到并发的魅力以及必要性。

我想，只要你不是整天都写那种int main()到底的代码的人，那么或多或少你会遇到代码响应不够用的情况，也应该有尝过并发编程的甜头。就像一个快餐点的服务员，既要在前台接待客户点餐，又要接电话送外卖，没有分身术肯定会忙得你焦头烂额的。幸运的是确实有这么一种技术，让你可以像孙悟空一样分身，灵魂出窍，乐哉乐哉地轻松应付一切状况,这就是多进程/线程技术。

并发技术，就是可以让你在同一时间同时执行多条任务的技术。你的代码将不仅仅是从上到下，从左到右这样规规矩矩的一条线执行。你可以一条线在main函数里跟你的客户交流，另一条线，你早就把你外卖送到了其他客户的手里。

所以，为何需要并发？因为我们需要更强大的功能，提供更多的服务，所以并发，必不可少。

二.多进程

什么是进程。最直观的就是一个个pid,官方的说法就：进程是程序在计算机上的一次执行活动。

说得简单点，下面这段代码执行的时候

进入main函数，这就是一个进程，进程pid会打印出来，然后运行到return，该函数就退出，然后由于该函数是该进程的唯一的一次执行，所以return后，该进程也会退出。

看看多进程。linux下创建子进程的调用是fork();

i am the child process, my process id is 15806
the exit pid:15806
i am the parent process, my process id is 15805
the exit pid:15805

这是gcc测试下的运行结果。

关于fork函数，功能就是产生子进程，由于前面说过，进程就是执行的流程活动。

那么fork产生子进程的表现就是它会返回2次，一次返回0，顺序执行下面的代码。这是子进程。

一次返回子进程的pid，也顺序执行下面的代码，这是父进程。

（为何父进程需要获取子进程的pid呢？这个有很多原因，其中一个原因：看最后的wait，就知道父进程等待子进程的终结后，处理其task_struct结构，否则会产生僵尸进程,扯远了，有兴趣可以自己google）。

如果fork失败，会返回-1.

额外说下atexit( print_exit ); 需要的参数肯定是函数的调用地址。

这里的print_exit 是函数名还是函数指针呢？答案是函数指针，函数名永远都只是一串无用的字符串。

某本书上的规则：函数名在用于非函数调用的时候，都等效于函数指针。

说到子进程只是一个额外的流程，那他跟父进程的联系和区别是什么呢？

我很想建议你看看linux内核的注解（有兴趣可以看看，那里才有本质上的了解），总之,fork后，子进程会复制父进程的task_struct结构，并为子进程的堆栈分配物理页。理论上来说，子进程应该完整地复制父进程的堆，栈以及数据空间，但是2者共享正文段。

关于写时复制：由于一般 fork后面都接着exec，所以，现在的 fork都在用写时复制的技术，顾名思意，就是，数据段，堆，栈，一开始并不复制，由父，子进程共享，并将这些内存设置为只读。直到父，子进程一方尝试写这些区域，则内核才为需要修改的那片内存拷贝副本。这样做可以提高 fork的效率。

三.多线程

线程是可执行代码的可分派单元。这个名称来源于“执行的线索”的概念。在基于线程的多任务的环境中，所有进程有至少一个线程，但是它们可以具有多个任务。这意味着单个程序可以并发执行两个或者多个任务。

简而言之，线程就是把一个进程分为很多片，每一片都可以是一个独立的流程。这已经明显不同于多进程了，进程是一个拷贝的流程，而线程只是把一条河流截成很多条小溪。它没有拷贝这些额外的开销，但是仅仅是现存的一条河流，就被多线程技术几乎无开销地转成很多条小流程，它的伟大就在于它少之又少的系统开销。（当然伟大的后面又引发了重入性等种种问题，这个后面慢慢比较）。

还是先看linux提供的多线程的系统调用：

第一个参数为指向线程标识符的指针。
第二个参数用来设置线程属性。
第三个参数是线程运行函数的起始地址。
最后一个参数是运行函数的参数。

这个多线程的例子应该很明了了，主线程做自己的事情，生成2个子线程，task1为分离，任其自生自灭，而task2还是继续送外卖，需要等待返回。（因该还记得前面说过僵尸进程吧，线程也是需要等待的。如果不想等待，就设置线程为分离线程）

 额外的说下，linux下要编译使用线程的代码，一定要记得调用pthread库。如下编译：

 gcc -o pthrea -pthread  pthrea.c

四.比较以及注意事项

1.看完前面，应该对多进程和多线程有个直观的认识。如果总结多进程和多线程的区别，你肯定能说，前者开销大，后者开销较小。确实，这就是最基本的区别。

2.线程函数的可重入性：

说到函数的可重入，和线程安全，我偷懒了，引用网上的一些总结。

线程安全：概念比较直观。一般说来，一个函数被称为线程安全的，当且仅当被多个并发线程反复调用时，它会一直产生正确的结果。

可重入：概念基本没有比较正式的完整解释，但是它比线程安全要求更严格。根据经验，所谓“重入”，常见的情况是，程序执行到某个函数foo()时，收到信号，于是暂停目前正在执行的函数，转到信号处理函数，而这个信号处理函数的执行过程中，又恰恰也会进入到刚刚执行的函数foo()，这样便发生了所谓的重入。此时如果foo()能够正确的运行，而且处理完成后，之前暂停的foo()也能够正确运行，则说明它是可重入的。

线程安全的条件：

要确保函数线程安全，主要需要考虑的是线程之间的共享变量。属于同一进程的不同线程会共享进程内存空间中的全局区和堆，而私有的线程空间则主要包括栈和寄存器。因此，对于同一进程的不同线程来说，每个线程的局部变量都是私有的，而全局变量、局部静态变量、分配于堆的变量都是共享的。在对这些共享变量进行访问时，如果要保证线程安全，则必须通过加锁的方式。

可重入的判断条件：

要确保函数可重入，需满足一下几个条件：

1、不在函数内部使用静态或全局数据 
2、不返回静态或全局数据，所有数据都由函数的调用者提供。 
3、使用本地数据，或者通过制作全局数据的本地拷贝来保护全局数据。
4、不调用不可重入函数。

可重入与线程安全并不等同，一般说来，可重入的函数一定是线程安全的，但反过来不一定成立。它们的关系可用下图来表示：

比如：strtok函数是既不可重入的，也不是线程安全的；加锁的strtok不是可重入的，但线程安全；而strtok_r既是可重入的，也是线程安全的。

如果我们的线程函数不是线程安全的，那在多线程调用的情况下，可能导致的后果是显而易见的——共享变量的值由于不同线程的访问，可能发生不可预料的变化，进而导致程序的错误，甚至崩溃。

3.关于IPC(进程间通信)

由于多进程要并发协调工作，进程间的同步，通信是在所难免的。

稍微列举一下linux常见的IPC.

linux下进程间通信的几种主要手段简介：

1. 管道（Pipe）及有名管道（named pipe）：管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信；
2. 信号（Signal）：信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；linux除了支持Unix早期信号语义函数sigal外，还支持语义符合Posix.1标准的信号函数sigaction（实际上，该函数是基于BSD的，BSD为了实现可靠信号机制，又能够统一对外接口，用sigaction函数重新实现了signal函数）；
3. 报文（Message）队列（消息队列）：消息队列是消息的链接表，包括Posix消息队列system V消息队列。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
4. 共享内存：使得多个进程可以访问同一块内存空间，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。
5. 信号量（semaphore）：主要作为进程间以及同一进程不同线程之间的同步手段。
6. 套接口（Socket）：更为一般的进程间通信机制，可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的，但现在一般可以移植到其它类Unix系统上：Linux和System V的变种都支持套接字。

或许你会有疑问，那多线程间要通信，应该怎么做？前面已经说了，多数的多线程都是在同一个进程下的，它们共享该进程的全局变量，我们可以通过全局变量来实现线程间通信。如果是不同的进程下的2个线程间通信，直接参考进程间通信。

4.关于线程的堆栈

说一下线程自己的堆栈问题。

是的，生成子线程后，它会获取一部分该进程的堆栈空间，作为其名义上的独立的私有空间。（为何是名义上的呢？)由于，这些线程属于同一个进程，其他线程只要获取了你私有堆栈上某些数据的指针，其他线程便可以自由访问你的名义上的私有空间上的数据变量。（注：而多进程是不可以的，因为不同的进程，相同的虚拟地址，基本不可能映射到相同的物理地址）

5.在子线程里fork

看过好几次有人问，在子线程函数里调用system或者 fork为何出错，或者fork产生的子进程是完全复制父进程的吗？

我测试过，只要你的线程函数满足前面的要求，都是正常的。

上面这段代码就可以正常得调用ls指令。

不过，在同时调用多进程（子进程里也调用线程函数）和多线程的情况下，函数体内很有可能死锁。

具体的例子可以看看这篇文章。

Linux内核对多进程和多线程的支持方式：

        线程机制支持并发程序设计技术，在多处理器上能真正保证并行处理。而在linux实现线程很特别，linux把所有的线程都当作进程实现。linux下线程看起来就像普通进程(只是该进程和其他进程共享资源，如地址空间)。上述机制与Microsoft windows或是Sun Solaris实现差异很大。

        Linux的线程实现是在核外进行的，核内提供的是创建进程的接口do_fork()。内核提供了两个系统调用__clone()和fork()，最终都用不同的参数调用do_fork()核内API。 do_fork() 提供了很多参数，包括CLONE_VM（共享内存空间）、CLONE_FS（共享文件系统信息）、CLONE_FILES（共享文件描述符表）、CLONE_SIGHAND（共享信号句柄表）和CLONE_PID（共享进程ID，仅对核内进程，即0号进程有效）。当使用fork系统调用产生多进程时，内核调用do_fork()不使用任何共享属性，进程拥有独立的运行环境。当使用pthread_create()来创建线程时，则最终设置了所有这些属性来调用__clone()，而这些参数又全部传给核内的do_fork()，从而创建的”进程”拥有共享的运行环境，只有栈是独立的，由 __clone()传入。

         即：Linux下不管是多线程编程还是多进程编程，最终都是用do_fork实现的多进程编程，只是进程创建时的参数不同，从而导致有不同的共享环境。Linux线程在核内是以轻量级进程的形式存在的，拥有独立的进程表项，而所有的创建、同步、删除等操作都在核外pthread库中进行。pthread 库使用一个管理线程（__pthread_manager() ，每个进程独立且唯一）来管理线程的创建和终止，为线程分配线程ID，发送线程相关的信号，而主线程pthread_create()） 的调用者则通过管道将请求信息传给管理线程。

很多朋友都说使用多线程的好处是资源占用少，其隐含之意就是说进程占用资源比线程多，对吧？但实际上Linux下多进程是否就真的点用很多资源呢？暂且不说进程是否比线程占用资源多，就进程占用资源的多少情况而言，Linux确实是做得相当节省的。产生一个多进程时肯定是要产生的一点内存是要复制进程表项，即一个task_struct结构，但这个结构本身做得相当小巧。其它对于一个进程来说必须有的数据段、代码段、堆栈段是不是全盘复制呢？对于多进程来说，代码段是肯定不用复制的，因为父进程和各子进程的代码段是相同的，数据段和堆栈段呢？也不一定，因为在Linux里广泛使用的一个技术叫copy-on-write，即写时拷贝。copy-on-write意味着什么呢？意味着资源节省，假设有一个变量x在父进程里存在，当这个父进程创建一个子进程或多个子进程时这个变量x是否复制到了子进程的内存空间呢？不会的，子进程和父进程使用同一个内存空间的变量，但当子进程或父进程要改变变量x的值时就会复制该变量，从而导致父子进程里的变量值不同。父子进程变量是互不影响的，由于父子进程地址空间是完全隔开的，变量的地址可以是完全相同的。

          Linux的”线程”和”进程”实际上处于一个调度层次，共享一个进程标识符空间，这种限制使得不可能在Linux上实现完全意义上的POSIX线程机制，因此众多的Linux线程库实现尝试都只能尽可能实现POSIX的绝大部分语义，并在功能上尽可能逼近。Linux进程的创建是非常迅速的。内核设计与实现一书中甚至指出Linux创建进程的速度和其他针对线程优化的操作系统（Windows,Solaris）创建线程的速度相比，测试结果非常的好，也就是说创建速度很快。由于异步信号是内核以进程为单位分发的，而LinuxThreads的每个线程对内核来说都是一个进程，且没有实现”线程组”，因此，某些语义不符合POSIX标准，比如没有实现向进程中所有线程发送信号，README对此作了说明。LinuxThreads中的线程同步很大程度上是建立在信号基础上的，这种通过内核复杂的信号处理机制的同步方式，效率一直是个问题。LinuxThreads 的问题，特别是兼容性上的问题，严重阻碍了Linux上的跨平台应用（如Apache）采用多线程设计，从而使得Linux上的线程应用一直保持在比较低的水平。在Linux社区中，已经有很多人在为改进线程性能而努力，其中既包括用户级线程库，也包括核心级和用户级配合改进的线程库。目前最为人看好的有两个项目，一个是RedHat公司牵头研发的NPTL（Native Posix Thread Library），另一个则是IBM投资开发的NGPT（Next Generation Posix Threading），二者都是围绕完全兼容POSIX 1003.1c，同时在核内和核外做工作以而实现多对多线程模型。这两种模型都在一定程度上弥补了LinuxThreads的缺点，且都是重起炉灶全新设计的。

          综上所述的结论是在Linux下编程多用多进程编程少用多线程编程。

         IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际编程之后，综合来看我觉得linux更适合做high performance server，不过在多线程这个具体的领域内，linux还是稍逊windows一点。这应该是情有可原的，毕竟unix家族都是从多进程过来的，而 windows从头就是多线程的。

如果是UNIX/linux环境，采用多线程没必要。

多线程比多进程性能高？误导！

应该说，多线程比多进程成本低，但性能更低。

在UNIX环境，多进程调度开销比多线程调度开销，没有显著区别，就是说，UNIX进程调度效率是很高的。内存消耗方面，二者只差全局数据区，现在内存都很便宜，服务器内存动辄若干G，根本不是问题。

多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。

多线程是平面交通系统，造价低，但红绿灯太多，老堵车。

我们现在都开跑车，油（主频）有的是，不怕上坡下坡，就怕堵车。

高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。TUXEDO是贝尔实验室的，与UNIX同宗，应该是对UNIX理解最为深刻的，他们的意见应该具有很大的参考意义。

多进程多线程优缺点：

在Linux下编程多用多进程编程少用多线程编程。

         IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际编程之后，综合来看我觉得linux更适合做high performance server，不过在多线程这个具体的领域内，linux还是稍逊windows一点。这应该是情有可原的，毕竟unix家族都是从多进程过来的，而 windows从头就是多线程的。

如果是UNIX/linux环境，采用多线程没必要。

多线程比多进程性能高？误导！

应该说，多线程比多进程成本低，但性能更低。

在UNIX环境，多进程调度开销比多线程调度开销，没有显著区别，就是说，UNIX进程调度效率是很高的。内存消耗方面，二者只差全局数据区，现在内存都很便宜，服务器内存动辄若干G，根本不是问题。

多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。

多线程是平面交通系统，造价低，但红绿灯太多，老堵车。

我们现在都开跑车，油（主频）有的是，不怕上坡下坡，就怕堵车。

高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。TUXEDO是贝尔实验室的，与UNIX同宗，应该是对UNIX理解最为深刻的，他们的意见应该具有很大的参考意义。

From: