自旋锁、阻塞锁、可重入锁、悲观锁、乐观锁、读写锁、偏向所、轻量级锁、重量级锁、锁膨胀、对象锁和类锁

原文链接：http://blog.csdn.net/a314773862/article/details/54095819

1、自旋锁
自旋锁可以使线程在没有取得锁的时候，不被挂起，而转去执行一个空循环，（即所谓的自旋，就是自己执行空循环），若在若干个空循环后，线程如果可以获得锁，则继续执行。若线程依然不能获得锁，才会被挂起。
使用自旋锁后，线程被挂起的几率相对减少，线程执行的连贯性相对加强。因此，对于那些锁竞争不是很激烈，锁占用时间很短的并发线程，具有一定的积极意义，但对于锁竞争激烈，单线程锁占用很长时间的并发程序，自旋锁在自旋等待后，往往毅然无法获得对应的锁，不仅仅白白浪费了CPU时间，最终还是免不了被挂起的操作 ，反而浪费了系统的资源。
在JDK1.6中，Java虚拟机提供-XX:+UseSpinning参数来开启自旋锁，使用-XX:PreBlockSpin参数来设置自旋锁等待的次数。
在JDK1.7开始，自旋锁的参数被取消，虚拟机不再支持由用户配置自旋锁，自旋锁总是会执行，自旋锁次数也由虚拟机自动调整。

可能引起的问题：
1.过多占据CPU时间：如果锁的当前持有者长时间不释放该锁，那么等待者将长时间的占据cpu时间片，导致CPU资源的浪费，因此可以设定一个时间，当锁持有者超过这个时间不释放锁时，等待者会放弃CPU时间片阻塞；
2.死锁问题：试想一下，有一个线程连续两次试图获得自旋锁（比如在递归程序中），第一次这个线程获得了该锁，当第二次试图加锁的时候，检测到锁已被占用（其实是被自己占用），那么这时，线程会一直等待自己释放该锁，而不能继续执行，这样就引起了死锁。因此递归程序使用自旋锁应该遵循以下原则：递归程序决不能在持有自旋锁时调用它自己，也决不能在递归调用时试图获得相同的自旋锁。

2、阻塞锁
让线程进入阻塞状态进行等待，当获得相应的信号（唤醒，时间） 时，才可以进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争，进入运行状态。。
JAVA中，能够进入\退出、阻塞状态或包含阻塞锁的方法有 ，synchronized 关键字（其中的重量锁），ReentrantLock，Object.wait()\notify()

3、可重入锁
可重入锁，也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。
在JAVA环境下 ReentrantLock 和synchronized 都是 可重入锁
下面是使用实例

[java] view plain copy

1. public class Test implements Runnable{  
2.   
3.     public synchronized void get(){  
4.         System.out.println(Thread.currentThread().getId());  
5.         set();  
6.     }  
7.   
8.     public synchronized void set(){  
9.         System.out.println(Thread.currentThread().getId());  
10.     }  
11.   
12.     @Override  
13.     public void run() {  
14.         get();  
15.     }  
16.     public static void main(String[] args) {  
17.         Test ss=new Test();  
18.         new Thread(ss).start();  
19.         new Thread(ss).start();  
20.         new Thread(ss).start();  
21.     }  
22. }  
23.   
24. public class Test implements Runnable {  
25.     ReentrantLock lock = new ReentrantLock();  
26.   
27.     public void get() {  
28.         lock.lock();  
29.         System.out.println(Thread.currentThread().getId());  
30.         set();  
31.         lock.unlock();  
32.     }  
33.   
34.     public void set() {  
35.         lock.lock();  
36.         System.out.println(Thread.currentThread().getId());  
37.         lock.unlock();  
38.     }  
39.   
40.     @Override  
41.     public void run() {  
42.         get();  
43.     }  
44.   
45.     public static void main(String[] args) {  
46.         Test ss = new Test();  
47.         new Thread(ss).start();  
48.         new Thread(ss).start();  
49.         new Thread(ss).start();  
50.     }  
51. }  

两个例子最后的结果都是正确的，即 同一个线程id被连续输出两次。
结果如下：
Threadid: 8
Threadid: 8
Threadid: 10
Threadid: 10
Threadid: 9
Threadid: 9
可重入锁最大的作用是避免死锁
我们以自旋锁作为例子，

