并行計算無疑是.Net Framework平臺的一大亮點，它自動的將一個任務(wù)分解，并以并發(fā)的形式執(zhí)行，程序員不用操心各任務(wù)之間的協(xié)作和同步問題，這使得可以更加專注于業(yè)務(wù)的實現(xiàn)。

　　.NET 中的 TPL(Task Parallel Library)，中文意思是任務(wù)并行庫，它的設(shè)計是為了能更簡單地編寫可自動使用多處理器的托管代碼。使用該庫，用戶可以非常方便地用現(xiàn)有序列代碼表達潛在并行性，這樣序列代碼中公開的并行任務(wù)將會在所有可用的處理器上同時運行，通常這會大大提高速度。

　　但是，從網(wǎng)上很多已經(jīng)發(fā)布的并行計算的例子來講，有很多存在一定的誤區(qū)甚至是誤導(dǎo)，這導(dǎo)致了一線編程人員產(chǎn)生一些錯誤的思路，它們多是通過示例講述并行計算的性能優(yōu)越性，似乎程序人員可以不費吹灰之力就能將程序性能提升N倍，如果這些想法沒有經(jīng)過比較就應(yīng)用于實際，那么就會造成一定的損失。這篇文章就來聊聊關(guān)于合理使用并行計算的問題，供大家參考，這些誤區(qū)主要包括：

　　1. 只要使用并行就會提高程序性能

　　2. 并行循環(huán)嵌套越多程序性能越高

　　3. 并行計算是運行時的事

　　下面讓我們來一個個的講解這些誤會。

　　● 誤區(qū)一 .只要使用并行就會提高程序性能

　　實時并不是這樣，實際上并行計算的使用對前提要求非常嚴(yán)格，一般情況大量使用并行計算不但不會提升性能，反而會適得其反，下面有兩個Case給大家說明。

　　Case 1. 使用Thread.Sleep()比較并行與單行程序的性能并不客觀。 

　　在許多并行計算與單行方式程序性能比較的例子中，很多都包含類似Thread.Sleep()的語句，運行這樣的Demo我們確實看到，并行的時間結(jié)果竟然提升如此許多，但是你有沒有仔細研究一下時間降低的原因呢？

　　有如下兩段代碼：

　　Code Part A：

for (int i = 0; i < 10; i++)

{

a = i.ToString();

Thread.Sleep(200);

}

　　Code Part B：

Parallel.For(0, 10, (i) =>

{

a = i.ToString();

Thread.Sleep(200);

});

　　在我的雙核本機上，測試結(jié)果是令人興奮的：Code Part A跑了2秒多，而Code Part B只跑了800多毫秒，時間大幅降低，然而這樣你就決定將你的代碼遷移到并行方式嗎？

　　我建議你還是等等再說吧，Code Part B比A具有更高性能的原因不是因為主代碼并行而帶來的性能提升，而是由于Sleep()，在并行環(huán)境中，任務(wù)實際上只是休息了1/N（N為并行數(shù)量），而不是單行程序中的全部，這是因為TPL將循環(huán)工作分解的緣故，在雙核本機上，Code Part B相當(dāng)于2個5次的循環(huán)同時進行，Sleep()又很少有共享資源的消耗，不需要與其他進程同步，所以運行時間比1次10次的循環(huán)降低了，假如我們?nèi)サ鬋ode Part A、B中的Sleep語句，那么結(jié)果又是如何呢？答案是兩者十分趨近。實際上在主代碼短短小的情況下，并行計算會表現(xiàn)出一定的性能不穩(wěn)定性，這里留一點，感興趣的朋友自己測試一下吧。

　　選擇并行計算處理問題，首先要保證你的樣本或需求適合并行處理，比如寫排序算法時就不能使用并行計算。

　　Case 2: 并行程序?qū)τ谧址c數(shù)字的處理效率是不同的。

　　@ 字符串累加：

　　單行：  

for (int i = 0; i < 100000; i++)

{

a += i.ToString();

}

　　并行： 

Parallel.For(0, 100000, (i) =>

{

a += i.ToString();

});

　　@ 字符串比較：

　　單行：

for (int i = 0; i < 100000; i++)

{

f = a.Equals(i.ToString());

}

　　并行：

Parallel.For(0, 100000, (i) =>

{

f = a.Equals(i.ToString());

});

　　@ 數(shù)字比較：

　　單行：

for (int i = 0; i < 100000000; i++)

{

f = i == j;

}

　　并行：

Parallel.For(0, 100000000, (i) =>

{

f = i == j;

});

　　運行以上三段測試代碼可知，TPL對于字符串處理還是很令人滿意的。所以不是所有情況都適合使用TPL庫處理程序，這一點對于程序中的遍歷情景很重要，在使用PLINQ時，建議先分析樣本空間的類型與具體操作，再決定使用哪種計算。

　　●  誤區(qū)二.并行循環(huán)嵌套越多程序性能越高

　　對于兩層以上循環(huán)的代碼段，在你決定使用并行前，先要做的是發(fā)現(xiàn)這段代碼的主要耗損在哪，是在外層還是在內(nèi)層，只有評估當(dāng)并行對性能帶來的提升大于損耗時，再重構(gòu)為并行也不遲，因為TPL在很多情形都提供了并行支持，很多程序員在能用到并行的地方都用并行，而沒有經(jīng)過測試比較，實際上有很多時候，在所有的地方加上并行特性，程序的性能反而會受到損失，這里就不在給出案例了。

　　從下圖可以看出，TPL雖然自動管理了循環(huán)中的對象，但是這些&ldquo;自動&rdquo;是有一些性能損失的，如果我們的代碼中不斷地要求TPL進行對象的拆分、合并、同步，而忽視了業(yè)務(wù)本身的優(yōu)化，那無疑是對性能不利的。

　　在這里Aicken給出一個建議，就是在并行前，先要評估這段代碼的任務(wù)量有多大，有沒有必要并行？這段代碼有沒有對磁盤等寫要求的競爭？代碼是處理什么任務(wù)的，以及代碼的運行環(huán)境是否支持并行；再者就是代碼重構(gòu)后進行性能測試，這樣才能保證并行計算有意義。

　　其實，用對并行計算除了對性能的提升外，還有一點可貴的地方，就是對代碼的重構(gòu)，簡潔而富有結(jié)構(gòu)性的代碼，更加符合編碼進步的要求，不是嗎？