分布式锁在分布式应用当中是要经常用到的,主要是解决分布式资源访问冲突的问题。 一开始考虑采用ReentrantLock来实现,但是实际上去实现的时候,是有问题的,ReentrantLock的lock和unlock要求必须是在同一线程进行,而分布式应用中,lock和unlock是两次不相关的请求,因此肯定不是同一线程,因此导致无法使用ReentrantLock。
接下来就考虑采用自己做个状态来进行锁状态的记录,结果发现总是死锁,仔细一看代码,能不锁死么。
1 2 3 4 5 6 7 8 9 10 11 12 |
public synchronized void lock(){ while(lock){ Thread.sleep(1); } lock=true; ... } public synchronized void unlock(){ |
第一个请求要求获得锁,好么,给他个锁定状态,然后他拿着锁去干活了。
这个时候,第二个请求也要求锁,OK,他在lock中等待解锁。
第一个干完活了,过来还锁了,这个时候悲催了,因为,他进不了unlock方法了。
可能有人会问,为什么采用while,而不是采用wait...notify?这个问题留一下,看看有人能给出来不?
总之,上面的方安案流产了。
同样,不把synchronized 放在方法上,直接放在方法里放个同步对象可以不??道理是一样的,也会发生上面一样的死锁。
到此为止前途一片黑暗。
@沈学良 同学的http://my.oschina.net/shenxueliang/blog/135865写了一个用zk做的同布锁,感觉还是比较复杂的且存疑。自己做不出来吧,又不死心。
再来看看Lock的接口,想了一下,不遵守Lock的接口了。编写了下面的接口。
1 2 3 4 5 6 7 8 9 |
public interface DistributedLock extends RemoteObject {
long lock() throws RemoteException, TimeoutException; long tryLock(long time, TimeUnit unit) throws RemoteException, TimeoutException; void unlock(long token) throws RemoteException; } |
呵呵,眼尖的同学可能已经发现不同了。
lock方法增加了个long返回值,tryLock方法,返回的也不是boolean,也是long,unlock方法多了一个long参数型参数,呵呵,技巧就在这里了。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
public class DistributedLockImpl extends UnicastRemoteObject implements DistributedLock { /** * 超时单位 */ private TimeUnit lockTimeoutUnit = TimeUnit.SECONDS; /** * 锁的令牌 */ private volatile long token = 0; /** * 同步对象 */ byte[] lock = new byte[0]; /** * 默认永不超时 */ long lockTimeout = 60 * 60;//默认超时3600秒 long beginLockTime;//获取令牌时间,单位毫秒 public DistributedLockImpl() throws RemoteException { /** |
下面对代码进行一下讲解。
上面的代码提供了,永远等待的获取锁的lock方法和如果在指定的时间获取锁失败就获得超时异常的tryLock方法,另外还有一个unlock方法。
技术的关键点实际上就是在token上,上面的实现,有一个基本的假设,就是两次远程调用之间的时间不可能在1纳秒之内完成。因此,每次锁的操作都会返回一个长整型的令牌,就是当时执行时间的纳秒数。下次解锁必须用获得的令牌进行解锁,才可以成功。如此,解锁就不用添加同步操作了,从而解决掉上面死锁的问题。
实际上,没有令牌也是可以的,但是那样就会导致a获取了锁,但是b执行unlock也会成功解锁,是不安全的,而加入令牌,就可以保证只有加锁者才可以解锁。
下面是测试代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
public class TestDLock { public static void main(String[] args) throws Exception { RmiServer rmiServer = new LocalRmiServer(); DistributedLockImpl distributedLock = new DistributedLockImpl(); rmiServer.registerRemoteObject("lock1", distributedLock); MultiThreadProcessor processor = new MultiThreadProcessor("aa"); for (int i = 0; i < 8; i++) { processor.addProcessor(new RunLock("aa" + i)); } long s = System.currentTimeMillis(); processor.start(); long e = System.currentTimeMillis(); System.out.println(e - s); rmiServer.unexportObject(distributedLock); } } class RunLock extends AbstractProcessor { @Override |
运行情况:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
-0 [main] INFO - 线程组<aa>运行开始,线程数8... -3 [aa-aa0] INFO - 线程<aa-aa0>运行开始... -3 [aa-aa1] INFO - 线程<aa-aa1>运行开始... -3 [aa-aa2] INFO - 线程<aa-aa2>运行开始... -3 [aa-aa3] INFO - 线程<aa-aa3>运行开始... -3 [aa-aa4] INFO - 线程<aa-aa4>运行开始... -4 [aa-aa5] INFO - 线程<aa-aa5>运行开始... -4 [aa-aa6] INFO - 线程<aa-aa6>运行开始... -8 [aa-aa7] INFO - 线程<aa-aa7>运行开始... end-19 -9050 [aa-aa3] INFO - 线程<aa-aa3>运行结束 end-17 -9052 [aa-aa1] INFO - 线程<aa-aa1>运行结束 end-20 -9056 [aa-aa4] INFO - 线程<aa-aa4>运行结束 end-16 -9058 [aa-aa0] INFO - 线程<aa-aa0>运行结束 end-21 -9059 [aa-aa5] INFO - 线程<aa-aa5>运行结束 end-26 -9063 [aa-aa7] INFO - 线程<aa-aa7>运行结束 end-18 -9064 [aa-aa2] INFO - 线程<aa-aa2>运行结束 end-22 -9065 [aa-aa6] INFO - 线程<aa-aa6>运行结束 -9066 [main] INFO - 线程组<aa>运行结束, 用时:9065ms 9069 |
也就是9069ms中执行了8000次锁定及解锁操作。
小结:
上面的分布式锁实现方案,综合考虑了实现简单,锁安全,锁超时等因素。实际测试,大概900到1000次获取锁和释放锁操作每秒,可以满足大多数应用要求。
由于昨天有粉要求尽快发出,因此发得比较匆忙,不足之处及BUG在所难免,欢迎拍砖。