1：java中自帶的鎖有系統所sychronized與應用層面的鎖lock，基於lock就介紹ReentrantLock。
基於這個層面的lock核心就是AQS，lock的底層原理實現還是依賴CAS，在jdk早期版本中，lock的性能是要優於sychronized的。主要是因爲之前的版本sychronized一直是一把重量級鎖需要去調用的操作系統。
2：而優化後的sychronized，在偏向鎖與輕量級鎖的實現依賴於對象體於CAS。關於他的具體介紹這個大家可以去百度他的實現原理。
在我們普通項目中要去保證一些數據操作的原子性，我們很多時候直接去使用java鎖。但是很多場景直接的對方法枷鎖不是特麼高效的意見事情，例如多個人對不同的類型的數據進行操作，操作不同類型之間完全不必要有鎖。如果系統的併發量不大，這樣也是沒什麼問題的，當然也可以去使用分段鎖。但是如果類型特別多，而且類型還是動態的，簡單的使用分段鎖的實現方式，也不是特別好了。
我想介紹一下我目前基於秒殺場景與防止超賣的實現，我使用的redis，我想要要說下我爲什麼使用redis來實現。很重要一點是因爲redis的線程模型，大家應該都知道他是一個單線程的模型，他有點類似netty使用的reactor模型，無論在什麼情況下，他都會只有一個命令的執行。其實大家也有一個疑惑點，這個的話跟使用隊列有什麼區別呢，其實在redis的模型中也是有一個隊列的。所以的請求執行命令都在隊列中，在大規模的場景中，我們可以有很多的redis，這意味着我們能有很多個類型的數據在並行執行。這樣的操作我們對我們的業務層面代碼影響是比較小的，如果是在微服務集羣的應用部署情況下，我們還要去使用分佈式鎖，這樣我們直接利用redis來操作，就節省了這些步驟，但是這樣也是有缺點的，如果併發比較高，公司的redis做了一主多從，那麼這樣的設計也是有問題的。因爲請求打在了計算之後的redis上，但是他多從，這樣同一個類型的數據不在同一個redis中執行。當然這個可以是在業務中去控制的，我目前是在對redis封裝的過程中基於不同的類型去做控制的。
3：對redis去實現這樣我們存放數據到redis然後之間進去操作就可以了，業務相對簡單。不需要去關心隊列呀，鎖呀這套東西。單體項目來說，直接使用是相對簡單的。