javaEE - 2（11000字详解多线程）

ice___Cpu

已于 2023-12-13 17:52:50 修改

阅读量1.3k

点赞数 27

分类专栏： javaEE 文章标签： java-ee java

于 2023-10-19 13:05:00 首次发布

本文链接：https://blog.csdn.net/weixin_73232539/article/details/133918444

版权

javaEE 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

一：多线程带来的的风险-线程安全

线程安全的概念：如果多线程环境下代码运行的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线程安全的。

当多个线程同时访问共享资源时，就会产生线程安全的风险，下面通过一段代码演示：

static class Counter {
  public int count = 0;
  void increase() {
    count++;
 }
}
public static void main(String[] args) throws InterruptedException {
  final Counter counter = new Counter();
  Thread t1 = new Thread(() -> {
    for (int i = 0; i < 50000; i++) {
      counter.increase();
   }
 });
  Thread t2 = new Thread(() -> {
    for (int i = 0; i < 50000; i++) {
      counter.increase();
   }
 });
  t1.start();
  t2.start();
  t1.join();//主线程等待t1线程结束
  t2.join();//主线程等待t2线程结束
  System.out.println(counter.count);
}

这个代码,是两个线程针对同一个变量各自自增 5w 次，运行程序,预期结果应该是10w，但是实际是个随机值一样。每次的结果还不一样。

实际结果和预期结果不相符,就是 bug ，由多线程引起的 bug => 线程不安全/线程安全问题

那么为什么会出现这个情况呢？这是因为count++ 操作本质上是三个cpu 指令构成：

load,把内存中的数据读取到cpu寄存器中.
add,就是把寄存器中的值,进行+1运算
save,把寄存器中的值写回到内存中.

在这里插入图片描述
由于多线程调度顺序是不确定的,实际执行过程中,这俩线程的++操作实际的指令排列顺序就有很多可能!!!

在这里插入图片描述

等等等等许多的组合

1.1 组合1

在这里插入图片描述
对于这种组合来说：

第一步：
在这里插入图片描述
第二步（t1-load）：

第三步(t1-add):

第四步（t1-save）：

第五步（t2-load）：

第六步（t2-add）：

第七步（t2-save）：

这种组合是没有问题的，能够无误的完成自增。

1.2 组合2

在这里插入图片描述
但是对于这种组合来说就有点问题了

第一步：
在这里插入图片描述
第二步(t1-load)：

第三步(t2-load):

第四步（t2-add）：

第五步（t1-add）：

第六步（t1-save）：

第七步（t2-save）：

这就和我们的预期结果2不一致了，因为这有类似脏读的数据，一切罪恶的根源就是cpu调度的抢占式执行！这就是多线程带来的风险。

当我们用一个线程修改同一个变量 -> 安全
多个线程读取同一个变量 -> 安全
多个线程修改不同的变量 -> 安全
多个线程修改同一个变量 -> 不安全

1.3 原子性

多个线程修改同一个变量不安全的原因主要是因为修改变量的操作不是原子性的

原子性是指一个操作是不可中断的，要么全部执行完成，要么完全不执行。

如果一个操作是原子的，那么在执行过程中不会被其他线程的干扰，同时也不会干扰其他线程的执行。

当多个线程同时对共享资源进行读写操作时，如果没有原子性保证，就会导致数据不一致、并发错误、死锁等问题。因此，在并发编程中，需要特别注意保证操作的原子性。

1.4 可见性

可见性问题是指一个线程对共享变量的修改可能不会立即被其他线程所看到，导致线程间的数据不一致性。

Java 内存模型 (JMM): Java虚拟机规范中定义了Java内存模型.目的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果.

在这里插入图片描述

线程之间的共享变量存在主内存 (Main Memory).
每一个线程都有自己的 “工作内存” (Working Memory) .
当线程要读取一个共享变量的时候, 会先把变量从主内存拷贝到工作内存, 再从工作内存读取数据.
当线程要修改一个共享变量的时候, 也会先修改工作内存中的副本, 再同步回主内存.

当一个线程对共享变量进行修改后，必须将修改后的值刷新到主内存中，以便其他线程可以看到这个变化。而其他线程在读取共享变量时，也需要将主内存中最新的值加载到自己的工作内存中。

可见性问题主要有以下两种情况：

