Java知识学习09（并发）

蔚落 2024-03-23 15:49 44阅读 0赞

[Java------原子性、可见性、有序性（讲得通俗易懂！！！点击这里查看！！！）][Java------]

***volatile关键字***

***1、如何保证变量的可见性？***

在 Java 中，`volatile` 关键字可以保证变量的可见性，如果我们将变量声明为 `volatile` ，这就指示 JVM，这个**变量是共享且不稳定的**，每次使用它都**到主存中进行读取**。

`volatile` 关键字其实并非是 Java 语言特有的，在 **C 语言里也有**，它最原始的意义就是**禁用 CPU 缓存**。如果我们将一个变量使用 `volatile` 修饰，这就指示 编译器，这个变量是**共享且不稳定**的，每次使用它都**到主存中进行读取**。`volatile` 关键字能保证数据的**可见性**，但**不能保证数据的原子性**。`synchronized` 关键字两者都能保证。

***2、如何禁止指令重排序？***

在 Java 中，`volatile` 关键字除了可以保证变量的可见性，还有一个重要的作用就是**防止 JVM 的指令重排序**。 如果我们将变量声明为 `volatile` ，在对这个变量进行读写操作的时候，会通过插入特定的 **内存屏障** 的方式来禁止指令重排序。

在 Java 中，`Unsafe` 类提供了三个开箱即用的内存屏障相关的方法，屏蔽了操作系统底层的差异：

public native void loadFence();
    public native void storeFence();
    public native void fullFence();

理论上来说，你通过这个三个方法也可以实现和`volatile`禁止重排序一样的效果，只是会麻烦一些。

***双重校验锁实现对象单例（线程安全） ：***

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;
        }
    }

`uniqueInstance` 采用 `volatile` 关键字修饰也是很有必要的， `uniqueInstance = new Singleton();` 这段代码其实是分为三步执行：  
1、为 uniqueInstance 分配内存空间  
2、初始化 uniqueInstance  
3、将 uniqueInstance 指向分配的内存地址

但是由于 **JVM 具有指令重排的特性**，执行顺序有可能变成 **1->3->2**。**指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例**。

例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。

***3、volatile可以保证原子性吗？***

volatile关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。

***4、什么是悲观锁？***  
悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，**共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。**

像 Java 中`synchronized`和`ReentrantLock`等独占锁就是悲观锁思想的实现。

public void performSynchronisedTask() {
        
        synchronized (this) {
        
            // 需要同步的操作
        }
    }
    
    private Lock lock = new ReentrantLock();
    lock.lock();
    try {
        
       // 需要同步的操作
    } finally {
        
        lock.unlock();
    }

高并发的场景下，激烈的锁竞争会造成**线程阻塞**，大量阻塞线程会**导致系统的上下文切换**，**增加系统的性能开销**。并且，悲观锁还可能会**存在死锁问题**，影响代码的正常运行。

***5、什么是乐观锁？***

乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，**无需加锁也无需等待**，**只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了**（具体方法可以使用**版本号机制**或 **CAS 算法**）。在 Java 中j`ava.util.concurrent.atomic`包下面的原子变量类（比如`AtomicInteger`、`LongAdder`）就是使用了乐观锁的一种实现方式 `CAS` 实现的。

// LongAdder 在高并发场景下会比 AtomicInteger 和 AtomicLong 的性能更好
    // 代价就是会消耗更多的内存空间（空间换时间）
    LongAdder sum = new LongAdder();
    sum.increment();

高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。

但是，如果冲突频繁发生（写占比非常多的情况），**会频繁失败和重试**，这样同样会非常影响性能，导致 CPU 飙升。不过，大量失败重试的问题也是可以解决的，像我们前面提到的 `LongAdder`以空间换时间的方式就解决了这个问题。

理论上来说：

*  悲观锁通常多用于写比较多的情况下（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了**频繁失败和重试**这个问题的话（比如`LongAdder`），也是可以考虑使用乐观锁的，要视实际情况而定。
 *  乐观锁通常多于写比较少的情况下（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，**乐观锁主要针对的对象是单个共享变量**（参考`java.util.concurrent.atomic`包下面的原子变量类）。

***6、如何实现乐观锁？***

乐观锁一般会使用**版本号机制**或 **CAS 算法**实现，CAS 算法相对来说更多一些，这里需要格外注意。

**版本号机制：**

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

举一个简单的例子 ：假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1、操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。

2、在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。

3、操作员 A 完成了修改工作，将数据版本号（ version=1 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本等于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。

