1. Introduction to reentrant locks
What is a reentrant lock, for example
Now I have a lock object lock, in the call to method A, it is locked with lock
After locking, there is a call to method B in method A, and method B is locked with lock.
If it is not a reentrant lock, it will deadlock when calling method B, because the lock lock in method A will not be released yet.
If it is a reentrant lock, then you can directly run the B method, you should understand this, once a lock is acquired in the same thread, then
The subsequent execution of the thread also needs this lock, so you can use it directly
Want to learn more about reference: https://blog.csdn.net/yanyan19880509/article/details/52345422 , and then go to see the relevant source code by yourself
Except for synchronize and ReentrantLock and subclasses, the others are not reentrant. Of course, with the help of AQS, you can implement reentry lock yourself
2.lock lock test
Add the code in IndexController as follows
@RequestMapping({"/hello"})
@ResponseBody
public String hello(){
//获取一把锁,只要名称一样就是同一把锁
RLock lock = redissonClient.getLock("my-lock");
//加锁 没加上锁的线程阻塞式等待,不用我们之前那样写的自旋
lock.lock();
//模拟业务执行
System.out.println("加锁成功,业务执行中,执行线程为:"+Thread.currentThread().getId());
try {
Thread.sleep(30000);
} catch (InterruptedException e) {
e.printStackTrace();
}finally {
//释放锁
System.out.println("释放锁,执行线程为:"+Thread.currentThread().getId());
lock.unlock();
}
return "hello";
}
The browser opens two windows at the same time to access this method
The browser displays as follows. You can see that one thread acquires the lock, executes the business and then releases the lock, and then another thread does the same operation. The thread that has not acquired the lock will block and wait until the lock is released.
The above has seen the basic functions of the lock. As we said in the previous section, the sudden downtime or the power failure lock is not released, or the lock is acquired, the atomicity problem is unlocked, and so on.
Does Reddison have a solution? A simple test
Now I am testing the problem of a thread that crashes when the lock is added and the lock is released before the lock is released. If the lock is not released after the crash, it will naturally deadlock.
Copy the application configuration and start after changing the port
Visit after starting two services
At this time, the service is stopped after the lock in the service on port 10201 is acquired
Seeing that the lock in the 10200 service can still be acquired, the business is executed as usual and the lock is released
Explain that the lock is released after the downtime. It is guessed that there should be a default expiration time, so the lock will be released after the service is stopped. More than that, I believe
The atomicity of acquiring and unlocking locks is also implemented at the bottom of the lock. If the business allows a long time, there is no need to worry about the automatic release of the lock before the business runs. During the business operation, there will be automatic renewal every ten seconds.
The next section takes you to see how the underlying code is implemented