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

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

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

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

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

public delegate void TimerCallback(
    object state
)
1
2
3

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

//以下代碼為偽碼

private system.threading.timer doSomeThingTimer=null;

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

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