public synchronized void eat()你為eat方法加上synchronized關鍵字，然後執行你的專案。
當你還沒且從未訪問到這個方法的時候就是無鎖狀態
終於, 你第一次訪問到這個帶synchronized的eat方法(可以是多個執行緒同時訪問 由於加了synchronized 同時只能進乙個)假如進來的為執行緒a
此時由於此方法加了synchronized, jvm會向`this`物件
（靜態方法為類物件，鎖指定物件的話就是synchronized括號的那個物件）
物件頭的markword寫入當前執行緒id,
之後這個a執行緒再訪問該方法看到物件頭執行緒id就是自己的就可以直接進入方法執行(可重入)，此時物件頭markword鎖標示位為01
其實此時還是乙個無鎖狀態 好比你在野外撿到乙個錢包 沒人看見 你就把上面寫上自己名字沒人管
第二個訪問執行緒也到了，由於`this`物件頭含有執行緒id不等於自己的執行緒id，
他就進入自旋狀態，（jdk hotspot一般自旋10次）同時會更新物件頭的markword鎖標示位為00
第二個執行緒等不及了，自旋10次後向os告狀，os來主持公道，為該方法的synchronized公升級為重量級鎖，更新markword的鎖標示為10synchronized 鎖的重入
1 乙個同步方法呼叫另外乙個同步方法，能否得到鎖?重入 synchronized預設支援重入 slf4j topic test public class demo catch interruptedexception e test2 為什麼test2還需要加sync 他本身就包含在test1 而te...
synchronized 修飾的鎖
datetime 2020 11 25 21 14 author db public class concurrency private static void lockcode private static void lockmethod 鎖的是物件例項方法，同一物件是同步的，不同物件是非同步的 ...
synchronized鎖的公升級
在分析markword時，提到了偏向鎖 輕量級鎖 重量級鎖。在分析這幾種鎖的區別時，我們先來思考乙個問題 使用鎖能夠實現資料的安全性，但是會帶來效能的下降。不使用鎖能夠基於執行緒並行提公升程式效能，但是卻不能保證執行緒安全性。這兩者之間似乎是沒有辦法達到既能滿足效能也能滿足安全性的要求。hotspo...