zookeeper实现分布式锁（三）

    前面我们介绍了使用zookeeper实现分布式锁的最常见的做法，就是通过创建临时节点，然后最小节点获取锁的方式。但是zookeeper实现分布式锁的方式不是这一种唯一的办法，我们知道，分布式锁的特点是同一时刻，只有一个进程能够获取锁，其他的进程获取失败，处于等待锁的状态，当获取锁的进程使用完毕之后，会释放锁资源，其他进程会再次争取这把锁。按照这个思路，再结合zookeeper的特点，如果我们同时创建一个永久节点，那么也只有一个进程会创建成功，其他的进程均失败，当我们删除这个永久节点的时候，其他进程才有可能会有一个进程创建成功。基于这个特点，我们可以利用zookeeper来创建另一种分布式锁。

    通过zookeeper创建永久节点的方式创建分布式锁，和普通的锁类似，就是进程获取锁没有一个顺序，谁抢到锁了，谁就占有它，直到完成指定的任务，然后释放锁，再由其他的进程竞争这把锁。这种分布式锁更容易理解，也更加的直观。当有锁资源释放的时候，其余没有获取锁的进程同时来争抢这把锁。

    获取锁的进程，也就是成功创建永久节点的进程，当释放锁的时候，会删除这个永久节点，那么其他进程就有可能会成功创建节点，这里释放锁的过程也很重要，需要明确指出永久节点的路径，才能够释放成功，即使连接不断开也没有关系，如下所示：

    没有获得锁的进程会等待，并且注册一个监听事件，还是监听指定路径的节点，这里所有的等待锁的节点，都监听同一个节点路径，当这个路径被删除的时候，触发节点删除事件，这时候，大家可以去争锁了。争锁就是递归调用加锁方法。如下所示：

   加锁方法：

    这个和最小临时节点获取锁的方法不同的地方在于，是所有没有获取到锁的进程都会去争这把锁，因为大家监听的节点都是一样的，没有什么先后之分，也没有优先级。这里的代码和原生的zookeeper api有些不一样，因为我们使用的是com.101tec这个依赖，下面给出完整的示例：

    pom.xml文件中增加com.101tec这个依赖。

<dependency>
  <groupId>com.101tec</groupId>
  <artifactId>zkclient</artifactId>
  <version>0.10</version>
</dependency>

    定义一个锁的接口Lock.java：

package com.xxx.lock;
public interface Lock {
	public void lock();
	public void unlock();
}

    定义一个抽象类，实现锁接口，ZookeeperAbstractLock.java：

package com.xxx.lock;
import org.I0Itec.zkclient.ZkClient;
public abstract class ZookeeperAbstractLock implements Lock {
	private static final String CONNECTSTRING="localhost:2181";
	protected ZkClient zkclient = new ZkClient(CONNECTSTRING);
	protected static final String PATH = "/lock";
	

	@Override
	public void lock() {
		if(tryLock()){
			System.out.println(Thread.currentThread().getName()+" 获取锁资源");
			return;
		}else{
			waitLock();
			lock();
		}
	}

	@Override
	public void unlock() {
		if(zkclient!=null){
			zkclient.delete(PATH);
			System.out.println(Thread.currentThread().getName()+" 释放锁资源");
			zkclient.close();
		}
	}

	abstract boolean  tryLock();
	abstract void waitLock();
}

    定义一个类继承抽象锁类，ZookeeperDistributedLock.java：

package com.xxx.lock;
import java.util.concurrent.CountDownLatch;
import org.I0Itec.zkclient.IZkDataListener;
public class ZookeeperDistributedLock extends ZookeeperAbstractLock {

	private CountDownLatch latch = null;
	@Override
	boolean tryLock() {
		try {
			zkclient.createPersistent(PATH);
			return true;
		} catch (Exception e) {
			return false;
		}
	}

	@Override
	void waitLock() {
		IZkDataListener listener = new IZkDataListener() {	
			@Override
			public void handleDataDeleted(String s) throws Exception {
				if(latch!=null){
					latch.countDown();
				}
			}
			@Override
			public void handleDataChange(String s, Object o) throws Exception {}
		};
		zkclient.subscribeDataChanges(PATH, listener);
		if(zkclient.exists(PATH)){
			latch = new CountDownLatch(1);
			try {
				latch.await();
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
		zkclient.unsubscribeDataChanges(PATH, listener);
	}

}

    测试类：

package com.xxx.lock;
public class MainService{

	public static void main(String[] args) {
		for(int i=0;i<10;i++){
			Thread thread = new Thread(new Runnable(){
				private Lock lock = new ZookeeperDistributedLock();			
				@Override
				public void run() {
					try {
						lock.lock();
						System.out.println(Thread.currentThread().getName()+" start.");
						Thread.sleep(200);
						System.out.println(Thread.currentThread().getName()+" end.");
					} catch (Exception e) {
						e.printStackTrace();
					}finally{
						lock.unlock();
					}
				}
			});
			thread.start();
		}
	}

}

    运行测试类，打印信息如下：

    因为这种锁的争锁过程是随机的，哪个进程获取锁，是无法预测的，但是获取锁之后，其余线程处于等待状态，只有获取锁的进程执行完毕，释放锁资源了，其余进程才有可能获取锁。

    这种锁的实现方式和redis实现的分布式锁类似，即同一时刻，只有一个进程会成功创建永久节点，就获得锁，其余进程则等待资源释放，释放会触发监听事件，剩余进程再次争锁。