原文見 cool shell
cas，即lock-free的一種實現，是構成jdk concurrent包高效併發容器的重要基礎，因此認真閱讀了一下。
讀後附註
對aba問題的理解：
在db裡，根據一行記錄中「最後修改時間」欄位的值是否變更，作為更新該行記錄時的參照物，是平時常見的一種做法，類似樂觀鎖。之所以這樣做有效，是因為時間不會被任意改寫，其始終線性遞增，否則就有可能發生aba問題。
而原文是想表達，本來指標指向的物件被**並重新new出來會導致指標的值變更，但由於某些執行時優化，可能會出現不同例項間直接復用堆記憶體的情況，即指標指向的位址沒變，但其指向的物件（的內容）已經變了。由於cas只是單純地比較指標，因此可能「看起來沒變，其實已經變了。」
所以，那個「活生生的例子」欠妥，應該是辣妹本來準備了多個跟你同一款的皮箱準備調包，她得手後，會把裝錢的皮箱掏空，然後從手頭的所有皮箱裡（包括那個剛被掏空的）任選乙個，調包給你。如果你在皮箱上留了記號，大部分情況下，還是能覺察到被調包了；然而如果她選擇「物歸原主」，光看皮箱你是無法作出判斷的。
對引用計數的理解：
fetch&add(p->refcnt, 1);
這一句是人為給引用計數加了1,從而避免p被**。只要不被**，就不會導致aba。
無鎖佇列的實現
可以用cas 以及fetch等原子操作來實現無鎖的佇列，說是無鎖其實感覺也是有鎖的，只是鎖的力度比較小，能提公升效能 bool cas t addr,t expected,t newvalue else return false 使用陣列來實現佇列是很常見的方法，因為沒有記憶體的分部和釋放，一切都會...
mySQL無鎖佇列 go 無鎖佇列
無鎖佇列適用場景 兩個執行緒之間的互動資料，乙個執行緒生產資料，另外乙個執行緒消費資料，效率高 缺點 需要使用固定分配的空間，不能動態增加 減少長度，存在空間浪費和無法擴充套件空間問題 package main import fmt reflect strings time type loopque...
lockFreeQueue 無鎖佇列實現與總結
在工程上，為了解決兩個處理器互動速度不一致的問題，我們使用佇列作為快取，生產者將資料放入佇列，消費者從佇列中取出資料。這個時候就會出現四種情況，單生產者單消費者，多生產者單消費者，單生成者多消費者，多生產者多消費者。我們知道，多執行緒往往會帶來資料不一致的情況，一般需要靠加鎖解決問題。但是，加鎖往往...