volatile 

     Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。在理解volatile作用时候，我们先看看jvm的内存模型。

Java内存模型规定，对于多个线程共享的变量，存储在主内存当中，每个线程都有自己独立的工作内存，线程只能访问自己的工作内存，不可以访问其它线程的工作内存。工作内存中保存了主内存共享变量的副本，线程要操作这些共享变量，只能通过操作工作内存中的副本来实现，操作完毕之后再同步回到主内存当中。

一个变量被定义为volatile,那说明这个变量是易变的。如果一个线程修改了这个变量，那这个线程将通知其他线程这个变量已做修改，工作内存保持的变量副本时效，必须重新从共享内存读取这个变量的最新值，因此，被volatile非常适合做状态标识。

public class Volatile {private volatile static boolean flag = true;public static void work() {while (flag) {System.out.println("=============");}}public static void stop() {flag = false;System.out.println("----stop work----");}public static void main(String[] args) {new Thread(new Runnable() {public void run() {work();}}).start();new Thread(new Runnable() {public void run() {try {Thread.sleep(100l);} catch (InterruptedException e) {}stop();}}).start();}
}

可以看见线程马上结束了自己的工作，但是我们如果不用volatile修饰flag，还是发现线程也马上停止了在控制台的打印。HotSpot编译器在server模式和client模式编译不同， 在client模式下，多线程读取变量时，都会直接从主内存中去读取，不会保存在工作内存中，所有加不加volatile效果一样，而server模式下，则对代码做了优化。而eclipse中默认的启动模式client。

ReetrantLock

     (画了一张不知道是什么图的图），图上我们可以看出，ReetrantLock有有属性Sync sync,FairSync和NonFairSync是Sync的两个子类，Sync继承自AQS(AbstractQueuedSynchronizer)。

    很明显，ReetrantLock实现了公平锁和非公平锁。通过源码我们可以看出ReetrantLock默认为非公平锁，并且提供了一个boolean参数的构造函数，true为公平锁，false为非公平锁。

 public ReentrantLock(){sync = new NonfairSync();}public ReentrantLock(boolean flag){sync = ((Sync) (flag ? ((Sync) (new FairSync())) : ((Sync) (new NonfairSync()))));}

现在我们来看看你ReetrantLock.lock(）到底干了什么？

 //FairSync:final void lock(){acquire(1);}//NonFairSync:final void lock(){if(compareAndSetState(0, 1))setExclusiveOwnerThread(Thread.currentThread());elseacquire(1);}//acquire(int i):public final void acquire(int i){if(!tryAcquire(i) && acquireQueued(addWaiter(Node.EXCLUSIVE), i))selfInterrupt();}

非公平锁一开始尝试检查state的值，如果是0就通过CAS看是否能成功置成1，操作如果成功，那么该线程获得锁，而公平锁并没有，这也就是公平和非公平的区别。如果非公平锁对state的CAS没有成功，则和公平锁一样acquire()。

 //FairSync:protected final boolean tryAcquire(int i){Thread thread = Thread.currentThread();int j = getState();if(j == 0){if(!hasQueuedPredecessors() && compareAndSetState(0, i)){setExclusiveOwnerThread(thread);return true;}} elseif(thread == getExclusiveOwnerThread()){int k = j + i;if(k < 0){throw new Error("Maximum lock count exceeded");} else{setState(k);return true;}}return false;}//NonFairSync:final boolean nonfairTryAcquire(int i){Thread thread = Thread.currentThread();int j = getState();if(j == 0){if(compareAndSetState(0, i)){setExclusiveOwnerThread(thread);return true;}} elseif(thread == getExclusiveOwnerThread()){int k = j + i;if(k < 0){throw new Error("Maximum lock count exceeded");} else{setState(k);return true;}}return false;}

同样在tryAcquire中，公平锁在state=0的情况下看了看sync队列中有没有人排在前面（确实是挺公平的），而非公平锁完全是不管这条件的，我们再来看看acquireQueued(addWaiter(Node.EXCLUSIVE), i)，addWaiter是把线程包装成Node，这里就不贴出来了。

final boolean acquireQueued(final Node node, int arg) {boolean failed = true;try {boolean interrupted = false;for (;;) {final Node p = node.predecessor();//如果当前的节点是head说明他是队列中第一个“有效的”节点，因此尝试获取if (p == head &&tryAcquire(arg)) {setHead(node);p.next = null;failed = false;return interrupted;}//否则，检查前一个节点的状态为，看当前获取锁失败的线程是否需要挂起。//如果需要，借助JUC包下的LockSopport类的静态方法Park挂起当前线程。if (shouldParkAfterFailedAcquire(p, node)&&parkAndCheckInterrupt()) interrupted = true;}} finally {//如果有异常if (failed)// 取消请求，对应到队列操作，就是将当前节点从队列中移除。 cancelAcquire(node);}
}

到此为止，一个线程对于锁的一次竞争才告一段落，结果又两种，要么成功获取到锁（不用进入到AQS队列中），要么获取失败被挂起，等待下次唤醒后继续循环尝试获取锁，值得注意的是，AQS的队列为FIFO队列，所以，每次及时被CPU假唤醒，且当前线程不是出在头节点的位置，也是会被挂起的。（为了防止篇幅过长，AQS中的condition和node将在下篇讲）。

那么问题来了，sychronized和ReentranLock各自要在什么场合用呢？下面贴一下各大博客的总结吧

synchronized是托管给JVM执行的，而lock是java写的控制锁的代码。在Java1.5中，synchronize是性能低效的。因为这是一个重量级操作，需要调用操作接口，导致有可能加锁消耗的系统时间比加锁以外的操作还多。相比之下使用Java提供的Lock对象，性能更高一些。但是到了Java1.6，发生了变化。synchronize在语义上很清晰，可以进行很多优化，有适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在Java1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地。

synchronized原语和ReentrantLock在一般情况下没有什么区别，但是在非常复杂的同步应用中，请考虑使用ReentrantLock，特别是遇到下面2种需求的时候。
     1.某个线程在等待一个锁的控制权时需要中断
     2.多个条件变量或者锁投票
     3.时间锁等候或者无块机构锁