修改后的值没有立即被其他线程看到：

当一个线程修改了共享变量的值，但该值并没有被及时刷新到主内存中，其他线程在读取该共享变量时仍然看到的是过期的旧值，而不是最新的修改值。

对共享变量的修改对其他线程来说是不可见的：

一个线程修改了共享变量的值并已经将其写入主内存，而其他线程在读取共享变量时却没有及时从主内存中加载最新的值，而是仍然从自己的工作内存中读取旧值。

由于每个线程有自己的工作内存, 这些工作内存中的内容相当于同一个共享变量的 “副本”. 此时修改线程1 的工作内存中的值, 线程2 的工作内存不一定会及时变化.

初始情况下, 两个线程的工作内存内容一致.
一旦线程1 修改了 a 的值, 此时主内存不一定能及时同步. 对应的线程2 的工作内存的 a 的值也不一定能及时同步.

在这里插入图片描述
这个时候代码中就容易出现问题.

此时引入了两个问题: 为啥要整这么多内存? 为啥要这么麻烦的拷来拷去?

为啥整这么多内存?

实际并没有这么多 “内存”. 这只是 Java 规范中的一个术语, 是属于 “抽象” 的叫法.所谓的 “主内存” 才是真正硬件角度的 “内存”. 而所谓的 “工作内存”, 则是指 CPU 的寄存器和高速缓存.

为啥要这么麻烦的拷来拷去?

因为 CPU 访问自身寄存器的速度以及高速缓存的速度, 远远超过访问内存的速度(快了 3 - 4 个数量级, 也就是几千倍, 上万倍).

比如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的. 但是如果只是第一次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问内存了. 效率就大大提高了.

那么接下来问题又来了, 既然访问寄存器速度这么快, 还要内存干啥??

答案就是一个字: 贵

在这里插入图片描述

1.5指令重排序

指令重排序是编译器和处理器为了优化代码执行效率而进行的一种手段。它可以改变代码中指令的执行顺序.

编译器和处理器进行指令重排序的目的是通过优化指令的执行顺序，减少指令之间的依赖性，提高指令级并行度，从而提高程序的执行效率。

JVM 和 CPU 指令集对指令重排序进行优化的原因是提高代码执行效率，减少指令的等待时间，充分利用处理器的并行执行能力，提高程序的性能和响应能力。

尽管指令重排序可以改善程序的执行效率，但在多线程环境下，指令重排序可能会导致线程安全问题。因此，在编写多线程代码时，需要使用适当的同步机制来保证线程之间的正确交互。

二：解决线程安全问题

2.1 synchronized关键字

如何解决线程不安全问题?需要从原因入手！能否让 count++变成原子的呢?当然有，那就是加锁!!

在Java中，可以使用synchronized关键字来保证原子性。synchronized关键字用于修饰方法或代码块，确保同一时刻只有一个线程可以执行被修饰的代码。

同步方法：将关键字synchronized直接应用于方法。当一个线程进入这个方法时，它将锁住整个方法，其他线程必须等待该线程执行完毕才能进入该方法。

public synchronized void synchronizedMethod() {
    // 线程安全代码
}

同步代码块：将关键字synchronized应用于代码块，指定一个对象作为锁。当一个线程进入代码块时，它将锁住指定的对象，其他线程必须等待锁的释放才能进入该代码块，当这个线程执行完代码块的代码时，会自动解锁。

public void synchronizedBlock() {
    synchronized (lock) {
        // 线程安全代码
    }
}

加锁的意思就是获取到锁，解锁的意思就说释放锁，加锁意味着获得对某个资源的独占访问权限，而解锁则是释放这个资源，使其他线程可以访问它。

在以上示例中，lock可以是任意Java对象。如果多个线程共享同一个锁对象，那么同一时刻只能有一个线程执行代码块内的代码。

synchronized关键字通过获取和释放锁来实现原子性。当一个线程获取到锁时，其他线程将无法进入相同的同步方法或代码块。这确保了被synchronized修饰的代码在同一时刻只能由一个线程执行，从而保证了原子性。

当两个线程对同一个对象加锁时，它们会争夺这个对象的锁资源，即发生了锁竞争。只有一个线程能够获得该对象的锁资源，而另一个线程将被阻塞，直到获得锁的线程释放锁资源。如果两个线程针对不同的对象加锁是不会发生锁竞争的，各自获取各自的锁即可。

