悲观锁:一上来就加锁,没有安全感,每次只能一个线程进入访问完毕后再解锁。是线程安全的,但是性能较差!
乐观锁:一开始不上锁,认为是没有问题的,大家一起跑,等要出线程安全问题的时候才开始控制。是线程安全的,且性能较好。
下面举例说明,先写一个没有锁的多线程场景:
public static void main(String[] args) throws Exception {
//需求:1个静态变量,100个线程,每个线程对其加100次 最终值为10000
Runnable target = new MyRunnable();
for (int i = 1; i <= 100; i++) {
new Thread(target).start();
}
}
public class MyRunnable implements Runnable{
private int count;//用实例变量代替静态变量 反正线程都是公用一个任务对象的 所以是可以的
@Override
public void run() {
//100次
for (int i = 0; i < 100; i++) {
System.out.println("count--------->"+(++count));
}
}
}
某次运行结果:
...
count--------->9989
count--------->9990
count--------->9991
count--------->9992
count--------->9993
count--------->9994
count--------->9995
count--------->9996
count--------->9997
count--------->9998
count--------->9999
//虽然概率比较小 还是出现了一次线程安全问题
//有一次增值计算重叠了 没有加到10000
下面是悲观锁的版本:
public class MyRunnable implements Runnable{
private int count;//用实例变量代替静态变量 反正线程都是公用一个任务对象的 所以是可以的
@Override
public void run() {
//100次
for (int i = 0; i < 100; i++) {
//这里锁的是单次计算的代码
//你总不能锁住整个方法 只让某个线程计算100次才让别的线程进来 效率太低
synchronized (this){
System.out.println("count--------->"+(++count));
}
}
}
}
某次运行结果:
...
count--------->9989
count--------->9990
count--------->9991
count--------->9992
count--------->9993
count--------->9994
count--------->9995
count--------->9996
count--------->9997
count--------->9998
count--------->9999
count--------->10000
下面是乐观锁的版本:
首先解释原理,安全问题来自于,比如当count是10时,俩个线程几乎同时进入,将其值修改成11,于是便发生了安全问题,少加了一次。乐观锁采用CAS算法(可以自己进入count.incrementAndGet()源码看看),在加之前就记录了count的原来的值,比如当线程进入时记录count是10,然后将其加到11准备写入时,发现count已经变成11了,于是会将这次修改写入作废,重复上述过程,重新加一次。
public class MyRunnable implements Runnable{
//整数修改的乐观锁:用java的原子类实现的
private AtomicInteger count = new AtomicInteger();
@Override
public void run() {
//100次
for (int i = 0; i < 100; i++) {
System.out.println("count--------->"+(count.incrementAndGet()));
}
}
}
执行结果可以发现没有线程安全问题。