找回密码
 FreeOZ用户注册
查看: 2510|回复: 22
打印 上一主题 下一主题

[论坛技术] 多线程和多进程?

[复制链接]
跳转到指定楼层
1#
发表于 19-2-2010 22:01:38 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?FreeOZ用户注册

x
求高手讲解。
到底什么时候用哪个?
做TCP server-client 时,对多个clients是用多线程还是多进程呢?
回复  

使用道具 举报

2#
发表于 20-2-2010 14:59:59 | 只看该作者
同时开两个迅雷叫多进程,一个迅雷同时连两个服务器叫多线程

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

3#
发表于 20-2-2010 15:01:51 | 只看该作者

回复 #1 GPS 的帖子

提示: 作者被禁止或删除, 无法发言
线程 是 串行的,
进程 是 并行的。

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

4#
 楼主| 发表于 20-2-2010 21:39:43 | 只看该作者
回复  

使用道具 举报

5#
 楼主| 发表于 20-2-2010 21:41:46 | 只看该作者
原帖由 dack 于 20-2-2010 14:59 发表
同时开两个迅雷叫多进程,一个迅雷同时连两个服务器叫多线程


那么多个迅雷链接同一个服务器时,服务器是fork 多个进程还是生成多个线程呢?
回复  

使用道具 举报

6#
发表于 20-2-2010 22:58:29 | 只看该作者
多线程和多进程都是为了并发处理,线程相对于进程来说对资源的要求小,切换的代价低.

用多线程就可以了.

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

7#
发表于 20-2-2010 23:39:24 | 只看该作者
原帖由 xblues 于 20-2-2010 15:01 发表
线程 是 串行的,
进程 是 并行的。


这个误导了吧?线程就是轻量型进程,本来是Unix上面特有的东东,当然windows也早就有了

线程的系统消耗少,便于内部通讯,线程和进程都可以进行并发处理

楼主的例子,tcp client,可以多进程也可以多线程,你可以每一个客户请求都建立一个进程(fork)单独处理,也可以建立一个线程处理

前者系统消耗比较大,所以现在一般这样的应用都是用线程来处理

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

8#
发表于 20-2-2010 23:46:02 | 只看该作者
原帖由 xblues 于 20-2-2010 15:01 发表
线程 是 串行的,
进程 是 并行的。

首先取决与CPU数量。
如果你只有一个CPU,那你永远不可能并行。
在有多个CPU的情况下,呵呵,可以实现。

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

9#
发表于 21-2-2010 10:57:47 | 只看该作者
原帖由 GPS 于 20-2-2010 21:41 发表


那么多个迅雷链接同一个服务器时,服务器是fork 多个进程还是生成多个线程呢?


这个要看服务器的软件怎么处理,估计都是多线程。不过你要编个多进程的服务器软件,技术上估计也是可行的吧。

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

10#
发表于 21-2-2010 15:58:44 | 只看该作者
我过去开发过银行ATM通信和处理程序。通信进程的实现方式有两种,一种是每收到一个请求,主程序生成一个子进程来处理该请求,该进程负责接收请求,发送给服务进程,然后等待回复,并且将应答发送给ATM。这种方式的缺点是进程数量太多,想想一个银行可能有几百上千台ATM(一个大城市),同时可能有几十上百台ATM在与主机通信,这样通信进程可能有几十上百个,对系统资源是很大的消耗。

我的实现方式是采用线程,一个通信进程可以产生若干线程(比如二十个)组成两个线程Pool,其中一部分用于接收请求,另一部分用于发送应答,由于这些线程可以共享进程的内存资源,因此一个请求完全可以由两个线程来处理,并且把原来一个进程的同步方式改成了异步方式。由于采用异步方式,20个线程往往可以达到50个进程同样的处理速度,而且对ATM的应答更快。

叙述不一定完全准确,毕竟是我96年开发的程序了。我一个同事当年开发了网络小蚂蚁,也用的类似技术。

评分

参与人数 2威望 +40 收起 理由
procoder + 30 我也做过一样的程序。
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

11#
发表于 21-2-2010 19:06:40 | 只看该作者
如果你的服务器对于业务的响应主要是一对一的无状态服务,那多进程并发就很好。
如果你的服务器需要大量的业务间通信,同时效率是一个非常重要的考虑因素,那多线程可能会比较合适。

