前言
final和volatile都是Java中的关键字，对于它们的使用有过一定的了解，但并不能完整掌握，最近在学习中发现了它们在多线程中保证线程安全时的使用，在此进行总结并理清它们的使用范围。
常见用法
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。
假设我们有如下类：
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，因此，我们的原子访问也只是看起来像是了。具体请看下面的例子，假设我们有下面的类：
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方法具体分解为下面三步
public void add() {
int temp = a;
temp = temp + 1;
a = temp;
}因此该方法可能存在两个线程调用后，只加了1个的情况，违反了原子性的要求（两个线程调用add，最终a应该+2）。要实现add方法的原子性可以通过两种手段：
- 用synchronized修饰add方法，相当于给方法加了锁
- 使用Atomic update工具类，具体可以参考AtomicXFieldUpdater，属性原子修改的外部工具类
使用AtomicIntegerFieldUpdater后的类定义如下：
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来完成 |
总结
final和volatile都在多线程中有着自己的适用范围，我的简单的理解是：final可以用于常量（初始化之后，引用不被修改），volatile可以用于多个线程的并发读写。当然，这两个修饰符只能保证最低级别的线程安全，在高并发中，我们需要更多的手段（如锁、CAS）来处理复杂的场景。