Java多线程并发锁和原子操作，你真的了解吗？

 

对于Java多线程，接触最多的莫过于使用synchronized，这个简单易懂，可谓一招吃遍天下，可能在一些特殊场景下确需要用一些其他的同步进行。今天我就简单介绍一下几种锁，其实像类似的博客和文章和很多，所以也不会多赘述，我更想抛出在实际应用中所碰到的问题。好，废话少说。

volatile

作为Java中的轻量级锁，当多线程中一个线程操作后可以保证其他线程可见，也就是书上所说的“可见性”，另外一个就是“重排序”。所谓重排序指的是JVM对指令的优化。很多人可能在实际实验中发现好像不是如此，最后的例子我也会说明这一点。

 

synchronized

这个作为Java中“重量级”的线程安全机制被大家所熟知。有些Java开发可能不知道volatile,也不太会去使用。但是如果不知道synchronized，估计这种情况就比较少了。

 

java.util.concurrent.locks.ReentrantLock

java.util.concurrent.中是JDK1.5中出的对于一些并发操作的类库，其中包括很多同学很喜欢的原子类，比如说AtomicInteger,我在这里也不会对其原理做过多的分析，因为我也还没有去看其源代码，所以也不好讲，也不是今天我想要讲的重点。

好，说一下ReentrantLock，这个锁主要是能显示的添加锁和释放锁，好处是更加灵活，能够更加准确的控制锁，也能确保系统的稳定，比如说“重连”。后面代码会有使用到。

 

项目中如果没有特殊需求除了synchronized其他也比较少用，各位编程爱好者可以在自己的项目中多使用其他锁机制以了解其工作原理和优劣。技术一定会精进不少。

实际场景

 

package com.yuzhipeng.m07.thread;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * 
 * @author Yu zhipeng | 2012-07-26
 *
 */
public class TestMultiThread  implements Runnable{

	private static int i;
	
	private static volatile Integer vi = 0;
	
	private static AtomicInteger ai = new AtomicInteger();
	
	private static Integer si = 0;
	
	private static int ri;
	
	private static AtomicInteger flag = new AtomicInteger();
	
	private Lock lock = new ReentrantLock();
	
	@Override
	public void run() {
		for(int k=0;k<200000;k++){
			i++;
			vi++;
			ai.incrementAndGet();
			synchronized(si){
				si++;
			}
			lock.lock();
			try{
				ri++;
			}finally{
				lock.unlock();
			}
			
		}
		flag.incrementAndGet();
	}
	
	public static void main(String[] args) throws InterruptedException{
		TestMultiThread t1 = new TestMultiThread();
		TestMultiThread t2 = new TestMultiThread();
		ExecutorService exec1 = Executors.newCachedThreadPool();
		ExecutorService exec2 = Executors.newCachedThreadPool();
		exec1.execute(t1);
		exec2.execute(t2);
		while(true){
			if(flag.intValue()==2){
				System.out.println("i>>>>>"+i);
				System.out.println("vi>>>>>"+vi);
				System.out.println("ai>>>>>"+ai);
				System.out.println("si>>>>>"+si);	
				System.out.println("ri>>>>>"+ri);	
				break;
			}
			Thread.sleep(50);
		}

		
	}
	
}

输出结果：

i>>>>>381890
vi>>>>>353610
ai>>>>>400000
si>>>>>392718
ri>>>>>392658

从上面的输出结果来看真是让人大感意外，只有原子操作AtomicInteger的结果保证了多线程的安全性，而其他不管是用轻量级的volatile还是重量级的synchronized都没有达到我们想要的效果。这也让我产生了大在的怀疑。难道问题真的这么蹊跷？

从这里不难看出除了AtomicInteger用的是其自己的方法而其他都是用到了Java的语法糖++操作。而这让我想起了++操作并非原子操作，而可能在其中间操作导致了其他线程对其他进行了修改，虽然同样的问题我在《Think in Java》中也找到可以佐证的例子。可是我在这里始终没有办法想通，因为我对si已经加了synchronized操作。难道还会有问题？这让我想把这段代码编译成字节码的冲动。好吧，下面看字节码（这里我单独把synchronized这一段操作抽出来，作为分析，其他几个就算了，不然编译后的字节码有点多）

为了方便看，先贴出源代码

public class TestSynchronizedThread  implements Runnable{

	private static Integer si = 0;
	
	@Override
	public void run() {
		for(int k=0;k<200000;k++){
			synchronized(si){
				si++;
			}
		}
	}
}

下面是字节码，为了节省篇幅，一些不重要的部分我将不贴出

   0:   iconst_0
   1:   istore_1
   2:   iload_1
   3:   ldc     #2; //int 200000
   5:   if_icmpge       55
   8:   getstatic       #3; //Field si:Ljava/lang/Integer;
   11:  dup
   12:  astore_2
   13:  monitorenter
   14:  getstatic       #3; //Field si:Ljava/lang/Integer;
   17:  astore_3
   18:  getstatic       #3; //Field si:Ljava/lang/Integer;
   21:  invokevirtual   #4; //Method java/lang/Integer.intValue:()I
   24:  iconst_1
   25:  iadd
   26:  invokestatic    #5; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
   29:  dup
   30:  putstatic       #3; //Field si:Ljava/lang/Integer;
   33:  astore  4
   35:  aload_3
   36:  pop
   37:  aload_2
   38:  monitorexit
   39:  goto    49
   42:  astore  5
   44:  aload_2
   45:  monitorexit
   46:  aload   5
   48:  athrow
   49:  iinc    1, 1
   52:  goto    2
   55:  return

从这里一看从monitorenter进入安全区到monitorexit出安全区没有发现si是处于中间状态的，那又是在哪出的问题呢？我已经无法解释了！！还请各位大侠指点。

 

PS：

这个问题肯定出在++操作上，如果我把锁对象换成其他公用对象，那这个问题得到解决。