线程<锁实现原理>

一个对象如果是多个线程的共享资源，应该尽可能在线程类中用属性维护起来，同时考虑在该对象对应的类中使用同步（函数或者代码块）加锁。这样才能确保准确性和一致性。如果了解过线程的生命周期，也会发现就绪、运行这两个生命周期也涉及到了锁的知识。

锁的作用

线程锁其实就是一种保护机制，在多线程的情况下，保证操作数据的正确性与一致性。

锁有那几种？

锁有以下几种：

• 悲观锁
• 乐观锁
• 独占锁
• 共享锁
• 公平锁
• 非公平锁
• 分布式锁
• 自旋锁
• 偏向锁

悲观锁

悲观锁就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。

悲观锁虽然解决了线程安全的问题，但是在高并发的场景下，会很多这样的修改请求，每个请求都需要等待 “锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗 尽，系统陷入异常。

以MySQL为例，悲观锁主要是表锁，行锁和间隙锁，叶锁，读锁，因为这些锁在被触发时会引起线程阻塞。每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁。在Java中，synchronized的思想也是悲观锁。

乐观锁

乐观锁就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采用其他的补偿措施。（最常见的补偿错误就是不断地重试，直到成功为止）。

乐观锁是相对于悲观锁采用更加宽松的加锁机制，总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。

大多数是采用带版本号 （Version）更新。实现这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回失败。 这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。

update table set x=x+1, version=version+1 where id=#{id} and version=#{version}; 

乐观锁其实在MySQL中本身不存在，但是MySQL提供了MVCC的机制，支持乐观锁机制。

什么是MVCC，其机制又是什么？

只有在InnoDB引擎下存在，MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，所说的乐观锁只在事务级别未提交锁和已提交锁时才会生效

MVCC机制：多版本并发控制，保证数据操作在多线程过程中，保证事务隔离的机制，可以降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的，对于数据的更新操作成功，会将这个版本号更新到数据的行中，事务提交成功，将新的版本号更新到此数据行中，这样保证了每个事务操作的数据，都是互不影响的，也不存在锁的问题.

CAS操作方式： 即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值、预期值、新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

独占锁

独占锁即是持有锁的线程只有一个。独占锁是一种悲观保守的加锁策略，它避免了读/读冲突，如果某个只读线程获取锁，则其他读线程都只能等待，这种情况下就限制了不必要的并发性，因为读操作并不会影响数据的一致性。

独占锁其实就是每次只能有一个线程能持有锁，ReentrantLock就是以独占方式实现的互斥锁。

AQS提供也独占锁必须实现的方法，具有独占锁功能的子类，它必须实现tryAcquire、tryRelease、isHeldExclusively等，独占锁获取锁时，设置节点模式为Node.EXCLUSIVE。

public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
}

AQS的ConditionObject只能与ReentrantLock一起使用，它是为了支持条件队列的锁更方便。ConditionObject的signal和await方法都是基于独占锁的，如果线程非锁的独占线程，则会抛出IllegalMonitorStateException。例如signalAll源码：

public final void signalAll() {
      if (!isHeldExclusively()) throw new IllegalMonitorStateException();
      Node first = firstWaiter;
      if (first != null) doSignalAll(first);
  ｝

共享锁

共享锁则允许多个线程同时获取锁，并发访问 共享资源。共享锁则是一种乐观锁，它放宽了加锁策略，允许多个执行读操作的线程同时访问共享资源。

典型的就是读锁——ReentrantReadWriteLock.ReadLock。即多个线程都可以读它，而且不影响其他线程对它的读，但是大家都不能修改它。CyclicBarrier， CountDownLatch和Semaphore也都是共享锁。

AQS提供了也共享锁必须实现的方法，共享锁功能的子类，必须实现tryAcquireShared和tryReleaseShared等方法，带有Shared后缀的方法都是支持共享锁加锁的语义。Semaphore是一种共享锁。共享锁获取锁，节点模式则为Node.SHARED。

private void doAcquireShared(int arg) {
        final Node node = addWaiter(Node.SHARED);
        boolean failed = true;
        .....
}

共享锁的意义

共享锁是为了提高程序的效率，举个例子：数据的操作有读写之分，对于写的操作加锁，保证数据正确性，而对于读的操作如果不加锁，在写读操作同时进行时，读的数据有可能不是最新数据，如果对读操作加独占锁，面对读多写少的程序肯定效率很低，所有就出现了共享锁，对于读的的操作就使用共享的概念，但是对于写的操作则是互斥的，保证了读写的数据操作都一致，在java中上述的锁也叫读写锁。

公平锁

公平锁，顾名思义，它是公平的，可以保证获取锁的线程按照先来后到的顺序，获取到锁。

在实现上，公平锁在进行ReentrantLock#lock时，首先会进行tryAcquire()操作。在tryAcquire中，会判断等待队列中是否已经有别的线程在等待了。如果队列中已经有别的线程了，则tryAcquire失败，则将自己加入队列。如果队列中没有别的线程，则进行获取锁的操作。

/**
     * Fair version of tryAcquire. Don't grant access unless
     * recursive call or no waiters or is first.
     **/
    protected final boolean tryAcquire(int acquires) {
      final Thread current = Thread.currentThread();
      int c = getState();
      if (c == 0) {
        if (!hasQueuedPredecessors() &&
          compareAndSetState(0, acquires)) {
          setExclusiveOwnerThread(current);
          return true;
        }
      }
      else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
          throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
      }
      return false;
    }

