http://blog.csdn.net/takemetofly/article/details/48086069
因为堆和方法区是被所有线程共享的，因此java程序需要为多线程访问的这两类数据进行协调。保存在堆中的实例变量和保存在方法区中的类变量。虚拟机为每一个对象和类都关联一个锁，类锁实际上是对象锁实现，锁住一个类的时候实际上锁的是那个类的Class实例对象。
一个代码块被synchronized修饰了，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待，等待获取锁的线程释放锁，而这里获取锁的线程释放锁只会有两种情况：
1）获取锁的线程执行完了该代码块，然后线程释放对锁的占有；
2）线程执行发生异常，此时JVM会让线程自动释放锁。
那么如果这个获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。
因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。
再举个例子：当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。
但是采用synchronized关键字来实现同步的话，就会导致一个问题：
如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程只能等待无法进行读操作。
因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。
另外，通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。
volatile实现的算法原理：缓存一致性协议——每个CPU有自己的缓存，当一个变量是共享变量（其他CPU也有此变量的副本），某个CPU正在更新，则通知其他CPU将该该变量的缓存行置为无效状态，当其他CPU需要使用时由于发现其缓存的变量是无效的，便会重新从内存中读取。
关键字volatile是虚拟机提供的最轻量级的同步机制。但volatile只能保证从主内存加载到操作数栈顶的变量的值是正确的(volatile修饰的变量具有可见性体现在值被改变后可以立即同步回主内存以便被其他未加载此变量的线程正确加载，但不能保证加载到操作数栈后的变量不被其它线程改变。)volatile的另一个作用是禁止指令重排序优化。
除了volatile具备可见性，final和synchronized关键字修饰的变量也具备可见性。final变量一旦完成初始化，其他线程则可看见其值，synchronized的可见性则体现在对一个变量执行unlock前必须保证该变量同步回主内存。
教材上说大致认为基本类型数据的访问是线程安全的，其实不严谨，因为对一个数据的读或写都不是由一个原子性操作完成的，读由load和read完成，写有store和write来完成。但对基本数据类型的常量的读写可以认为是线程安全的。
Lock接口有两个非常强大的实现类重入锁和读写锁，下面一一讲解这些内容。
Lock接口的使用
Lock lock = new ReentrantLock();
lock.lock();
try{
//可能会出现线程安全的操作
}finally{
//一定在finally中释放锁
//也不能把获取锁在try中进行，因为有可能在获取锁的时候抛出异常
lock.ublock();
}Lock接口与synchronized关键字的区别
- Lock接口可以尝试非阻塞地获取锁 当前线程尝试获取锁。如果这一时刻锁没有被其他线程获取到，则成功获取并持有锁。
*Lock接口能被中断地获取锁 与synchronized不同，获取到锁的线程能够响应中断，当获取到的锁的线程被中断时，中断异常将会被抛出，同时锁会被释放。- Lock接口在指定的截止时间之前获取锁，如果截止时间到了依旧无法获取锁，则返回。
Lock接口的API
ReentrantLock是Lock接口一种常见的实现，它是支持重进入的锁即表示该锁能够支持一个线程对资源的重复加锁。该锁还支持获取锁时的公平与非公平的选择。
- void lock() 获取锁,调用该方法当前线程将会获取锁，当锁获取后，该方法将返回。获取不到会一直获取，因此此方法是阻塞的。
- boolean tryLock() 尝试非阻塞的获取锁，调用该方法立即返回，true表示获取到锁
- boolean tryLock(long time,TimeUnit unit) throws InterruptedException 和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false
- void lockInterruptibly() throws InterruptedException 可中断获取锁，与lock()方法不同之处在于该方法会响应中断，即在锁的获取过程中可以中断当前线程
- 当一个线程获取了锁之后，是不会被interrupt()方法中断的。interrupt()方法不能中断正在运行过程中的线程，线程处于阻塞状态才可被中断(如线程调用了sleep，join，wait方法等)，但线程获取锁的过程中不可被中断(除了上面新学的方法lockInterruptibly)。线程中断只能。
Thread.interrupt()方法不会中断一个正在运行的线程。它的作用是，在线程受到阻塞时抛出一个中断信号，这样线程就得以退出阻塞的状态。更确切的说，如果线程被Object.wait, Thread.join和Thread.sleep三种方法之一阻塞，那么，它将接收到一个中断异常（InterruptedException），从而提早地终结被阻塞状态。
interrupt方法并不是强制终止线程，它只能设置线程的interrupted状态，被block的线程(sleep() or join())在被调用interrupt时会产生InterruptException(lock是不会的，直到获取到锁才会去处理中断标志)，此时是否终止线程由本线程自己决定
- 说白了线程的中断方法起作用的基本条件是阻塞，但也不一定立即起作用，比如lock()方法直到获取到了锁才会处理中断标志。
- void unlock() 释放锁
关于锁的重进入，其实synchronized关键字也支持。如前所述，synchronized关键字也是隐式的支持重进入而对于ReentrantLock而言，对于已经获取到锁的线程，再次调用lock()方法时依然可以获取锁而不被阻塞。
synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。
看下面这段代码就明白了：
|
1
2
3
4
5
6
7
8
9
|
class MyClass { public synchronized void method1() { method2(); } public synchronized void method2() { }} |
上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。
而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。
刚刚提到的公平获取锁与非公平获取锁。如果在绝对时间上，先对于锁进行获取的请求一定先被满足，那么这个锁就是公平的，反之就是非公平的。公平的获取锁也就是等待时间最久的线程优先获取到锁。ReentrantLock的构造函数来控制是否为公平锁。
我在第一次了解到公平获取锁与非公平获取锁的时候，第一反应是公平获取锁的效率高，应该使用公平获取锁。但实际的情况是，非公平获取锁的效率远远大于公平获取锁。
ReentrantLock是排他锁，该锁在同一时刻只允许一个线程来访问，而读写锁在同一时刻允许可以有多个线程来访问，但在写线程访问时，所有的读线程和其他写线程被阻塞。实现读写锁的接口后调用其获取读锁方法或调用其获取写锁方法可以获取一个读锁或者一个写锁，通过读写锁分离，使得并发性相比一般的排他锁有了很大的提升。
如果有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁。
如果有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，则申请的线程会一直等待释放写锁。
读写锁除了使用在写操作happends-before与读操作以及并发性的提升之外，读写锁也能够简化读写交互场景的编程方式。假设在程序中定义一个共享的用作缓存数据结构，它的大部分时间提供读服务(查询，搜索等)而写操作较少，但写操作之后需要立即对后续的读操作可见。在没有读写锁之前，实现这个功能需要使用等待通知机制(http://blog.csdn.net/canot/article/details/50879963)。无论使用那种方式，目的都是为了写操作立即可见于读操作而避免脏读。但使用读写锁却比等待通知简单明了多了。
一般情况下，读写锁性能优于排他锁。它能提供更好的并发性和吞吐量。
ReentrantReadWriteLock读写锁的几个特性:
- 公平选择性
- 重进入
- 锁降级
读写锁的示例:缓存
public class Cache{
static Map<String,Object> map = new HashMap<String,Object>();
static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
static Lock rLock = rwl.readLock();
static Lock wLock = rwl.writeLock();
//获取一个key对应的value
public static final Object get(String key){
r.lock();
try{
return map.get(key);
}finally{
r.unlock();
}
}
//设置key对应的value并返回旧的value
public static fianl Object put(String key,Object value){
w.lock();
try{
return map.put(key,value);
}final{
w.unlock();
}
}
//清空缓存
public static fianl void clear(){
w.lock();
try{
map.clear();
} finally{
w.unlock();
}
}
}上述缓存示例中，我们使用了一个非线程安全的HashMap作为缓存的时候然后使用读写锁来保证线程安全。Cache使用读写锁提升读操作的并发性，也保证每次写操作对读操作的及时可见性，同时简化了编程方式。
读写锁的锁降级
锁降级是指写锁降级成为读锁。如果当前线程持有写锁，然后将其释放再获取读锁的过程不能称为锁降级。锁降级指的在持有写锁的时候再获取读锁,获取到读锁后释放之前写锁的过程称为锁释放。
锁降级在某些情况下是非常必要的，主要是为了保证数据的可见性。如果当前线程不获取读锁而直接释放写锁，假设此时另外一个线程获取了写锁并修改了数据。那么当前线程无法感知该线程的数据更新。
本来线程是占用cpu资源的，但是如果挂起的话，操作系统就不给这个现成分配cpu资源，除非以后再恢复，所以线程挂起的作用就是节省cpu资源.举个例子，系统中有10个线程要运行，如果要求在1秒内所有的线程都运行一遍，则每个线程可运行时间为10分之一秒，也就是如果一个线程已经运行了10分之一秒，系统会停止该线程（或称为挂起该线程），运行下一个线程，当又轮到挂起的线程运行时，系统会从该线程停止的地方运行，这种线程挂起是由系统进行的，即所谓的线程调度。有时候，我们的线程暂时没有数据处理，我们也可以通过一些API来使自己的线程挂起，当系统检测到线程被用户挂起时，就算轮到该线程系统也不会运行该线程，而是直接去运行下一个线程，这种情况下，除非用户使该线程退出挂起状态，否则系统不会运行该线程。从这个意义上来讲，一个线程挂起将会给其他线程赢得更多的运行时间（或机会），也就节约了CPU的时间资源。http://www.cnblogs.com/meet/p/5290909.html
首先这些术语都是对于线程来说的。对线程的控制就好比你控制了一个雇工为你干活。你对雇工的控制是通过编程来实现的。
private AtomicReference<Thread> sign =new AtomicReference<>();
public void lock(){
Thread current = Thread.currentThread(); 获取当前正在运行的线程
while(!sign.compareAndSet(null, current)){
}
}
public void unlock (){
Thread current = Thread.currentThread();
sign.compareAndSet(current, null);
}
}