一、為什么要使用 synchronized
使用synchronized的原因在于：它能夠確保多個線程在同一時刻，只能有一個線程處于方法或者同步塊中，它保證了線程對變量訪問的可見性和排他性。
二、synchronized 原理
在JDK 1.6之前，synchronized的實現是基于對象上的監視器，這也被稱為重量鎖。默認情況下，每一個對象都有一個關聯的Monitor，而每個Monitor包含了一個EntryCount計數器，它是synchronized實現可重入的關鍵。
在JDK 1.6之后，對鎖進行了一系列優化的措施，通過引入自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。
這些優化措施最終的目的是減少鎖操作的開銷，然而它所改變的只是鎖的實現方式，但是加鎖和解鎖這一基本原則是沒有改變的。這篇文章主要是介紹synchronized的使用，因此，在后面的介紹中，我們還是按照比較容易理解的重量鎖的方式進行分析，在之后的文章中，我們再來談一下優化后的實現策略。
2.1 進入同步方法或者代碼塊
當一個線程執行某個對象的同步方法或者代碼塊時，會先檢查這個對象所關聯的Monitor's EntryCount是否為0：
- 如果
EntryCount為0，那么該線程就會將Monitor’s EntryCount設置為1，并成為該Monitor的所有者，接著執行該方法或者代碼塊中的語句。 - 如果
EntryCount不為0，這時會去檢查對象所關聯的Monitor的持有者是哪一個線程： - 第一種情況：持有該
Monitor的線程就是當前正在嘗試獲取Monitor的線程，那么將EntryCount的數值加1，繼續執行方法或者代碼塊中的語句。 - 第二種情況：持有該
Monitor的是其它的線程，那么該線程進入阻塞狀態，直到EntryCount的數值變為0。
2.2 退出同步方法或者代碼塊
當一個線程從同步方法或者代碼塊退出時，會將EntryCount減1，如果EntryCount變為0，那么該線程會釋放它所持有的Monitor。之前那些阻塞在synchronized的線程會嘗試去獲取Monitor，成功獲取Monitor的線程可以進入同步方法或者代碼塊。
三、synchronized 使用
對于synchronized的使用，我們有兩種分類方法：
- 根據使用場景分類
- 根據
Monitor關聯的對象分類。
3.1 根據使用場景分類
很多介紹synchronized的文章，都是通過使用場景進行分類的，一般來說可以分為如下四種使用場景，而每種場景下根據Monitor所關聯的對象不同，又會衍生出另外的用法：
- 靜態方法
//靜態方法，使用的是Class類鎖
synchronized public static void staticMethod() {}
- 靜態方法代碼塊
private static final byte[] mStaticLockByte = new byte[1];
//靜態方法代碼塊1，使用的是Class類鎖
public static void staticBlock1() {
synchronized (SynchronizedObject.class) {}
}
//靜態方法代碼塊2，使用的是內部靜態變量鎖
public static void staticBlock2() {
synchronized (mStaticLockByte) {}
}
- 普通方法
//普通方法，使用的是調用該方法的對象鎖
synchronized public void method() {}
- 普通方法代碼塊
private static final byte[] mStaticLockByte = new byte[1];
private final byte[] mLockByte = new byte[1];
//普通方法代碼塊1，使用的是Class類鎖
public void block1() {
synchronized (SynchronizedObject.class) {}
}
//普通方法代碼塊2，使用的是mLockByte的變量鎖
public void block2() {
synchronized (mLockByte) {} //變量需要聲明為final
}
//普通方法代碼塊3，使用的是mStaticLockByte的變量鎖
public void block3() {
synchronized (mStaticLockByte) {}
}
//普通方法代碼塊4，使用的是調用該方法的對象鎖
public void block4() {
synchronized (this) {}
}
3.2 根據 Monitor 關聯的對象分類
根據使用場景進行分類，主要是為了讓大家知道如何使用synchronized關鍵字，然而要真正地理解synchronized，就需要結合第二節談到的synchronized原理，其實3.1中談到的多種場景，都是和Monitor有關，那么從和Monitor關聯的對象來看，我們重新對3.1中的8種場景重新進行分類：
-
Class對象： - 靜態方法
- 靜態方法代碼塊1 -
SynchronizedObject.class - 普通方法代碼塊1 -
SynchronizedObject.class - 調用方法的對象
- 普通方法
- 普通方法代碼塊4 -
this - 靜態對象
- 靜態方法代碼塊2 -
mStaticLockByte - 普通方法代碼塊3 -
mStaticLockByte - 非靜態對象
- 普通方法代碼塊1 -
mLockByte
如果使用場景屬于上面的同一個分類當中，那么才有可能產生線程阻塞在synchronized關鍵字的情況，舉一個例子，如果A線程通過靜態方法訪問（分類一）并且沒有從該方法退出：
- 這時
B線程是通過一個對象的普通方法來訪問（分類二），那么是不會阻塞的，這是因為調用該方法的對象所關聯的Monitor沒有被持有。 - 如果
B線程使用的是靜態方法代碼塊來訪問，而該靜態方法代碼塊使用的是SynchronizedObject.class來修飾（分類一），由于這兩種使用場景是屬于同一個分類，那么就會B線程就會進入阻塞狀態，這是因為SynchronizedObject類所關聯的Monitor已經被A線程持有了。
四、小結
從表面上來看，synchronized的使用可以簡單地分為同步方法和同步代碼塊，但是究竟在什么情況下會導致一個線程在synchronized上阻塞，則需要分析synchronized方法所嘗試獲取的Monitor的是否已經被其它線程持有了。