还要看你的支撑库有哪些。如果是白手兴家,多进程开发比多线程发发难度小很多。
而开发语言也是一个考虑因素。C语言中fork一个进程是很简单的事,在Java里,启动一个新进程会让你头痛很久。

原帖由 GPS 于 19-2-2010 22:01 发表
求高手讲解。
到底什么时候用哪个?
做TCP server-client 时,对多个clients是用多线程还是多进程呢?

评分

参与人数 1威望 +10 收起 理由
GPS + 10 谢谢分享!

查看全部评分

回复  

使用道具 举报

12#
 楼主| 发表于 21-2-2010 22:03:17 | 只看该作者
多谢各位指点,受益不小。
总结一下,能用线程的就不用进程,主要为了节省开支,提高效率。
多线程增加了技术上的难度,所以还要考虑开发平台的因素。
如果有啥理解不对的,大家再指点啊。
我有1,2百个mobile clients要长时间的保持连接,实时通讯,那么是用一个进程,多个线程好呢?还是先分几个进程,每个进程再用多线程?
方法一相对简单一点,方法二可以把开销分到几个SERVER上,有必要吗?
回复  

使用道具 举报

13#
发表于 21-2-2010 22:49:57 | 只看该作者
mobile client一般流量不大,访问强度不大,虽然是长连接,但事实上和短连接区别不大。
线程比进程的开销小很多,如果你很执着于系统的最小化,这个业务采用多线程、线程池的模式会很好。
另一方面,如果你根本不在乎系统的大小,多进程有利于你这个“长连接”的实现,毕竟一个连接一个fork()很直观。

以Java为例,你可以考虑一些相对成熟的网络实现基础库,比如Netty, Mina(说实话,也不算成熟,buggy),
由这个库提供的线程池支持来实现业务响应,你根本不需要在线程维护、连接维护上下过多的功夫。
我没有用过C++的ACE库,但听说这东西很好很强大,有经验的同学来介绍一下。

如果你什么也没有,白手兴家,又要快速成型,那就一个连接fork()一个进程吧。一两百个mobile client,随便找一台PC server就搞定了。
我以前用一台sparc20就搞定上千的实时长连接,几千的实时长连接也就一台p4 server,1G内存来搞定。

原帖由 GPS 于 21-2-2010 22:03 发表
多谢各位指点,受益不小。
总结一下,能用线程的就不用进程,主要为了节省开支,提高效率。
多线程增加了技术上的难度,所以还要考虑开发平台的因素。
如果有啥理解不对的,大家再指点啊。
我有1,2百个mobile c ...
回复  

使用道具 举报

14#
 楼主| 发表于 22-2-2010 10:10:17 | 只看该作者
因为是长连接,客户相对稳定,但是mobile client的连接不稳定,要经常反复连接,是不是可以采用,线程不断,当SOCKET断开,重新连接时再把新的socket交给原来的连接来处理,这样可以避免线程维护。这方法实际可行吗? 还是现成的线程池比较简单呢?
回复  

使用道具 举报

15#
发表于 22-2-2010 13:28:53 | 只看该作者
你这里涉及到两个概念,一个是连接,另一个是会话。socket的处理是连接管理,而你的所谓“长连接”则是会话的管理,这是两个不同的概念。
至于是否线程,这个不是太有所谓。

我没有mobile client的运营经验,但我很怀疑你的这个说法:mobile client的连接不稳定。因为mobile网络协议本身就能在一定程度上容错,
让连接变得相对稳定。当然,一定要和有线网络连接相比,那是不行的,但很不稳定就算不上了。

举一个可行的实现例子吧。以多进程实现为例,每一个socket accept产生一个新的进程,客户端保存自己的session id以做识别,再以
session id为key,数据库中保存所有的会话记录、状态记录、transaction等,整个程序以数据库共享进行通信。
我想这样的架构基本上可以满足你的要求了。

多线程实现的话,可以把一些临时的会话信息入在内存,把客户间的信息交互做成直接的程序内部运算,以提高响应效率,其他需要persistent的信息
放入数据库中即可。

原帖由 GPS 于 22-2-2010 10:10 发表
因为是长连接,客户相对稳定,但是mobile client的连接不稳定,要经常反复连接,是不是可以采用,线程不断,当SOCKET断开,重新连接时再把新的socket交给原来的连接来处理,这样可以避免线程维护。这方法实际可行吗? ...

评分