下面是一个简单的代码示例，展示了两个线程对同一个对象进行加锁的情况：

public class LockExample {
    private final Object lock = new Object();

    public void thread1() {
        synchronized (lock) {
            // 临界区1
            // 线程1获得了锁资源，执行一些操作
        }
    }

    public void thread2() {
        synchronized (lock) {
            // 临界区2
            // 线程2获得了锁资源，执行一些操作
        }
    }
}

在上面的代码示例中，lock对象是一个共享资源，两个线程thread1()和thread2()分别对lock对象进行加锁。

当线程1执行到synchronized (lock)时，它会尝试获取lock对象的锁资源。如果锁资源可用，线程1将获得锁，并执行临界区1的代码。此时，如果线程2尝试执行synchronized (lock)，它将无法获得锁资源，因为锁资源已经被线程1占用。线程2将被阻塞，直到线程1释放锁资源。

同样地，当线程2执行到synchronized (lock)时，它会尝试获取lock对象的锁资源。如果锁资源可用，线程2将获得锁，并执行临界区2的代码。此时，如果线程1尝试执行synchronized (lock)，它将无法获得锁资源，因为锁资源已经被线程2占用。线程1将被阻塞，直到线程2释放锁资源。

理解 “阻塞等待”：

针对每一把锁, 操作系统内部都维护了一个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进行加锁, 就加不上了, 就会阻塞等待, 一直等到之前的线程解锁之后, 由操作系统唤醒一个新的线程, 再来获取到这个锁.

注意:

上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 “唤醒”. 这也就是操作系统线程调度的一部分工作.

假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.

2.1.1synchronized 的特性

当谈到synchronized关键字时，它具有三个重要的特性：互斥性、内存可见性和可重入性。下面将逐个解释这些特性：

互斥性：

synchronized关键字用于保护临界区，确保同时只有一个线程可以执行临界区代码。这意味着当一个线程进入synchronized代码块时，其他线程将被阻塞，直到该线程执行完临界区代码并释放锁。

内存可见性：

synchronized 的工作过程:
3. 获得互斥锁
4. 从主内存拷贝变量的最新副本到工作的内存
5. 执行代码
6. 将更改后的共享变量的值刷新到主内存
7. 释放互斥锁

synchronized关键字还确保了线程之间的内存可见性。当线程进入synchronized代码块并获取锁时，它会把修改后的值刷新回主内存，并且当其他线程获取锁时，它们会重新从主内存中读取最新的值。这确保了共享变量的值在不同线程之间保持一致。

可重入性：

synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；

理解 “把自己锁死”：一个线程没有释放锁, 然后又尝试再次加锁.

// 第一次加锁, 加锁成功
lock();
// 第二次加锁, 锁已经被占用, 阻塞等待.
lock();

按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第二个锁. 但是释放第一个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无法进行解锁操作. 这时候就会死锁。

在这里插入图片描述

Java 中的 synchronized 是可重入锁, 因此没有上面的问题.

代码示例：

static class Counter {
  public int count = 0;
  synchronized void increase() {
    count++;
 }
  synchronized void increase2() {
    increase();
 }
}

这个代码是完全没问题的. 因为 synchronized 是可重入锁.

在上述的代码中,increase 和 increase2 两个方法都加了 synchronized, 此处的synchronized 都是针对 this 当前对象加锁的.

在调用 increase2 的时候, 先加了一次锁, 执行到 increase 的时候, 又加了一次锁. (上个锁还没释放, 相当于连续加两次锁)

在可重入锁的内部, 包含了 “线程持有者” 和 “计数器” 两个信息.

如果某个线程加锁的时候, 发现锁已经被人占用, 但是恰好占用的正是自己, 那么仍然可以继续获取到锁, 并让计数器自增
解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)

2.2.2synchronized的锁对象

直接修饰普通方法: 相当于对this加锁

public class SynchronizedDemo {
  public synchronized void methond() {
 }
}

修饰静态方法: 相当于对类对象加锁

public class SynchronizedDemo {
  public synchronized static void method() {
 }
}

修饰代码块: 明确指定锁哪个对象.

修饰代码块又可以分为两种：

