多個使用者下訂單， 生成全域性自增的訂單id
定義全域性變數 a =0,
啟動50 個執行緒 生成50 個訂單id 時 a+1， 會有重複的訂單id 出現。 執行緒不安全
解決：一：基於 jvm 解決方式。
1.將全域性變數， 自增時得**塊 加synchorized 關鍵字
2. lock lock= new reentranlock（）
tryfinally
二： 分布式 解決方式
資料庫鎖 ： 悲觀鎖。。。。效能非常差
redis 鎖 ： 容易產生死鎖
zookeeper 鎖
資料監聽觸發器
持久節點， 與zookeeper 客戶端 斷開 資料還存在
臨時節點：與zookeeper 客戶端 斷開 資料還不存在
不帶變編號的節點：create aaa 後 再 create aaa 會報錯
帶編號的節點：create aaa 生成 aaa_000001 的編號節點
再create aaa 不會報錯 生成aaa_000002 的編號節點
基於異常的分布式鎖（基於臨時節點）
建立不帶序號的節點， 建立成功獲得鎖， 建立不成功， 會丟擲異常， 監聽lock 節點， 當lock 刪除時，再重新去建立節點
基於相互監聽（效能高， 占用資源， 基於臨時帶序號的節點）
高併發下列舉單例執行緒安全？
先說結果，不是安全的 展示下列舉單例 package com.self.entity public enum logsingleton public logsingleton add override public string tostring 然後是呼叫方法 package com.self.t...
高併發下實現執行緒安全的i 操作
這個比較簡單，就是在進行i 操作時，直接使用synchronized加鎖，也可以使用lock加鎖，本質都是一樣的 鎖原理不同 最終都是通過加鎖來保證多執行緒安全的。public class synchronized add public static void main string args th...
高併發下，如何防止快取被「擊穿」
對於一些設定了過期時間的key，如果這些key可能會在某些時間點被超高併發地訪問，是一種非常 熱點 的資料。這個時候，需要考慮另外乙個問題 快取被 擊穿 的問題。啟用新的get方法，防止快取被 擊穿 擊穿 快取在某個時間點過期的時候，恰好在這個時間點對這個key有大量的併發請求過來，這些請求發現快取...