Non-advertising: This photo was taken in Pengzhou, Sichuan province – Starry Bubble House, douyin Internet celebrity homestay.

These reviews

The last article was the second in distributed Locks – who secretly released our locks.

Review:

If the execution time of the synchronized code block is not properly evaluated, thread 1’s synchronized code block does not complete execution within the specified timeout, and the key is automatically removed, causing thread 2 to compete for the lock.

However, the lock will still be released in the finally block after thread 1 business is executed. The lock release process does not determine which thread added the lock, resulting in accidental release of the lock on thread 2.

The solution we use is to set the value to the token value (which can be a UUID) when the lock is added, and determine whether the token is equal to the token set when the lock is released. Therefore, only the lock added by the thread itself will be released, not the lock of other threads.

The problem of feedback

Concurrent classical problem

This scheme was questioned: some friends left me messages on wechat, but the feedback still had the problem of thread safety. First of all, thank you very much for your valuable advice:

Figure 1: jsonL feedback problem

There is thread safe code in @jsonl feedback. I took a screenshot and marked it with a red box, as shown below:

Figure 2: Code with suspected thread safety problems

If you’ve studied concurrent programming, this snippet might be sensitive to typical “read-write” operations such as i++. What looks like a one-step operation is actually composed of three steps:

  • Get the value of I
  • I value + 1
  • Assign the new value to I

So i++ is not atomic. Similarly, the code in the red box in the above image, the first step to query the value of the key, the second step to delete the key, is also not atomic. Therefore, it is also thread unsafe. So what’s the problem with this code in a distributed lock scenario? Let me illustrate this with a sequence diagram:

Figure 3: Timing diagrams for thread 1 and thread 2

Don’t know when it comes to here, if you have found the problem, because get (key) and del (key) of atomic destruction, location, the arrow points to the mistake of the release of the thread 2 lock, thread 2 lock is released, a distributed lock was really lost its meaning, for synchronized code block by multiple threads or threads in the process of the multiple access at the same time.

How to ensure the atomicity of two commands

Redis introduced scripting in 2.6, allowing developers to write scripts in Lua and upload them to Redis for execution. Redis executes the entire script as a whole, with no other commands inserted in between.

With Lua script support, we only need to write the get+del logic in the script to ensure the atomicity of the two commands, and we can release the lock safely with Lua script:

if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end
Copy the code

Figure 4: Lua script for get+del

You must be wondering, how does Java call Lua scripts? We can use Java client tools such as Jedis.

Call Lua’s methods: jedis. Eval (script, key, params).

Stage summary

After several twists and turns, the distributed lock seems to have seen the prototype. Solved most of our scenarios and prototypes.

Figure 5: Distributed lock phase summary

The use of distributed locks in some Internet companies I work for and even in some large factories is actually only applied to this.

However, when using distributed locks, it’s not as if there aren’t other problems, just a shortcut, a trade-off between cost and implementation. After all, other problems are less likely. And some of the older systems themselves packaged Redis distributed locks without using a framework like Redission, also a little rough.

However, there are problems with distributed locking that should not be ignored, and we will continue to talk about them in the next article.

Good tip: Visit the interview cycle website for more information on interviewing, architecture, algorithms, middleware and other important materials.