###用简单的例子说明, 你如果想同时拨电话给 A, B,那么可以这么做.
用两个电话, 分别拨出,然后分别对他们说话 -- 多线程设计,线程共享全局数据
###找小张,小王,让他们分别打电话给A,B -- 多进程设计,多进程的数据是完全隔离,必须通过进程间通信,解决数据共享的问题.
进程比线程更健壮稳定,但是设计更为复杂. 多线程很容易同步状态,相当于一个人同时处理多个任务, 多进程难度就比较高,相当于团队管理. UI中线程运用较多. 高性能服务设计当中,只用进程,因为隔离度高.
比如Oracle/msqlserver 都有专门的进程负责读写,专门的进程负责记录日志,专门的进程负责网络连接.... 非对等多进程(进程分别负责不同的事情),可以非常好的管理并发问题. 而mysql 是对等多线程/进程(所有进程/线程做同样的事情), 必然遇到争用的问题, 所以mysql 是无法很好处理并发写,除非整个软件重写. 这也是宏哥认为mysql 不是数据库的其中一个原因.
Open source的大多软件,都可以作为反面教材,尤其是在软件设计领域.
同时win 的进程和 linux进程有所不同. Linux对父进程进行完整拷贝,win 类似linux中轻进程.互相不等价.
线程比进程更快,是完全扯淡的东西. 线程唯一的优势是数据共享简单,以及Bootstrap成本更低,代价就是一个线程出问题,全部挂掉. 典型比如Java虚拟机这个烂玩意.
~~~~聊天室 就是用的线程 如果用进程的话 系统不一会就端口不够用了 内存什么的也不够 好处是：我想T人 直接根据套接字或者IP 在socket层一脚T掉 每个连接都是一个线程 缺点是必须写client端 服务器本身是进程用来接收线程 统一80端口 QQ也是这个模式
~~~~~~ 明显的舆论倾向有时候是集体的醒悟, 有时候也是集体的愚昧迷信. (就像一群死囚犯互相鼓励说,政府免除我们死刑了,免除了,免除了,虽然让人暂时幻想暂时解脱,但事实永远会来到.)
面向对象曾经的极力鼓吹就是一例. 个人同样觉得多进程被鼓吹的有点过了.(或许是因为对google的chrome方案的崇拜吧)
多进程和多线程的本质其实很清楚.就那么几条. 2种模型有好有坏,重复教科书的概念是没意义的. win是非常正统的实现了的教科书式线程模型, 多线程用在win上很合适. 在linux/unix上多线程性能好处不那么大了. 但在win下, 还照搬linux的经验一定要鼓吹全面多进程化, 就让人不明白了, 有好东西 你还不爱用??? 至于通信的复杂度,我觉得多进程/多线程 各有各的痛苦,难兄难弟, 但多线程不人性化. (多进程人性化的原因是因为它只剩较人性化方案:消息队列可用了, : ) ) 出错后隔离资源(不必再费劲初始化) ,多进程稳赢. 性能上 多线程稳赢. 看各自需求了.
崩溃的问题, 多进程里代码崩溃后,通信是一样要停滞下来; 多线程模型中捕获异常后重启逻辑,或者重启整个进程, 大家效果是一样的. 如同" java程序不会崩溃, 只是会报异常, 而C++程序会崩溃, 简直太可怕了.好恐怖. " 只能冷笑,好像用上异常 逻辑就可以一路无错顺畅的跑到死. 崩溃和异常对于逻辑本质上有区别吗? no. 进程崩了,你还得操心把它重启, 正对应着 多线程下, 程序崩溃了,你要重启整个进程,或者能想出完美的资源释放/逻辑重置方案 继续运行下去. 出错处理,没人可以省心.
分析自己应用的具体状况, 2者混合用,最佳. firefox把plugincontainer分出去.利用了多进程的优点,把爱崩溃,资源状况复杂的垃圾插件丢出去, 就是非常nice的设计.