一、多線程下的i++操作的並發問題
package passtra; public class SynchronizedDemo implements Runnable{ private static int count=0; @Override public void run() { for(int i=0;i<10000000;i++){ count++; } } public static void main(String[] args) { for(int i=0;i<10;i++){ new Thread(new SynchronizedDemo()).start(); } try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } System.err.println("result:"+count); } }
開啟了10個線程，每個線程都累加了10000000次，如果結果正確的話總數應該是10*10000000=1000000000.可是運行多次結果都不是這個數，而且每次運行結果都不一樣。
線程安全問題主要來源於JMM的設計，主要集中在主內存和線程的工作內存而導致的內存可見性問題，以及重排序導致的問題。
線程運行時擁有自己的棧空間，會在自己的棧空間運行，如果多線程間沒有共享的數據也就是說多線程間並沒有協作完成一件事情，那么多線程就不能發揮優勢，不能帶來巨大的價值。
那么共享數據的線程安全問題怎么處理？就是讓每個線程依次去讀寫這個共享變量，這樣就不會有任何數據安全的問題，因為每個線程所操作的都是當前最新版本數據。那么，在Java中synchronized就具有使每個線程依次排隊操作共享變量的功能，很顯然，這種同步機制相率很低，但synchronized是其他並發容器實現的基礎。
package passtra; public class SynchronizedDemo implements Runnable{ private static int count=0; @Override public void run() { synchronized(SynchronizedDemo.class){ for(int i=0;i<10000000;i++){ count++; } } } public static void main(String[] args) { for(int i=0;i<10;i++){ new Thread(new SynchronizedDemo()).start(); } try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } System.err.println("result:"+count); } }
二、synchronized最主要的使用方式
在Java代碼中使用synchronized可使用在代碼塊和方法中，根據synchronized使用位置可以有這些使用場景：
synchronized可以用在方法上也可以用在代碼塊上。其中方法還是實例方法和靜態方法分別鎖的的是該類的實例對象和該類的對象。修飾實例方法，作用於當前的實例對象加鎖，進入代碼同步代碼前要獲得當前對象的實例的鎖。修飾靜態方法，作用於當前類對象加鎖，進入同步代碼前要獲得當前對象的鎖。
也就是給當前類加鎖，會作用於類的所有對象實例，因為靜態成員不屬於任何一個實例對象，是類成員（static表明這是該類的一個靜態資源，不管new了多少個對象，只有一份，所有對該類的所有對象都加了鎖）。所以如果一個線程A調用一個實例對象的非靜態synchronized方法，而線程B需要調用這個實例對象的所屬類的靜態synchronized方法，是允許的，不會發生互斥現象，因為訪問靜態synchronized方法占用的鎖時當前的類，而訪問非靜態synchronized方法占用的是當前實例對象鎖
修飾代碼塊，指定加鎖對象，對給定對象加鎖，進入同步代碼快庫前要獲得給定對象的鎖。
和synchronized方法一樣，synchronized(this)代碼塊也是鎖定當前對象的。synchronized關鍵字加到static關鍵字和synchronized(class)代碼塊上都是給Class類上鎖。另外需要注意的是：盡量不要用synchronized(String a)因為JVM中，字符串常量池具有緩沖功能
三、寫一個synchronized實現的雙重校驗實現的單例模式
package passtra; public class Singlethon{ private volatile static Singlethon uniqueInstance; private Singlethon(){ } public static Singlethon getUniqueInstance(){ //先判斷對象是否實例化過，沒有實例化進入加鎖代碼
if(uniqueInstance==null){ //類對象加鎖
synchronized(Singlethon.class){ if(uniqueInstance ==null){ uniqueInstance=new Singlethon(); } } } return uniqueInstance; } }
uniqueInstance采用volatile關鍵字修飾也是很有必要的，可以禁止JVM的指令重排，保證在多線程環境下也能正常運行，uniqueInstance=new Singletion();這段代碼其實是分三步執行的：
1、為uniqueInstance分配內存空間
2、初始化uniqueInstance
3、將uniqueInstance指向分配的內存地址
但由於JVM具有指令重排的特性，執行順序有可能變成1->3->2.指令重排在單線程下不會出現問題，但在多線程下會導致一個線程互毆的還沒有初始化的實例。例如，線程A執行了1和3，此時線程B調用getuniqueInstance()后發現uniqueInstance不為空，因此返回uniqueInstance，但此時uniqueInstance還未被初始化。
四、synchronized在JDK1.6之后有哪些底層優化
在早期的版本中，synchronized屬於重量級鎖，效率低下，因為監視器鎖（monitor）是依賴於底層操作系統的Mntex Lock來實現的，Java的線程是映射到操作系統的原生線程之上的。如果要掛起或者喚醒一個線程，都需要操作系統幫忙完成，而操作系統實現線程之間的切換時需要從用戶態轉換到內核態，這個狀態之間的轉換需要相對比較長的時間，時間成本相對較高，這也是為什么早期的synchronized效率低的原因。
在JDK1.6之后從JVM層面對synchronized較大優化，所以現在的synchronized鎖效率也優化得很不錯了。
JDK1.6對鎖的實現引入了大量的優化，如：自旋鎖、適應性自旋鎖、所消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。
五、CAS操作
什么是CAS
使用鎖時，線程獲取鎖是一種悲觀鎖策略，即假設每一次執行臨界區代碼都會產生沖突，所以當前線程獲取到鎖的時候同時也會阻塞其他線程獲取該鎖。而CAS操作（又稱為無鎖操作）是一種樂觀鎖，它假設所有線程訪問共享資源的時候不會出現沖突，既然不會出現沖突自然就不會阻塞其他線程的操作，因此線程就不會出現阻塞停頓的狀態.如果出現了沖突怎么辦？無鎖操作是使用CAS（compare and swap）又叫做比較交換來鑒別線程是否出現沖突，出現沖突就重試當前操作直到沒有沖突為止。
CAS操作過程
CAS比較交換的過程可以通俗的理解為CAS(V,O,N)，包含三個值分別為：V：內存地址存放的實際值；O：預期的值（舊值）；N：更新的值。當V和O相同時，也就是說舊值和內存中實際的值相同表明該值沒有被其他線程更改過，即該舊值O就是目前來說最新的值，就可以將新值N賦值給V。反之，V和O不相同，表明該值已經被其他線程改過了則該舊值O不是最新版本的值了，所以不能將新值N賦給V，返回V即可。當對個線程使用CAS操作一個變量時，只有一個線程會成功，並更新成功，其余線程會失敗。失敗的線程會重新嘗試，當然也可以選擇掛起線程。
CAS的實現需要硬件指令集的支撐，在JDK1.5后虛擬機才可以使用處理器提供的CMPXCHG指令實現。
CAS應用場景
在J.U.C包中利用CAS實現類有很多，在Lock實現中會由CAS改變state變量，在atomic中的實現類中幾乎都是用CAS實現，JDK1.8中的concurrentHashMap等等。
CAS問題
1、ABA問題
因為CAS會檢查舊值有沒有變化，這里存在一個問題，比如一個舊值A變成B然后再變成A，剛好在做CAS時檢查發現舊值並沒有變化依然為A，但是實際上的確發生了變化，解決方案可以演戲數據庫中常用的樂觀鎖方式，添加一個版本號可以解決。原來的變化路徑A->B->C就變成了1A->2B->3C。JDK1.5后atmoic包中提供了AtomicStampedReference來解決BA問題。
2、自旋時間過長
使用CAS非阻塞同步，會自旋進行下一次嘗試，如果這里自旋時間過長對性能是很大的消耗。JDK1.6后加入了適應性自旋：如果某個鎖自旋很少成功獲得，那么下一次就會減少自旋。
3、只能保證一個共享變量的原子操作
當對一個共享變量執行操作時CAS能保證其原子性，如果對多個共享變量金性操作，CAS就不能保證其原子性。有一個解決方案是利用對象整合多個共享變量，然后將這個對象做CAS操作。atomic中提供了AtomicReference來保證引用對象之間的原子性。
六、偏向鎖
大多數情況下，鎖不僅不存在多線程競爭，而且總是由同一個線程多次獲得，為了讓線程獲得鎖的代價更低而引入了偏向鎖。
偏向鎖的獲取
當一個線程訪問同步塊並獲取鎖時，會在對象頭和棧幀中的鎖記錄里存儲偏向的線程ID，以后該線程在進入和退出同步塊時不需要進行CAS加鎖h和解鎖，只需要簡單地測試一下對象頭的Mark word里是否存儲着指向當前線程的偏向鎖，如果測試成功，表示線程已經獲得鎖。如果測試失敗，則需要再測試一下Mark word中偏向鎖標識是否設置成1（表示當前是偏向鎖），如果沒有設置，則使用CAS競爭鎖，如果設置了，則嘗試使用CAS將對象頭的偏向鎖指向當前線程。
偏向鎖的撤銷
偏向鎖使用了一種等到競爭出現才釋放的機制，所以當其他線程嘗試競爭偏向鎖時持有偏向鎖的線程才會釋放鎖。
偏向鎖的撤銷，需要等待全局安全點（在這個時間點上沒有正在執行的字節碼）它會首先暫停擁有偏向鎖的線程，然后檢查持有偏向鎖的線程是否活着，如果線程不處於活動狀態，則將對象頭設置成無鎖狀態；如果線程仍活着，擁有偏向鎖的棧會被執行，遍歷偏向對象的鎖記錄，棧中的鎖記錄和對象頭的Mark Word要么重新偏向於其他線程，要么恢復到無鎖或者標記對象不適合作為偏向鎖，最后喚醒暫停的線程。
線程1展示了偏向鎖獲取的過程，線程2 展示了偏向鎖撤銷的過程。
如何關閉偏向鎖
偏向鎖在Java6和7里是默認開啟的，但是它在應用程序啟動幾秒鍾之后才激活，如有必要可以使用JVM參數來關閉延遲：-XX:BiasedLockingStartupDelay=0。
如果確定應用程序里所有的鎖通常情況下處於競爭狀態，可以通過JVM參數關閉偏向鎖： -XX:UseBiasedLocking=false，那么程序默認會進入輕量級鎖狀態。
七、輕量級鎖
加鎖
線程在執行同步塊之前，JVM會先在當期線程的棧幀中創建用於存儲鎖記錄的空間，並將對象頭中的Mark Word復制到鎖記錄中，官方稱為Displace的 Mark Word。
然后線程嘗試使用CAS將對象頭中的Mark Word替換為指向鎖記錄的指針。
如果更新成功，當前線程獲得鎖。
如果更新失敗，表示其他線程競爭鎖，當前線程便嘗試使用自旋來獲取鎖。
解鎖
輕量級解鎖時，會使用原子的CAS操作將Displaced Mark Word替換回到對象頭。
如果成功，則表示沒有競爭發生
如果失敗，便是當前鎖存在競爭，鎖就會膨脹成重量級鎖。
因為自旋會消耗CPU，為了避免無用的自旋（比如獲得鎖的線程被阻塞住了），一旦鎖升級成重量級鎖，就不會再恢復到輕量級鎖狀態。當鎖處於這個狀態下，其他線程試圖獲取鎖時，都會被阻塞住，當持有鎖的線程釋放鎖之后會喚醒這些線程，被喚醒的線程就會進行新一輪的奪鎖之爭
八、偏向鎖，輕量級鎖、重量級鎖的比較
| 鎖 | 優點 | 缺點 | 適用場景 |
| 偏向鎖 | 加鎖和解鎖不需要額外的消耗，和執行非同步方法相比僅存在納秒級的差距 | 如果線程間存在鎖競爭，會帶來額外的鎖撤銷的消耗 | 適用於只有一個線程訪問同步塊場景 |
| 輕量級鎖 | 競爭的線程不會阻塞，提高了程序的響應速度 | 如果始終得不到鎖競爭的線程，只用自旋會消耗CPU | 追求響應時間，同步塊執行速度非常快 |
| 重量級鎖 | 線程競爭不會使用自旋，不會消耗CPU | 線程阻塞，響應時間緩慢 | 追求吞吐量，同步塊執行速度較長 |
九、為什么wait、notify、notifyAll要與synchronized一起使用
wait、notify、notifyAll方法都是Object的方法，也就是說，每個類中都有這些方法。
Object.wait()：釋放當前對象鎖，並進入到阻塞隊列
Object.notify()：喚醒當前對象阻塞隊列里的任一線程（並不保證是哪個）
Object.notigyAll()：喚醒當前阻塞隊列里的所有線程
為什么這三個方法要和synchronized一起使用呢？我們要先了解到：
每一個對象都有一個與之對應的監視器
每一個監視器里面都有一個該對象的鎖和一個等待隊列和一個同步隊列
wait()方法的語義有兩個，一個是釋放當前鎖，另一個是進入阻塞隊列，可以看到，這些操作都是與監視器相關的，當然要指定一個監視器才能完成這個操作了。
notify()方法也是一樣，用來喚醒一個線程，你要去喚醒，首先你要知道它在哪，所以必須先找到該對象，也就是獲取該對象的鎖，當獲取對象的鎖之后，才能去該對象的對應的等待隊列去喚醒一個線程，值得注意的是，只有執行喚醒工作的線程離開同步塊，即釋放鎖之后，被喚醒的線程才能去競爭鎖。
notifyAll()方法和notify()方法一樣，只不過是喚醒等到隊列中的所有線程。
因wait()而阻塞的線程是放在阻塞隊列中的，因競爭失敗導致的阻塞是放在同步隊列中的，notify和notifyAll實質上是把阻塞隊列中的線程放到同步隊列中。