天增的博客
首页
博客
  • 分布式解决方案
  • Java并发工具包
  • redis
  • LeetCode
  • 系统设计
  • JVM体系
Github (opens new window)
Rss (opens new window)
  • zh-CN
  • en-US
首页
博客
  • 分布式解决方案
  • Java并发工具包
  • redis
  • LeetCode
  • 系统设计
  • JVM体系
Github (opens new window)
Rss (opens new window)
  • zh-CN
  • en-US
  • Java并发工具包
  • 并发基础
    • 线程基础
      • Thread的状态
      • 进程与线程
      • 正确停止线程的方式
      • Thread的实现方式
      • waitnotifynotifyAll
      • 生产者消费者模型
    • 线程安全
      • 线程不安全
      • 线程安全
        • 什么是线程安全问题
        • 为何会出现线程安全问题
        • 一共有哪三类线程安全问题
      • 需要注意线程安全问题的情况
  • 并发工具
    • 线程协作
      • Semaphore信号量
      • CountDownLatch详解
      • 使用CompletableFuture解决旅游平台问题
      • 使用CyclicBarrier解决团建问题
    • Future
      • Future主要功能
      • FutureTask源码分析
    • ThreadLocal
      • ThreadLocal内存泄漏
      • ThreadLocal使用场景
    • 原子类
      • 原子类的作用概览
      • 原子类的性能分析
    • 阻塞队列
      • 常见的阻塞队列
      • 阻塞队列的常用方法
      • 什么是阻塞队列
    • 并发容器
      • HashMap
      • CopyOnWriteArrayList
      • ConcurrentHashMap详解
    • 线程池
      • 为什么多线程会带来性能问题
      • 线程池的优势
      • 创建线程池的参数
        • 如何设置线程数
      • 线程池线程复用原理
      • ForkJoin框架
    • 各种锁
      • 锁的种类和特点
        • 公平锁非公平锁
        • 自旋锁非自旋锁
        • 共享锁独占锁
        • 乐观锁和悲观锁
      • JVM锁优化
      • synchronized和Lock的对比
      • lock的常用方法
  • 底层原理
    • CAS原理
    • AQS框架
    • 伪共享
    • java内存模型
      • Java内存模型介绍
      • happens-before规则
  • topic
  • Java并发工具包
  • 并发基础
  • 线程安全
  • 线程安全
2022-04-21
目录

线程安全

# 线程安全

# 什么是线程安全问题

我们要先了解什么是线程安全,才可以在工作中尽量避免使用线程不安全的代码。

虽然线程安全经常被提及,但是对于线程安全并没有一个明确的定义。

在《Java Concurrency In Practice》这种书中,作者Brian Goetz 对线程安全是这样理解的

当多线程访问一个对象的时候,如果不用考虑在多线程下的调度和交替执行的问题,也不需要进行额外的同步,而调用这个对象的结果都可以获得正确的结果,那这个线程就是安全的。

如果某个对象是线程安全的,那个对于使用者来说,在使用时就不用考虑方法间的协调,比如不用考虑读写和写入不能不行的问题,也不用考虑任何额外的同步问题。

# 为何会出现线程安全问题

众所周知,CPU、内存、I/O 设备的速度是有极大差异的,为了合理利用 CPU 的高性能,平衡这三者的速度差异,计算机体系结构、操作系统、编译程序都做出了贡献,主要体现为:

  • CPU 增加了缓存,以均衡与内存的速度差异;// 导致 可见性问题
  • 操作系统增加了进程、线程,以分时复用 CPU,进而均衡 CPU 与 I/O 设备的速度差异;// 导致 原子性问题
  • 编译程序优化指令执行次序,使得缓存能够得到更加合理地利用。// 导致 有序性问题

# 可见性: CPU缓存引起

可见性:一个线程对共享变量的修改,另外一个线程能够立刻看到。

//线程1执行的代码
int i = 0;
i = 10;
 
//线程2执行的代码
int j = i;

假若执行线程1的是CPU1,执行线程2的是CPU2。由上面的分析可知,当线程1执行 i =10这句时,会先把i的初始值加载到CPU1的高速缓存中,然后赋值为10,那么在CPU1的高速缓存当中i的值变为10了,却没有立即写入到主存当中。

此时线程2执行 j = i,它会先去主存读取i的值并加载到CPU2的缓存当中,注意此时内存当中i的值还是0,那么就会使得j的值为0,而不是10.

这就是可见性问题,线程1对变量i修改了之后,线程2没有立即看到线程1修改的值。

# 原子性: 分时复用引起

原子性:即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断,要么就都不执行。

在现代操作系统中,CPU都是分时间片运行的,多个程序在cpu中以一段时间间隔内进行轮转。

每个程序依次执行一段时间。宏观上所有程序同时执行,其实内部还是每时处理一个程序。在程序执行到一半就切换到下一个程序了,就会造成原子性问题。

经典的转账问题:比如从账户A向账户B转1000元,那么必然包括2个操作:从账户A减去1000元,往账户B加上1000元。

试想一下,如果这2个操作不具备原子性,会造成什么样的后果。假如从账户A减去1000元之后,操作突然中止。然后又从B取出了500元,取出500元之后,再执行 往账户B加上1000元 的操作。这样就会导致账户A虽然减去了1000元,但是账户B没有收到这个转过来的1000元。

所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。

# 有序性: 重排序引起

有序性:即程序执行的顺序按照代码的先后顺序执行。

