一、原子性高頻問題

1.1 Java中如何實(shí)現(xiàn)線程安全?

線程安全問題：多線程操作共享數(shù)據(jù)出現(xiàn)的問題。

實(shí)現(xiàn)線程安全方式：

• 悲觀鎖：synchronized，lock（AQS）
• 樂觀鎖：CAS

可以根據(jù)業(yè)務(wù)情況，選擇ThreadLocal，讓每個(gè)線程玩自己的數(shù)據(jù)。

1.2 CAS底層實(shí)現(xiàn)

• 先比較一下值是否與預(yù)期值一致，如果一致，交換，返回true
• 先比較一下值是否與預(yù)期值一致，如果不一致，不交換，返回false

CAS在Java層面最多就能看到native方法，可以去看Unsafe類中提供的CAS操作

四個(gè)參數(shù)：哪個(gè)對象，哪個(gè)屬性的內(nèi)存偏移量，oldValue，newValue

native是直接調(diào)用本地依賴庫C++中的方法。

unsafe源碼：https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/share/vm/prims/unsafe.cpp

cmpxchg源碼：https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp

cmpxchg ，是匯編的指令，CPU硬件底層就支持 比較和交換 （cmpxchg），cmpxchg并不保證原子性的，如果是多核的操作系統(tǒng)，需要追加一個(gè)lock指令。

lock指令可以理解為是CPU層面的鎖，一般鎖的粒度就是 緩存行 級(jí)別的鎖，當(dāng)然也有 總線鎖 ，但是成本太高，CPU會(huì)根據(jù)情況選擇。

1.3 CAS的常見問題

1. ABA問題： ABA不一定是問題！因?yàn)橐恍┲淮嬖?++，–的這種操作，即便出現(xiàn)ABA問題，也不影響結(jié)果！

   比如說一個(gè)線程one從內(nèi)存位置V中取出A，這時(shí)候另一個(gè)線程two也從內(nèi)存中取出A，并且two進(jìn)行了一些操作變成了B，然后two又將V位置的數(shù)據(jù)變成A，這時(shí)候線程one進(jìn)行CAS操作發(fā)現(xiàn)內(nèi)存中仍然是A，然后one操作成功。

   解決方案很簡單，Java端已經(jīng)提供了，JUC下提供的AtomicStampedReference就可以實(shí)現(xiàn)。修改value的同時(shí)，指定好版本號(hào)，一旦版本號(hào)和數(shù)據(jù)的版本號(hào)不一致就執(zhí)行失敗。
   

2. 自旋次數(shù)過多問題：自旋次數(shù)過多，會(huì)額外的占用大量的CPU資源！浪費(fèi)資源。

   解決方案：

   • synchronized方向：從CAS幾次失敗后，就將線程掛起（WAITING），避免占用CPU過多的資源！
   • LongAdder方向：這里是基于類似 分段鎖 的形式去解決（要看業(yè)務(wù)，有限制的），傳統(tǒng)的AtmoicLong是針對內(nèi)存中唯一的一個(gè)值去++，LongAdder在內(nèi)存中搞了好多個(gè)值，多個(gè)線程去加不同的值，當(dāng)你需要結(jié)果時(shí)，我將所有值累加，返回給你。

3. 只針對一個(gè)屬性保證原子性

1.4 四種引用類型 + ThreadLocal的問題？

ThreadLocal的問題：見Java基礎(chǔ)面試題——IO和多線程專題

四種引用類型：

• 強(qiáng)引用：User xx = new User(); xx就是強(qiáng)引用，只要引用還在，GC就不會(huì)回收！

• 軟引用：用一個(gè)SofeReference引用的對象，就是軟引用，如果內(nèi)存空間不足，才會(huì)回收只有軟引用指向?qū)ο蟆?一般用于做緩存。

  SoftwareReference xx = new SoftwareReference (new User);User user = xx.get();
  

• 弱引用：WeakReference引用的對象，一般就是弱引用，只要執(zhí)行GC，就會(huì)回收只有弱引用指向的對象。可以解決內(nèi)存泄漏的問題 ，看ThreadLocal即可

• 虛引用：PhantomReference引用的對象，就是虛引用，拿不到虛引用指向的對象，一般監(jiān)聽GC回收階段，或者是回收堆外內(nèi)存時(shí)使用。

