沒什麼太多說的，多線程與高併發，面試重點，咱直接進入正題，聯合底層源碼，咱們從源碼看一下，多線程與高併發底層的知識點，這也是阿里p8+的面試官建議的學習到的級別java
CAS
Compare And Swap (Compare And Exchange) / 自旋 / 自旋鎖 / 無鎖linux
由於常常配合循環操做，直到完成爲止，因此泛指一類操做git
cas(v, a, b) ，變量v，期待值a, 修改值b面試
ABA問題，你的女友在離開你的這段兒時間經歷了別的人，自旋就是你空轉等待，一直等到她接納你爲止bootstrap
解決辦法（版本號 AtomicStampedReference），基礎類型簡單值不須要版本號安全
Unsafe
AtomicInteger:多線程
public final int incrementAndGet() { for (;;) { int current = get(); int next = current + 1; if (compareAndSet(current, next)) return next; } } public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }
Unsafe:架構
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
運用：併發
package com.mashibing.jol; import sun.misc.Unsafe; import java.lang.reflect.Field; public class T02_TestUnsafe { int i = 0; private static T02_TestUnsafe t = new T02_TestUnsafe(); public static void main(String[] args) throws Exception { //Unsafe unsafe = Unsafe.getUnsafe(); Field unsafeField = Unsafe.class.getDeclaredFields()[0]; unsafeField.setAccessible(true); Unsafe unsafe = (Unsafe) unsafeField.get(null); Field f = T02_TestUnsafe.class.getDeclaredField("i"); long offset = unsafe.objectFieldOffset(f); System.out.println(offset); boolean success = unsafe.compareAndSwapInt(t, offset, 0, 1); System.out.println(success); System.out.println(t.i); //unsafe.compareAndSwapInt() } }
jdk8u: unsafe.cpp:app
cmpxchg = compare and exchange
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x)) UnsafeWrapper("Unsafe_CompareAndSwapInt"); oop p = JNIHandles::resolve(obj); jint* addr = (jint *) index_oop_from_field_offset_long(p, offset); return (jint)(Atomic::cmpxchg(x, addr, e)) == e; UNSAFE_END
jdk8u: atomic_linux_x86.inline.hpp
is_MP = Multi Processor
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) { int mp = os::is_MP(); __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)" : "=a" (exchange_value) : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp) : "cc", "memory"); return exchange_value; }
jdk8u: os.hpp is_MP()
static inline bool is_MP() { // During bootstrap if _processor_count is not yet initialized // we claim to be MP as that is safest. If any platform has a // stub generator that might be triggered in this phase and for // which being declared MP when in fact not, is a problem - then // the bootstrap routine for the stub generator needs to check // the processor count directly and leave the bootstrap routine // in place until called after initialization has ocurred. return (_processor_count != 1) || AssumeMP; }
jdk8u: atomic_linux_x86.inline.hpp
#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
最終實現：
cmpxchg = cas修改變量值
lock cmpxchg 指令
硬件：
lock指令在執行後面指令的時候鎖定一個北橋信號
（不採用鎖總線的方式）
工具：JOL = Java Object Layout
<dependencies> <!-- https://mvnrepository.com/artifact/org.openjdk.jol/jol-core --> <dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol-core</artifactId> <version>0.9</version> </dependency> </dependencies>
jdk8u: markOop.hpp
// Bit-format of an object header (most significant first, big endian layout below): // // 32 bits: // -------- // hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object) // size:32 ------------------------------------------>| (CMS free block) // PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object) // // 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)
synchronized的橫切面詳解
- synchronized原理
- 升級過程
- 彙編實現
- vs reentrantLock的區別
java源碼層級
synchronized(o)
字節碼層級
monitorenter moniterexit
JVM層級（Hotspot）
package com.mashibing.insidesync; import org.openjdk.jol.info.ClassLayout; public class T01_Sync1 { public static void main(String[] args) { Object o = new Object(); System.out.println(ClassLayout.parseInstance(o).toPrintable()); } }
com.mashibing.insidesync.T01_Sync1$Lock object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5) 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) 49 ce 00 20 (01001001 11001110 00000000 00100000) (536923721) 12 4 (loss due to the next object alignment) Instance size: 16 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
com.mashibing.insidesync.T02_Sync2$Lock object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 90 2e 1e (00000101 10010000 00101110 00011110) (506368005) 4 4 (object header) 1b 02 00 00 (00011011 00000010 00000000 00000000) (539) 8 4 (object header) 49 ce 00 20 (01001001 11001110 00000000 00100000) (536923721) 12 4 (loss due to the next object alignment) Instance size: 16 bytes Space losses: 0 bytes internal + 4 bytes external = 4 bytes tota
InterpreterRuntime:: monitorenter方法
IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem)) #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif if (PrintBiasedLockingStatistics) { Atomic::inc(BiasedLocking::slow_path_entry_count_addr()); } Handle h_obj(thread, elem->obj()); assert(Universe::heap()->is_in_reserved_or_null(h_obj()), "must be NULL or an object"); if (UseBiasedLocking) { // Retry fast entry if bias is revoked to avoid unnecessary inflation ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK); } else { ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK); } assert(Universe::heap()->is_in_reserved_or_null(elem->obj()), "must be NULL or an object"); #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif IRT_END
synchronizer.cpp
revoke_and_rebias
void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS) { if (UseBiasedLocking) { if (!SafepointSynchronize::is_at_safepoint()) { BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD); if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) { return; } } else { assert(!attempt_rebias, "can not rebias toward VM thread"); BiasedLocking::revoke_at_safepoint(obj); } assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now"); } slow_enter (obj, lock, THREAD) ; }
void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {
markOop mark = obj->mark();
assert(!mark->has_bias_pattern(), "should not see bias pattern here");
if (mark->is_neutral()) {
// Anticipate successful CAS -- the ST of the displaced mark must
// be visible <= the ST performed by the CAS.
lock->set_displaced_header(mark);
if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {
TEVENT (slow_enter: release stacklock) ;
return ;
}
// Fall through to inflate() ...
} else
if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) {
assert(lock != mark->locker(), "must not re-lock the same lock");
assert(lock != (BasicLock*)obj->mark(), "don't relock with same BasicLock");
lock->set_displaced_header(NULL);
return;
}
#if 0
// The following optimization isn't particularly useful.
if (mark->has_monitor() && mark->monitor()->is_entered(THREAD)) {
lock->set_displaced_header (NULL) ;
return ;
}
#endif
// The object header will never be displaced to this lock,
// so it does not matter what the value is, except that it
// must be non-zero to avoid looking like a re-entrant lock,
// and must not look locked either.
lock->set_displaced_header(markOopDesc::unused_mark());
ObjectSynchronizer::inflate(THREAD, obj())->enter(THREAD);
}
inflate方法：膨脹爲重量級鎖
鎖升級過程
JDK8 markword實現表：
無鎖 - 偏向鎖 - 輕量級鎖 （自旋鎖，自適應自旋）- 重量級鎖
synchronized優化的過程和markword息息相關
用markword中最低的三位表明鎖狀態 其中1位是偏向鎖位 兩位是普通鎖位
- Object o = new Object() 鎖 = 0 01 無鎖態
- o.hashCode() 001 + hashcode00000001 10101101 00110100 00110110
01011001 00000000 00000000 00000000little endian big endian 00000000 00000000 00000000 01011001 00110110 00110100 10101101 00000000 - 默認synchronized(o) 00 -> 輕量級鎖 默認狀況 偏向鎖有個時延，默認是4秒 why? 由於JVM虛擬機本身有一些默認啓動的線程，裏面有好多sync代碼，這些sync代碼啓動時就知道確定會有競爭，若是使用偏向鎖，就會形成偏向鎖不斷的進行鎖撤銷和鎖升級的操做，效率較低。-XX:BiasedLockingStartupDelay=0
- 若是設定上述參數 new Object () - > 101 偏向鎖 ->線程ID爲0 -> Anonymous BiasedLock 打開偏向鎖，new出來的對象，默認就是一個可偏向匿名對象101
- 若是有線程上鎖 上偏向鎖，指的就是，把markword的線程ID改成本身線程ID的過程 偏向鎖不可重偏向 批量偏向 批量撤銷
- 若是有線程競爭 撤銷偏向鎖，升級輕量級鎖 線程在本身的線程棧生成LockRecord ，用CAS操做將markword設置爲指向本身這個線程的LR的指針，設置成功者獲得鎖
- 若是競爭加重 競爭加重：有線程超過10次自旋， -XX:PreBlockSpin， 或者自旋線程數超過CPU核數的一半， 1.6以後，加入自適應自旋 Adapative Self Spinning ， JVM本身控制 升級重量級鎖：-> 向操做系統申請資源，linux mutex , CPU從3級-0級系統調用，線程掛起，進入等待隊列，等待操做系統的調度，而後再映射回用戶空間
(以上實驗環境是JDK11，打開就是偏向鎖，而JDK8默認對象頭是無鎖)
偏向鎖默認是打開的，可是有一個時延，若是要觀察到偏向鎖，應該設定參數
沒錯，我就是廁所所長
加鎖，指的是鎖定對象
鎖升級的過程
JDK較早的版本 OS的資源 互斥量 用戶態 -> 內核態的轉換 重量級 效率比較低
現代版本進行了優化
無鎖 - 偏向鎖 -輕量級鎖（自旋鎖）-重量級鎖
偏向鎖 - markword 上記錄當前線程指針，下次同一個線程加鎖的時候，不須要爭用，只須要判斷線程指針是否同一個，因此，偏向鎖，偏向加鎖的第一個線程 。hashCode備份在線程棧上 線程銷燬，鎖降級爲無鎖
有爭用 - 鎖升級爲輕量級鎖 - 每一個線程有本身的LockRecord在本身的線程棧上，用CAS去爭用markword的LR的指針，指針指向哪一個線程的LR，哪一個線程就擁有鎖
自旋超過10次，升級爲重量級鎖 - 若是太多線程自旋 CPU消耗過大，不如升級爲重量級鎖，進入等待隊列（不消耗CPU）-XX:PreBlockSpin
自旋鎖在 JDK1.4.2 中引入，使用 -XX:+UseSpinning 來開啓。JDK 6 中變爲默認開啓，而且引入了自適應的自旋鎖（適應性自旋鎖）。
自適應自旋鎖意味着自旋的時間（次數）再也不固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。若是在同一個鎖對象上，自旋等待剛剛成功得到過鎖，而且持有鎖的線程正在運行中，那麼虛擬機就會認爲此次自旋也是頗有可能再次成功，進而它將容許自旋等待持續相對更長的時間。若是對於某個鎖，自旋不多成功得到過，那在之後嘗試獲取這個鎖時將可能省略掉自旋過程，直接阻塞線程，避免浪費處理器資源。
偏向鎖因爲有鎖撤銷的過程revoke，會消耗系統資源，因此，在鎖爭用特別激烈的時候，用偏向鎖未必效率高。還不如直接使用輕量級鎖。
synchronized最底層實現
public class T { static volatile int i = 0; public static void n() { i++; } public static synchronized void m() {} publics static void main(String[] args) { for(int j=0; j<1000_000; j++) { m(); n(); } } }
java -XX:+UnlockDiagonositicVMOptions -XX:+PrintAssembly T
C1 Compile Level 1 (一級優化)
C2 Compile Level 2 (二級優化)
找到m() n()方法的彙編碼，會看到 lock comxchg .....指令
synchronized vs Lock (CAS)
在高爭用 高耗時的環境下synchronized效率更高 在低爭用 低耗時的環境下CAS效率更高 synchronized到重量級以後是等待隊列（不消耗CPU） CAS（等待期間消耗CPU） 一切以實測爲準
鎖消除 lock eliminate
public void add(String str1,String str2){ StringBuffer sb = new StringBuffer(); sb.append(str1).append(str2); }
咱們都知道 StringBuffer 是線程安全的，由於它的關鍵方法都是被 synchronized 修飾過的，但咱們看上面這段代碼，咱們會發現，sb 這個引用只會在 add 方法中使用，不可能被其它線程引用（由於是局部變量，棧私有），所以 sb 是不可能共享的資源，JVM 會自動消除 StringBuffer 對象內部的鎖。
鎖粗化 lock coarsening
public String test(String str){ int i = 0; StringBuffer sb = new StringBuffer(): while(i < 100){ sb.append(str); i++; } return sb.toString(): }
JVM 會檢測到這樣一連串的操做都對同一個對象加鎖（while 循環內 100 次執行 append，沒有鎖粗化的就要進行 100 次加鎖/解鎖），此時 JVM 就會將加鎖的範圍粗化到這一連串的操做的外部（好比 while 虛幻體外），使得這一連串操做只須要加一次鎖便可。
