面试之Java圣经7

the_Serendipity

已于 2022-03-01 09:52:50 修改

阅读量110

点赞数

分类专栏： Java 面试文章标签：面试 java

于 2022-02-27 21:14:00 首次发布

本文链接：https://blog.csdn.net/the_kingyang/article/details/123167452

版权

Java 面试专栏收录该内容

12 篇文章 1 订阅

订阅专栏

之前说到了多线程，多线程还有一部分重要的知识就是锁，今天来总结一下锁的相关问题

锁是什么？

在多线程和集合中我们有提到是否线程安全这个特性，例如linklist和arraylist都不是线程安全的等等，线程安全只指多线程情况下，会数据不一致等问题吗？带着问题我们可以回到多线程中，多线程的实现，使系统cpu利用率大大提高，多线程的线程安全问题就出现了。由于多个线程是共同占有所属进程的资源和空间地址的，那么就会存在一个问题：如果多个线程要同时访问某个资源，怎么处理？考虑如何保证数据的一致性，Java锁机制(同步问题)可以保证。

锁都有那些？

锁的分类如下，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计

乐观锁/悲观锁
独享锁/共享锁
互斥锁/读写锁
可重入锁
公平锁/非公平锁
分段锁
偏向锁/轻量级锁/重量级锁
自旋锁
ReentrantLock锁 Synchronized锁

乐观锁/悲观锁：乐观和悲观锁并不是实际的锁，它是一个设计思路

乐观锁：它的设计思路就是每次拿数据的时候都会认为别人不会修改数据，所以不会上锁，但是在更新的时候会判断在此期间有没有人更新这个数据，可以使用版本号机制，乐观锁适用于多读的场景，提高吞吐率，例如：在j.u.c包下面的原子变量类就是使用了乐观锁的一种实现方式CAS（Compare and Swap 比较并交换）

乐观锁------数据版本机制

实现数据版本一般有两种，第一种版本号，第二种时间戳。

版本号方式：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

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

乐观锁------CAS操作

CAS操作，当多个线程使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其他的线程都会更新失败，失败的线程不会挂起，而是被告知这次竞争失败，并可以再次尝试。

CAS操作中包含三个操作数，需要读写的内存位置（V)，进行比较的预期值(A)和拟写入的新值(B)，如果内存位置V的值和预期A值向匹配，那么处理器会将该值更新为B，否则处理器不做出任何操作。

CAS底层就是提现在Java语言中就是sun.miscUnSafe类中的各个方法。调用UnSafe类中的CAS方法,JVM会帮我实现CAS汇编指令.这是一种完全依赖于硬件功能,通过它实现了原子操作。再次强调,由于CAS是一种系统原语,原语属于操作系统用于范畴,是由若干条指令组成,用于完成某个功能的一个过程,并且原语的执行必须是连续的,在执行过程中不允许中断,也即是说CAS是一条原子指令,不会造成所谓的数据不一致的问题。

悲观锁：悲观锁和乐观锁相反，它的设计思路就是每次拿数据的时候都会认为别人会修改数据，所以每次拿数据都会上锁，悲观锁适用于写操作多的场景，这样别人拿数据的时候就会阻塞直到获取到锁，例如synchronized关键字的实现就是悲观锁。

加锁机制：在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking），如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。

独享锁/共享锁：和悲观锁乐观锁一样，都是设计思路

独享锁：是指该锁一次只能被一个线程所持有。对于Java ReentrantLock而言，其是独享锁。但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。

共享锁：是指该锁可被多个线程所持有。

读锁的共享锁可保证并发读是非常高效的，读写，写读，写写的过程是互斥的。

独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

AQS框架

AQS全称是：AbstractQueuedSynchronizer，抽象的队列式的同步器，AQS定义了一套多线程访问共享资源的同步框架。

AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行）如：Semaphore/CountDownLatch）。它维护了一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此列）。

volatile：被volatile修饰的变量能够保证每个线程能够获取该变量的最新值，从而避免出现数据脏读的现象。

不同的自定义同步器争用共享资源的方式也不同，自定义同步器在实现只需实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经实现了，自定义同步器主要实现以下几种方法：

isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

以ReentrantLock为例，state初始化为0，表示未锁定，A线程lock()时，会调用获取资源方法独占锁并将state+1,此后其他线程再获取资源时就会失败，直到A线程unlock到state=0为止，其他线程才有机会获取该锁，当然线程A可以重复获取此锁的(state会累加)，这就是可重入的概念，但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。 AQS部分参考链接

互斥锁/读写锁

互斥锁在Java中的具体实现就是ReentrantLock。

　　读写锁在Java中的具体实现就是ReadWriteLock。

可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。

ReetrantLock和Synchronized都是可重入锁，可重入锁的一个好处是可一定程度避免死锁。

公平锁/非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。

对于Java ReetrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。

　　对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

分段锁

分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。

我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7和JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock）。

当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在哪一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。

　　但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。

　　分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。