趋势的一道面试题：网络编程中设计并发服务器，使用多进程 与 多线程 ，请问有什么区别？

[xlookfor]

rt

[gnixemos]

进程间通信开销也比较大

但是进程间安全

[bm1408]

问这个题目的人，我估计它有。。。。。。。

[vcan]

呵呵，这个问题，唉
首先回答他线程和进程之间的区别，即包括各自的优点，也包括各自的缺点

我根本就不赞成用多进程模式。我感觉，几乎没有无法用多线程代替的多进程。之所以现在有很多多进程系统，很大因素就是因为开发团队无法有效控制复杂进程的开发，只好利用进程间天然的安全性来保护各个模块，但也带来了很大的代价－－多余的进程通信代码，大的进程开销。

[fytzzh]

1，进程：子进程是父进程的复制品。子进程获得父进程数据空间、堆和栈的复制品。
2，线程：相对与进程而言，线程是一个更加接近与执行体的概念，它可以与同进程的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。
两者都可以提高程序的并发度，提高程序运行效率和响应时间。
线程和进程在使用上各有优缺点：线程执行开销小，但不利于资源管理和保护；而进程正相反。同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。

[allen_wang]

但是，有时候在企业级的应用中，稳定压倒一切。
一些多余的开销，在那种1000多万的服务器上，和稳定性要求比起来，还不是很重要。。。

[allen_wang]

多线程模型，每个连接的开销比较小（切换开销，资源开销等）
多进程模型，开销相对多线程要大些，但是也有他的好处，不用过多考虑线程模型中全局资源的互斥使用，如果存在资源泄漏，每个连接推出后，进程结束，所有资源都释放，不会有泄漏。而线程模型会积累这种泄漏的资源。

随便瞎写的。呵呵。

[allen_wang]

vcan
你的观点我同意，我只是针对进程退出会释放资源而说的一种可能的情况。

关于设计，好的设计固然是很重要的。
但是，有时候设计的太好了（或者说太过了），对于真正的研发团队来说，反而有很大的难度。尤其是在很强的schedule压力下。
我知道有设计的太过，研发2年而放弃重来的项目。
也有要在短短半年内靠个位数的团队弄出win、solaris、linux多平台的几十万行项目的schedule。

因而，有很多时候，不是我们想要做到多好，就能做到多好的。
对于客户而言，很笨，但是能够马上解决问题的办法，就是好办法。

[wb19822002]

多线程的优势：
1. 创建与环境切换开销少
2. 同步的开销少（进程间同步一般牵涉OS内核）
3. 数据复制可通过“进程局部内存”

多线程的局限性：
1. 性能损失
（1）单处理器、“计算任务繁重”的应用程序不会从多线程中获益
（2）高精度的锁定策略会带来高同步开销
2. 健壮性降低
线程之间接收到的“MMU保护”很少或没有
3. 缺乏高精度的访问控制

摘自《C++网络编程（卷I）》,学习中。。。。。。

[vcan]

allen_wang

我不赞成这种观点，服务的稳定性不是靠多进程能够实现的。要看系统的逻辑关系。如果4个功能模块是串联关系，则系统稳定性是串行模型，其稳定性将主要取决于稳定性最差的那个模块，且还要差一些。如果是并行模型，则稳定性主要取决于稳定性最好的模块，且还要好一点。与利用进程或利用线程设计无关。这两种方法都可实现并行或串行方案。

且既然买1000多万的服务器，必是其访问量很大，如果效率设计不好，效果会非常差，因为每个访问的资源多占用一点点，整个服务器就会增加很多负担。因此，越是关键服务，越要认真考虑设计，而不要寄期望于购买的设备。

[iorizht]

好帖

[OpenHero]

线程池

[lovememememe]

mark

[sankt]

学习