Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to use ZooKeeper to achieve Java cross-JVM distributed read-write locks. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Read-write lock:

Use ZooKeeper to implement Java distributed locks across JVM (read-write locks).

A brief introduction to read-write locks, when using read-write locks, multiple clients (threads) can acquire "read locks" at the same time, but "write locks" are exclusive and can only be acquired separately.

1. Suppose thread A _ B acquires the "read lock", then the C thread cannot acquire the "write lock".

2. Assuming that the C thread acquires the "write lock", then the A _ Magi B thread cannot acquire the "read lock".

In some cases, this will greatly improve the performance of the system. Java already provides a mechanism for this kind of locking in a single JVM process. You can refer to the ReentrantReadWriteLock class.

ZK-based distributed read-write lock:

This paper mainly introduces the distributed read-write lock of ZK or the implementation based on Curator client.

Package com.framework.code.demo.zook.lock;import org.apache.curator.RetryPolicy;import org.apache.curator.framework.CuratorFramework;import org.apache.curator.framework.CuratorFrameworkFactory;import org.apache.curator.framework.recipes.locks.InterProcessMutex;import org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock;import org.apache.curator.retry.ExponentialBackoffRetry Public class ReadWriteLock {/ * @ param args * @ throws Exception * / public static void main (String [] args) throws Exception {RetryPolicy retryPolicy = new ExponentialBackoffRetry (1000 CuratorFrameworkFactory 3); CuratorFramework client = CuratorFrameworkFactory .newClient ("192.168.1.103 throws Exception 2181", retryPolicy); client.start () InterProcessReadWriteLock readWriteLock = new InterProcessReadWriteLock (client, "/ read-write-lock"); / / read lock final InterProcessMutex readLock = readWriteLock.readLock (); / / write lock final InterProcessMutex writeLock = readWriteLock.writeLock () Try {readLock.acquire (); System.out.println (Thread.currentThread () + "get read lock") New Thread (new Runnable () {@ Override public void run () {try {/) The write lock cannot be read until the read lock is released. WriteLock.acquire (); System.out.println (Thread.currentThread () + "get write lock");} catch (Exception e) {e.printStackTrace () } finally {try {writeLock.release () } catch (Exception e) {e.printStackTrace () }}) .start (); / / pauses for 3000 milliseconds without releasing the lock, when other threads can acquire the read lock, but not the write lock. Thread.sleep (3000);} catch (Exception e) {e.printStackTrace ();} finally {readLock.release ();} Thread.sleep (1000000); client.close ();}}

The principle of implementation:

The principle of implementation is basically similar to the principle of locks introduced earlier, and the differences are mainly explained here.

1. Write lock the node name that is written when the lock is applied for is like this xxxx-__WRIT__00000000xxx for example: _ c_9b6e456b-94fe-47e7-b968-34027c094b7d-__WRIT__0000000006

2. The node name written by the read lock when applying for the lock is as follows: xxxx-__READ__00000000xxx for example: _ c_9b6e456b90-9c33-6294665cf525--b6448-__READ__0000000005

The difference is that the string written to the lock contains WRIT and reads the contained READ

The difference between getting a lock:

1. The processing of the write lock when acquiring the lock is consistent with the principle described in the previous article, that is, to determine whether there is a node in front of you, if not, you can acquire the lock, and if so, wait for the previous node to release the lock.

2. The processing of the read lock when acquiring the lock is to determine whether there is a node in front of the write lock, that is, whether the previous node contains WRIT, and if so, wait for the previous node to release the lock.

It doesn't matter that there are other read lock nodes in front of the read itself, it can still acquire the lock, which is why the read can be shared by multiple clients.

The above is the editor to share with you how to use ZooKeeper to achieve Java cross-JVM distributed read and write locks. If you happen to have similar doubts, please refer to the above analysis. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.