衆所周知鎖有兩種：樂觀鎖與悲觀鎖。
獨佔鎖是一種悲觀鎖，而 synchronized 就是一種獨佔鎖，synchronized 會導致其它所有未持有鎖的線程阻塞，而等待持有鎖的線程釋放鎖。
所謂樂觀鎖就是，每次不加鎖而是假設沒有衝突而去完成某項操作，如果因爲衝突失敗就重試，直到成功爲止。而樂觀鎖用到的機制就是CAS。
下面以一組漫畫來全面講解CAS，轉載來自於微信公衆號：“程序員小灰”
————— 第二天 —————
————————————
示例程序：啓動兩個線程，每個線程中讓靜態變量count循環累加100次。
最終輸出的count結果是什麼呢？一定會是200嗎？
加了同步鎖之後，count自增的操作變成了原子性操作，所以最終的輸出一定是count=200，代碼實現了線程安全。
爲什麼這麼說呢？關鍵在於性能問題。
Synchronized關鍵字會讓沒有得到鎖資源的線程進入BLOCKED狀態，而後在爭奪到鎖資源後恢復爲RUNNABLE狀態，這個過程中涉及到操作系統用戶模式和內核模式的轉換，代價比較高。
儘管Java1.6爲Synchronized做了優化，增加了從偏向鎖到輕量級鎖再到重量級鎖的過度，但是在最終轉變爲重量級鎖之後，性能仍然較低。
jdk1.6以後 對synchronized鎖做了哪些優化
1.適應自旋鎖
自旋鎖：爲了減少線程狀態改變帶來的消耗 不停地執行當前線程
2.鎖消除：
不可能存在共享數據競爭的鎖進行消除
3.鎖粗化：
將連續的加鎖 精簡到只加一次鎖
4.輕量級鎖：
無競爭條件下 通過CAS消除同步互斥
5.偏向鎖：
無競爭條件下 消除整個同步互斥，連CAS都不操作。
所謂原子操作類，指的是java.util.concurrent.atomic包下，一系列以Atomic開頭的包裝類。例如AtomicBoolean，AtomicInteger，AtomicLong。它們分別用於Boolean，Integer，Long類型的原子性操作。
現在我們嘗試在代碼中引入AtomicInteger類：
使用AtomicInteger之後，最終的輸出結果同樣可以保證是200。並且在某些情況下，代碼的性能會比Synchronized更好。
什麼是CAS？
CAS是英文單詞Compare And Swap的縮寫，翻譯過來就是比較並替換。
CAS機制當中使用了3個基本操作數：內存地址V，舊的預期值A，要修改的新值B。
更新一個變量的時候，只有當變量的預期值A和內存地址V當中的實際值相同時，纔會將內存地址V對應的值修改爲B。
這樣說或許有些抽象，我們來看一個例子：
1.在內存地址V當中，存儲着值爲10的變量。
2.此時線程1想要把變量的值增加1。對線程1來說，舊的預期值A=10，要修改的新值B=11。
3.在線程1要提交更新之前，另一個線程2搶先一步，把內存地址V中的變量值率先更新成了11。
4.線程1開始提交更新，首先進行A和地址V的實際值比較（Compare），發現A不等於V的實際值，提交失敗。
5.線程1重新獲取內存地址V的當前值，並重新計算想要修改的新值。此時對線程1來說，A=11，B=12。這個重新嘗試的過程被稱爲自旋。
6.這一次比較幸運，沒有其他線程改變地址V的值。線程1進行Compare，發現A和地址V的實際值是相等的。
7.線程1進行SWAP，把地址V的值替換爲B，也就是12。
從思想上來說，Synchronized屬於悲觀鎖，悲觀地認爲程序中的併發情況嚴重，所以嚴防死守。CAS屬於樂觀鎖，樂觀地認爲程序中的併發情況不那麼嚴重，所以讓線程不斷去嘗試更新。
CAS的缺點：
1.CPU開銷較大
在併發量比較高的情況下，如果許多線程反覆嘗試更新某一個變量，卻又一直更新不成功，循環往復，會給CPU帶來很大的壓力。
2.不能保證代碼塊的原子性
CAS機制所保證的只是一個變量的原子性操作，而不能保證整個代碼塊的原子性。比如需要保證3個變量共同進行原子性的更新，就不得不使用Synchronized了。
因爲它本身就只是一個鎖住總線的原子交換操作啊。兩個CAS操作之間並不能保證沒有重入現象。
3.ABA問題
這是CAS機制最大的問題所在。
什麼是ABA問題？怎麼解決？我們下一期來詳細介紹。