乐观锁和悲观锁的区别
悲观锁(Pessimistic Lock):每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
乐观锁(Optimistic Lock):每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。
乐观锁例子:
/**
* 乐观锁
*
* 场景:有一个对象value,需要被两个线程调用,由于是共享数据,存在脏数据的问题
* 悲观锁可以利用synchronized实现,这里不提.
* 现在用乐观锁来解决这个脏数据问题
*
*/
public class OptimisticLock {
public static int value = 0; // 多线程同时调用的操作对象
/**
* A线程要执行的方法
*/
public static void invoke(int Avalue, String i)
throws InterruptedException {
Thread.sleep(1000L);//延长执行时间
if (Avalue != value) {//判断value版本
System.out.println(Avalue + ":" + value + "A版本不一致,不执行");
value--;
} else {
Avalue++;//对数据操作
value = Avalue;;//对数据操作
System.out.println(i + ":" + value);
}
}
/**
* B线程要执行的方法
*/
public static void invoke2(int Bvalue, String i)
throws InterruptedException {
Thread.sleep(1000L);//延长执行时间
if (Bvalue != value) {//判断value版本
System.out.println(Bvalue + ":" + value + "B版本不一致,不执行");
} else {
System.out.println("B:利用value运算,value="+Bvalue);
}
}
/**
* 测试,期待结果:B线程执行的时候value数据总是当前最新的
*/
public static void main(String[] args) throws InterruptedException {
new Thread(new Runnable() {//A线程
public void run() {
try {
for (int i = 0; i < 3; i++) {
int Avalue = OptimisticLock.value;//A获取的value
OptimisticLock.invoke(Avalue, "A");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
new Thread(new Runnable() {//B线程
public void run() {
try {
for (int i = 0; i < 3; i++) {
int Bvalue = OptimisticLock.value;//B获取的value
OptimisticLock.invoke2(Bvalue, "B");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
测试结果:
A:1
0:1B版本不一致,不执行
B:利用value运算,value=1
A:2
B:利用value运算,value=2
A:3
从结果中看出,B线程在执行的时候最后发现自己的value和执行前不一致,说明被A修改了,那么放弃了本次执行.
多运行几次发现了下面的结果:
A:1
B:利用value运算,value=0
A:2
1:2B版本不一致,不执行
A:3
B:利用value运算,value=2
从结果看A修改了value值,B却没有检查出来,利用错误的value值进行了操作. 为什么会这样呢?
这里就回到前面说的乐观锁是有一定的不安全性的,B在检查版本的时候A还没有修改,在B检查完版本后更新数据前(例子中的输出语句),A更改了value值,这时B执行更新数据(例子中的输出语句)就发生了与现存value不一致的现象.
针对这个问题,我觉得乐观锁要解决这个问题还需要在检查版本与更新数据这个操作的时候能够使用悲观锁,比如加上synchronized,让它在最后一步保证数据的一致性.这样既保证多线程都能同时执行,牺牲最后一点的性能去保证数据的一致.
补充
有两种方式来保证乐观锁最后同步数据保证它原子性的方法
1,CAS方式:Java非公开API类Unsafe实现的CAS(比较-交换),由C++编写的调用硬件操作内存,保证这个操作的原子性,concurrent包下很多乐观锁实现使用到这个类,但这个类不作为公开API使用,随时可能会被更改.我在本地测试了一下,确实不能够直接调用,源码中Unsafe是私有构造函数,只能通过getUnsafe方法获取单例,首先去掉eclipse的检查(非API的调用限制)限制以后,执行发现报 java.lang.SecurityException异常,源码中getUnsafe方法中执行访问检查,看来java不允许应用程序获取Unsafe类. 值得一提的是反射是可以得到这个类对象的.
2,加锁方式:利用Java提供的现有API来实现最后数据同步的原子性(用悲观锁).看似乐观锁最后还是用了悲观锁来保证安全,效率没有提高.实际上针对于大多数只执行不同步数据的情况,效率比悲观加锁整个方法要高.特别注意:针对一个对象的数据同步,悲观锁对这个对象加锁和乐观锁效率差不多,如果是多个需要同步数据的对象,乐观锁就比较方便.
扩展:利用反射获得Unsafe对象
第一步:去掉eclipse受限制的API检查:
将Windows->Preferences->Java-Complicer->Errors/Warnings->Deprecated and restricted API,中的Forbidden references(access rules)设置为Warning,Unsafe可以编译通过。
第二步:利用反射跳过安全检查获取Unsafe对象:
Class<Unsafe> s1 = (Class<Unsafe>) Class.forName("sun.misc.Unsafe");
Field u1 = s1.getDeclaredField("theUnsafe");//获得Unsafe的theUnsafe属性
u1.setAccessible(true);//获得private属性的可访问权限
Unsafe unsafe1 = (Unsafe) u1.get(null);//获得Class中属性对应的值
System.out.println(unsafe1.addressSize());//测试获取的Unsafe对象
//或者
Field u = Unsafe.class.getDeclaredField("theUnsafe");
u.setAccessible(true);
Unsafe unsafe = (Unsafe) u.get(null);
System.out.println(unsafe.addressSize());//测试获取的Unsafe对象
关于Unsafe的使用方法给个参考地址
地址:http://ifeve.com/sun-misc-unsafe/
上一篇: Java乐观锁和悲观锁的区别