? ? ? ? 簡單說一下，redis鎖主要解決并發(fā)量大的情況下，代碼被重復(fù)執(zhí)行。比如一件商品的庫存值為50，在多個線程同時進入去修改商品的庫存值時，會出現(xiàn)該商品會被同時修改兩次為48，就會造成我們數(shù)據(jù)的錯亂 ，明明商品購買記錄是兩次，庫存量卻只減少了1。

? ? ? ? 所以我們基于這種情況可以用到redis的鎖機制，它可以讓每個線程一一排隊去執(zhí)行修改庫存的記錄，第一個改完第二個才會去改，當然這里會給每一把鎖加上唯一標識，并在最后銷毀的時候判斷是不是該線程的鎖，要不會出現(xiàn)一種情況，我銷毀掉了不屬于自己的線程鎖，最后在把redis的鎖釋放掉，相當于銷毀。

? ? ? ? 問題來了，在我們加上鎖時，執(zhí)行業(yè)務(wù)代碼的時候，突然拋出了異常，導(dǎo)致當前線程崩潰，從而沒有銷毀掉鎖，那么后面的線程就會一直等待，就造成了死鎖。解決的方案就是把異常try了，把銷毀步驟放在finally里面，這樣就可以排除掉代碼異常了。

? ? ? ? 有一種特殊的情況，如果在系統(tǒng)掛掉情況下，異常還沒拋出，還沒執(zhí)行finally里面的代碼，同樣也會造成死鎖，這時我們就是用到redis的延時執(zhí)行，在加上鎖的同時給這把鎖加上十秒的延時，十秒后自動釋放掉這把鎖，這種情況理論上可以解決我們的問題，但在延時的過程中，如果我們執(zhí)行的業(yè)務(wù)代碼需要十幾秒的時間，那么就會出現(xiàn)每個十秒后會釋放掉不屬于自己的鎖。

? ? 目前這種已經(jīng)能解決并發(fā)量不大的情況。