4、操作员 B 完成了操作，也将版本号（ version=1 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 1 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须等于当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。

***CAS 算法***

`CAS` 的全称是 `Compare And Swap`（比较与交换） ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是**用一个预期值和要更新的变量值进行比较，两值相等才会进行更新**。

CAS 是一个原子操作，底层依赖于一条 CPU 的原子指令。

原子操作 即最小不可拆分的操作，也就是说操作一旦开始，就不能被打断，直到操作完成。

**CAS 涉及到三个操作数：**

*  V ：要更新的变量值(Var)
 *  E ：预期值(Expected)
 *  N ：拟写入的新值(New)

当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。

举一个简单的例子 ：线程 A 要修改变量 i 的值为 6，i 原值为 1（V = 1，E=1，N=6，假设不存在 ABA 问题）。

1、i 与 1 进行比较，如果相等， 则说明没被其他线程修改，可以被设置为 6 。

2、i 与 1 进行比较，如果不相等，则说明被其他线程修改，当前线程放弃更新，CAS 操作失败。

**当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作**。

Java 语言并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的（JNI 调用）。因此， CAS 的具体实现和操作系统以及 CPU 都有关系。

`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject、compareAndSwapInt、compareAndSwapLong`方法来实现的对`Object、int、long`类型的 `CAS` 操作

/**
    	*  CAS
      * @param o         包含要修改field的对象
      * @param offset    对象中某field的偏移量
      * @param expected  期望值
      * @param update    更新值
      * @return          true | false
      */
    public final native boolean compareAndSwapObject(Object o, long offset,  Object expected, Object update);
    
    public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update);
    
    public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);

***7、乐观锁存在哪些问题？***

**ABA 问题**是乐观锁最常见的问题。

**ABA 问题：**

如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 "ABA"问题。

ABA 问题的解决思路是在变量前面`追加上版本号或者时间戳`。

JDK 1.5 以后的 `AtomicStampedReference` 类就是用来解决 ABA 问题的，其中的 `compareAndSet()` 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

public boolean compareAndSet(V   expectedReference,
                                 V   newReference,
                                 int expectedStamp,
                                 int newStamp) {
        
        Pair<V> current = pair;
        return
            expectedReference == current.reference &&
            expectedStamp == current.stamp &&
            ((newReference == current.reference &&
              newStamp == current.stamp) ||
             casPair(current, Pair.of(newReference, newStamp)));
    }

**循环时间长开销大：**

CAS 经常会用到**自旋操作**来进行**重试**，也就是**不成功就一直循环执行直到成功**。如果长时间不成功，会给 CPU 带来非常大的执行开销。

如果 JVM 能支持处理器提供的 `pause` 指令那么效率会有一定的提升，`pause` 指令有两个作用：

1、可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。

2、可以避免在退出循环的时候因内存顺序冲而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。

**只能保证一个共享变量的原子操作**

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了`AtomicReference`类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用`AtomicReference`类把多个共享变量合并成一个共享变量来操作。

***8、synchronized 是什么？有什么用？***

`synchronized` 是 Java 中的一个关键字，翻译成中文是同步的意思，主要**解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行**。

在 Java 早期版本中，`synchronized` 属于 重量级锁，效率低下。这是因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。

不过，在 Java 6 之后， `synchronized` 引入了大量的优化如**自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁**等技术来减少锁操作的开销，这些优化让 `synchronized` 锁的效率提升了很多。因此， `synchronized` 还是可以在实际项目中使用的，像 JDK 源码、很多开源框架都大量使用了 synchronized 。

***9、如何使用 synchronized？***

`synchronized` 关键字的使用方式主要有下面 3 种：  
1、修饰实例方法  
2、修饰静态方法  
3、修饰代码块

*  修饰实例方法 （锁当前对象实例）

给当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁 。

synchronized void method() {
        
        //业务代码
    }

*  修饰静态方法 （锁当前类）

给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 **class** 的锁。这是因为静态成员不属于任何一个实例对象，归整个类所有，不依赖于类的特定实例，被类的所有实例共享。

synchronized static void method() {
        
        //业务代码
    }

\*\*静态 synchronized 方法和非静态 synchronized 方法之间的调用互斥么？  
\*\*`不互斥！`

如果一个线程 A 调用一个实例对象的非静态 `synchronized` 方法，而线程 B 需要调用这个实例对象所属类的静态 `synchronized` 方法，是允许的，不会发生互斥现象，因为访问静态 `synchronized` 方法**占用的锁是当前类的锁**，而访问非静态 `synchronized` 方法占用的锁是**当前实例对象锁**。

