5. java 锁

锁分类

1. AQS（抽象队列同步器）

同步队列（即阻塞队列，线程处于blocked状态，头结点是获取了锁的节点）和等待队列（线程处于waiting状态），等待队列的节点/线程被执行signal（）加入同步队列

公平锁只有同步队列的第一个节点能获取锁，非公平锁只有第一个或尚未加入的能获取锁；公平锁和非公平锁区别在于判断当前节点是否有前置节点
锁实际上是通过内部类Sync（即同步器；子类FairSync和NonfairSync）实现，而Sync继承自AbstractQueuedSynchronizer（AQS），AQS通过内部类Node（同步队列和等待队列的节点）和ConditionObject（条件获取锁）来实现锁的功能

应用

reentrantlock，CountDownLatch，CyclicBarrier，Semaphore中使用

加锁解锁流程

获取锁：

(ReentrantLock.lock()调用sync.acquire(1)；acquire先tryAcquire，检查有无前置节点（公平锁），cas修改state状态；若成功则获取锁成功并返回；若失败则调用addWaiter加入同步队列，然后acquireQueued会判断addWaiter添加的节点如果是前驱节点是头节点，并且能够获得同步状态的话，当前线程能够获得锁该方法执行结束退出；否则先将节点状态设置成SIGNAL，然后调用LookSupport.park方法使得当前线程阻塞。)
（获取失败加入同步队列）

释放锁：

释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒同步队列里的其他线程来获取资源。（ReentrantLock.unlock()调用sync.release(1);release()先更新state，若更新后为0，则获取head节点，调用unparkSuccessor(h);unparkSuccessor调用LockSupport.unpark(head的next节点.thread)唤醒同步队列的下一节点，使其尝试获取锁）
（唤醒同步队列下一节点，从同步队列取出）

Node节点状态（waitStatus）：

  1. CANCELLED：值为1，在同步队列中等待的线程等待超时或被中断，需要从同步队列中取消该Node的结点，其结点的waitStatus为CANCELLED，即结束状态，进入该状态后的结点将不会再变化。
  2. SIGNAL（同步队列中）：值为-1，被标识为该等待唤醒状态的后继结点，当其前继结点的线程释放了同步锁或被取消，将会通知该后继结点的线程执行。说白了，就是处于唤醒状态，只要前继结点释放锁，就会通知标识为SIGNAL状态的后继结点的线程执行。
  3. CONDITION（等待队列中）：值为-2，与Condition相关，该标识的结点处于等待队列中，结点的线程等待在Condition上，当其他线程调用了Condition的signal()方法后，CONDITION状态的结点将从等待队列转移到同步队列中， 等待获取同步锁。
  4. PROPAGATE：值为-3，与共享模式相关，在共享模式中，该状态标识结点的线程处于可运行状态。

加入等待队列/条件队列

condition是要和lock配合使用的也就是condition和Lock是绑定在一起的
使用场景
阻塞队列BlockingDeque

加入等待队列/条件队列
condition.await()方法后会使得当前获取lock的线程进入到等待队列，直至被signal/signalAll后会使得当前线程从等待队列中移至到同步队列中去，直到获得了lock后才会从await方法返回，或者在等待时被中断会做中断处理。

从等待队列中取出
调用condition的signal或者signalAll方法可以将等待队列中等待时间最长的节点移动到同步队列中，使得该节点能够有机会获得lock。

同步队列为什么是双向链表，而等待队列是单链表？

在队列同步器中，头节点是成功获取到同步状态的节点，而头节点的线程释放了同步状态后，将会唤醒其他后续节点，后继节点的线程被唤醒后需要检查自己的前驱节点是否是头节点，如果是则尝试获取同步状态。

