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

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

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

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

　　2. 并行循環嵌套越多程序性能越高

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

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

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

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

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

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

　　有如下兩段代碼：

　　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);

});

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

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

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

　　Case 2: 并行程序對于字符串與數字的處理效率是不同的。

　　@ 字符串累加：

　　單行：  

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());

});

　　@ 數字比較：

　　單行：

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

{

f = i == j;

}

　　并行：

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

{

f = i == j;

});

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

　　●  誤區二.并行循環嵌套越多程序性能越高

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

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

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

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