parallel處理
當存在以下情況：
1、需處理多個獨立方法
2、各方法之間不存在共享資源的情況
3、各方法可以使用相同的委托
就可以使用Parallel類的相關(guān)方法進行處理
以下是官網(wǎng)上的一個例子，

using System.Threading.Tasks;   class Test{    static int N = 1000;    static void TestMethod()    {        // Using a named method.        Parallel.For(0, N, Method2);        // Using an anonymous method.        Parallel.For(0, N, delegate(int i)        {            // Do Work.        });    //Using ForEach    Parallel.ForEach(collection,item=>DoWork(item));        // Using a lambda expression.        Parallel.For(0, N, i =>        {            // Do Work.        });    }    static void Method2(int i)    {        // Do work.    }}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

個人認為在這功能有點語法糖感覺。原因有兩個：
原因一：從這個語法的本身而言，其使用多線程處理操作，本身就會消耗資源，因此parallel類更適合處理較復(fù)雜、耗時較長的操作。范圍縮小了！
原因二：即使處理較復(fù)雜、耗時較長的任務(wù)，在業(yè)務(wù)上也大多是使用同一數(shù)據(jù)庫事務(wù)，這樣就能保證要么全成功要么全失敗。而使用parallel類出現(xiàn)部分失敗時，對于業(yè)務(wù)而言就比較困難了。
綜上，個人認為對于parallel適應(yīng)的范圍不是很大。
定時器
定時器需要好好的寫寫！我的業(yè)務(wù)程序有一需求，就是比較頻繁的定時查找數(shù)據(jù)，并將數(shù)據(jù)打印出來！之前使用WinForm界面上的timer，結(jié)果悲劇，當處理大量數(shù)據(jù)時，會存在兩個問題：1、界面卡死；2、相同的內(nèi)容會打印多遍（一般會打印2遍）。這兩個問題那段時間經(jīng)常被業(yè)務(wù)部門投訴！后來使用了多線程的定時器，解決了這個問題。
System.Threading.Timer類的構(gòu)造函數(shù)如下所示：

public Timer(TimerCallback callback,object state,int dueTime,int period)
1

Timer構(gòu)造器中四個參數(shù)的的定義分別如下：
callback的委托定義如下

public delegate void TimerCallback(    object state)
1
2
3

state為callback的參數(shù)值，若為空，可為null；
dueTime為從準備到執(zhí)行的時間
period為時間每次操作的時間間隔
因此timer的一般使用方式如下：

//以下代碼為偽碼private system.threading.timer doSomeThingTimer=null;//開始執(zhí)行定時操作的button按鈕public void button_click(e){    doSomeThingTimer = new system.threading.timer(doSomeWork,null,5000,timeout.infinite);}//具體的業(yè)務(wù)邏輯方法private void doSomeWork(object status){    //業(yè)務(wù)邏輯代碼    //這兒一定要使用change方法，改變定時操作    doSomeThingTimer.change(8000,timeout.infinite);}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

以上就是使用timer的具體方法，其中doSomeWork方法中使用了change方法。原因如下：若不使用change方法，而是在timer中定義好操作每次的執(zhí)行間隔，則會出現(xiàn)以下情況。若操作的時間很長，超過了每次的執(zhí)行間隔，則線程池就會調(diào)用額外的線程去執(zhí)行操作，相當于有兩個線程分別去執(zhí)行doSomeWork。因此，為了避免這種情況的發(fā)生，需要在操作中使用change方法。
Timer小結(jié)
1、system.threading.timer類是使用線程池線程，其內(nèi)部使用了Threadpool.queueUserWorkItem()方法。這也是為何timer的委托與queueUserWorkItem的委托一致的原因。
2、在線程池內(nèi)部，線程池為所有的system.threading.timer共同使用一個線程。若一個不夠用，則會額外再開立新的線程
3、system.windows.forms.timer中也有一個定時器，但該定時器屬于UI線程，實UI線程有一消息泵，定時啟動該定時器。這個定時器適合用于非常簡單、耗時短、更新界面相關(guān)的操作。用于后臺的或耗時的操作，請不要使用
4、system.windows.threading.dispatcherTimer類是system.windows.forms.timer在wpf和silverlight的等價物
5、system.timers.timer類。這個類很有意思，它是一個控件，當定時觸發(fā)時，它會調(diào)用CLR的線程池線程進行操作。按理說它是正合適，但是它也有歷史，它是不應(yīng)該存在的。因為在微軟大規(guī)模整理線程和定時器相關(guān)的方法之前，就把它留在了FCL中，因此由于歷史原因，它也就沒被刪除。但平時盡量不要使用它。
線程池相關(guān)
當前線程池的上限是1000，一般情況下不要更改線程池的任何限定。

當使用threadpool.queueuserworkitem()及system.threding.timer創(chuàng)建的工作項會存放到上圖中的全局隊列中。然后線程池中的線程（也就是圖中的工作者線程），會按照FIFO（先入先出，隊列）的原則從全局隊列中獲取工作項，以進行完成。在這個過程中全局隊列有一個同步鎖，防止多個線程搶奪一個工作項。當工作者線程選取工作項后，全局隊列就會將該工作項在列表中刪除。
若此時，創(chuàng)建了一個task，則線程池會將task工作項放置在上圖中的本地隊列中。從而工作者線程就會優(yōu)先到本地隊列中獲取工作項。選取方式與全局隊列有區(qū)別，是后入先出的原則（即棧）獲取工作項。若本地隊列中已經(jīng)沒了工作項，則線程會到其他本地隊列中“偷取”工作項進行處理。若所有的本地隊列中的工作項都處理完了，則工作者線程就到全局隊列中獲取工作項。若全局隊列中的工作項都處理完了，則工作者線程就會睡眠，然后一定時間段后自然醒來，若發(fā)現(xiàn)還沒有事情做，就自殺掉。
若是一個外部的非工作者線程（例如，window線程），則不管是Threadpool還是timer還是task，CLR都將其放入全局隊列中，非工作者線程會從全局隊列中獲取工作項以進行工作。
偽共享
我的系統(tǒng)是64位的操作系統(tǒng)，這也就意味著，系統(tǒng)可以一次性讀取64byte的數(shù)據(jù)，因此創(chuàng)建2個int32的數(shù)據(jù)時，很有肯能兩個int32變量存儲在一個緩存線里。因此有兩個線程對兩個變量進行多次操作的時候，就會因讀取相同的內(nèi)容而進行資源的爭奪，因此會造成性能的降低。因此為了避免這種“偽共享”的情況導(dǎo)致的性能下降，可以采用一些attribute，使兩個字段分配到兩個緩存線中，這樣就會使性能提升。
26章小結(jié)
主要就是講述了task。
待解決問題
整理attribute
26章完

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。