final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
            	//线程被唤醒后继续执行循环体的操作
            	//获取前置节点并判断是否为head
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                //将节点状态设置为SIGNAL（同步队列）
                if (shouldParkAfterFailedAcquire(p, node) &&
                //阻塞当前线程
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

公平锁效率低

原因：

​ 公平锁要维护一个队列，后来的线程要加锁，即使锁空闲，也要先检查有没有其他线程在 wait，如果有自己要挂起，加到队列后面，然后唤醒队列最前面线程。这种情况下相比较非公平锁多了一次挂起和唤醒。

​ 线程切换的开销，其实就是非公平锁效率高于公平锁的原因，因为非公平锁减少了线程挂起的几率，后来的线程有一定几率逃离被挂起的开销。

2. 偏向锁

对象头

对象的内存布局（对象头，实例数据，填充数据）
对象头包括两部分信息，

1. 用于存储对象自身的运行时数据（Mark word），如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，拥有锁的thread Id
2. 类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例
   对象的访问定位（句柄和直接引用（快））
   
   

锁的状态

1. 无锁
2. 偏向锁
3. 轻量级锁
4. 重量级所

对象头的mark word 记录拥有锁的thread Id，
线程的栈帧中存储对象头的mark word

（1）偏向锁

为什么要引入偏向锁？

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。
适用场景
始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去执行同步块

偏向锁的升级

当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

（2）轻量级锁

为什么要引入轻量级锁？

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。

轻量级锁什么时候升级为重量级锁？

线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；
如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。
但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。

升降级关系

为了避免无用的自旋，轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了；偏向锁升级为轻量级锁也不能再降级为偏向锁。一句话就是锁可以升级不可以降级，但是偏向锁状态可以被重置为无锁状态。

（3）这几种锁的优缺点（偏向锁、轻量级锁、重量级锁）

自旋锁

Java原子类中的递增操作就通过CAS+自旋锁实现的

自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗

3. Synchronized

原理简述：对象头的mark word指向monitor对象，monitor对象存有等待锁和持有锁的线程信息
详细说明
对象头是我们需要关注的重点，它是synchronized实现锁的基础，因为synchronized申请锁、上锁、释放锁都与对象头有关。对象头主要结构是由Mark Word 组成，其中Mark Word存储对象的hashCode、锁信息或分代年龄或GC标志等信息。

同步代码块是利用 monitorenter 和 monitorexit 指令实现的，而同步方法则是利用 flags 实现的。

重量级锁的指向互斥量的指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态；monitor是由ObjectMonitor实现的；ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSe t集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。如下图所示

 public synchronized static void aa(){ //类锁，方法
         }
        public synchronized  void aa(){ //对象锁，方法
         }

   synchronized (this){            //对象锁，代码块
            for(int i = 0;i < 100000;i++){
                sum++;
            }
        }

  synchronized (AA.class) {  //类锁，代码块
            System.out.println();
        }

4. ReenTrantLock

底层实现：

​ ReenTrantLock的实现是一种自旋锁，通过循环调用CAS操作来实现加锁。它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。

和synchronized区别

总结：jvm层面，不用手动释放，会阻塞，高级功能：可以非公平，可以中断，条件等待(Condition)

​ 1、底层实现：synchronized 是JVM层面的锁，是Java关键字，通过monitor对象来完成（monitorenter与monitorexit），ReentrantLock 是从jdk1.5以来（java.util.concurrent.locks.Lock）提供的API层面的锁。

​ 2、实现原理****：synchronized 的实现涉及到锁的升级，具体为无锁、偏向锁、自旋锁、向OS申请重量级锁；ReentrantLock实现则是通过利用CAS（CompareAndSwap）自旋机制**保证线程操作的原子性和volatile保证数据可见性以实现锁的功能。

​ 3、是否可手动释放：synchronized 不需要用户去手动释放锁，synchronized 代码执行完后系统会自动让线程释放对锁的占用； ReentrantLock则需要用户去手动释放锁，如果没有手动释放锁，就可能导致死锁现象。

​ 4、是否可中断synchronized是不可中断类型的锁，除非加锁的代码中出现异常或正常执行完成； ReentrantLock则可以中断，可通过trylock(long timeout,TimeUnit unit)设置超时方法或者将lockInterruptibly()放到代码块中，调用interrupt方法进行中断。

​ 5、是否公平锁synchronized为非公平锁 ReentrantLock则即可以选公平锁也可以选非公平锁，通过构造方法new ReentrantLock时传入boolean值进行选择，为空默认false非公平锁，true为公平锁,公平锁性能非常低。

5. cas（适用并发低，否则浪费cpu）

aba问题

6. 锁优化

编码层：减少锁时间和粒度，循环中的加锁放到循环外，适用cas，读写锁，并发包的锁等
系统层：自适应自旋锁，锁消除，锁升级

​ 自旋锁可以避免等待竞争锁进入阻塞挂起状态被唤醒造成的内核态和用户态之间的切换的损耗，它们只需要等一等（自旋），但是如果锁被其他线程长时间占用，一直不释放CPU，死等会带来更多的性能开销；自旋次数默认值是10

​ 对上面自旋锁优化方式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，这就解决了自旋锁带来的缺点