非公平锁

非公平锁，顾名思义，各个线程获取到锁的顺序，不一定和它们申请的先后顺序一致，有可能后来的线程，反而先获取到了锁。

/**
     * Sync object for non-fair locks
     */
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;
        /**
         * Performs lock.  Try immediate barge, backing up to normal
         * acquire on failure.
         */
        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }

非公平锁，在进行ReentrantLock#lock时，会直接尝试进行加锁，如果成功，则获取到锁，如果失败，则进行和公平锁相同的动作。

从公平锁和非公平的实现上来看，他们的操作基本相同，唯一的区别在于，在lock时，非公平锁会直接先进行尝试加锁的操作。

当前一个线程完成了锁的使用，并且释放了，而且此时等待队列非空时，如果这是有新线程申请锁，那么，公平锁和非公平锁的表现就会出现差异。

分布式锁

分布式锁，这种从事后端的会更加了解，一般分为三种：

• zookeeper

  zookeeper原理：基于zookeeper瞬时有序节点实现的分布式锁，其主要逻辑如下（该图来自于IBM网站）。大致思想即为：每个客户端对某个功能加锁时，在zookeeper上的与该功能对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

• memcached分布式锁

  memcached原理:memcached带有add函数，利用add函数的特性即可实现分布式锁。add和set的区别在于：如果多线程并发set，则每个set都会成功，但最后存储的值以最后的set的线程为准。而add的话则相反，add会添加第一个到达的值，并返回true，后续的添加则都会返回false。利用该点即可很轻松地实现分布式锁。

• redis分布式锁

  redis分布式锁即可以结合zk分布式锁锁高度安全和memcached并发场景下效率很好的优点，可以利用jedis客户端实现。

参考：https://surlymo.iteye.com/blog/2082684

自旋锁

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

使用自旋锁后，线程被挂起的几率相对减少，线程执行的连贯性相对加强。因此，对于那些锁竞争不是很激烈，锁占用时间很短的并发线程，具有一定的积极意义，但对于锁竞争激烈，单线程锁占用很长时间的并发程序，自旋锁在自旋等待后，往往毅然无法获得对应的锁，不仅仅白白浪费了CPU时间，最终还是免不了被挂起的操作 ，反而浪费了系统的资源。

在JDK1.6中，Java虚拟机提供-XX:+UseSpinning参数来开启自旋锁，使用-XX:PreBlockSpin参数来设置自旋锁等待的次数。

在JDK1.7开始，自旋锁的参数被取消，虚拟机不再支持由用户配置自旋锁，自旋锁总是会执行，自旋锁次数也由虚拟机自动调整。

偏向锁

偏向锁是JDK1.6提出来的一种锁优化的机制。其核心的思想是，如果程序没有竞争，则取消之前已经取得锁的线程同步操作。也就是说，若某一锁被线程获取后，便进入偏向模式，当线程再次请求这个锁时，就无需再进行相关的同步操作了，从而节约了操作时间，如果在此之间有其他的线程进行了锁请求，则锁退出偏向模式。在JVM中使用-XX:+UseBiasedLocking