作者：小傅哥
博客：https://bugstack.cn
沉淀、分享、成長，讓自己和他人都能有所收獲！😄
感覺什么都不會，從哪開始呀！
這是最近我總能被問到的問題，也確實是。一個初入編程職場的新人，或是一個想重新努力學習的老司機，這也不會，那也不會，總會犯愁從哪開始。
講道理，畢竟 Java 涉及的知識太多了，要學應該是學會學習的能力，而不是去背題、背答案，拾人牙慧是不會有太多收益的。
學習的過程要找對方法，遇到問題時最好能自己想想，你有哪些方式學會這些知識。是不感覺即使讓你去百度搜，你都不知道應該拿哪個關鍵字搜！只能拿著問題直接找人問，這樣缺少思考，缺少大腦撞南墻的過程，其實最后也很難學會。
所以，你要學會的是自我學習的能力，之后是從哪開始都可以，重要的是開始和堅持！
謝飛機，小記，周末逛完奧特萊斯，回來就跑面試官家去了！
謝飛機：duang、duang、duang，我來了！
面試官：來的還挺準時，洗洗手吃飯吧！
謝飛機：嘿嘿…
面試官：你看我這塊魚豆腐，像不像 synchronized 鎖！
謝飛機：啊！？
面試官：飛機，正好問你。synchronized、volatile，有什么區(qū)別呀？
謝飛機：嗯，volatile 保證可見性，synchronized 保證原子性！
面試官：那不用 volatile，只用 synchronized 修飾方式，能保證可見性嗎？
謝飛機：這…，我沒驗證過！
面試官：吃吧，吃吧！一會給你個 synchronized 學習大綱，照著整理知識點！
HotSpot虛擬機 markOop.cpp 中的 C++ 代碼注釋片段，描述了 64bits 下 mark-word 的存儲狀態(tài)，也就是圖 15-1 的結(jié)構(gòu)示意。
這部分的源碼注釋如下：
64 bits:
--------
unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object)
JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object)
PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
size:64 ----------------------------------------------------->| (CMS free block)
unused:25 hash:31 -->| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object)
JavaThread*:54 epoch:2 cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && biased object)
narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)
源碼地址：jdk8/hotspot/file/vm/oops/markOop.hpp
HotSpot虛擬機中，對象在內(nèi)存中存儲的布局可以分為三塊區(qū)域：對象頭（Header）、實例數(shù)據(jù)（Instance Data）和對齊填充（Padding）。
-XX:-UseCompressedOops）后，長度為8字節(jié)。其指向的位置是對象對應的Class對象（其對應的元數(shù)據(jù)對象）的內(nèi)存地址。另外，在mark-word鎖類型標記中，無鎖，偏向鎖，輕量鎖，重量鎖，以及GC標記，5種類中沒法用2比特標記（2比特最終有4種組合00、01、10、11），所以無鎖、偏向鎖，前又占了一位偏向鎖標記。最終：001為無鎖、101為偏向鎖。
為了可以更加直觀的看到對象結(jié)構(gòu)，我們可以借助 openjdk 提供的 jol-core 進行打印分析。
引入POM
<!-- https://mvnrepository.com/artifact/org.openjdk.jol/jol-cli -->
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-cli</artifactId>
<version>0.14</version>
</dependency>
測試代碼
public static void main(String[] args) {
System.out.println(VM.current().details());
Object obj = new Object();
System.out.println(obj + " 十六進制哈希：" + Integer.toHexString(obj.hashCode()));
System.out.println(ClassLayout.parseInstance(obj).toPrintable());
}
運行結(jié)果
# Running 64-bit HotSpot VM.
# Using compressed oop with 3-bit shift.
# Using compressed klass with 3-bit shift.
# Objects are 8 bytes aligned.
# Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
# Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
在 Run-->Edit Configurations->VM Options 配置參數(shù) -XX:-UseCompressedOops 關閉指針壓縮。
運行結(jié)果
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 12 0c 53 (00000001 00010010 00001100 01010011) (1393299969)
4 4 (object header) 02 00 00 00 (00000010 00000000 00000000 00000000) (2)
8 4 (object header) 00 1c b9 1b (00000000 00011100 10111001 00011011) (465116160)
12 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
接下來，我們調(diào)整下測試代碼，看下哈希值在對象頭中具體是怎么存放的。
測試代碼
public static void main(String[] args) {
System.out.println(VM.current().details());
Object obj = new Object();
System.out.println(obj + " 十六進制哈希：" + Integer.toHexString(obj.hashCode()));
System.out.println(ClassLayout.parseInstance(obj).toPrintable());
}
運行結(jié)果
0x2530c12關于這個倒過來的問題是因為，大小端存儲導致；
mark-word結(jié)構(gòu)
如圖 15-5 最右側(cè)的 3 Bit（1 Bit標識偏向鎖，2 Bit描述鎖的類型）是跟鎖類型和GC標記相關的，而 synchronized 的鎖優(yōu)化升級膨脹就是修改的這三位上的標識，來區(qū)分不同的鎖類型。從而采取不同的策略來提升性能。
在HotSpot虛擬機中，monitor是由C++中ObjectMonitor實現(xiàn)。
synchronized 的運行機制，就是當 JVM 監(jiān)測到對象在不同的競爭狀況時，會自動切換到適合的鎖實現(xiàn)，這種切換就是鎖的升級、降級。
那么三種不同的 Monitor 實現(xiàn)，也就是常說的三種不同的鎖：偏斜鎖（Biased Locking）、輕量級鎖和重量級鎖。當一個 Monitor 被某個線程持有后，它便處于鎖定狀態(tài)。
Monitor 主要數(shù)據(jù)結(jié)構(gòu)如下：
// initialize the monitor, exception the semaphore, all other fields
// are simple integers or pointers
ObjectMonitor() {
_header = NULL;
_count = 0; // 記錄個數(shù)
_waiters = 0,
_recursions = 0; // 線程重入次數(shù)
_object = NULL; // 存儲 Monitor 對象
_owner = NULL; // 持有當前線程的 owner
_WaitSet = NULL; // 處于wait狀態(tài)的線程，會被加入到 _WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; // 單向列表
FreeNext = NULL ;
_EntryList = NULL ; // 處于等待鎖block狀態(tài)的線程，會被加入到該列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}
源碼地址：jdk8/hotspot/file/vm/runtime/objectMonitor.hpp
_WaitSet、_EntryList，用來保存 ObjectWaiter 對象列表。鎖🔒執(zhí)行效果如下：
如圖 15-06，每個 Java 對象頭中都包括 Monitor 對象(存儲的指針的指向)，synchronized 也就是通過這一種方式獲取鎖，也就解釋了為什么 synchronized() 括號里放任何對象都能獲得鎖🔒！
原子性是指一個操作是不可中斷的，要么全部執(zhí)行成功要么全部執(zhí)行失敗。
案例代碼
private static volatile int counter = 0;
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 10; i++) {
Thread thread = new Thread(() -> {
for (int i1 = 0; i1 < 10000; i1++) {
add();
}
});
thread.start();
}
// 等10個線程運行完畢
Thread.sleep(1000);
System.out.println(counter);
}
public static void add() {
counter++;
}
這段代碼開啟了 10 個線程來累加 counter，按照預期結(jié)果應該是 100000。但實際運行會發(fā)現(xiàn)，counter 值每次運行都小于 10000，這是因為 volatile 并不能保證原子性，所以最后的結(jié)果不會是10000。
修改方法 add()，添加 synchronized：
public static void add() {
synchronized (AtomicityTest.class) {
counter++;
}
}
這回測試結(jié)果就是：100000 了！
因為 synchronized 可以保證統(tǒng)一時間只有一個線程能拿到鎖，進入到代碼塊執(zhí)行。
反編譯查看指令碼
javap -v -p AtomicityTest
public static void add();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=2, args_size=0
0: ldc #12 // class org/itstack/interview/AtomicityTest
2: dup
3: astore_0
4: monitorenter
5: getstatic #10 // Field counter:I
8: iconst_1
9: iadd
10: putstatic #10 // Field counter:I
13: aload_0
14: monitorexit
15: goto 23
18: astore_1
19: aload_0
20: monitorexit
21: aload_1
22: athrow
23: return
Exception table:
同步方法
ACC_SYNCHRONIZED 這是一個同步標識，對應的16進制值是 0x0020
這10個線程進入這個方法時，都會判斷是否有此標識，然后開始競爭 Monitor 對象。
同步代碼
monitorenter，在判斷擁有同步標識 ACC_SYNCHRONIZED 搶先進入此方法的線程會優(yōu)先擁有 Monitor 的 owner ，此時計數(shù)器 +1。monitorexit，當執(zhí)行完退出后，計數(shù)器 -1，歸 0 后被其他進入的線程獲得。在上一章節(jié) volatile 篇中，我們知道它保證變量對所有線程的可見性。最終的效果就是在添加 volatile 的屬性變量時，線程A修改值后，線程B使用此變量可以做出相應的反應，比如 while(!變量) 退出。
那么，synchronized 具備可見性嗎，我們做給例子。
public static boolean sign = false;
public static void main(String[] args) {
Thread Thread01 = new Thread(() -> {
int i = 0;
while (!sign) {
i++;
add(i);
}
});
Thread Thread02 = new Thread(() -> {
try {
Thread.sleep(3000);
} catch (InterruptedException ignore) {
}
sign = true;
logger.info("vt.sign = true while (!sign)")
});
Thread01.start();
Thread02.start();
}
public static int add(int i) {
return i + 1;
}
這是兩個線程操作一個變量的例子，因為線程間對變量 sign 的不可見性，線程 Thread01 中的 while (!sign) 會一直執(zhí)行，不會隨著線程 Thread02 修改 sign = true 而退出循環(huán)。
現(xiàn)在我們給方法 add 添加 synchronized 關鍵字修飾，如下：
public static synchronized int add(int i) {
return i + 1;
}
添加后運行結(jié)果：
23:55:33.849 [Thread-1] INFO org.itstack.interview.VisibilityTest - vt.sign = true while (!sign)
Process finished with exit code 0
可以看到當線程 Thread02 改變變量 sign = true 后，線程 Thread01 立即退出了循環(huán)。
注意：不要在方法中添加 System.out.println() ，因為這個方法中含有 synchronized 會影響測試結(jié)果！
那么為什么添加 synchronized 也能保證變量的可見性呢？
因為：
as-if-serial，保證不管編譯器和處理器為了性能優(yōu)化會如何進行指令重排序，都需要保證單線程下的運行結(jié)果的正確性。也就是常說的：如果在本線程內(nèi)觀察，所有的操作都是有序的；如果在一個線程觀察另一個線程，所有的操作都是無序的。
這里有一段雙重檢驗鎖（Double-checked Locking）的經(jīng)典案例：
public class Singleton {
private Singleton() {
}
private volatile static Singleton instance;
public Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
為什么，synchronized 也有可見性的特點，還需要 volatile 關鍵字？
因為，synchronized 的有序性，不是 volatile 的防止指令重排序。
那如果不加 volatile 關鍵字可能導致的結(jié)果，就是第一個線程在初始化初始化對象，設置 instance 指向內(nèi)存地址時。第二個線程進入時，有指令重排。在判斷 if (instance == null) 時就會有出錯的可能，因為這會可能 instance 可能還沒有初始化成功。
synchronized 是可重入鎖，也就是說，允許一個線程二次請求自己持有對象鎖的臨界資源，這種情況稱為可重入鎖🔒。
那么我們就寫一個例子，來證明這樣的情況。
public class ReentryTest extends A{
public static void main(String[] args) {
ReentryTest reentry = new ReentryTest();
reentry.doA();
}
public synchronized void doA() {
System.out.println("子類方法：ReentryTest.doA() ThreadId：" + Thread.currentThread().getId());
doB();
}
private synchronized void doB() {
super.doA();
System.out.println("子類方法：ReentryTest.doB() ThreadId：" + Thread.currentThread().getId());
}
}
class A {
public synchronized void doA() {
System.out.println("父類方法：A.doA() ThreadId：" + Thread.currentThread().getId());
}
}
測試結(jié)果
子類方法：ReentryTest.doA() ThreadId：1
父類方法：A.doA() ThreadId：1
子類方法：ReentryTest.doB() ThreadId：1
Process finished with exit code 0
這段單例代碼是遞歸調(diào)用含有 synchronized 鎖的方法，從運行正常的測試結(jié)果看，并沒有發(fā)生死鎖。所有可以證明 synchronized 是可重入鎖。
synchronized鎖對象的時候有個計數(shù)器，他會記錄下線程獲取鎖的次數(shù)，在執(zhí)行完對應的代碼塊之后，計數(shù)器就會-1，直到計數(shù)器清零，就釋放鎖了。
之所以，是可以重入。是因為 synchronized 鎖對象有個計數(shù)器，會隨著線程獲取鎖后 +1 計數(shù)，當線程執(zhí)行完畢后 -1，直到清零釋放鎖。
關于 synchronized 鎖🔒升級有一張非常完整的圖，可以參考：
synchronized 鎖有四種交替升級的狀態(tài)：無鎖、偏向鎖、輕量級鎖和重量級，這幾個狀態(tài)隨著競爭情況逐漸升級。
synchronizer源碼：/src/share/vm/runtime/synchronizer.cpp
// NOTE: must use heavy weight monitor to handle jni monitor exit
void ObjectSynchronizer::jni_exit(oop obj, Thread* THREAD) {
TEVENT (jni_exit) ;
if (UseBiasedLocking) {
Handle h_obj(THREAD, obj);
BiasedLocking::revoke_and_rebias(h_obj, false, THREAD);
obj = h_obj();
}
assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
ObjectMonitor* monitor = ObjectSynchronizer::inflate(THREAD, obj);
// If this thread has locked the object, exit the monitor. Note: can't use
// monitor->check(CHECK); must exit even if an exception is pending.
if (monitor->check(THREAD)) {
monitor->exit(true, THREAD);
}
}
XX:-UseBiasedLocking=false偏斜鎖會延緩 JIT 預熱進程，所以很多性能測試中會顯式地關閉偏斜鎖，偏斜鎖并不適合所有應用場景，撤銷操作（revoke）是比較重的行為，只有當存在較多不會真正競爭的 synchronized 塊兒時，才能體現(xiàn)出明顯改善。
當鎖是偏向鎖的時候，被另一個線程所訪問，偏向鎖就會升級為輕量級鎖，其他線程會通過自旋的形式嘗試獲取鎖，不會阻塞，提高性能。
在代碼進入同步塊的時候，如果同步對象鎖狀態(tài)為無鎖狀態(tài)（鎖標志位為“01”狀態(tài)，是否為偏向鎖為“0”），JVM虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的Mark Word的拷貝，官方稱之為 Displaced Mark Word。
自旋鎖是指嘗試獲取鎖的線程不會立即阻塞，而是采用循環(huán)的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環(huán)會消耗CPU。
自旋鎖的默認大小是10次，可以調(diào)整：-XX：PreBlockSpin
如果自旋n次失敗了，就會升級為重量級的鎖。重量級的鎖，在 1.3 Monitor 對象中已經(jīng)介紹。
之前一直了解到 Java 不會進行鎖降級，但最近整理了大量的資料發(fā)現(xiàn)鎖降級確實是會發(fā)生。
When safepoints are used?
Below are few reasons for HotSpot JVM to initiate a safepoint:
Garbage collection pauses
Code deoptimization
Flushing code cache
Class redefinition (e.g. hot swap or instrumentation)
Biased lock revocation
Various debug operation (e.g. deadlock check or stacktrace dump)
Biased lock revocation，當 JVM 進入安全點 SafePoint的時候，會檢查是否有閑置的 Monitor，然后試圖進行降級。
synchronized 鎖涉及到了較多的C++源碼分析學習，源碼地址：https://github.com/JetBrains/jdk8u_hotspot