锁-面试考点

锁

常见锁的集合以及各个锁代表的基本含义

乐观锁和悲观锁

• 根据线程要不要锁住同步资源分为：乐观锁和悲观锁

悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。Java中，synchronized关键字和Lock的实现类都是悲观锁。

而乐观锁认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）。乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的。

根据从上面的概念描述我们可以发现：

悲观锁适合写操作多的场景，先加锁可以保证写操作时数据正确。

​ 乐观锁适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。

自旋锁和适应性自旋锁

• 根据锁住同步资源失败，线程要不要阻塞：非阻塞包含自旋锁和适应性自旋锁

• 在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。

  而为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁。

自旋锁本身是有缺点的，它不能代替阻塞。自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当挂起线程。

适用场景：自旋锁的实现原理同样也是CAS，AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。

无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁

• 根据多线程竞争同步资源的流程细节区别：
  • 不锁住资源，多个线程中只有一个能修改资源成功，其他线程会重试：无锁
  • 同一个资源执行同步资源时自动获取资源：偏向锁
  • 多个线程竞争同步资源时，没有获取资源的线程自旋等待锁释放：轻量级锁
  • 多个线程竞争同步资源时，没有获取资源的线程阻塞等待唤醒：重量级锁

这四种锁是指锁的状态，专门针对synchronized的。

无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。

轻量级锁是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。

重量级锁升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。整体的锁状态升级流程如下：

综上，偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作。而轻量级锁是通过用CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒而影响性能。重量级锁是将除了拥有锁的线程以外的线程都阻塞。

公平锁和非公平锁

• 多个线程竞争锁时要不要排队：公平锁（排队）、非公平锁（先插队，插队失败再排队）

公平锁是指多个线程按照申请锁的顺序来获取锁，线程直接进入队列中排队，队列中的第一个线程才能获得锁。公平锁的优点是等待锁的线程不会饿死。缺点是整体吞吐效率相对非公平锁要低，等待队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大。

非公平锁是多个线程加锁时直接尝试获取锁，获取不到才会到等待队列的队尾等待。但如果此时锁刚好可用，那么这个线程可以无需阻塞直接获取到锁，所以非公平锁有可能出现后申请锁的线程先获取锁的场景。非公平锁的优点是可以减少唤起线程的开销，整体的吞吐效率高，因为线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程。缺点是处于等待队列中的线程可能会饿死，或者等很久才会获得锁。

可重入锁和不可重入锁

• 一个线程中多个流程能不能获取同一把锁：能：可重入锁；不能：非可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

共享锁和排他锁

• 多个线程能不能共享同一把锁：能：共享锁 不能：排他锁

独享锁也叫排他锁，是指该锁一次只能被一个线程所持有。如果线程T对数据A加上排它锁后，则其他线程不能再对A加任何类型的锁。获得排它锁的线程即能读数据又能修改数据。JDK中的synchronized和JUC中Lock的实现类就是互斥锁。

共享锁是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据。

1.JAVA中如何确保N个线程可以访问N个资源，但同时又不导致死锁？

答：避免死锁的方式就是：指定获取锁的顺序，并强制线程按照指定的顺序获取锁。因此，如果所有的线程都是以同样的顺序加锁和释放锁，就不会出现死锁了。

预防死锁，预先破坏产生死锁的四个条件。互斥不可能破坏，所以有如下三种方法：

• .破坏请求和保持条件，进程必须等所有要请求的资源都空闲时才能申请资源，这种方法会使资源浪费严重(有些资源可能仅在运行初期或结束时才使用，甚至根本不使用). 允许进程获取初期所需资源后，便开始运行，运行过程中再逐步释放自己占有的资源，比如有一个进程的任务是把数据复制到磁盘中再打印，前期只需获得磁盘资源而不需要获得打印机资源，待复制完毕后再释放掉磁盘资源。这种方法比第一种方法好，会使资源利用率上升。
• 破坏不可抢占条件，这种方法代价大，实现复杂。
• 破坏循坏等待条件，对各进程请求资源的顺序做一个规定，避免相互等待。这种方法对资源的利用率比前两种都高，但是前期要为设备指定序号，新设备加入会有一个问题，其次对用户编程也有限制。

2.请问什么是死锁(deadlock)?

