在Golang中是鎖或Channel還是Atomic

  與其他程式設計語言一樣在并發環境下如不對多個goroutine（線程）通路或修改的共享資源元素的進行控制，讓進入臨界區的對象互斥。就可能會出現資料異常情況；

  一個非線程安全對象如下，如不對Id的通路進行控制，多個goroutine進行更新Id字段是就會出現資料不一緻的情況，如下示例：

  啟動100個goroutine用于更新對象c中的Id字段值，此時由于出現多個協程同時進入臨界區同時對Id變量進行修改。導緻對象c中的Id字段值出現了不可預知的情況。此時程式輸出的結果可能是：98、93、95等；

  下面分别使用鎖與channel對臨界區進行并發控制，使得輸出得到正常的結果，并簡單對比兩者的性能；

  現在在結構體Conf中添加一個讀寫鎖變量sync.RWMutex，此時Conf繼承了RWMutex中所有的方法字段等。通過此對象就可以對Id變量的通路進行加鎖， struct變為如下：

定義一個新方法，此方法使用了鎖對臨界區通路進行了并發控制：

  此時程式總是能夠輸出正确的結果：100

  用channel控制臨界資源的通路，原理也非常簡單，建立一個長度為1的channel變量，進去臨界區前往channel中寫入一個值，由于長度為1，此時别的協程将無法往channel中寫入值堵塞在此處channel上，前一個協程通路完臨界區後從channel讀取值，此後别的協程可再此往channel中寫入值，進而能夠進入臨界區，結構體修改如下；

  使用channel進行并發控制，需要注意取出lockChan中的值，此處使用了defer用于控制channel值的釋放。

  無需修改Conf結構體，直接調用atomic的相關方法即可，方法如下，此時也是能夠得到正确的值；

  通過跑Golang基準測試看看鎖、原子變量、channel三者的性能如何，毫無疑問原子變量肯定是性能最好的，這是對底層的CAS操作連臨界區都沒有産生；這裡主要對比鎖與channel性能，三個測試函數都和下函數類似；

  此時可以看到毫無懸念的atomic原子操作的方式性能最高，比其他兩種低一個數量級，鎖的方式比channel時間快了一倍，每次平均執行時間隻需44.45納秒，而channel每次需要84.12ns納秒；當然此處的隻是簡單對比；

  能用atomic時肯定是用atomic，至于鎖和channel選哪個，還是要看應用場景、業務邏輯、可維護性等，總體來說兩者性能差别不算太大，如果不太熟悉channel在過于複雜的業務邏輯中channel或許可讀性會降低；但golang中的兩個核心就是goroutine和channel；