*  修饰代码块 （锁指定对象/类）

对括号里指定的对象/类加锁：  
1、`synchronized(object)` 表示进入同步代码库前要获得 **给定对象的锁**。  
2、`synchronized(类.class)` 表示进入同步代码前要获得 **给定 Class 的锁**

synchronized(this) {
        
        //业务代码
    }

**总结：**

*  `synchronized` 关键字加到 `static` 静态方法和 `synchronized(class)` 代码块上都是是**给 Class 类上锁**；
 *  `synchronized` 关键字加到**实例方法上**是**给对象实例上锁**；
 *  尽量不要使用 `synchronized(String a)` 因为 JVM 中，字符串常量池具有缓存功能。

***10、构造方法可以用 synchronized 修饰么？***

先说结论：构造方法**不能**使用 synchronized 关键字修饰。

构造方法本身就属于线程安全的，不存在同步的构造方法一说。

***11、synchronized 底层原理了解吗？***

`synchronized` 关键字底层原理属于 JVM 层面的东西。

如果是**实例方法**，JVM 会尝试获取**实例对象的锁**。如果是**静态方法**，JVM 会尝试**获取当前 class 的锁**。

***总结：***

`synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令**指向同步代码块的开始位置**，`monitorexit` 指令则**指明同步代码块的结束位置**。

`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。

不过两者的本质都是对对象监视器 `monitor` 的获取。

***12、synchronized 和 volatile 有什么区别？***

`synchronized` 关键字和 `volatile` 关键字是**两个互补的存在，而不是对立的存在**！

*  `volatile` 关键字是**线程同步的轻量级实现**，所以 `volatile`性能肯定比`synchronized`关键字要好 。但是 `volatile` 关键字只能**用于变量**而 `synchronized` 关键字可以**修饰方法以及代码块** 。
 *  `volatile` 关键字能**保证数据的可见性**，但**不能保证数据的原子性**。`synchronized` 关键字**两者都能保证**。
 *  `volatile`关键字主要用于`解决变量在多个线程之间的可见性`，而 `synchronized` 关键字**解决的是多个线程之间访问资源的同步性**。

***13、ReentrantLock\# ReentrantLock 是什么？***

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

public class ReentrantLock implements Lock, java.io.Serializable {
        }

`ReentrantLock` 里面有一个内部类 `Sync`，`Sync` 继承 `AQS（AbstractQueuedSynchronizer）`，添加锁和释放锁的大部分操作实际上都是在 Sync 中实现的。`Sync` 有`公平锁 FairSync` 和`非公平锁 NonfairSync` 两个子类。

`ReentrantLock` 默认`使用非公平锁`，也可以通过构造器来显式的指定使用公平锁。

// 传入一个 boolean 值，true 时为公平锁，false 时为非公平锁
    public ReentrantLock(boolean fair) {
        
        sync = fair ? new FairSync() : new NonfairSync();
    }

从上面的内容可以看出， `ReentrantLock` 的底层就是由 AQS 来实现的。

***14、公平锁和非公平锁有什么区别？***

*  公平锁 : **锁被释放之后，先申请的线程先得到锁**。**性能较差**一些，因为公平锁为了保证时间上的绝对顺序，**上下文切换更频繁**。
 *  非公平锁 ：**锁被释放之后，后申请的线程可能会先获取到锁，是随机或者按照其他优先级排序的**。性能更好，但**可能会导致某些线程永远无法获取到锁。**

***15、synchronized 和 ReentrantLock 有什么区别？***

**1、两者都是可重入锁**

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

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

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

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

由于 `synchronized`锁是可重入的，同一个线程在调用method1() 时可以直接获得当前对象的锁，执行 method2() 的时候可以再次获取这个对象的锁，不会产生死锁问题。

假如`synchronized`是不可重入锁的话，由于该对象的锁已被当前线程所持有且无法释放，这就导致线程在执行 method2()时获取锁失败，会出现死锁问题。

**2、synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API**

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

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

**3、ReentrantLock 比 synchronized 增加了一些高级功能**

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

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

***16、可中断锁和不可中断锁有什么区别？***

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

***17、共享锁和独占锁有什么区别？***

*  共享锁 ：一把锁可以被多个线程同时获得。
 *  独占锁 ：一把锁只能被一个线程获得。

***18、线程持有读锁还能获取写锁吗？***

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

***19、读锁为什么不能升级为写锁？***

写锁可以降级为读锁，但是读锁却不能升级为写锁。

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

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

[Java------]: https://blog.csdn.net/ly0724ok/article/details/117030234/