答：两个线程或两个以上线程都在等待对方执行完毕才能继续往下执行的时候就发生了死锁。结果就是这些线程都陷入了无限的等待中。

3.请说明一下synchronized的可重入怎么实现。

答：实现原理如下

• 每个锁关联一个线程持有者和一个计数器。当计数器为0时表示该锁没有被任何线程持有，那么任何线程都都可能获得该锁而调用相应方法。
• 当一个线程请求成功后，JVM会记下持有锁的线程，并将计数器计为1。此时其他线程请求该锁，则必须等待。
• 而该持有锁的线程如果再次请求这个锁，就可以再次拿到这个锁，同时计数器会递增。当线程退出一个synchronized方法/块时，计数器会递减，如果计数器为0则释放该锁。

4.请讲一下非公平锁和公平锁在reetrantlock里的实现过程是怎样的。

答：首先那如何能保证每个线程都能拿到锁呢，队列FIFO（先进先出）是一个完美的解决方案

• 在公平的锁中，如果有另一个线程持有锁或者有其他线程在等待队列中等待这个所，那么新发出的请求的线程将被放入到队列中。而非公平锁上，只有当锁被某个线程持有时，新发出请求的线程才会被放入队列中（此时和公平锁是一样的）。所以，它们的差别在于非公平锁会有更多的机会去抢占锁。

• 公平锁：

      final Thread current = Thread.currentThread();
      int c = getState();
      if (c == 0) {
          if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
       }
  
  
      #hasQueuedPredecessors的实现
      public final boolean hasQueuedPredecessors() {
     
          Node t = tail; // Read fields in reverse initialization order
          Node h = head;
          Node s;
          return h != t &&
              ((s = h.next) == null || s.thread != Thread.currentThread());
      }
  
  
  
  public class MyFairLock {
      /**
       *     true 表示 ReentrantLock 的公平锁
       */
      private  ReentrantLock lock = new ReentrantLock(true);
  
      public   void testFail(){
          try {
              lock.lock();
              System.out.println(Thread.currentThread().getName() +"获得了锁");
          }finally {
              lock.unlock();
          }
      }
      public static void main(String[] args) {
          MyFairLock fairLock = new MyFairLock();
          Runnable runnable = () -> {
              System.out.println(Thread.currentThread().getName()+"启动");
              fairLock.testFail();
          };
          Thread[] threadArray = new Thread[10];
          for (int i=0; i<10; i++) {
              threadArray[i] = new Thread(runnable);
          }
          for (int i=0; i<10; i++) {
              threadArray[i].start();
          }
      }
  }
  

• 非公平锁

          final Thread current = Thread.currentThread();
          int c = getState();
          if (c == 0) {
              if (compareAndSetState(0, acquires)) {
                  setExclusiveOwnerThread(current);
                  return true;
              }
          }
  
  
  
  /**
   * Created by Fant.J.
   */
  public class MyNonfairLock {
      /**
       *     false 表示 ReentrantLock 的非公平锁
       */
      private  ReentrantLock lock = new ReentrantLock(false);
  
      public  void testFail(){
          try {
              lock.lock();
              System.out.println(Thread.currentThread().getName() +"获得了锁");
          }finally {
              lock.unlock();
          }
      }
      public static void main(String[] args) {
          MyNonfairLock nonfairLock = new MyNonfairLock();
          Runnable runnable = () -> {
              System.out.println(Thread.currentThread().getName()+"启动");
              nonfairLock.testFail();
          };
          Thread[] threadArray = new Thread[10];
          for (int i=0; i<10; i++) {
              threadArray[i] = new Thread(runnable);
          }
          for (int i=0; i<10; i++) {
              threadArray[i].start();
          }
      }
  }
  
  

• 优缺点：非公平锁性能高于公平锁性能。首先，在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。而且，非公平锁能更充分的利用cpu的时间片，尽量的减少cpu空闲的状态时间。

• 使用场景：使用场景的话呢，其实还是和他们的属性一一相关，举个栗子：如果业务中线程占用(处理)时间要远长于线程等待，那用非公平锁其实效率并不明显，但是用公平锁会给业务增强很多的可控制性。

总结：如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，FIFO。对于非公平锁，只要CAS设置同步状态成功，则表示当前线程获取了锁，而公平锁还需要判断当前节点是否有前驱节点，如果有，则表示有线程比当前线程更早请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。