高并发——并发锁

1、不同的加锁方式

类锁

      在代码中的方法上加了static和synchronized的锁，或者synchronized(xxx.class）的代码段

对象锁

      在代码中的方法上加了synchronized的锁，或者synchronized(this）的代码段

私有锁

      在类内部声明一个私有属性如private Object lock，在需要加锁的代码段synchronized(lock）

注： 类锁和对象锁不会产生竞争，二者的加锁方法不会相互影响。
私有锁和对象锁也不会产生竞争，二者的加锁方法不会相互影响。

2、加锁的时间

悲观锁

      一段执行逻辑加上悲观锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放.

乐观锁

      一段执行逻辑加上乐观锁,不同线程同时执行时,可以同时进入执行,在最后更新数据的时候要检查这些数据是否被其他线程修改了(版本和执行初是否相同),没有修改则进行更新,否则放弃本次操作.

读写锁

      读写锁即是针对于读写操作的互斥锁。多个读者可以同时进行读，写者必须互斥，写者优先于读者

3、是否顺序

公平锁

      指的是哪个线程先运行，那就可以先得到锁。

非公平锁

      是不管线程是否是先运行，都是随机获得锁的。

4、 线程间

互斥锁

      只要被锁住，其他任何线程都不可以访问被保护的资源

阻塞锁

      可以说是让线程进入阻塞状态进行等待，当获得相应的信号（唤醒，时间） 时，才可以进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争，进入运行状态。

可重入锁

      也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。

自旋锁

      可以使线程在没有取得锁的时候，不被挂起，而转去执行一个空循环，（即所谓的自旋，就是自己执行空循环），若在若干个空循环后，线程如果可以获得锁，则继续执行。若线程依然不能获得锁，才会被挂起。

信号量锁

      从概念上说，信号量(semaphore)是原子化(automically)递增和递减的非负整数。如果一个线程试图递减一个信号量，但这个信号量的值已经为0，则线程将会阻塞。另一个线程“发出(post)”这个信号(semaphore)，使用信号量大于0之后，被阻塞的线程才会被释放。

5、锁变化

锁的状态总共有四种

      无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，

锁膨胀

      从轻量锁膨胀到重量级锁是在轻量级锁解锁过程发生的。

重量级锁

      Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。

轻量级锁

      “轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是，首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前，先明白一点，轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。

偏向锁　

      引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

无锁状态

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

锁削除

      是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。锁削除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行

锁粗化

      原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快地拿到锁。
　　大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。
　　如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（膨胀）到整个操作序列的外部，这样只需要加锁一次就可以了。