java多线程(四)

锁

java 多线程的锁我是感觉是一个非常有难度的知识点，多线程的锁有十几种，以前我在面试的时候就有面试官问过我了不了解多线程锁，我当时想锁有什么难的啊，不就常用的那几种嘛，结果我直接就回到深入研究过，然后这次面试结果也就可想而知了！当一个技术让你觉得的它特别难的时候这个时候不要怀疑自己的智商，大多数人智商都处于一个水平线，大多数时候都是出于对未知问题的恐惧！其实我们只要一步一步来慢慢的一点点的来了解它终究会有弄懂的一刻，所以不要放弃！keep moving！

1、自旋锁

一、自旋锁的概念
首先是一种锁，与互斥锁相似，基本作用是用于线程（进程）之间的同步。与普通锁不同的是，一个线程A在获得普通锁后，如果再有线程B试图获取锁，那么这个线程B将会挂起（阻塞）；试想下，如果两个线程资源竞争不是特别激烈，而处理器阻塞一个线程引起的线程上下文的切换的代价高于等待资源的代价的时候（锁的已保持者保持锁时间比较短），那么线程B可以不放弃CPU时间片，而是在“原地”忙等，直到锁的持有者释放了该锁，这就是自旋锁的原理，可见自旋锁是一种非阻塞锁。

Java自旋锁 的实现原理：如果自旋锁被另外一个线程对象持有，那么当前获取锁的线程将陷入while循环等待，直到那个持有自旋锁的线程对象释放它所持有的自旋锁，那么那些想要获取该自旋锁的线程对象 将会有一个获得该自旋锁。
  基于他这种原理，等待的时候，并不释放cpu时间片，相比synchronized  wait()操作，减小了释放，重新获取的消耗。 该自旋锁适用于，当前线程竞争不强烈的时候使用。

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











使用了CAS原子操作，lock函数将currentThread设置为当前线程，并且预测原来的值为空。unlock函数将currentThread设置为null，并且预测值为当前线程。
当有第二个线程调用lock操作时由于currentThread值不为空，导致循环一直被执行，直至第一个线程调用unlock函数将owner设置为null，第二个线程才能进入临界区。
由于自旋锁只是将当前线程不停地执行循环体，不进行线程状态的改变，所以响应速度更快。但当线程数不停增加时，性能下降明显，因为每个线程都需要执行，占用CPU时间。如果线程竞争不激烈，并且保持锁的时间段。适合使用自旋锁。

自旋锁又分可重入锁实现方式和不可重入锁实现方式(不可重入方式极易造成死锁)

上面的实现方式是不可重入的实现方式

只需要增加几行调试信息我们就可以看到效果











下面来看看可重入自旋锁的实现方式有何不同








在SpinLock中加入了count计数器并增加相应的判断

CAS操作需要硬件的配合；
保证各个CPU的缓存（L1、L2、L3、跨CPU Socket、主存）的数据一致性，通讯开销很大，在多处理器系统上更严重；
没法保证公平性，不保证等待进程/线程按照FIFO顺序获得锁。

对于自旋锁来说，
若有同一线程两调用lock() ，会导致第二次调用lock位置进行自旋，产生了死锁
说明这个锁并不是可重入的。（在lock函数内，应验证线程是否为已经获得锁的线程）


2、自旋锁的其他种类

在自旋锁中 另有三种常见的锁形式:TicketLock ，CLHlock 和MCSlock
(A)Ticket Lock 是为了解决上面的公平性问题，类似于现实中银行柜台的排队叫号：锁拥有一个服务号，表示正在服务的线程，还有一个排队号；每个线程尝试获取锁之前先拿一个排队号，然后不断轮询锁的当前服务号是否是自己的排队号，如果是，则表示自己拥有了锁，不是则继续轮询。

当线程释放锁时，将服务号加1，这样下一个线程看到这个变化，就退出自旋








缺点

Ticket Lock 虽然解决了公平性的问题，但是多处理器系统上，每个进程/线程占用的处理器都在读写同一个变量serviceNum ，每次读写操作都必须在多个处理器缓存之间进行缓存同步，这会导致繁重的系统总线和内存的流量，大大降低系统整体的性能。

下面介绍的CLH锁和MCS锁都是为了解决这个问题的。



CLHLock 和MCSLock 则是两种类型相似的公平锁，采用链表的形式进行排序，

(B)CLHLock





CLH锁也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程只在本地变量上自旋，它不断轮询前驱的状态，如果发现前驱释放了锁就结束自旋。







(C)MCSLock
MCS Spinlock 是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程只在本地变量上自旋，直接前驱负责通知其结束自旋，从而极大地减少了不必要的处理器缓存同步的次数，降低了总线和内存的开销。




实现
MCS队列锁的具体实现如下：
1、如图（a）所示，队列初始化时没有结点，tail=null；
2、如图（b）所示，线程A想要获取锁，于是将自己置于队尾，由于它是第一个结点，它的locked域为false;；
3、如果（c）所示，线程B和C相继加入队列，前面说了这个队列是由next指针串起来的，所以a->next=b,b->next=c。且B和C现在没有获取锁，处于等待状态，所以它们的locked域为true，尾指针指向线程C对应的结点；
4、如果（d）所示，线程A释放锁后，顺着它的next指针找到了线程B，并把B的locked域设置为false。这一动作会触发线程B获取锁。
从上面的实现可以看出，MSC与CLH最大的不同并不是链表是显示还是隐式，而是线程自旋的规则不同，CLH是在前趋结点的locked域上自旋等待，而MSC是在自己的结点的locked域上自旋等待。正因为如此，它解决了CLH在NUMA系统架构中获取locked域状态内存过远的问题。









3、阻塞锁


4、可重入锁
本文里面讲的是广义上的可重入锁，而不是单指JAVA下的ReentrantLock。
可重入锁，也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。
在JAVA环境下 ReentrantLock 和synchronized 都是 可重入锁


[color=red][/color]锁（未完待续）

锁2转载自并发编程网 –http://ifeve.com/java_lock_see2/