[java] view plain copy

1. public class SpinLock {  
2.     private AtomicReference<Thread> owner =new AtomicReference<>();  
3.     public void lock(){  
4.         Thread current = Thread.currentThread();  
5.         while(!owner.compareAndSet(null, current)){  
6.         }  
7.     }  
8.     public void unlock (){  
9.         Thread current = Thread.currentThread();  
10.         owner.compareAndSet(current, null);  
11.     }  
12. }  

对于自旋锁来说，
1、若有同一线程两调用lock() ，会导致第二次调用lock位置进行自旋，产生了死锁
说明这个锁并不是可重入的。（在lock函数内，应验证线程是否为已经获得锁的线程）
2、若1问题已经解决，当unlock（）第一次调用时，就已经将锁释放了。实际上不应释放锁。
（采用计数次进行统计）
修改之后，如下：

[java] view plain copy

1. public class SpinLock1 {  
2.     private AtomicReference<Thread> owner =new AtomicReference<>();  
3.     private int count =0;  
4.     public void lock(){  
5.         Thread current = Thread.currentThread();  
6.         if(current==owner.get()) {  
7.             count++;  
8.             return ;  
9.         }  
10.         while(!owner.compareAndSet(null, current)){  
11.         }  
12.     }  
13.     public void unlock (){  
14.         Thread current = Thread.currentThread();  
15.         if(current==owner.get()){  
16.             if(count!=0){  
17.                 count--;  
18.             }else{  
19.                 owner.compareAndSet(current, null);  
20.             }  
21.         }  
22.     }  
23. }  

该自旋锁即为可重入锁。

4 悲观锁和乐观锁
悲观锁(Pessimistic Lock), 顾名思义就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。独占锁是悲观锁的一种实现

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。使用CAS来保证,保证这个操作的原子性

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

参考：http://www.cnblogs.com/softidea/p/5309312.html
http://blog.csdn.net/hongchangfirst/article/details/26004335

5 轮询锁和定时锁
由tryLock实现，与无条件获取锁模式相比，它们具有更完善的错误恢复机制。可避免死锁的发生：
boolean tryLock()：仅在调用时锁为空闲状态才获取该锁。如果锁可用，则获取锁，并立即返回值 true。如果锁不可用，则此方法将立即返回值 false。
 
boolean tryLock(long time, TimeUnit unit) throws InterruptedException：
　　如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁。
 
　　如果锁可用，则此方法将立即返回值 true。如果锁不可用，出于线程调度目的，将禁用当前线程，并且在发生以下三种情况之一前，该线程将一直处于休眠状态：
 
　　锁由当前线程获得；或者
　　其他某个线程中断当前线程，并且支持对锁获取的中断；或者
　　已超过指定的等待时间
　　如果获得了锁，则返回值 true。
 
　　如果当前线程：
 
　　在进入此方法时已经设置了该线程的中断状态；或者
　　在获取锁时被中断，并且支持对锁获取的中断，
　　则将抛出 InterruptedException，并会清除当前线程的已中断状态。
　　如果超过了指定的等待时间，则将返回值 false。如果 time 小于等于 0，该方法将完全不等待。

6 显示锁和内置锁
显示锁用Lock来定义、内置锁用syschronized。
内置锁：每个java对象都可以用做一个实现同步的锁，这些锁成为内置锁。线程进入同步代码块或方法的时候会自动获得该锁，在退出同步代码块或方法时会释放该锁。获得内置锁的唯一途径就是进入这个锁的保护的同步代码块或方法。
内置锁是互斥锁。

7 读-写锁
Lock接口以及对象，使用它，很优雅的控制了竞争资源的安全访问，但是这种锁不区分读写，称这种锁为普通锁。为了提高性能，Java提供了读写锁，在读的地方使用读锁，在写的地方使用写锁，灵活控制，如果没有写锁的情况下，读是无阻塞的,在一定程度上提高了程序的执行效率。
Java中读写锁有个接口java.util.concurrent.locks.ReadWriteLock，也有具体的实现ReentrantReadWriteLock，详细的API可以查看JavaAPI文档。
ReentrantReadWriteLock 和 ReentrantLock 不是继承关系，但都是基于 AbstractQueuedSynchronizer 来实现。
lock方法 是基于CAS 来实现的
ReadWriteLock中暴露了两个Lock对象：

