鹅 城 锁 事

1. Java锁事

1.1 大厂面试题

一、Synchronized相关问题
1.Synchronized 用过吗，其原理是什么?
2.你刚才提到获取对象的锁，这个“锁”到底是什么?如何确定对象的领?
3.什么是可重入性，为什么说Synchronized是可重入锁?
4.JVM对Java的原生锁做了哪些优化?
5.为什么说Synchronized是非公平锁?
6.什么是锁消除和锁粗化?
7.为什么说Synchronized是—个悲观领?乐观锁的实现原理又是什么?什么是CAS？
8.乐观锁—定就是好的吗?
9、synchronized实现原理，monitor对象什么时候生成的?知道monitor的monitorenter和monitorexit这两个是怎么保证同步的吗，或者说，这两个操作计算机底层是如何执行的
10.刚刚你提到了synchronized的优化过程，详细说一下吧。偏向锁和轻量级锁有什么区别?

二、可重入锁ReentrantLock及其他显式锁相关问题
1.跟Synchronized相比，可重入锁ReentrantLock 其续现原理有什么不同?
2那么请谈谈AQS框架是怎么回事儿?
3.请尽可能详尽地对比下Synchronized和 ReentrantLock的异同。
4.ReentrantLock是如何实现可重入性的?

三、其他
1.你怎么理解iava多线程的?怎么处理并发?线程池有那几个核心参数?你们项目中如何根据实际场景设置参数的?
2.Java加锁有哪几种锁？
3.简单说说lock ?
4.hashmap的实现原理? hash冲突怎么解决?为什么使用红黑树?
5.spring里面都使用了那些设计模式?循环依赖怎么解决?
6.项目中那个地方用了countdownlanch，怎么使用的?
7、从集合开始吧，介绍一下常用的集合类，哪些是有序的，哪些是无序的
8、hashmap是如何寻址的，哈希碰撞后是如何存储数据的，1.8后什么时候变成红黑树,红黑树有什么好处
9、concurrrenthashmap怎么实现线程安全，一个里面会有几个段 segment，jdk1.8后有优化concurrenthashmap吗?分段锁有什么坏处

1.2 乐观锁和悲观锁

悲观锁：
认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。
synchronized关键字和Lock的实现类都是悲观锁
显式的锁定之后再操作同步资源

乐观锁：
认为自己在使用数据时不会有别的线程修改数据或资源，所以不会添加锁
在Java中是通过使用无锁编程来实现，只是在更新数据的时候去判断，之前有没有别的线程更新了这个数据。
如果这个数据没有被更新，当前线程将自己修改的数据成功写入。
如果这个数据已经被其它线程更新，则根据不同的实现方式执行不同的操作，比如放弃修改、重试抢锁等等
如原子操作类那些底层是CAS算法，也就是乐观锁。

判断规则
1）版本号机制Version
2）最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的。

使用场景：
适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。
乐观锁则直接去操作同步资源，是种无锁算法，得之我幸不得我命，再努力就是

1.3 synchronized

阿里Java规范
高并发时，同步调用应该去考置锁的性能损耗。能用无锁数据结构，就不要用锁;能锁区块，就不要锁整个方法体﹔能用对象锁，就不要用类锁。
说明︰尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。

synchronized的三种应用方式
作用于实例方法，当前实例加锁，进入同步代码前要获得当前实例的锁;
作用于代码块，对括号里配置的对象加锁。
作用于静态方法，当前类加锁，进去同步代码前要获得当前类对象的锁;

从字节码角度分析synchronized实现
javap -c .class文件反编译

-c:对代码进行反汇编
-v -verbose 输出附加信息(包括行号、本地变量表，反汇编等详细信息)

synchronized同步代码块
实现使用的是monitorenter和monitorexit指令,他俩总是搭配使用，一个monitorenter对应两个monitorexit，monitorenter表示获得锁，monitorexit表示释放锁。但是经过反编译发现，里面多了monitorexit，是为了发生异常时也能正常释放锁。正常情况下走前面的monitorexit，异常情况走后面的monitorexit。极端情况下，也会出现一对一的情况，在退出同步代码前抛出异常，此时就是一对一的情况，因为就没有正常情况了，无论那种情况都会抛出异常。

synchronized普通同步方法
javap -v .class文件反编译
调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置。如果设置了，执行线程会将先持有monitor锁，然后再执行方法，
最后在方法完成(无论是正常完成还是非正常完成)时释放monitor

synchronized静态同步方法
javap -v .class文件反编译
ACC_STATIC,ACC_SYNCHRONIZED。相比于普通同步方法，静态同步方法多了一个ACC_STATIC访问标志，使用它来区分该方法是否静态同步方法

面试题:为什么任何一个对象都可以成为一个锁