锁当前对象

public class SynchronizedDemo {
  public void method() {
    synchronized (this) {
     
   }
 }
}

锁类对象

public class SynchronizedDemo {
  public void method() {
    synchronized (SynchronizedDemo.class) {
   }
 }
}

我们重点要理解，synchronized 锁的是什么. 两个线程竞争同一把锁, 才会产生阻塞等待.
在这里插入图片描述

2.2.3 Java 标准库中的线程安全类

Java 标准库中很多都是线程不安全的. 这些类可能会涉及到多线程修改共享数据, 又没有任何加锁措施.

ArrayList
LinkedList
HashMap
TreeMap
HashSet
TreeSet
StringBuilder

但是还有一些是线程安全的. 使用了一些锁机制来控制.

Vector (不推荐使用)
HashTable (不推荐使用)
ConcurrentHashMap
StringBuffer

在这里插入图片描述
StringBuffer 的核心方法都带有 synchronized .

还有的虽然没有加锁, 但是不涉及 “修改”, 仍然是线程安全的

String

2.2volatile 关键字

volatile关键字在Java中用于确保多线程环境下的变量在不同线程之间的可见性。

在多线程环境中，每个线程都有自己的本地缓存，这样可以提高运行效率。然而，由于本地缓存与主内存之间的同步延迟，当一个线程修改了变量的值时，其他线程可能无法立即感知到这个修改，而继续读取本地缓存中的旧值。这就导致了内存可见性问题。

而volatile关键字的作用就是解决这个问题。当一个变量被声明为volatile时，所有对该变量的读写操作都会直接同步到主内存中，这样其他线程就能够及时地看到最新的值。换句话说，volatile关键字可以防止指令重排序优化。

代码在写入 volatile 修饰的变量的时候,

改变线程工作内存中volatile变量副本的值
将改变后的副本的值从工作内存刷新到主内存

代码在读取 volatile 修饰的变量的时候,

从主内存中读取volatile变量的最新值到线程的工作内存中
从工作内存中读取volatile变量的副本

加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了.

注意：volatile关键字只能保证变量的可见性，并不能解决线程安全问题。如果多个线程同时修改一个变量的值，那么仍然会存在竞态条件和数据一致性问题。在这种情况下，需要使用synchronized关键字或其他线程安全的机制来保证数据的一致性。

下面是一个简单的示例，演示了volatile关键字的使用：

public class Worker implements Runnable {
    private volatile boolean isRunning = true;

    public void run() {
        while (isRunning) {
            // 业务逻辑
        }
    }

    public void stop() {
        isRunning = false;
    }
}

在上述代码中，isRunning变量被声明为volatile，所以当调用stop()方法时，其他线程能够立即看到isRunning变量的修改，从而终止循环并停止线程的执行。

volatile还有一个效果：禁止指令重排序

注意：

synchronized 既能保证原子性, 也能保证内存可见性.
volatile只能保证内存可见性，不能保证原子性

三：wait 和 notify

由于线程之间是抢占式执行的，因此线程之间执行的先后顺序难以预知，但是实际开发中有时候我们希望合理的协调多个线程之间的执行先后顺序。

完成这个协调工作, 主要涉及到这几个个方法

wait() / wait(long timeout): 让当前线程进入等待状态.
notify() / notifyAll(): 唤醒在当前对象上等待的线程.

注意: wait, notify, notifyAll 都是 Object 类的方法.

3.1 wait

对于Java中的wait，它是一个用于多线程同步的方法。下面是关于wait方法的解释：

wait使当前执行代码的线程进行等待，并将线程放入等待队列中。同时，wait方法会释放当前的锁，让其他线程有机会获得这个锁。
wait方法必须与synchronized关键字一起使用。如果在没有synchronized的代码块中使用wait方法，会直接抛出异常。
wait方法在满足以下条件之一时结束等待：
- 其他线程调用了该对象的notify方法，唤醒了等待线程。
- 等待时间超时。wait方法提供了一个带有timeout参数的版本，可以指定等待的时间。
- 其他线程调用了等待线程的interrupted方法，导致wait方法抛出InterruptedException异常。

