今天面试官告诉我多线程才能提供服务端的并发

anders0913

多线程？呵呵，告诉他自备塑料袋，死的惨了，没人给他收尸

voipexplore

果然小白。
番出以前的帖子看看：
“多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。”
-------这个适用场景是，各个进程之间通讯交互少，藕荷少，很适合多进程方式

“多线程是平面交通系统，造价低，但红绿灯太多，老堵车。”
-------这个原因是业务决定了，各模块间交互频繁，藕荷性高，适合多线程。

“高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。”
------不是主张多进程，实在是它产生与1983年，那时侯多线程标准混乱，接口不友好。直到90年代，POSIX1003.4a小组才统一了这种局面。TUXEDO作为中间件，多进程的分布式灵活部署，以及高性能硬件的机器参与，促成了TUXEDO的高性能。

总之，多进程多线程的使用场景不同，多进程可以更灵活的分布式部署，整合更多的机器。藕荷性高数据交互频繁的单个模块内适合多线程。

至于协议栈和业务层使用独立进程，中间共享内存通讯，除了底层的人藐视业务层人的开发能力，实在想不出其他原因。
另外，web服务器这种各个连接间均不通讯的简单应用场景，实际开发中是少而又少。

netgc

关注中

cskyrain

貌似有道理

laura.kylin

这种烂问题，主要看服务器做什么工作，一概而论而单纯讨论进程和线程的性能差别都是无意义的！
唉，什么世道！

我要思考

我来总结一下吧。 这几天自己在写一个IM 服务器.发现无论是用多进场还是多线程 具体是看业务类型。 一味的说多进程或多线程能提高并发,是不太可取的。 更多的时候可能多进程和多线程同时使用。

这个帖子算是娱乐贴吧.

apsong

原帖由 我要思考 于 2009-12-28 19:35 发表
今天面试我问面试官，怎么有效的提高服务端的并发能力。他告诉我用多线程。我问他为什么CU论坛的高手大都说做服务端用多进程比多线程并发高。还把我当小白问，问我多进程和多线程的区分。我直接说线程上下文切换效率底。他不回答我，让我自己看文档去。

“线程上下文切换效率低”，是指单进程不需要“上下文切换”，还是指进程间切换效率高于进程内线程切换效率？
还是其它？我晕掉了……

zylthinking

多进程确实看上去没有锁的问题， 不过只是现象吧。
多线程之所以有锁， 是因为要并发访问共享数据， 多进程访问共享内存的时候， 就可以不用锁？
除了专门想的免锁算法， 似乎也做不到， 另一方面， 多线程难道就不能使用免锁算法了？

所以， 说多进程怎么怎么高性能的， 至少这个理由靠不住的。
之所以unix like操作系统上多进程模式服务器多些， 多半是历史原因吧。

axlrose

此贴必火，占位观看

dooros

进程。。。线程。。。 哪个NB ？