二、可見性高頻問題

2.1 Java的內(nèi)存模型

在處理指令時(shí)，CPU會(huì)拉取數(shù)據(jù)，優(yōu)先級(jí)是從L1（線程獨(dú)享）到L2（內(nèi)核獨(dú)享）到L3（多核共享），如果都沒有，需要去主內(nèi)存中拉取，JMM就是在CPU和主內(nèi)存之間，來協(xié)調(diào)，保證可見、有序性等操作。

Java Memory Model
、

2.2 保證可見性的方式

啥是可見性： 可見性是指線程間的，對變量的變化是否可見。

Java層面中，保證可見性的方式有很多：

• volatile，用volatile基本數(shù)據(jù)類型，可以保證每次CPU去操作數(shù)據(jù)時(shí)，都直接去主內(nèi)存進(jìn)行讀寫。
• synchronized，synchronized的內(nèi)存語義可以保證在獲取鎖之后，可以保證前面操作的數(shù)據(jù)是可見的。
• lock（CAS-volatile），也可以保證CAS或者操作volatile的變量之后，可以保證前面操作的數(shù)據(jù)是可見的。
• final，是常量沒法動(dòng)~~。

2.3 volatile修飾引用數(shù)據(jù)類型

volatile修飾引用數(shù)據(jù)類型，只能保證引用數(shù)據(jù)類型的地址是可見的，不保證內(nèi)部屬性可見。

2.4 有了MESI協(xié)議，為啥還有volatile？

MESI是CPU緩存一致性的協(xié)議，大多數(shù)的CPU廠商都根據(jù)MESI去實(shí)現(xiàn)了緩存一致性的效果。

MESI協(xié)議和volatile不沖突，因?yàn)镸ESI是CPU層面的，而CPU廠商很多實(shí)現(xiàn)不一樣，而且CPU的架構(gòu)中的一些細(xì)節(jié)也會(huì)有影響，比如Store Buffer會(huì)影響寄存器寫入L1緩存，導(dǎo)致緩存不一致。volatile的底層生成的是匯編的lock指令，這個(gè)指令會(huì)要求強(qiáng)行寫入主內(nèi)存，并且可以忽略Store Buffer這種緩存從而達(dá)到可見性的目的，而且會(huì)利用MESI協(xié)議，讓其他緩存行失效。當(dāng)然，如果沒有MESI協(xié)議，volatile也會(huì)存在一些問題。

2.5 volatile的可見性底層實(shí)現(xiàn)

volatile的底層生成的是匯編的lock指令，這個(gè)指令會(huì)要求強(qiáng)行寫入主內(nèi)存，并且可以忽略Store Buffer這種緩存從而達(dá)到可見性的目的，而且會(huì)利用MESI協(xié)議，讓其他緩存行失效。

三、有序性高頻問題

3.1 什么是有序性問題

在Java編譯.java為.class時(shí)，會(huì)基于JIT做優(yōu)化，將指令的順序做調(diào)整，從而提升執(zhí)行效率。在CPU層面，也會(huì)對一些執(zhí)行進(jìn)行重新排序，從而提升執(zhí)行效率。這種指令的調(diào)整，在一些特殊的操作上，會(huì)導(dǎo)致出現(xiàn)問題。

單例模式中的懶漢機(jī)制中，就存在一個(gè)這樣的問題。懶漢為了保證線程安全，一般會(huì)采用DCL的方式。

3.2 volatile的有序性底層實(shí)現(xiàn)

被volatile修飾的屬性，在編譯時(shí)，會(huì)在前后追加 內(nèi)存屏障 ，這個(gè)內(nèi)存屏障是JDK規(guī)定的，目的是保證volatile修飾的屬性不會(huì)出現(xiàn)指令重排的問題。

Store Store：屏障前的讀寫操作，必須全部完成，再執(zhí)行后續(xù)操作

Store Load：屏障前的寫操作，必須全部完成，再執(zhí)行后續(xù)讀操作

Load Load：屏障前的讀操作，必須全部完成，再執(zhí)行后續(xù)讀操作

Load Store：屏障前的讀操作，必須全部完成，再執(zhí)行后續(xù)寫操作