wait方法必须在synchronized代码块或synchronized方法中使用的主要原因是它依赖于对象的监视器（也称为锁）。当一个线程调用wait方法时，它会释放持有的锁，然后进入等待状态，直到其他线程调用相同对象上的notify或notifyAll方法来唤醒它。

代码示例：

public static void main(String[] args) throws InterruptedException {
  Object object = new Object();
  synchronized (object) {
    System.out.println("等待中");
    object.wait();
    System.out.println("等待结束");
 }
}

这样在执行到object.wait()之后就一直等待下去，那么程序肯定不能一直这么等待下去了。这个时候就需要使用到了另外一个方法唤醒的方法notify()。

3.2 notify（）

notify 方法是唤醒等待的线程.

方法notify()也要在同步方法或同步块中调用，该方法是用来通知那些可能等待该对象的对象锁的其它线程，对其发出通知notify，并使它们重新获取该对象的对象锁。

如果有多个线程等待，则有线程调度器随机挑选出一个呈 wait 状态的线程。(并没有 “先来后到”)

以下是notify方法的详细解释：

notify方法是在Object类中定义的，它用于唤醒等待在同一对象上的某个线程。当线程调用wait方法在对象上等待时，它会释放对象的锁，并进入等待状态。
如果有其他线程调用了相同对象上的notify方法，那么其中的一个线程（无法确定具体是哪个线程）会被唤醒，并且开始竞争对象的锁。
notify方法只会唤醒一个等待线程。如果有多个线程在等待状态，不能确定哪个线程会被唤醒。
唤醒的线程然后可以继续执行，但是它需要重新获得对象的锁才能进入同步代码块或方法。
如果没有线程在等待该对象的锁，调用notify方法不会有任何影响。

下面是一个使用notify方法唤醒线程的简单Java代码示例：

class MyThread extends Thread {
    private final Object lock;

    public MyThread(Object lock) {
        this.lock = lock;
    }

    public void run() {
        synchronized (lock) {
            System.out.println("线程开始等待");
            try {
                lock.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("线程被唤醒");
        }
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Object lock = new Object();
        MyThread thread = new MyThread(lock);

        synchronized (lock) {
            thread.start();
            Thread.sleep(2000); // 主线程休眠2秒钟，模拟执行一些其他操作

            System.out.println("主线程执行notify操作");
            lock.notify();
        }
    }
}

在上面的示例中，我们创建了一个MyThread类继承自Thread类，该线程在synchronized块中调用wait方法进行等待。在主线程中，我们先让主线程休眠2秒钟，然后调用notify方法来唤醒等待的线程。

当运行该程序时，它会输出以下内容：

线程开始等待
主线程执行notify操作
线程被唤醒

请注意，在使用notify方法前，需要通过synchronized关键字锁住共享对象。

notify方法只是唤醒某一个等待线程. 使用notifyAll方法可以一次唤醒所有的等待线程.

理解 notify 和 notifyAll：

notify 只唤醒等待队列中的一个线程. 其他线程还是乖乖等着

在这里插入图片描述

notifyAll 一下全都唤醒, 需要这些线程重新竞争锁

在这里插入图片描述

3.3 wait 和 sleep 的对比

他们的主要的区别在于：

wait方法是Object类的方法，用于线程之间的同步和通信，需要在同步块或同步方法中使用，调用时会释放锁，只能被唤醒或者中断才能继续执行；
sleep方法是Thread类的方法，用于线程的暂停一段指定时间，不会释放锁，只能通过时间结束或被中断才能继续执行。

两者的使用场景和目的也不同，需要根据具体需求来选择使用哪个方法。

ice___Cpu

关注

27
点赞
踩
28

收藏

觉得还不错? 一键收藏
打赏
22
评论
javaEE - 2（11000字详解多线程）

11000字详解多线程第二篇
复制链接

扫一扫

专栏目录

javaEE - 2（11000字详解多线程）

一：多线程带来的的风险-线程安全

1.1 组合1

1.2 组合2

1.3 原子性

1.4 可见性

1.5指令重排序

二：解决线程安全问题

2.1 synchronized关键字

2.1.1synchronized 的特性

2.2.2synchronized的锁对象

2.2.3 Java 标准库中的线程安全类

2.2volatile 关键字

三：wait 和 notify

3.1 wait

3.2 notify（）

3.3 wait 和 sleep 的对比

“相关推荐”对你有帮助么？