Java基础-关键字Part1

西红柿炒蛋丶
118 阅读11分钟

1 volatile

1.1 简介

volatile是Java中用于修饰变量的关键字，其可以保证该变量的可见性以及顺序性，但是无法保证原子性。更准确地说是volatile关键字只能保证单操作的原子性， 比如x=1 ，但是无法保证复合操作的原子性，比如x++

其为Java提供了一种轻量级的同步机制：保证被volatile修饰的共享变量对所有线程总是可见的，也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。相比于synchronized关键字（synchronized通常称为重量级锁），volatile更轻量级，开销低，因为它不会引起线程上下文的切换和调度。

1.2 保证可见性

可见性：是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看到修改的值。示例代码如下：

public class VisibilityTest {
    private boolean flag = true;
​
    public void change() {
        flag = false;
        System.out.println(Thread.currentThread().getName() + "，已修改flag=false");
    }
​
    public void load() {
        System.out.println(Thread.currentThread().getName() + "，开始执行.....");
        int i = 0;
        while (flag) {
            i++;
        }
        System.out.println(Thread.currentThread().getName() + ",结束循环");
    }
​
    public static void main(String[] args) throws InterruptedException {
        VisibilityTest test = new VisibilityTest();
​
        // 线程threadA模拟数据加载场景
        Thread threadA = new Thread(() -> test.load(), "threadA");
        threadA.start();
​
        // 让threadA执行一会儿
        Thread.sleep(1000);
        // 线程threadB 修改 共享变量flag
        Thread threadB = new Thread(() -> test.change(), "threadB");
        threadB.start();
​
    }
}

其中Java中的volatile关键字提供了一个功能：那就是被volatile修饰的变量P被修改后，JMM会把该线程本地内存中的这个变量P，立即强制刷新到主内存中去，导致其他线程中的volatile变量P缓存无效，也就是说其他线程使用volatile变量P在时，都是从主内存刷新的最新数据。而普通变量的值在线程间传递的时候一般是通过主内存以共享内存的方式实现的；

因此，可以使用volatile来保证多线程操作时变量的可见性。除了volatile，Java中的synchronized和final两个关键字 以及各种Lock也可以实现可见性。加锁的话， 当一个线程进入 synchronized代码块后，线程获取到锁，会清空本地内存，然后从主内存中拷贝共享变量的最新值到本地内存作为副本，执行代码，又将修改后的副本值刷新到主内存中，最后线程释放锁。

1.3 保证有序性

1.3.1 简介

有序性，顾名思义即程序执行的顺序按照代码的先后顺序执行。但现代的计算机中CPU中为了能够让指令的执行尽可能地同时运行起来，提示计算机性能，采用了指令流水线。一个 CPU 指令的执行过程可以分成 4 个阶段：取指、译码、执行、写回。这 4 个阶段分别由 4 个独立物理执行单元来完成。

理想的情况是：指令之间无依赖，可以使流水线的并行度最大化 但是如果两条指令的前后存在依赖关系，比如数据依赖，控制依赖等，此时后一条语句就必需等到前一条指令完成后，才能开始。所以CPU为了提高流水线的运行效率，对无依赖的前后指令做适当的乱序和调度，即现代的计算机中CPU是乱序执行指令的

另一方面，只要不会改变程序的运行结果，Java编译器是可以通过指令重排来优化性能。然而，重排可能会影响本地处理器缓存与主内存交互的方式，可能导致在多线程的情况下发生"细微"的BUG。指令重排对于非原子性的操作，在不影响最终结果的情况下，其拆分成的原子操作可能会被重新排列执行顺序,提升性能。指令重排不会影响单线程的执行结果，但是会影响多线程并发执行的结果正确性。

1.4 原子性

所谓原子性：即一个或者多个操作作为一个整体，要么全部执行，要么都不执行，并且操作在执行过程中不会被线程调度机制打断；而且这种操作一旦开始，就一直运行到结束，中间不会有任何上下文切换（context switch）。

volatile关键字无法保证原子性 ，更准确地说是volatile关键字只能保证单操作的原子性， 比如x=1 ，但是无法保证复合操作的原子性，比如x++

2 final

2.1 简介

final可以修饰变量，方法和类，用于表示所修饰的内容一旦赋值之后就不会再被改变，比如String类就是一个final类型的类

image.png

2.2 修饰变量

数据类型

  • 基本类型，一旦被赋值，该值不能被改变。
  • 引用类型，一旦引用被初始化指向一个对象，就不能指向别的对象，但对象内容可以被修改

成员变量

通常每个类中的成员变量可以分为类变量（static修饰的变量）以及实例变量。针对这两种类型的变量赋初值的时机是不同的。

  • 类变量可以在声明变量的时候直接赋初值或者在静态代码块中给类变量赋初值
  • 实例变量可以在声明变量的时候给实例变量赋初值，在非静态初始化块中以及构造器中赋初值。

类变量有两个时机赋初值，而实例变量则可以有三个时机赋初值。当final变量未初始化时系统不会进行隐式初始化，会出现报错。

局部变量

final局部变量由程序员进行显式初始化，如果final局部变量已经进行了初始化则后面就不能再次进行更改，如果final变量未进行初始化，可以进行赋值，当且仅有一次赋值，一旦赋值之后再次赋值就会出错。

2.3 修饰方法