管程(Monitors）:可以看做一个软件模块，它是将共享的变量和对于这些共享变量的操作封装起来，形成一个具有一定接口的功能模块，进程可以调用管程来实现进程级别的并发控制。

Java虚拟机可以支持方法级的同步和方法内部一段指令序列的同步，这两种同步结构都是使用管程(Monitor，更常见的是直接将它称为“锁”）来实现的。
方法级的同步是隐式的，无须通过字节码指令来控制，它实现在方法调用和返回操作之中。虚拟机可以从方法常量池中的方法表结构中的ACC_SYNCHRONIZED访问标志得知一个方法是否被声明为同步方法。当方法调用时，调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置，如果设置了，执行线程就要求先成功持有管程，然后才能执行方法，最后当方法完成（无论是正常完成还是非正常完成）时释放管程。在方法执行期间，执行线程持有了管程，其他任何线程都无法再获取到同一个管程。如果一个同步方法执行期间抛出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的管程将在异常抛到同步方法边界之外时自动释放。

通过C底层原语了解,在HotSpot虚拟机中，monitor采用objectMonitor实现
ObjectMonitor.java→ObjectMonitor.cpp→objectMonitor.hpp
每个对象天生都带着一个对象监视器
每一个被锁住的对象都会和Monitor关联起来
objectMonitor.hpp的关键属性

1.4 公平锁与非公平锁

公平锁：
指多个线程按照中请求锁的顺序来获取锁，这里类似排队买票，先来的人先买后来的人在队尾排着，这是公平的
Lock lock = new ReentrantLock(true);/l/true表示公平锁,先来先得

非公平锁：
是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先中请的线程优先获取锁，在高并发环境下，有可能造成优先级翻转或者饥饿的状态（某个线程一直得不到锁)
Lock lock = new ReentrantLock(false); false表示非公平锁，后来的也可能先获得锁。空参默认非公平锁

为什么会有公平锁/非公平锁的设计?为什么默认非公平?
恢复挂起的线程到真正锁的获取还是有时间差的，从开发人员来看这个时间微乎其微，但是从CPU的角度来看，这个时间差存在的还是很明显的。所以非公平锁能更充分的利用CPU的时间片，尽量减少CPU空闲状态时间。

使用多线程很重要的考量点是线程切换的开销，当采用非公平锁时，当1个线程请求锁获取同步状态，然后释放同步状态，所以刚释放锁的线程在此刻再次获取同步状态的概率就变得非常大，所以就减少了线程的开销。

什么时候用公平?什么时候用非公平?
如果为了更高的吞吐量，很显然非公平锁是比较合适的，因为节省很多线程切换时间，吞吐量自然就上去了;
否则那就用公平锁，大家公平使用。

马太效应在锁的争抢过程中也是表现得淋漓尽致，强者恒强。但人非线程，岂能为了效率就舍弃了公平？

1.5 可重入锁（递归锁）

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁(前提，锁对象得是同一个对象)，不会因为之前已经获取过还没释放而阻塞。
如果是1个有 synchronized修饰的递归调用方法，程序第2次进入被自己阻塞了岂不是天大的笑话，出现了作茧自缚。所以Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

一个线程中的多个流程可以获取同一把锁，持有这把同步锁可以再次进入。自己可以获取自己的内部锁

可重入锁种类
隐式锁（即synchronized关键字使用的锁）默认是可重入锁

指的是可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁，这样的锁就叫做可重入锁。
简单的来说就是:在一个synchronized修饰的方法或代码块的内部调用本类的其他synchronized修饰的方法或代码块时，是永远可以得到锁

显式锁（即Lock）也有ReentrantLock这样的可重入锁。
Lock.unLock();//正常情况，加锁几次就要解锁几次
由于加锁次数和释放次数不一样，第二个线程始终无法获取到锁，导致一直在等待

Synchronized的重入的实现机理
每个锁对象拥有一个锁计数器和一个指向持有该锁的线程的指针。
当执行monitorenter时，如果目标锁对象的计数器为零，那么说明它没有被其他线程所持有，Java虚拟机会将该锁对象的持有线程设
置为当前线程，并且将其计数器加1。
在目标锁对象的计数器不为零的情况下，如果锁对象的持有线程是当前线程，那么Java虚拟机可以将其计数器加1，否则需要等待，直至持有线程释放该锁。
当执行monitorexit时，Java虚拟机则需将锁对象的计数器减1。计数器为零代表锁已被释放。

1.6 死锁

死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去，如
果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。

产生死锁主要原因
系统资源不足
资源分配不当
进程运行推进的顺序不合适

死锁代码

public class DeadLockTest {

    public static void main(String[] args) {
        Object objectA = new Object();
        Object objectB = new Object();
        new Thread(()->{
            synchronized (objectA){
                System.out.println("获得objectA锁,尝试获得objectB锁");
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (objectB){
                    System.out.println("获得objectA锁,成功获得objectB锁");
                }
            }
        },"A").start();

        new Thread(()->{
            synchronized (objectB){
                System.out.println("获得objectB锁,尝试获得objectA锁");
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (objectA){
                    System.out.println("获得objectB锁,成功获得objectA锁");
                }
            }
        },"B").start();
    }
}

如何排查死锁
纯命令：jps -l
jstack 进程编号
图形化：jconsole

1.7 总结

写锁(独占锁)/读锁(共享锁)

自旋锁SpinLock

无锁→偏向锁→轻量锁→重量锁

无锁→独占锁→读写锁→邮戳锁

synchronized 小总结(重要)
指针指向monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个monitor与之关联。当一个montor被某个线程持有后，它便处于锁定状态。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码
ObjectMonitor.hpp文件，C++实现的)

注：本文是学习B站周阳老师《尚硅谷2022版JUC并发编程》课程所做学习笔记。