在读写锁的加锁策略中，允许多个读操作同时进行，但每次只允许一个写操作。读写锁是一种性能优化的策略。

RentrantReadWriteLock在构造时也可以选择是一个非公平的锁（默认）还是公平的锁。

8 对象锁和类锁
java的对象锁和类锁在锁的概念上基本上和内置锁是一致的，但是，两个锁实际是有很大的区别的，对象锁是用于对象实例方法，或者一个对象实例上的，类锁是用于类的静态方法或者一个类的class对象上的。
类的对象实例可以有很多个，但是每个类只有一个class对象，所以不同对象实例的对象锁是互不干扰的，但是每个类只有一个类锁。但是有一点必须注意的是，其实类锁只是一个概念上的东西，并不是真实存在的，它只是用来帮助我们理解锁定实例方法和静态方法的区别的.
synchronized只是一个内置锁的加锁机制，当某个方法加上synchronized关键字后，就表明要获得该内置锁才能执行，并不能阻止其他线程访问不需要获得该内置锁的方法。

调用对象wait()方法时，会释放持有的对象锁，以便于调用notify方法使用。notify()调用之后，会等到notify所在的线程执行完之后再释放锁


9：锁粗化（Lock Coarsening）：
锁粗化的概念应该比较好理解，就是将多次连接在一起的加锁、解锁操作合并为一次，将多个连续的锁扩展成一个范围更大的锁。举个例子：

[java] view plain copy

1. 1 package com.paddx.test.string;  
2.  2   
3.  3 public class StringBufferTest {  
4.  4     StringBuffer stringBuffer = new StringBuffer();  
5.  5   
6.  6     public void append(){  
7.  7         stringBuffer.append("a");  
8.  8         stringBuffer.append("b");  
9.  9         stringBuffer.append("c");  
10. 10     }  
11. 11 }  

　　这里每次调用stringBuffer.append方法都需要加锁和解锁，如果虚拟机检测到有一系列连串的对同一个对象加锁和解锁操作，就会将其合并成一次范围更大的加锁和解锁操作，即在第一次append方法时进行加锁，最后一次append方法结束后进行解锁。

10 互斥锁
互斥锁, 指的是一次最多只能有一个线程持有的锁。如Java的Lock


15 无锁状态-》偏向锁-》轻量级锁-》重量级锁。锁膨胀
　锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，
锁膨胀：从轻量锁膨胀到重量级锁是在轻量级锁解锁过程发生的。
重量级锁：Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。
轻量级锁：“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是，首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前，先明白一点，轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。
偏向锁：　引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

无锁状态：在代码进入同步块的时候，如果同步对象锁状态为无锁状态。

重量级锁、轻量级锁和偏向锁之间转换：

11 锁消除（Lock Elimination）：锁消除即删除不必要的加锁操作。根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么可以认为这段代码是线程安全的，不必要加锁。看下面这段程序：

[java] view plain copy

1. package com.paddx.test.concurrent;  
2.   
3.  public class SynchronizedTest02 {  
4.    
5.     public static void main(String[] args) {  
6.         SynchronizedTest02 test02 = new SynchronizedTest02();  
7.          //启动预热  
8.          for (int i = 0; i < 10000; i++) {  
9.             i++;  
10.         }  
11.        long start = System.currentTimeMillis();  
12.         for (int i = 0; i < 100000000; i++) {  
13.             test02.append("abc", "def");  
14.         }  
15.         System.out.println("Time=" + (System.currentTimeMillis() - start));  
16.     }  
17.   
18.     public void append(String str1, String str2) {  
19.         StringBuffer sb = new StringBuffer();  
20.         sb.append(str1).append(str2);  
21.     }  
22. }  

虽然StringBuffer的append是一个同步方法，但是这段程序中的StringBuffer属于一个局部变量，并且不会从该方法中逃逸出去，所以其实这过程是线程安全的，可以将锁消除。下面是我本地执行的结果

12、信号量
线程同步工具：Semaphore