突然想到有關(guān)C#中使用event特性時關(guān)于線程安全的問題，以前雖然有遵從“復(fù)制引用+null判斷”的模式（盲目地），但沒有深入了解和思考。
為之查詢了資料和實(shí)驗，對此有了進(jìn)一步的理解。
定義（field-like event）：
public event EventHandler Done;
類內(nèi)raise：
PRotected void OnDone(){ var done = Done; if (done != null) { done(this, new EventArgs()); }}
不禁要問，為何要復(fù)制引用？多線程下表現(xiàn)如何？
為了解決上面哪些疑惑，我查了一些資料，其中有來自當(dāng)時C#編譯器開發(fā)組成員的一篇博文 Field-like Events Considered Harmful。
這篇博文介紹了C#3.0中編譯器對于field-like event（也是最常見的使用方式）的實(shí)現(xiàn)。
對于如此的代碼，
class EventInCS3{ public event EventHandler Done;}
編譯器會將其轉(zhuǎn)換成：
class EventInCS3{ private EventHandler __Done; // 1 public event EventHandler Done { add { lock (this) // 2 { __Done = __Done + value; // 3 } } remove { lock (this) { __Done = __Done - value; } } }}
有以下幾點(diǎn)值得注意（同注釋編號）：
1.event下隱藏的真正delegate鏈。實(shí)際上我們使用的是子類MulticastDelegate（可以參考 開源的coreclr實(shí)現(xiàn)）。
3.正如+、-操作符對于string類型是起字符串組合作用，其對于delegate類型也同樣是起到兩條鏈的組合作用（參考 MSDN），實(shí)際上是調(diào)用了Delegate.Combine和Delegate.Remove。同時也引入了經(jīng)典的線程問題（修改丟失）。
2.為了解決多線程問題，使用了lock。
（就先不管這個lock(this)了。當(dāng)然上面提到的 博文 里提到了，編譯器并不是通過lock，繼而通過Monitor的靜態(tài)方法來同步，而是通過IL即MethodImplAttribute(MethodImplOptions.Synchronized)實(shí)現(xiàn)。這些都是C#本身不推薦的方法。）
而在C#4.0中，同步的實(shí)現(xiàn)有了變化，同樣參見同一作者兩年后的 這一篇博文。
編譯器默認(rèn)的add、remove實(shí)現(xiàn)，改為使用compare and swap來實(shí)現(xiàn)lock-free同步。值得注意的是，delegate是不可更改的類型，即+=、-=之后，會指向一個新的對象，而不再是原對象（類似string）。
通過IL查看程序集里生成的add_Done、remove_Done，可以發(fā)現(xiàn)端倪，大致會生成如下的代碼：
static void add_Done(EventHandler value){ EventHandler V_0 = __Done; EventHandler V_1, V_2; do { V_1 = V_0; V_2 = (EventHandler)Delegate.Combine(V_1, value); V_0 = Interlocked.CompareExchange<EventHandler>(ref __Done, V_2, V_1); } while (V_0 != V_1);}
在同一作者的 另一篇博文 中，介紹了C#4.0中event相關(guān)的語義變化，主要是+=、-=操作符的語義變化。
在C#3.0中，對于一個event，如果在該類之外訪問這個event，則會被認(rèn)為是訪問這個event本身，如我們熟知的只能通過+=、-=這兩個操作符來訪問（即是調(diào)用對應(yīng)的add、remove訪問器）；而在類的內(nèi)部，所有對這個event的訪問，都會被認(rèn)為是訪問作為event實(shí)現(xiàn)的delegate本身（即訪問Done，實(shí)際上訪問到的是__Done）。
這么處理的話，我們就能在OnDone方法里復(fù)制引用，判斷null，進(jìn)行調(diào)用。因為此時Done這個標(biāo)識符，代表的是一個EventHandler對象的引用。
C#3.0的問題也在于此，這種情況下，我們寫下
Done += SomeHandlerMethod;
時，+=實(shí)際是調(diào)用了：
EventHandler EventHandler.Operator +(EventHandler left, EventHandler right)在Visual Studio 2015里寫一個普通的、非event的EventHandler的+=運(yùn)算，鼠標(biāo)放在+=上時，顯示的也是這個函數(shù)簽名。C#3.0時即使對event也是這么處理的。
導(dǎo)致我們失去了默認(rèn)add訪問器提供的同步功能。
而這一現(xiàn)象在C#4.0中得到了改善。在類內(nèi)部訪問event的標(biāo)識符時，+=、-=操作符就會被認(rèn)為是add、remove的調(diào)用了。
可知在C#4.0寫下同樣的代碼時，+=調(diào)用的簽名為：
void EventInCS4.Done.add
自定義event時（非field-like event），我們自己編寫的add、remove訪問器就沒有默認(rèn)的同步了。如果要考慮線程安全，需要手動加上同步（比如lock(someLockObject)）。
此時，在類內(nèi)部訪問event標(biāo)識符，只會被當(dāng)成是訪問event本身。要引發(fā)事件（Done）的話，需訪問對應(yīng)delegate（__Done(this, new EventArgs())）。
一般情況下無需自己實(shí)現(xiàn)event，用field-like就好了。
因為不管是通過event標(biāo)識符訪問delegate（field-like event），還是直接訪問delegate（自定義event），我們得到的都是delegate對象的引用，而且delegate對象是不可更改的。引用的復(fù)制是原子的。所以我們可以隨意地復(fù)制該delegate的引用，然后判斷null并invoke。
一些code snippet如：
public static class EventExtension{ public static void Raise<T>(this EventHandler<T> handler, object sender, T args) { if (handler != null) { handler(sender, args); } } public static void Raise(this EventHandler handler, object sender, EventArgs args); // 重載版}
delegate的引用會以pass-by-value形式得到復(fù)制，所以直接
Done.Raise(this, new EventArgs());
Done?.Invoke(this, new EventArgs());
null-conditional操作符也會進(jìn)行引用的復(fù)制，所以是線程安全的。（沒有Done?(...)這種寫法）
對于編譯器是否會將復(fù)制引用作為重復(fù)的局部變量優(yōu)化掉，以至于在一些情況下需要使用諸如以下的方式的問題，我沒有深入了解。
Interlocked.CompareExchange(ref Done, null, null);
簡單查詢一下之后，得知對于微軟自家的CLR無需關(guān)心這個問題，蓋其遵循較嚴(yán)格的內(nèi)存模型（memory model），不會引入新的讀取操作。但其他情況下有可能存在這樣的問題。相關(guān)文章和討論鏈接如下：
新聞熱點(diǎn)
疑難解答
