乐观锁与悲观锁

        乐观锁和悲观锁是多线程并发编程中的两种思想。其中乐观锁是指假定不会发生并发冲突，只在提交操作时检查是否违反数据完整性。就是说使用了乐观锁，只会在提交的时候判断是否出现冲突，如果出现了冲突由开发者进行判断如何继续操作。而悲观锁则是假定会发生并发冲突，是一种保守的思想，屏蔽一切可能违反数据完整性的操作。以下通过乐观锁和悲观锁的具体实现方式来更深入了解这两种思想。

1.悲观锁

         悲观锁的最典型的实现方式就是互斥锁synchronized的使用，synchronized是一个典型的独占锁，使用的就是悲观锁的思想，但是这存在很大的缺点，比如一个线程需要某个资源，但是这个资源的占用时间很短，当线程第一次抢占这个资源时，可能这个资源被占用，如果挂起这个线程，可能立即发现资源可用，然后又需要花费很长时间重新抢占锁。因此在整个过程中时间代价很高。因此悲观锁是以更多时间的代价来保证数据的完整性。以下是使用sychronized的用例：

package concurrent;
import java.util.concurrent.*;
class Count1{
	public int number;
}
public class SynchronizedTest {
	private static Count1 count=new Count1();
	private static final ExecutorService es=Executors.newFixedThreadPool(10);
	
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		
		long start=System.currentTimeMillis();
		for(int i=0;i<1000;i++)
		{
			Thread t1=new Thread() {
				public void run() {
					synchronized(count)
					{
						System.out.println(Thread.currentThread().getName()+"自增加1，当前值为:"+(++count.number));
					}
				}
			};
			es.execute(t1);
		}
		try {
			Thread.sleep(1000);
		}
		catch(InterruptedException e)
		{
			e.printStackTrace();
		}
		System.out.println("总共耗时："+(System.currentTimeMillis()-start-1000)+"ms");

	}

}

部分运行结果如下：

pool-1-thread-5自增加1，当前值为:985
pool-1-thread-5自增加1，当前值为:986
pool-1-thread-5自增加1，当前值为:987
pool-1-thread-5自增加1，当前值为:988
pool-1-thread-5自增加1，当前值为:989
pool-1-thread-5自增加1，当前值为:990
pool-1-thread-5自增加1，当前值为:991
pool-1-thread-2自增加1，当前值为:992
pool-1-thread-8自增加1，当前值为:993
pool-1-thread-7自增加1，当前值为:994
pool-1-thread-6自增加1，当前值为:995
pool-1-thread-3自增加1，当前值为:996
pool-1-thread-1自增加1，当前值为:997
pool-1-thread-4自增加1，当前值为:998
pool-1-thread-9自增加1，当前值为:999
pool-1-thread-10自增加1，当前值为:1000
总共耗时：17ms

        以上是悲观锁的具体实现方式独占锁synchronized的实例，自增1000的时间是17ms。

2.乐观锁

        乐观锁的核心算法是CAS（CompareandSwap，比较并交换），它涉及到三个操作数：内存值、预期值、新值，当且仅当预期值和内存值相等时才将内存值修改为新值。这样处理的逻辑是，首先检查某块内存的值是否跟之前我读取时的一样，如不一样则表示期间此内存值已经被别的线程更改过，舍弃本次操作，否则说明期间没有其他线程对此内存值操作，可以把新值设置给此块内存。乐观锁避免了悲观锁独占对象的现象，同时也提高了并发性能。因此乐观锁的最常见的实现方式就是CAS，其中CAS最典型的例子就是J.U.C包的atomic系列的类。

1.简单CAS实现

对于自增的，可以使用AtomicInteger类来实现自增。

package concurrent;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;

public class AtomicTest {
    private static final AtomicInteger ai=new AtomicInteger(0);
    private static final ExecutorService es=Executors.newFixedThreadPool(10);
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		long start=System.currentTimeMillis();
		for(int i=0;i<1000;i++)
		{
			Thread t1=new Thread() {
				public void run() {
					System.out.println(Thread.currentThread().getName()+"实现自增加1，当前值为："+ai.incrementAndGet());
				}
			};
			es.execute(t1);
		}
		try {
			Thread.sleep(1000);
		}
		catch(InterruptedException e)
		{
			e.printStackTrace();
		}
		System.out.println("总共耗时："+(System.currentTimeMillis()-start-1000)+"ms");
		

	}

}