volatile在JMM層面，保證JIT不重排可以理解，但是，CPU怎么實(shí)現(xiàn)的,
查看這個(gè)文檔：https://gee.cs.oswego.edu/dl/jmm/cookbook.html

不同的CPU對內(nèi)存屏障都有一定的支持，比如×86架構(gòu)，內(nèi)部自己已經(jīng)實(shí)現(xiàn)了LS，LL，SS，只針對SL做了支持。

去openJDK再次查看，mfence是如何支持的。其實(shí)在底層還是mfence內(nèi)部的lock指定，來解決指令重排問題。

四、synchronized高頻問題

4.1 synchronized鎖升級(jí)的過程?

鎖就是對象，隨便哪一個(gè)都可以，Java中所有對象都是鎖。

升級(jí)過程：無鎖(匿名偏向)->偏向鎖->輕量級(jí)鎖->重量級(jí)鎖

無鎖(匿名偏向)： 一般情況下，new出來的一個(gè)對象，是無鎖狀態(tài)。因?yàn)槠蜴i有延遲，在啟動(dòng)JVM的4s中，不存在偏向鎖，但是如果關(guān)閉了偏向鎖延遲的設(shè)置，new出來的對象，就是匿名偏向。

偏向鎖： 當(dāng)某一個(gè)線程來獲取這個(gè)鎖資源時(shí)，此時(shí)，就會(huì)變?yōu)槠蜴i，偏向鎖存儲(chǔ)線程的ID，當(dāng)偏向鎖升級(jí)時(shí)，會(huì)觸發(fā)偏向鎖撤銷，偏向鎖撤銷需要等到一個(gè)安全點(diǎn)，比如GC的時(shí)候，偏向鎖撤銷的成本太高，所以默認(rèn)開始時(shí)，會(huì)做偏向鎖延遲。

安全點(diǎn)：

• GC
• 方法返回之前
• 調(diào)用某個(gè)方法之后
• 甩異常的位置
• 循環(huán)的末尾

輕量級(jí)鎖： 當(dāng)在出現(xiàn)了多個(gè)線程的競爭，就要升級(jí)為輕量級(jí)鎖（有可能直接從無鎖變?yōu)檩p量級(jí)鎖，也有可能從偏向鎖升級(jí)為輕量級(jí)鎖），輕量級(jí)鎖的效果就是基于CAS嘗試獲取鎖資源，這里會(huì)用到自適應(yīng)自旋鎖，根據(jù)上次CAS成功與否，決定這次自旋多少次。

重量級(jí)鎖： 如果到了重量級(jí)鎖，如果有線程持有鎖，其他競爭的，就掛起。

4.2 synchronized鎖粗化&鎖消除？

鎖粗化（鎖膨脹）：（JIT優(yōu)化）

while(){sync(){// 多次的獲取和釋放，成本太高，優(yōu)化為下面這種}
}
//----
sync(){while(){//  優(yōu)化成這樣}
}

鎖消除：在一個(gè)sync中，沒有任何共享資源，也不存在鎖競爭的情況，JIT編譯時(shí)，就直接將鎖的指令優(yōu)化掉。

4.3 synchronized實(shí)現(xiàn)互斥性的原理？

偏向鎖：查看對象頭中的MarkWord里的線程ID，是否是當(dāng)前線程，如果不是，就CAS嘗試改，如果是，就拿到了鎖資源。

輕量級(jí)鎖：查看對象頭中的MarkWord里的Lock Record指針指向的是否是當(dāng)前線程的虛擬機(jī)棧，如果是，拿鎖執(zhí)行業(yè)務(wù)，如果不是CAS，嘗試修改，修改他幾次，不成，再升級(jí)到重量級(jí)鎖。

重量級(jí)鎖：查看對象頭中的MarkWord里的指向的ObjectMonitor，查看owner是否是當(dāng)前線程，如果不是，扔到ObjectMonitor里的EntryList中，排隊(duì)，并掛起線程，等待被喚醒。

4.4 wait為什么是Object下的方法？

1. wait方法是在持有sync鎖的時(shí)候釋放鎖資源。
2. sync鎖的是對象也就是Object。
3. 所以wait自然是Object下的方法。