• 執行緒安全問題：多執行緒，共享資源，非原子性操作；同一時間，同一資源

• i++不是原子性操作，是一組操作，三步操作

  1.從主存讀值
  2.+1操作
  3.刷寫到記憶體

A B 都想執行i++

A 獲取CPU資源 時間片形式

A 2ms B 5ms

會導致資料更新出問題

解決：synchronized

各種悲觀鎖：多執行緒並行=>單執行緒序列

A沒用完不讓B用

sync：堆，執行緒共享區，鎖物件，int count = 0; 預設互斥量為0

lock：AQS volatile static int state = 0; 預設互斥量也為0

可見，互斥量 int

//單機鎖互斥原理
if (count/state == 0){
    count/state = 1;//獲取鎖成功
    //一頓操作
    count/state = 0;
    //喚醒別人
} else {
    //獲取鎖失敗，掛起執行緒並加入佇列等待
}
 

分散式鎖

獲取鎖：相同目錄建立一個資料夾，mkdir /usr/lock/

釋放鎖：rm -rf /usr/lock/

只有一個執行緒能成功在一個路徑建立這個資料夾，其他執行緒等待

redis實現

只有一個執行緒能 set 成功，f 為 true

finally，即使中間斷了也會釋放鎖，但是斷電了還是執行不了，所以要給鎖加一個 timeout 過期時間，過時間自動刪除了

圖中第 4 行執行後斷電，第 5 行沒有執行，一直佔用鎖怎麼辦

//寫到一行了，具有原子性
Boolean f = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, lockValue, timeout);
 

業務時間超過鎖的 timeout 時間咋辦（ABC問題）

給鎖加上唯一標識，自己上的鎖只有自己能解開，具體操作：

String lockValue = UUID.randomUUID.toString();

但是業務還是跑不完啊，怎麼辦（AB問題）

開子執行緒（守護執行緒）續命，監視到主執行緒死了/業務結束了，結束自己；主執行緒死了：鎖 timeout 釋放 / 業務結束了：finally 釋放鎖

守護執行緒：

主從架構鎖失效

redis 高效能 電商：

zookeeper 高穩定 金融：主伺服器知道你想上鎖後，把這個訊息發給從伺服器，從伺服器有一半以上都知道你上鎖了，上鎖才能成功（分散式鎖，投票上鎖？）

分散式鎖基於單機鎖推導，悲觀鎖

redisson用法

併發那麼高，分散式鎖效能得多慢，怎麼解決

1.降低鎖粒度，多餘的業務別放鎖裡啊，不同的物件別用一個鎖啊，加了不同業務的獨立 id

2.分段容器，每個資料做分段，甚至細到每個資料，每個資料的每個欄位，整體架構優化