部分运行结果如下所示：

pool-1-thread-7实现自增加1，当前值为：984
pool-1-thread-4实现自增加1，当前值为：1000
pool-1-thread-5实现自增加1，当前值为：999
pool-1-thread-2实现自增加1，当前值为：998
pool-1-thread-6实现自增加1，当前值为：997
pool-1-thread-3实现自增加1，当前值为：996
pool-1-thread-9实现自增加1，当前值为：995
pool-1-thread-1实现自增加1，当前值为：994
总共耗时：8ms

总的来说使用AtomicInteger类的实现自增可以比独占锁实现自增一定程度上减少时间。

2.ABA问题

        CAS可以解决悲观锁上的不足，但是存在一个典型的问题：ABA问题。ABA问题就是指在CAS操作过程中首先将值A变为A，然后将B变为A，完成这一换值过程之后，便又进行A-B，在判断内存值与预期值时，返回的是true，说明并不知道该值之前已经改变过了，这就是ABA问题。比如以下例子：

package concurrent;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;

public class AtomicTest {
    private static final AtomicInteger ai=new AtomicInteger(0);
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		long start=System.currentTimeMillis();
	
		Thread t1=new Thread() {
			public void run() {
				ai.compareAndSet(0, 1);//0-1
				ai.compareAndSet(1, 0);//1-0
			}
		};
		Thread t2=new Thread() {
			public void run() {
				boolean ans=ai.compareAndSet(0, 1);//再判断是否为0，所以虽然变动了，但是结果并不知道这个数改变过，只知道结果依然相同。
				System.out.println(ans);
			}
		};
		t1.start();
		t2.start();
		try {
		t1.join();
		t2.join();
		}
		catch(InterruptedException e)
		{
			e.printStackTrace();
		}
		

	}

}

        运行得到结果如下：

true

        以上t1线程的工作是将0变1，再将1变为0，使用的是compareAndSet(int expect,int update)；说明t1线程对ai作出了改变，然后t2线程对其进行判断是否还等于原来那个初始值，返回一个boolean值，让两个线程按序进行，即先进行更改操作，再进行判断。得到的结果是该值与初始值致，并未发现该值已经发生了改变。

3.ABA问题的解决方案

        上述就是将值修改之后再修改回初值，就判断不出是否修改过，因此做出了修改，引进了版本号以及时间戳的概念，就是引入一个值判断记录数据更改的次数或者版本数，从而来判断该值是否作出了改变，从而避免了ABA问题。示例如下：

package concurrent;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicStampedReference;

public class AtomicTest {
    private static final AtomicStampedReference<String> asr=new AtomicStampedReference("A",0);
    static String initReference=asr.getReference();
	static int initStamp=asr.getStamp();
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		long start=System.currentTimeMillis();
		
		Thread t1=new Thread() {
			public void run() {
				asr.compareAndSet(asr.getReference(), "B",asr.getStamp(),asr.getStamp()+1);//A-B
				asr.compareAndSet(asr.getReference(), "A",asr.getStamp(),asr.getStamp()+1);//B-A
			}
		};
		Thread t2=new Thread() {
			public void run() {
				boolean ans=asr.compareAndSet(initReference, "B",initStamp,initStamp+1);//再判断是否为初始值，所以虽然与初始值相同，但是时间戳不同，说明该值已经改动过，所以返回false.
				System.out.println(ans);
				System.out.println("初始值与预期值是否相等："+(initReference==asr.getReference())+";时间戳是否相等:"+(initStamp==asr.getStamp()));
			}
		};
		t1.start();
		t2.start();
		try {
		t1.join();
		t2.join();
		}
		catch(InterruptedException e)
		{
			e.printStackTrace();
		}
		

	}

}

运行结果如下：

false
初始值与预期值是否相等：true;时间戳是否相等:false

        由上面运行结果可以看出，虽然与初始值相同，但是时间戳的不同，则表明该值改动过，所以返回false。