参与人数 1威望 +20 收起 理由
GPS + 20 谢谢分享!

查看全部评分

回复  

使用道具 举报

16#
 楼主| 发表于 22-2-2010 14:21:15 | 只看该作者
mobile连接不稳定我是指当没有信号的时候,GPRS连接就会断了,比如进入隧道,或者地下室,或者当有电话打进时候,好像TCPl连接也会中断。
你说的对,是指保持会话。
当GPRS连接断掉了,进程也中断,你上面说的架构是通过保存状态来恢复。
我原来想是GPRS断了,但是不中断进程,而在新联接中识别该会话是否已经存在,如果存在,就用原来的进程,否则从新建个进程。好像复杂化了,还是你的方法可行。
谢谢。

评分

参与人数 1威望 +30 收起 理由
procoder + 30 谢谢分享!

查看全部评分

回复  

使用道具 举报

17#
发表于 23-2-2010 19:41:44 | 只看该作者
能用多线程都用多线程,线程比进程轻装,通信容易。
回复  

使用道具 举报

18#
发表于 23-2-2010 19:42:58 | 只看该作者
原帖由 GPS 于 22-2-2010 14:21 发表
mobile连接不稳定我是指当没有信号的时候,GPRS连接就会断了,比如进入隧道,或者地下室,或者当有电话打进时候,好像TCPl连接也会中断。
你说的对,是指保持会话。
当GPRS连接断掉了,进程也中断,你上面说的架构 ...

可以做一个GPRS服务程序来完成这个功能。我做的3G是一个模块,每次通信检查一下,有链接就通信,没有就重连。
回复  

使用道具 举报

19#
发表于 24-2-2010 01:06:12 | 只看该作者
进程的隔离级别要高,但相应的通信也要麻烦些,一般在同一台机器内的多进程系统比较少见。
我曾经做过一个多进程的插件系统构架,支持把插件加载到不同的进程中。进程间用内存映射文件和Remoting通信。当时主要的目的是:在一个插件崩溃时完全不影响其它插件,最大化保证系统的稳定性;插件可以独立卸载,实现不停机升级

评分

参与人数 2威望 +45 收起 理由
GPS + 15 谢谢分享!
procoder + 30 谢谢分享!

查看全部评分

回复  

使用道具 举报

20#
发表于 24-2-2010 02:13:42 | 只看该作者
说句题外话,用了一段时间的iphone,optus网络,感觉实在是很不爽,有时候显示3G,实际却和没连接一样。
不知道是网络问题,服务器端的程序问题,还是iphone的问题。
回复  

使用道具 举报

21#
发表于 24-2-2010 11:28:34 | 只看该作者
原帖由 woodheadz 于 24-2-2010 01:06 发表
进程的隔离级别要高,但相应的通信也要麻烦些,一般在同一台机器内的多进程系统比较少见。
我曾经做过一个多进程的插件系统构架,支持把插件加载到不同的进程中。进程间用内存映射文件和Remoting通信。当时主要的目 ...

多的,Chrome就是这样。
回复  

使用道具 举报

22#
发表于 24-2-2010 11:28:53 | 只看该作者
上面的回复,多的=对的
回复  

使用道具 举报

23#
 楼主| 发表于 24-2-2010 13:16:41 | 只看该作者
原帖由 procoder 于 23-2-2010 19:42 发表

可以做一个GPRS服务程序来完成这个功能。我做的3G是一个模块,每次通信检查一下,有链接就通信,没有就重连。


在mobile端,如果由于GPRS断了,检查到的TCP连接状态确是好的,不知道是什么原因,是不是必须检查GPRS的状态?可是,如果GPRS在,也不能说明TCP在呀。
在SERVER端,由于见到的只是TCP连接,也不能检查GPRS状态。
因为要时刻让两端都能检查状态,我是从两端没隔个时间,就发个信号,如果那一端在一定时间内没收到,就认为断了,并主动切断连接。mobile端当发现错误后就主动建立连接。这样可保证server端在连接中断后,仍然可以等待连接再建立。好像有本书是这么说的。
大家给看看是否合理。
回复  

使用道具 举报

您需要登录后才可以回帖 登录 | FreeOZ用户注册

本版积分规则

小黑屋|手机版|Archiver|FreeOZ论坛

GMT+11, 1-2-2025 08:56 , Processed in 0.074625 second(s), 52 queries , Gzip On, Redis On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表