我們一起來分析一下原因,我們獲取鎖之后,我們只打印了一個日志,然后從配置文件里面拿到一個hour,然后就結束了,結束之后就來到finally里邊,而這個時間并沒有執行SQL語句,所以他的時間會非常非常短,是小于一秒的,而另外一個TOMCAT在執行的時候呢,在等待一秒之后,發現我又能獲取鎖了,所以在同一次Schedule執行的時候,我們就會發生兩個進程,都拿到分布式鎖,所以這一次我們把waittime改成0,/*** Redisson分布式鎖實現* @throws InterruptedException*/ // @Scheduled(cron="0 */1 * * * ?")//每1分鐘(每個1分鐘的整數倍)public void closeOrderTaskV4() throws InterruptedException {RLock lock = redissonManager.getRedisson().getLock(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);boolean getLock = false;try {if(getLock = lock.tryLock(0,50, TimeUnit.SECONDS)){//trylock增加鎖log.info("===獲取{},ThreadName:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,Thread.currentThread().getName());int hour = Integer.parseInt(PropertiesUtil.getProperty("close.order.task.time.hour","2"));iOrderService.closeOrder(hour);}else{log.info("===沒有獲得分布式鎖:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);}}finally {if(!getLock){return;}log.info("===釋放分布式鎖:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);lock.unlock();為1的時候兩個TOMCAT都會獲取到鎖的一個問題,那我們就可以使waittime變成0,解決了這個問題,不再去等待,所以這也是我們實際工作中發現的一個問題,一個小坑,如果大家對這里的預估時間不是太準確的話,建議把waittime這個時間設置為0,以及如何分析waittime的一個原理,在使用Redisson的時候,我們最好使用waittime是0,否則會產生兩邊同時拿到分布式鎖的一個問題,也就是我們分布式事務執行的非常非常快,小于1秒的時候,就會有這么一個坑,我現在在實際工作中使用Redisson分布式鎖的時候,也會把waittime統一設置成0,finally里如果沒有獲取到所就直接return了,并不會執行unlock和打印日志,所以在TOMCAT2里只會看到沒有獲取到分布式鎖,和我們預期是一致的,waittime請大家務必設置成0,這樣比較統一,也不會出現問題,我們也不需要來評估這個定時任務,所執行業務邏輯的時候,他所耗費的一個時間,我們只需要讓每一次的waittime,為0即可,讓每一個TOMCAT競爭鎖并不等待,對分布式鎖原生實現,和Redisson來實現分布式鎖,都有一個比較深入的理解了

?

總結

以上是生活随笔為你收集整理的Redisson分布式锁实战-2：解决wait_time之坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。