计算机基础

Appearance

volatile 关键字 ​

  • 保证原子可见性，表明该变量是共享且不稳定的，每次使用它都到主存中进行读取。（非Java独有，C也有）
  • 防止 JVM 指令重排，由于创建一个对象分成 1、分配内存空间，2、初始化对象，3、对象指向分配的内存空间，如果指令重排，可能 132 的顺序，导致一个线程获得还没有初始化的对象。
    • 比如下面的单例模式，13 后其他线程执行，发生这个对象不是 null，拿去使用，但是没有初始化，导致异常
    • 指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致，多线程可能导致一些异常
    • 是通过插入内存屏障实现的
  • 但是不能保证原子性，加锁才能，比如通过多线程对 volatile 进行 ++ 操作，而 ++ 包括：读取值，值增加，值写会三部，volatile 没办法保证两个线程同时操作不异常
双重校验锁实现对象单例（线程安全）
java
public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {
    }

    public  static Singleton getUniqueInstance() {
       //先判断对象是否已经实例过，没有实例化过才进入加锁代码
        if (uniqueInstance == null) {
            //类对象加锁
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

synchronized 关键字 ​

  • 保证了数据可见性和原子性
  • 依赖底层操作系统的锁，但是有很多优化，如
    • 自旋锁：如果线程持有锁时间很短，不会休眠，而是自旋等待
    • 锁消除：JVM 通过逃逸分析发现有些锁无用，不会执行锁操作
    • 轻量级锁：CAS 锁
  • 使用：
    • 修饰实例方法：同一个实例对象的该方法只能同时被一个线程执行，多个实例独立；
    • 修饰静态方法：该类的所有实例共享一把锁
    • 修饰代码块：可以是任意非 null 的对象，给类加锁或者给实例加锁都可以
    • 构造方法不能使用 synchronized 修饰，但内部可以有 synchronized代码块，但是构造方法本身线程安全，不太用到

ReentrantLock ​

实现了 Lock 接口，是一个可重入且独占式的锁，和 synchronized 关键字类似。不过，ReentrantLock 更灵活、更强大，增加了轮询、超时、中断、公平锁和非公平锁等高级功能。

synchronized 和 ReentrantLock 有什么区别？ ​

两者都是可重入锁 ​

可重入锁 也叫递归锁，指的是线程可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。

JDK 提供的所有现成的 Lock 实现类，包括 synchronized 关键字锁都是可重入的。

在下面的代码中，method1() 和 method2()都被 synchronized 关键字修饰，method1()调用了method2()。

java
public class SynchronizedDemo {
    public synchronized void method1() {
        System.out.println("方法1");
        method2();
    }

    public synchronized void method2() {
        System.out.println("方法2");
    }
}

由于 synchronized锁是可重入的，同一个线程在调用method1() 时可以直接获得当前对象的锁，执行 method2() 的时候可以再次获取这个对象的锁，不会产生死锁问题。假如synchronized是不可重入锁的话，由于该对象的锁已被当前线程所持有且无法释放，这就导致线程在执行 method2()时获取锁失败，会出现死锁问题。

synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API ​

synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。

ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。

ReentrantLock 比 synchronized 增加了一些高级功能 ​

相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：

  • 等待可中断 : ReentrantLock提供了一种能够中断等待锁的线程的机制，通过 lock.lockInterruptibly() 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
  • 可实现公平锁 : ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。ReentrantLock默认情况是非公平的。
  • 可实现选择性通知（锁可以绑定多个条件）: synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制。ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition()方法。

如果你想使用上述功能，那么选择 ReentrantLock 是一个不错的选择。

可中断锁和不可中断锁有什么区别？ ​

  • 可中断锁：获取锁的过程中可以被中断，不需要一直等到获取锁之后 才能进行其他逻辑处理。ReentrantLock 就属于是可中断锁。
  • 不可中断锁：一旦线程申请了锁，就只能等到拿到锁以后才能进行其他的逻辑处理。 synchronized 就属于是不可中断锁。

ReentrantReadWriteLock ​

ReentrantReadWriteLock 在实际项目中使用的并不多，面试中也问的比较少，简单了解即可。JDK 1.8 引入了性能更好的读写锁 StampedLock 。

ReentrantReadWriteLock 是什么？ ​

  • 一般锁进行并发控制的规则：读读互斥、读写互斥、写写互斥。
  • 读写锁进行并发控制的规则：读读不互斥、读写互斥、写写互斥（只有读读不互斥）。

ReentrantReadWriteLock 其实是两把锁，一把是 WriteLock (写锁)，一把是 ReadLock（读锁） 。读锁是共享锁，写锁是独占锁。读锁可以被同时读，可以同时被多个线程持有，而写锁最多只能同时被一个线程持有。

ReentrantReadWriteLock 适合什么场景？ ​

由于 ReentrantReadWriteLock 既可以保证多个线程同时读的效率，同时又可以保证有写入操作时的线程安全。因此，在读多写少的情况下，使用 ReentrantReadWriteLock 能够明显提升系统性能。

线程持有读锁还能获取写锁吗？ ​

  • 在线程持有读锁的情况下，该线程不能取得写锁(因为获取写锁的时候，如果发现当前的读锁被占用，就马上获取失败，不管读锁是不是被当前线程持有)。
  • 在线程持有写锁的情况下，该线程可以继续获取读锁（获取读锁时如果发现写锁被占用，只有写锁没有被当前线程占用的情况才会获取失败）。

读锁为什么不能升级为写锁？ ​

写锁可以降级为读锁，但是读锁却不能升级为写锁。这是因为读锁升级为写锁会引起线程的争夺，毕竟写锁属于是独占锁，这样的话，会影响性能。

另外，还可能会有死锁问题发生。举个例子：假设两个线程的读锁都想升级写锁，则需要对方都释放自己锁，而双方都不释放，就会产生死锁。

正在精进

Copyright © 2025 菜鸟