<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>中文 &#187; yah99wolf</title>
	<atom:link href="http://software.intel.com/zh-cn/blogs/author/yah99wolf/feed/" rel="self" type="application/rss+xml" />
	<link>http://software.intel.com/zh-cn/blogs</link>
	<description></description>
	<lastBuildDate>Mon, 28 May 2012 14:23:20 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
		<item>
		<title>鱼还是熊掌：浅谈多进程多线程的选择</title>
		<link>http://software.intel.com/zh-cn/blogs/2010/07/20/400004478/</link>
		<comments>http://software.intel.com/zh-cn/blogs/2010/07/20/400004478/#comments</comments>
		<pubDate>Tue, 20 Jul 2010 01:15:31 +0000</pubDate>
		<dc:creator>yah99wolf</dc:creator>
				<category><![CDATA[博客征文专栏]]></category>
		<category><![CDATA[并行计算]]></category>

		<guid isPermaLink="false">http://software.intel.com/zh-cn/blogs/2010/07/20/400004478/</guid>
		<description><![CDATA[关于多进程和多线程，教科书上最经典的一句话是“进程是资源分配的最小单位，线程是CPU调度的最小单位”，这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那就没有这么简单了，选的不好，会让你深受其害。 经常在网络上看到有的XDJM问“多进程好还是多线程好？”、“Linux下用多进程还是多线程？”等等期望一劳永逸的问题，我只能说：没有最好，只有更好。根据实际情况来判断，哪个更加合适就是哪个好。 我们按照多个不同的维度，来看看多线程和多进程的对比（注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受）。 看起来比较简单，优势对比上是“线程 3.5 v 2.5 进程”，我们只管选线程就是了？ 呵呵，有这么简单我就不用在这里浪费口舌了，还是那句话，没有绝对的好与坏，只有哪个更加合适的问题。我们来看实际应用中究竟如何判断更加合适。 1）需要频繁创建销毁的优先用线程 原因请看上面的对比。 这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的 2）需要进行大量计算的优先使用线程 所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。 这种原则最常见的是图像处理、算法处理。 3）强相关的处理用线程，弱相关的处理用进程 什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。 一般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。 当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。 4）可能要扩展到多机分布的用进程，多核分布的用线程 原因请看上面对比。 5）都满足需求的情况下，用你最熟悉、最拿手的方式 至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。 需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。]]></description>
			<content:encoded><![CDATA[<p>关于多进程和多线程，教科书上最经典的一句话是“进程是资源分配的最小单位，线程是CPU调度的最小单位”，这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那就没有这么简单了，选的不好，会让你深受其害。<br />
经常在网络上看到有的XDJM问“多进程好还是多线程好？”、“Linux下用多进程还是多线程？”等等期望一劳永逸的问题，我只能说：没有最好，只有更好。根据实际情况来判断，哪个更加合适就是哪个好。<br />
我们按照多个不同的维度，来看看多线程和多进程的对比（注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受）。<br />
<img src="http://images.csdn.net/upimgs/liyp/01.png" alt="" width="536" height="332" /><br />
看起来比较简单，优势对比上是“线程 3.5 v 2.5 进程”，我们只管选线程就是了？<br />
呵呵，有这么简单我就不用在这里浪费口舌了，还是那句话，没有绝对的好与坏，只有哪个更加合适的问题。我们来看实际应用中究竟如何判断更加合适。<br />
1）需要频繁创建销毁的优先用线程<br />
原因请看上面的对比。<br />
这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的<br />
2）需要进行大量计算的优先使用线程<br />
所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。<br />
这种原则最常见的是图像处理、算法处理。<br />
3）强相关的处理用线程，弱相关的处理用进程<br />
什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。<br />
一般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。<br />
当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。<br />
4）可能要扩展到多机分布的用进程，多核分布的用线程<br />
原因请看上面对比。<br />
5）都满足需求的情况下，用你最熟悉、最拿手的方式<br />
至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。<br />
需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。</p>
]]></content:encoded>
			<wfw:commentRss>http://software.intel.com/zh-cn/blogs/2010/07/20/400004478/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