使用final方法的原因：确保在继承中使方法行为保持不变，并且不会被覆盖（设计考虑）。

  • final修饰的方法不可以重写（重写发生在父类与之类）
  • final修饰的方法可以重载（同一个类）

类中所有的private方法都隐式地指定为final的。由于其它类无法取用private方法，因此无法覆盖它。可以对private方法添加final修饰，但没意义。

2.4 修饰类

当类定义为final时，表示该类不可继承。
final类的所有方法都是隐式为final，因为无法覆盖它们

2.5 重排序

2.5.1 基本数据类型

案例代码：假设线程A在执行writer()方法，线程B执行reader()方法。 image.png

写final域重排序

写final域的重排序规则禁止对final域的写重排序到构造函数之外，这个规则的实现主要包含了两个方面：

  • JMM(Java Memory Model)禁止编译器把final域的写重排序到构造函数之外；
  • 编译器会在final域写之后，构造函数return之前，插入一个storestore屏障（关于内存屏障可以看这篇文章）。这个屏障可以禁止处理器把final域的写重排序到构造函数之外。

我们再来分析writer方法，虽然只有一行代码，但实际上做了两件事情：

  • 构造了一个FinalDemo对象；
  • 把这个对象赋值给成员变量finalDemo
image.png

由于a,b之间没有数据依赖性，普通域（普通变量）a可能会被重排序到构造函数之外，线程B就有可能读到的是普通变量a初始化之前的值（零值），这样就可能出现错误。而final域变量b，根据重排序规则，会禁止final修饰的变量b重排序到构造函数之外，从而b能够正确赋值，线程B就能够读到final变量初始化后的值。因此，写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域就不具有这个保障。比如在上例，线程B有可能就是一个未正确初始化的对象finalDemo。

读final域重排序规则

读final域重排序规则为：在一个线程中，初次读对象引用和初次读该对象包含的final域，JMM会禁止这两个操作的重排序。 （注意，这个规则仅仅是针对处理器），处理器会在读final域操作的前面插入一个LoadLoad屏障。实际上，读对象的引用和读该对象的final域存在间接依赖性，一般处理器不会重排序这两个操作。但是有一些处理器会重排序，因此，这条禁止重排序规则就是针对这些处理器而设定的。

read()方法主要包含了三个操作：

  • 初次读引用变量finalDemo;
  • 初次读引用变量finalDemo的普通域a;
  • 初次读引用变量finalDemo的final与b;

假设线程A写过程没有重排序，那么线程A和线程B有一种的可能执行时序为下图：

image.png

读对象的普通域被重排序到了读对象引用的前面就会出现线程B还未读到对象引用就在读取该对象的普通域变量，这显然是错误的操作。而final域的读操作就“限定”了在读final域变量前已经读到了该对象的引用，从而就可以避免这种情况。读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读这个包含这个final域的对象的引用。

2.5.2 引用数据类型

对final修饰对象的成员域写操作

针对引用数据类型，final域写针对编译器和处理器重排序增加****了这样的约束：在构造函数内对一个final修饰的对象的成员域的写入，与随后在构造函数之外把这个被构造的对象的引用赋给一个引用变量，这两个操作是不能被重排序的。注意这里的是“增加”也就说前面对final基本数据类型的重排序规则在这里还是使用。这句话是比较拗口的，下面结合实例来看。

image.png

针对上面的实例程序，线程线程A执行wirterOne方法，执行完后线程B执行writerTwo方法，然后线程C执行reader方法。下图就以这种执行时序出现的一种情况来讨论

image.png

由于对final域的写禁止重排序到构造方法外，因此1和3不能被重排序。由于一个final域的引用对象的成员域写入不能与随后将这个被构造出来的对象赋给引用变量重排序，因此2和3不能重排序。

对finla修饰对象的成员域读操作

JMM可以确保线程C至少能看到写线程A对final引用的对象的成员域的写入，即能看下arrays[0] = 1，而写线程B对数组元素的写入可能看到可能看不到。JMM不保证线程B的写入对线程C可见，线程B和线程C之间存在数据竞争，此时的结果是不可预知的。如果可见的，可使用锁或者volatile。

重排序总结

按照final修饰的数据类型分类：

  • 基本数据类型

    • final域写：禁止final域写与构造方法重排序，即禁止final域写重排序到构造方法之外，从而保证该对象对所有线程可见时，该对象的final域全部已经初始化过。
    • final域读：禁止初次读对象的引用与读该对象包含的final域的重排序。

  • 引用数据类型

    • 额外增加约束：禁止在构造函数对一个final修饰的对象的成员域的写入与随后将这个被构造的对象的引用赋值给引用变量 重排序

2.6 逸出

对final域写重排序规则可以确保我们在使用一个对象引用的时候该对象的final域已经在构造函数被初始化过了。但是这里其实是有一个前提条件的，也就是：在构造函数，不能让这个被构造的对象被其他线程可见，也就是说该对象引用不能在构造函数中“逸出” 。以下面的例子来说：

image.png

可能执行的时序图：

image.png

假设一个线程A执行writer方法另一个线程执行reader方法。因为构造函数中操作1和2之间没有数据依赖性，1和2可以重排序，先执行了2，这个时候引用对象referenceDemo是个没有完全初始化的对象，而当线程B去读取该对象时就会出错。尽管依然满足了final域写重排序规则：在引用对象对所有线程可见时，其final域已经完全初始化成功。但是，引用对象“this”逸出，该代码依然存在线程安全的问题。

avatar
文章
阅读
粉丝