final和volatile在thread-safe中的作用

前言

final和volatile都是Java中的关键字,对于它们的使用有过一定的了解,但并不能完整掌握,最近在学习中发现了它们在多线程中保证线程安全时的使用,在此进行总结并理清它们的使用范围。博客原文地址final和volatile在thread-safe中的作用

常见用法

final的常规用法

final关键字可以用来修饰类、方法、属性,它在各自不同的位置中的含义是不同的。

  • 修饰类、方法时,表示该类不能被继承,该方法不能被重写(override)。
  • 修饰属性变量时,表示它为一个常量,一经初始化,便不可进行修改。

虽然上面分开来两条进行讲述,但其实究其根本,final关键字最根本的含义就是,它所修饰的“对象”(这里并不是指面向对象编程中的对象)都是不能进行“=”操作的,也就是说不能进行赋值操作,它是一个“final decision”,是一个最终的决定。

怎么理解呢?试想,我们用final来修饰classA,此时classA就不能被继承,是不是可以理解为classA这个“对象”不能进行其他的赋值操作,它已经确定了!那么此时的赋值操作赋的是什么值呢?内存地址。试想任何变量在JVM中都是需要指向一个地址,类的定义也是一样,因此如果类classA在定义是被final修饰,那么该类的地址就不能进行修改以指向另一个地址,如果地址不能修改,那么classA就只能指向JVM最开始加载该类时的地址,因此classA也就不能被继承了。同理,final修饰方法也是一样,该方法的引用地址不能进行修改,因此也就不能进行重写了。final修饰属性、变量时就更是如此了。

需要注意的是,final在修饰属性、变量时,如果它的类型是一个引用类,此时不能进行赋值指的是不能进行“=”将其指向另一个引用,但是其引用内部的值时可以改变的。如final修饰了 List, 则该list不能进行 = 操作,可以进行 add操作。

综上,final修饰的不能进行 “=” 操作。

volatile

volatile其实大家了解的已经够多了,用一句话来解释的话就是“volatile修饰的属性的读、写必须通过主内存”,这句话具体的理解可以通过下图进行。

如图所示,每个线程都有自己的“local storage”,对于主内存中的变量a的读写,线程都会先从主内存复制a的一份拷贝到线程本地内存中,之后的读写都是在本地内存中执行,因此,多个线程对同一个变量的读写就各自不可见,这就违反了thread-safe。

volatile通过强制变量的读写都在主内存进行,保证了多线程的thread-safe,如果volatile修饰了变量a,此时线程A和线程B对变量a的读写都是通过主内存进行的,因此,任一线程对a的修改都会对其他线程立即可见,就避免了多线程间变量值不一致的问题。

具体的原理是和内存屏障有关系,感兴趣的同学可以深入了解一下,浅析Java内存模型

两个关键字的常用用法已经进行了介绍,看起来似乎volatile才在thread-safe中起作用,那么final的作用是什么呢?

thread-safe用途

final关键字

上面介绍了final的常用用途,一句话概括就是“不可修改引用地址”,由于这个特性,使得final在修饰属性变量时可以达到一定程度的thread-safe。

假设我们有如下类:

1
2
3
4
5
6
7
8
public class MultiReadResource {
public final int id;
public final List list;
public MultiReadResource(int id, List list) {
this.id = id;
this.list = list;
}
}

该类是一个多线程读的资源,内部有两个公有属性:id和list,都是由final来进行修饰,它们的赋值通过唯一的构造函数来进行。如果我们在主线程中进行了MultiReadResource的一个对象obj的初始化,在子线程中threadA、threadB并发的读取,因此,如果一旦obj初始化了,则id, list 一定也有值。什么意思?就是说多线程对于obj的访问(access)是不需要任何额外同步措施,就可以原子访问的,线程读取obj要么为null,要么obj引用存在且id、list也存在,这是JVM做的保证。

原子访问的定义: 对于对象的访问要么为空,要么为最终状态,不能访问到中间状态,在此处的含义是,不存在obj的id有值,list为空的状态(除非obj初始化的时候list赋值为null)。

由此可知,如果一个类的属性在初始化后引用不会改变,我们可以简单的将其用final修饰,此时无须任何额外同步操作,JVM可以保证该属性并发访问的thread-safe。

volatile关键字

volatile与final相反,它修饰的为需要多线程修改的变量,如果一个属性变量被volatile修改,那么这意味着:

  • 该变量不能进行线程的本地缓存,任何的读写都是直接针对主内存的。
  • 对该变量的访问看起来就像是原子访问的一样,且读、写都是无锁的。

什么叫“看起来就像是原子访问”?我们可以借助事务来理解,事务的原子性是很重要的,单机事务中保证原子性的两大手段是:加锁和MVCC(多版本控制)(单机事务拾遗)。对于volatile变量,我们既没有加锁,又没有MVCC,因此,我们的原子访问也只是看起来像是了。具体请看下面的例子,假设我们有下面的类:

1
2
3
4
5
6
7
8
9
10
11
12
public class SingleField {
volatile int a;
public void add() {
a++;
}
public int get() {
return a;
}
public int set(int t) {
this.a = t;
}
}

对于上面定义的类来说,get、set方法都是原子的,但是add并不是,因为add方法具体分解为下面三步

1
2
3
4
5
public void add() {
int temp = a;
temp = temp + 1;
a = temp;
}

因此该方法可能存在两个线程调用后,只加了1个的情况,违反了原子性的要求(两个线程调用add,最终a应该+2)。要实现add方法的原子性可以通过两种手段:

使用AtomicIntegerFieldUpdater后的类定义如下:

1
2
3
4
5
6
7
8
9
public class SingleField {
private static final AtomicIntegerFieldUpdater<Record> ADDER =
AtomicIntegerFieldUpdater.newUpdater(SingleField.class, "a");
volatile int a;
public void add() {
ADDER.incrementAndGet(this);
}
// get、set方法省略
}

其本质上是使用了CAS原语。

synchronized本质上是加锁,其和volatile的使用区别如下:

/ synchronized volatile
变量类型 Object Object 或 基本类型(int,long)
允许null? no yes
是否阻塞? yes no
任何缓存变量访问同步? yes jdk5之后
同步何时发生? 进入/退出 synchronized 语法块 volatile变量被访问时
能够支持多步的原子操作(上面的add方法) yes jdk5之后可以通过Atomic 的 get、set来完成

需要注意的是,如果volatile修饰的是一个复合元素,如int[] array,此时,如果某个线程将array指向另一个数组的地址,则其他线程可以读取到该修改;但如果该线程执行了 array[3]=10, 其他线程不一定能获取到array[3],此时需要额外的同步方法。

总结

final和volatile都在多线程中有着自己的适用范围,我的简单的理解是:final可以用于常量(初始化之后,引用不被修改),volatile可以用于多个线程的并发读写。当然,这两个修饰符只能保证最低级别的线程安全,在高并发中,我们需要更多的手段(如锁、CAS)来处理复杂的场景。

参考资料