java 关于锁 常见面试题

synchronized原理

每一个对象都会和一个监视器monitor关联。监视器被占用时会被锁住，其他线程无法获取该monitor。当JVM执行某个线程的某个方法内部的monitorenter时，它会尝试去获取当前对象对应monitor的所有权，过程如下：

1. 若monitor的进入数为0，线程可以进入monitor，并将monitor的进入设置为1.当前线程成为monitor 的owner
2. 若线程已拥有monitor的所有权，允许它重入monitor，则进入monitor的进入数+1
3. 若其他线程已拥有monitor的所有权，那么当前尝试获取monitor所有权的线程会被阻塞，直到monitor的进入数为0 ，才能重新尝试获取monitor的所有权。

monitorenter小结：

synchronized的锁对象会关联一个monitor，这个monitor不是我们主动创建的，是JVM的线程执行到这个同步代码块，发现锁对象没有monitor就会创建monitor，monitor内部有两个重要的成员变量。owner：拥有这把锁的线程，recursions会记录线程拥有锁的次数。当一个线程拥有monitor后其他线程只能等待

monitorexit：

1. 能执行monitorexit指令的线程一定是拥有当前对象的monitor的所有权的线程
2. 执行monitorexit时会将monitor的进入数-1.当monitor的进入数减为0时，当前线程退出monitor，不在拥有monitor的所有权，此时其他被这个monitor阻塞的线程可以尝试去获取这个monitor的所有权

monitorexit释放锁

monitorexit插入在方法结束处和异常处，JVM保证每个monitorenter必须有对应的monitorexit

synchronized出现异常会释放锁吗

会！！！

小结：

synchronized是变成了monitorenter和monitorexit两个指令，每个锁对象都会关联一个monitor（监视器，它才是真正的锁对象），它内部有两个重要的成员变量 ：owner：会保存获得锁的线程，recursions会保存线程获得锁的次数，当执行到monitorexit时，recursions会-1，当计数器减到0时，这个线程就会释放锁。

synchronized和lock的区别

synchronized	lock
关键字	接口
锁方法，代码块	锁代码块
不可中断	lock方法不可中断，trylock方法可中断
自动释放锁	unlock方法手动释放锁
不能判断线程是否拿到锁	可以判断线程是否拿到锁 （trylock方法，拿到锁返回true，否则返回false）
非公平锁	ReentrantLock可以控制是否是公平锁

synchronized锁升级过程（锁的膨胀）

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

偏向锁是在只有一个线程执行同步块时进一步提高性能，适用于一个线程反复获得同一锁的情况，偏向锁可以提高带有同步但无竞争的程序性性能。

轻量级锁针对在多线程交替执行同步块的情况下，可以避免重量级锁引起的性能消耗。

重量级锁会阻塞、唤醒请求加锁的线程。它针对的是多个线程同时竞争同一把锁的情况。

ThreadLocal的应用场景

通常情况下，我们创建的变量是可以被任何⼀个线程访问并修改的。如果想实现每⼀个线程都有⾃⼰的专属本地变量该如何解决呢？ JDK中提供的 ThreadLocal 类正是为了解决这样的问题。
ThreadLocal 类主要解决的就是让每个线程绑定⾃⼰的值，可以将 ThreadLocal 类形象的⽐喻成存放数据的盒⼦，盒⼦中可以存储每个线程的私有数据。
如果你创建了⼀个 ThreadLocal 变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是 ThreadLocal 变量名的由来。他们可以使⽤ get（） 和 set（） ⽅法来获取默认值或将其值更改为当前线程所存的副本的值，从⽽避免了线程安全问题。

再举个简单的例⼦：
⽐如有两个⼈去宝屋收集宝物，这两个共⽤⼀个袋⼦的话肯定会产⽣争执，但是给他们两个⼈每个⼈分配⼀个袋⼦的话就不会出现这样的问题。如果把这两个⼈⽐作线程的话，那么ThreadLocal就是⽤来避免这两个线程竞争的。

ThreadLocal 与synchronized的区别

虽然ThreadLocal模式与synchronized关键字都用于处理多线程并发访问线程变量问题，不过两者处理问题的思路和角度不同。

	synchronized	ThreadLocal
原理	同步机制采用“以时间换空间”的方式，只提供一份变量，让不同的线程排队访问	ThreadLocal采用“以空间换时间”的方式，为每一个线程都提供了一份变量的副本
侧重点	多个线程之间访问资源的同步	多个线程中让每个线程之间的数据相互隔离

volatile怎么保证可见性

在当前的java内存模型下，线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中变量值的拷贝，造成数据的不一致。

要解决这个问题，就需要把变量声明为volatile，这就指示JVM，这个变量是不稳定的，每次使用它都要到主存中进行读取。

synchronized 关键字和 volatile 关键字的区别

synchronized	volatile
修饰方法、代码块	修饰变量
多线程访问synchronized会阻塞	多线程访问volatile不会发生阻塞
保证数据的可见性，原子性	保证数据的可见性
解决多个线程访问资源的同步性	解决变量在多个线程之间的可见性

volatile+双重检查实现单例模式

/*
   目标：双重检查机制，以及使用volatile修饰（最好，最安全，最推荐）
   步骤：
        1.构造器私有
        2.提供一个静态变量用于存储一个单例对象
        3.提供一个方法进行双重检查机制返回单例对象
        4.使用volatile修饰静态的变量

    双重检查的优点：线程安全，延迟加载，效率较高！
 */
public class Singleton {
    private volatile static Singleton INSTANCE;
    private Singleton(){
        
    }
    public static Singleton getInstance(){
        // 第一次检查：判断单例对象的变量是否为null
        if(INSTANCE == null){
            synchronized (Singleton.class){
                //第二次检查：判断单例对象的变量是否为null
                if(INSTANCE == null){
                    INSTANCE = new Singleton();
                }
            }

        }
        return INSTANCE;
    }
}

为什么要使用volatile修饰呢？

1. 禁止指令重排序
   创建对象要经过如下几个步骤
   a. 分配内存空间
   b. 调用构造器，初始化实例
   c. 返回地址给引用

   但是JVM具有指令重排的特性，执行的顺序有可能变成 a-c-b,指令重排在单线程下不会出现问题，但是在多线程下会导致一个线程获得还没有初始化的实例。例如：线程T1执行了a，b，此时线程T2调用getInstance()方法发现INSTANCE不为null，因此返回INSTANCE，但此时INSTANCE还未被初始化。

2. 保证可见性
   由于可见性问题，线程T1在自己的工作线程内创建了实例，但此时还未同步到主内存中，此时线程T2判断INSTANCE还是null，那么线程T2又将在自己的工作线程创建一个实例，这样就创建了多个实例

   如果加上了volatile修饰INSTANCE之后，保证了可见性，一旦线程T1返回了实例，线程T2可以立即发现INSTANCE不为null