在执行程序时为了提高性能,编译器和处理器常常会对指令做重排序。重排序分三种类型:

  • 编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。
  • 指令级并行的重排序。现代处理器采用了指令级并行技术(Instruction-Level Parallelism, ILP)来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。
  • 内存系统的重排序。由于处理器使用缓存和读 / 写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。
int i = 0;              
boolean flag = false;
i = 1;                //语句1  
flag = true;          //语句2

上面代码定义了一个int型变量,定义了一个boolean类型变量,然后分别对两个变量进行赋值操作。从代码顺序上看,语句1是在语句2前面的,那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗? 不一定,为什么呢? 这里可能会发生指令重排序(Instruction Reorder)。

从 java 源代码到最终实际执行的指令序列,会分别经历下面三种重排序:

img

上述的 1 属于编译器重排序,2 和 3 属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器,JMM 的编译器重排序规则会禁止特定类型的编译器重排序(不是所有的编译器重排序都要禁止)。对于处理器重排序,JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时,插入特定类型的内存屏障(memory barriers,intel 称之为 memory fence)指令,通过内存屏障指令来禁止特定类型的处理器重排序(不是所有的处理器重排序都要禁止)。

# 一共有哪三类线程安全问题

# 运行结果错误

首先,来看一个经典的例子,正常情况下结果应该在20000,但是运行结束之后会远小于20000

	public class Test{
    public static int i = 0;

    public static void main(String[] args) throws InterruptedException {
        Runnable r = new Runnable() {

            @Override
            public void run() {
                for (int j = 0; j < 10000; j++) {
                    i++;
                }
            }
        };
        Thread t1 = new Thread(r);
        t1.start();
        Thread t2 = new Thread(r);
        t2.start();
        t1.join();
        t2.join();
        System.out.println(r);
    }
  }

由于i++不是一个原子操作,分为3步

  • 第一个步骤是读取;
  • 第二个步骤是增加;
  • 第三个步骤是保存。

又因为CPU执行的过程中,是分时间片执行的

  1. 在线程1的时候在增加完之后没有保存,
  2. 切换到线程2的,线程2读取到的是0
  3. 线程2执行增加并保存,此时 i = 1
  4. 线程1执行保存,i = 1
  5. 进行一次循环之后,依然等于1

# 发布和初始化导致线程安全问题

我们创建对象并发布和初始化供其他的类或者对象使用是很常见的操作,如果类初始化的时机不对就有可能导致线程安全问题。

下面这段代码演示了,在构造函数中使用线程,在创建对象的时候,会调用线程对students进行初始化操作,然后在获取students的时候,将就会导致报错,原因是在主线程执行到get方法的时候,子线程可能还没有启动

public class WrongInit {
  
  private Map<Integer,String> students;
  
  public WrongInit(){
    new Thread(()->{
      students = new Map<Integer,String>();
      students.put(1,"小红");
      students.put(2,"小绿");
      students.put(3,"小蓝");
    }).start();
  }
  
  public static void main(String[] args){
    WrongInit wrongInit = new WrongInit();
    System.out.println(wrongInit.students.get(1));
  }
}

# 活跃性问题

活跃性问题,典型情况有三种。死锁、活锁、饥饿

# 死锁

死锁的典型场景就是,两个线程都等着互相释放锁。

public class TestLock{
  private static Object o1 = null;
  private static Object o2 = null;
  public static void main(String[] args){
     new Thread(()->{
       synchronized(o1){
          synchronized(o2){
             System.out.println("线程1拿到2把锁");
          }
       }
     }).start();
    
    new Thread(()->{
       synchronized(o2){
          synchronized(o1){
             System.out.println("线程2拿到2把锁");
          }
       }
     }).start();
  }
}
# 产生死锁的原因主要是:

(1) 因为系统资源不足。

(2) 进程运行推进的顺序不合适。

(3) 资源分配不当等。

如果系统资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则

就会因争夺有限的资源而陷入死锁。其次,进程运行推进顺序与速度不同,也可能产生死锁。

# 产生死锁的四个必要条件:

(1) 互斥条件:一个资源每次只能被一个进程使用。

(2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。

(3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。

(4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之

一不满足,就不会发生死锁。

# 死锁的解除与预防:

理解了死锁的原因,尤其是产生死锁的四个必要条件,就可以最大可能地避免、预防和

解除死锁。所以,在系统设计、进程调度等方面注意如何不让这四个必要条件成立,如何确

定资源的合理分配算法,避免进程永久占据系统资源。此外,也要防止进程在处于等待状态

的情况下占用资源。因此,对资源的分配要给予合理的规划。

# 活锁

假设有一个消息队列,里面放着各种各样的消息,这个时候有一个消息自身写错了导致订阅失败,无法正确的被处理,这个时候重试队列会把这个消息放到队列的第一个,然后无限重复。就造成后续的消息无法成功的被处理。

# 饥饿

java中的线程有优先级的概念,从1~10。默认为5,最高10,最低1.如果一个线程被设置为1,那就有可能永远没有办法被调度。也就形成了饥饿。

最近更新
01
以 root 身份启动 transmission-daemon
12-13
02
Debian系统安装qbittorrent-nox
12-09
03
LXC Debain12安装zerotier并实现局域网自动nat转发
07-29
更多文章>
Theme by Vdoing | Copyright © 2015-2024 天增 | 苏ICP备16037388号-1
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式