Java下如何保证多线程安全

95 篇文章 1 订阅
43 篇文章 0 订阅
前言

        可能有人会觉得,只要我写代码的时候不去开启其他线程,那么就不会有多线程的问题了。

        然而事实并非如此,如果仅仅是一些简单的测试代码,确实代码都会顺序执行而不是并发执行,但是Java应用最广泛的web项目中,绝大部分(如果不是所有的话)web容器都是多线程的——以tomcat为例, 每一个进来的请求都需要一个线程,直到该请求结束。 这样一来,即使本身不打算多线程运行的代码,实际上几乎都会以多线程的方式执行。

        在 Spring 注册的 bean(默认都是单例),在设为单例的 bean 中出现的成员变量或静态变量,都必须注意是否存在多线程竞争导致的多线程不安全的问题。

        ——可见,有些时候确实都是人在江湖,身不由己。积累多线程的知识是必不可少的。

1.为什么会有多线程不安全的问题

1.1.写不安全

        上面讲到 web 容器会多线程访问 JVM,这里还有一个问题,为什么多线程时就会存在多线程不安全呢?这是因为在 JVM 中的内存管理,并不是所有内存都是线程私有的,Heap(Java堆)中的内存是线程共享的。

        而 Heap 中主要是存放对象的,这样多个线程访问同一个对象时,就会使用到同一块内存了,在这块内存中存着的成员变量就会受到多个线程的操作。

如下图所示:

图片

因为是增加2和3,结果应该是15才对,但是因为多线程的原因,导致结果是12或13。

1.2.读不安全

        上面的写操作不安全是一方面,事实上 Java 中还存在更加糟糕的问题,就是读到的数据也不一致。

        因为多个线程虽然访问对象时是使用的同一块内存(这块内存可称为主内存),但是为了提高效率,每个线程有时会都会将读取到的值缓存在本线程内(具体因不同 JVM 的实现逻辑而有不同,所以缓存不是必然的),这些缓存的数据可称为副本数据。

        这样,就会出现,某个值已经被某个线程更改了,但是其他线程却不知道,也不去主内存更新数据的情况。

如下图所示:

上图的情况,其实线程的并发度相对要低一点,但即使是其他线程更改的数据,有的线程也不知道,因为读不安全导致了数据不一致。

2.如何让多线程安全

        既然已经知道了会发生不安全的问题,那么要怎么解决这些问题呢?

2.1.读一致性

        Java 中针对上述“读不安全”的问题提供了关键字 volatile 来解决问题,被 volatile 修饰的成员变量,在内容发生更改的时候,会通知所有线程去主内存更新最新的值,这样就解决了读不安全的问题,实现了读一致性。

        但是,读一致性是无法解决写一致性的,虽然能够使得每个线程都能及时获取到最新的值,但是1.1中的写一致性问题还是会存在。

        既然如此,Java 为啥还要提供 volatile 关键字呢?这并非多余的存在,在某些场景下只需要读一致性的话,这个关键字就能够满足需求而且性能相对还不错,因为其他的能够保证“读写”都一直的办法,多多少少存在一些牺牲。

2.2.写一致性

        Java 提供了三种方式来保证读写一致性,分别是互斥锁、自旋锁、线程隔离。

2.2.1.互斥锁

        互斥锁只是一个锁概念,在其他场景也叫做独占锁、悲观锁等,其实就是一个意思。它是指线程之间是互斥的,某一个线程获取了某个资源的锁,那么其他线程就只能睡眠等待。

        在 Java 中互斥锁的实现一般叫做同步线程锁,关键字 synchronized,它锁住的范围是它修饰的作用域,锁住的对象是: 当前对象(对象锁) 或 类的全部对象(类锁) ——锁释放前,其他线程必将阻塞,保证锁住范围内的操作是原子性的,而且读取的数据不存在一致性问题。

  • 对象锁:当它修饰方法、代码块时,将会锁住当前对象

  • 类锁:修饰类、静态方法时,则是锁住类的所有对象

注意: 锁住的永远是对象,锁住的范围永远是 synchronized 关键字后面的花括号划定的代码域。

2.2.2.自旋锁

        自旋锁也只是一个锁概念,在其他场景也叫做乐观锁等。

        自旋锁本质上是不加锁,而是通过对比旧数据来决定是否更新:

图片

        如上所示,不管线程1与线程2哪个先执行,哪个后执行,结果都会是15,由此实现了读写一致性。而因为步骤3的更新失败而在步骤4中更新数据后再此尝试更新的过程,就叫做自旋——自旋只是个概念:表示 操作失败后,线程会循环进行上一步的操作,直到成功为止。

        这种方式避免了线程的上下文切换以及线程互斥等,相对于互斥锁而言,它允许并发的存在(互斥锁不存在并发,只能同步进行)。

        在 Java 的 java.util.concurrent.atomic 包 中提供了自旋的操作类,诸如 AtomicInteger、AtomicLong 等,都能够达到此目的。

图片

  1. 上面代码中的18行的代码,直接对一个int变量++操作,这是多线程不安全的

  2. 其中注释掉的19、20、21行代码则是加上了同步线程锁的写法,同步的操作使得多线程安全

  3. 下面的25行代码则是基于自旋锁的操作,也是多线程安全的

        但是,如果并发度很高的话,就会导致某些线程一直都无法更新成功(因为一直有其他线程更改了值),会使得线程长时间占用CPU和线程。所以自旋锁是属于低并发的解决方案。

        另外,直接使用这些自旋的操作类还是太过原始,所以Java还在这个基础上封装了一些类,能够简单直接地接近于 synchronized 那么方便地对某段代码上锁,即是 ReentrantLock 以及 ReentrantReadWriteLock,限于篇幅,这里不详细介绍他们的使用。

2.2.3.线程隔离

        既然自旋锁只是低并发的解决方案,那么遇到高并发要如何处理呢?答案是将成员变量设成线程隔离的,也就是说每个线程都各自使用自己的变量,互相自己是不相关的。这样自然也做到了多线程安全。但是这种做法是让所有线程都互相隔离的了,所以他们之间是不存在互相操作的。

        在 Java 中提供了 ThreadLocal 类来实现这种效果:

// 声明线程隔离的变量,变量类型通过泛型决定
private static ThreadLocal<Integer> localInt = new ThreadLocal<>();

// 获取泛型类的对象
Integer integer = localInt.get();

if (integer==null){
    integer = 0;
}

// 将泛型对象设到变量中
localInt.set(++integer);

总结

        本文主要讲了为什么会出现多线程不安全的原因,其中涉及读不安全与写不安全。Java 使用 volatile 关键字实现了读一致性,使用同步线程锁(synchronized)、自旋操作类(AtomicInteger等 )以及线程隔离类(ThreadLocal )来实现了写一致性,这三种方法中,同步线程锁效率最低,自旋操作类在非高并发的场景可大大提高效率,但是要想实现真正的高并发,还是需要用到线程隔离类来实现。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值