1.2Java内存模型——原子性、内存可见性、重排序、顺序一致性、volatile、锁、final_可见性原子性一致性内存

转载自：https://blog.csdn.net/qq_31997407/article/details/79705767

 

一、原子性

原子性操作指相应的操作是单一不可分割的操作。例如，对int变量count执行count++d操作就不是原子性操作。因为count++实际上可以分解为3个操作：（1）读取变量count的当前值；（2）拿count的当前值和1做加法运算；（3）将加完后的值赋给count变量。

在多线程环境中，非原子操作可能会受其他线程的干扰。比如，上述例子如果没有对相应的代码进行同步（Synchronization）处理，则可能出现在执行第2个操作的时候，count变量的值已经被其他线程修改过了。当然，synchronized关键字可以帮助我们实现原子性操作，以避免这种线程间的干扰情况。

synchronized关键字可以实现操作的原子性，其实质是：通过该关键字所包括的临界区（Critical Section）的排他性保证在任何一个时刻只有一个线程能够执行临界区中的代码，这使得临界区中的代码代表了一个原子操作。这一点，大家基本都很清楚。但是，synchronized关键字所起到的另一个作用——保证内存的可见性（Memory Visibility），也是我们值得回顾的地方。

二、内存可见性

  CPU在执行代码的时候，为了减少变量访问的时间消耗可能将代码中访问的变量的值缓存到该CPU缓存区中，因此，相应的代码再次访问该变量的时候，相应的值可能从CPU缓存中而不是主内存中读取的。同样的，代码对这些被缓存过的变量的值的修改也可能仅是被写入CPU缓存区，而没有写入主内存。由于每个CPU都有自己的缓存区，因此一个CPU缓存区中的内容对于其他CPU而言是不可见的。这就导致了在其他CPU上运行的其他线程可能无法“看到”该线程对某个变量值的更改。这就是所谓的内存可见性。

synchronized关键字的另一个作用就是保证了一个线程执行临界区中的代码时，所修改的变量值对于稍后执行该临界区的线程来说是可见的。这对于保证多线程代码的正确性来说非常重要。

而volatile关键字也能够保证内存可见性。即一个线程对一个采用volatile关键字修饰的变量的值的更改，对于其他访问该变量的线程而言总是可见的。也就是说，其他线程不会读到一个“过期”的变量值。因此，有人将volatile关键字和synchronized关键字所代表的内部锁做比较，将其称为轻量级的锁。这种称呼其实并不恰当，volatile关键字只能保证内存可见性，它并不能像synchronized关键字所代表的内部锁那样能够保证操作的原子性。volatile关键字实现内存可见性的核心机制是：当一个线程修改了一个volatile修饰的变量的值时，该值会被写入主内存（即RAM）而不仅仅是当前线程所在的CPU的缓存区，而其他CPU的缓存区中存储的该变量的值也会因此而失效（从而得以更新为主内存中该变量的“新值”）。这就保证了其他线程访问该volatile修饰的变量时，总是可以获取到该变量的最新值。

三、指令重排序

volatile关键字的另一个作用是：它禁止了指令重排序（Re-order）。编译器和CPU为了提高指令的执行效率可能会进行指令重排序，这使得代码的实际执行方式可能不是按照我们所认为的方式进行。例如下面的实例变量初始化语句：

private SomeClass someObject = new SomeClass();

上述语句非常简单：（1）创建类SomeClass 的实例；（2）将类SomeClass 的实例的引用赋给变量someObject 。但是由于指令的重排序作用，这段代码的实际执行顺序可能是：（1）分配一段用于存储SomeClass 实例的内存空间；（2）将对该内存空间的引用赋给变量someObject；（3）创建类SomeClass 的实例。因此，当其他线程访问someObject变量的值时，其得到的仅是指向一段存储SomeClass 实例的的内存空间的引用而已，而该内存空间相应的SomeClass 实例的初始化可能尚未完成，这就可能导致一些意想不到的结果。而禁止指令重排序则是可以使得上述代码按照我们所期望的顺序（正如代码所表达的顺序）来执行。

禁止指令重排序虽然导致编译器和CPU无法对一些指令进行可能的优化，但是它某种程度上让代码执行看起来更符合我们的期望。

Volatile、synchronized两者的区别联系

1.volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取；synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
2.volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的。
3.volatile仅能实现变量的修改可见性，不能保证原子性（线程A修改了变量还没结束时,另外的线程B可以看到已修改的值,而且可以修改这个变量,而不用等待A释放锁,因为Volatile 变量没上锁）；而synchronized则可以保证变量的修改可见性和原子性。
4.volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞和上下文切换。
5.volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化。

6.在使用volatile关键字时要慎重，并不是只要简单类型变量使用volatile修饰，对这个变量的所有操作都是原子操作。当变量的值由自身决定时，如n=n+1、n++ 等，volatile关键字将失效。只有当变量的值和自身无关时对该变量的操作才是原子级别的，如n = m + 1，这个就是原级别的。所以在使用volatile关键时一定要谨慎，如果自己没有把握，可以使用synchronized来代替volatile。

7.“锁是昂贵的”，谨慎使用锁机制。

四、顺序一致性

 

数据竞争与顺序一致性保证

当程序未正确同步时，就会存在数据竞争。java内存模型规范对数据竞争的定义如下：

• 在一个线程中写一个变量，
• 在另一个线程读同一个变量，
• 而且写和读没有通过同步来排序。

当代码中包含数据竞争时，程序的执行往往产生违反直觉的结果（前一章的示例正是如此）。如果一个多线程程序能正确同步，这个程序将是一个没有数据竞争的程序。

JMM对正确同步的多线程程序的内存一致性做了如下保证：

• 如果程序是正确同步的，程序的执行将具有顺序一致性（sequentially consistent）--即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同（马上我们将会看到，这对于程序员来说是一个极强的保证）。这里的同步是指广义上的同步，包括对常用同步原语（lock，volatile和final）的正确使用。

顺序一致性内存模型

顺序一致性内存模型是一个被计算机科学家理想化了的理论参考模型，它为程序员提供了极强的内存可见性保证。顺序一致性内存模型有两大特性：

• 一个线程中的所有操作必须按照程序的顺序来执行。
• （不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。

顺序一致性内存模型为程序员提供的视图如下：

在概念上，顺序一致性模型有一个单一的全局内存，这个内存通过一个左右摆动的开关可以连接到任意一个线程。同时，每一个线程必须按程序的顺序来执行内存读/写操作。从上图我们可以看出，在任意时间点最多只能有一个线程可以连接到内存。当多个线程并发执行时，图中的开关装置能把所有线程的所有内存读/写操作串行化。

为了更好的理解，下面我们通过两个示意图来对顺序一致性模型的特性做进一步的说明。

假设有两个线程A和B并发执行。其中A线程有三个操作，它们在程序中的顺序是：A1->A2->A3。B线程也有三个操作，它们在程序中的顺序是：B1->B2->B3。

假设这两个线程使用监视器来正确同步：A线程的三个操作执行后释放监视器，随后B线程获取同一个监视器。那么程序在顺序一致性模型中的执行效果将如下图所示：

现在我们再假设这两个线程没有做同步，下面是这个未同步程序在顺序一致性模型中的执行示意图：

未同步程序在顺序一致性模型中虽然整体执行顺序是无序的，但所有线程都只能看到一个一致的整体执行顺序。以上图为例，线程A和B看到的执行顺序都是：B1->A1->A2->B2->A3->B3。之所以能得到这个保证是因为顺序一致性内存模型中的每个操作必须立即对任意线程可见。

但是，在JMM中就没有这个保证。未同步程序在JMM中不但整体的执行顺序是无序的，而且所有线程看到的操作执行顺序也可能不一致。比如，在当前线程把写过的数据缓存在本地内存中，且还没有刷新到主内存之前，这个写操作仅对当前线程可见；从其他线程的角度来观察，会认为这个写操作根本还没有被当前线程执行。只有当前线程把本地内存中写过的数据刷新到主内存之后，这个写操作才能对其他线程可见。在这种情况下，当前线程和其它线程看到的操作执行顺序将不一致。

同步程序的顺序一致性效果

下面我们对前面的示例程序ReorderExample用监视器来同步，看看正确同步的程序如何具有顺序一致性。

请看下面的示例代码：

class SynchronizedExample {
int a = 0;
boolean flag = false;
 
public synchronized void writer() {
    a = 1;
    flag = true;
}
 
public synchronized void reader() {
    if (flag) {
        int i = a;
        ……
    }
}
}

上面示例代码中，假设A线程执行writer()方法后，B线程执行reader()方法。这是一个正确同步的多线程程序。根据JMM规范，该程序的执行结果将与该程序在顺序一致性模型中的执行结果相同。下面是该程序在两个内存模型中的执行时序对比图：

在顺序一致性模型中，所有操作完全按程序的顺序串行执行。而在JMM中，临界区内的代码可以重排序（但JMM不允许临界区内的代码“逸出”到临界区之外，那样会破坏监视器的语义）。JMM会在退出监视器和进入监视器这两个关键时间点做一些特别处理，使得线程在这两个时间点具有与顺序一致性模型相同的内存视图（具体细节后文会说明）。虽然线程A在临界区内做了重排序，但由于监视器的互斥执行的特性，这里的线程B根本无法“观察”到线程A在临界区内的重排序。这种重排序既提高了执行效率，又没有改变程序的执行结果。

从这里我们可以看到JMM在具体实现上的基本方针：在不改变（正确同步的）程序执行结果的前提下，尽可能的为编译器和处理器的优化打开方便之门。

未同步程序的执行特性

对于未同步或未正确同步的多线程程序，JMM只提供最小安全性：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，null，false），JMM保证线程读操作读取到的值不会无中生有（out of thin air）的冒出来。为了实现最小安全性，JVM在堆上分配对象时，首先会清零内存空间，然后才会在上面分配对象（JVM内部会同步这两个操作）。因此，在以清零的内存空间（pre-zeroed memory）分配对象时，域的默认初始化已经完成了。

JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行结果一致。因为未同步程序在顺序一致性模型中执行时，整体上是无序的，其执行结果无法预知。保证未同步程序在两个模型中的执行结果一致毫无意义。

和顺序一致性模型一样，未同步程序在JMM中的执行时，整体上也是无序的，其执行结果也无法预知。同时，未同步程序在这两个模型中的执行特性有下面几个差异：

1. 顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行（比如上面正确同步的多线程程序在临界区内的重排序）。这一点前面已经讲过了，这里就不再赘述。
2. 顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。这一点前面也已经讲过，这里就不再赘述。
3. JMM不保证对64位的long型和double型变量的读/写操作具有原子性，而顺序一致性模型保证对所有的内存读/写操作都具有原子性。

第3个差异与处理器总线的工作机制密切相关。在计算机中，数据通过总线在处理器和内存之间传递。每次处理器和内存之间的数据传递都是通过一系列步骤来完成的，这一系列步骤称之为总线事务（bus transaction）。总线事务包括读事务（read transaction）和写事务（write transaction）。读事务从内存传送数据到处理器，写事务从处理器传送数据到内存，每个事务会读/写内存中一个或多个物理上连续的字。这里的关键是，总线会同步试图并发使用总线的事务。在一个处理器执行总线事务期间，总线会禁止其它所有的处理器和I/O设备执行内存的读/写。下面让我们通过一个示意图来说明总线的工作机制：

如上图所示，假设处理器A，B和C同时向总线发起总线事务，这时总线仲裁（bus arbitration）会对竞争作出裁决，这里我们假设总线在仲裁后判定处理器A在竞争中获胜（总线仲裁会确保所有处理器都能公平的访问内存）。此时处理器A继续它的总线事务，而其它两个处理器则要等待处理器A的总线事务完成后才能开始再次执行内存访问。假设在处理器A执行总线事务期间（不管这个总线事务是读事务还是写事务），处理器D向总线发起了总线事务，此时处理器D的这个请求会被总线禁止。

总线的这些工作机制可以把所有处理器对内存的访问以串行化的方式来执行；在任意时间点，最多只能有一个处理器能访问内存。这个特性确保了单个总线事务之中的内存读/写操作具有原子性。

在一些32位的处理器上，如果要求对64位数据的读/写操作具有原子性，会有比较大的开销。为了照顾这种处理器，java语言规范鼓励但不强求JVM对64位的long型变量和double型变量的读/写具有原子性。当JVM在这种处理器上运行时，会把一个64位long/ double型变量的读/写操作拆分为两个32位的读/写操作来执行。这两个32位的读/写操作可能会被分配到不同的总线事务中执行，此时对这个64位变量的读/写将不具有原子性。

当单个内存操作不具有原子性，将可能会产生意想不到后果。请看下面示意图：

如上图所示，假设处理器A写一个long型变量，同时处理器B要读这个long型变量。处理器A中64位的写操作被拆分为两个32位的写操作，且这两个32位的写操作被分配到不同的写事务中执行。同时处理器B中64位的读操作被拆分为两个32位的读操作，且这两个32位的读操作被分配到同一个的读事务中执行。当处理器A和B按上图的时序来执行时，处理器B将看到仅仅被处理器A“写了一半“的无效值。

参考文献

1. JSR-133: Java Memory Model and Thread Specification
2. Shared memory consistency models: A tutorial
3. The JSR-133 Cookbook for Compiler Writers
4. 深入理解计算机系统（原书第2版）
5. UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers
6. The Java Language Specification, Third Edition

 

五、锁

六、final

 

        根据程序上下文环境，Java关键字final有“这是无法改变的”或者“终态的”含义，它可以修饰非抽象类、非抽象类成员方法和变量。你可能出于两种理解而需要阻止改变：设计或效率。

        final类不能被继承，没有子类，final类中的方法默认是final的。

        final方法不能被子类的方法覆盖，但可以被继承。

        final成员变量表示常量，只能被赋值一次，赋值后值不再改变。

        final不能用于修饰构造方法。

        注意：父类的private成员方法是不能被子类方法覆盖的，因此private类型的方法默认是final类型的。

1、final类

       

，默认都是final的。在设计类时候，如果这个类不需要有子类，类的实现细节不允许改变，并且确信这个类不会载被扩展，那么就设计为final类。

2、final方法

        如果一个类不允许其子类覆盖某个方法，则可以把这个方法声明为final方法。

        使用final方法的原因有二：

        第一、把方法锁定，防止任何继承类修改它的意义和实现。

        第二、高效。编译器在遇到调用final方法时候会转入内嵌机制，大大提高执行效率。

 例如：

3、final变量（常量）

        用final修饰的成员变量表示常量，值一旦给定就无法改变！

        final修饰的变量有三种：静态变量、实例变量和局部变量，分别表示三种类型的常量。

        从下面的例子中可以看出，一旦给final变量初值后，值就不能再改变了。

        另外，final变量定义的时候，可以先声明，而不给初值，这中变量也称为final空白，无论什么情况，编译器都确保空白final在使用之前必须被初始化。但是，final空白在final关键字final的使用上提供了更大的灵活性，为此，一个类中的final数据成员就可以实现依对象而有所不同，却有保持其恒定不变的特征。

 

 

二、static

 

        static表示“全局”或者“静态”的意思，用来修饰成员变量和成员方法，也可以形成静态static代码块，但是Java语言中没有全局变量的概念。

 

        被static修饰的成员变量和成员方法独立于该类的任何对象。也就是说，它不依赖类特定的实例，被类的所有实例共享。只要这个类被加载，Java虚拟机就能根据类名在运行时数据区的方法区内定找到他们。因此，static对象可以在它的任何对象创建之前访问，无需引用任何对象。

 

        用public修饰的static成员变量和成员方法本质是全局变量和全局方法，当声明它类的对象市，不生成static变量的副本，而是类的所有实例共享同一个static变量。

 

        static变量前可以有private修饰，表示这个变量可以在类的静态代码块中，或者类的其他静态成员方法中使用（当然也可以在非静态成员方法中使用--废话），但是不能在其他类中通过类名来直接引用，这一点很重要。实际上你需要搞明白，private是访问权限限定，static表示不要实例化就可以使用，这样就容易理解多了。static前面加上其它访问权限关键字的效果也以此类推。

 

        static修饰的成员变量和成员方法习惯上称为静态变量和静态方法，可以直接通过类名来访问，访问语法为：

类名.静态方法名(参数列表...) 

类名.静态变量名

        用static修饰的代码块表示静态代码块，当Java虚拟机（JVM）加载类时，就会执行该代码块（用处非常大，呵呵）。

 

1、static变量

        按照是否静态的对类成员变量进行分类可分两种：一种是被static修饰的变量，叫静态变量或类变量；另一种是没有被static修饰的变量，叫实例变量。两者的区别是：

        对于静态变量在内存中只有一个拷贝（节省内存），JVM只为静态分配一次内存，在加载类的过程中完成静态变量的内存分配，可用类名直接访问（方便），当然也可以通过对象来访问（但是这是不推荐的）。

        对于实例变量，没创建一个实例，就会为实例变量分配一次内存，实例变量可以在内存中有多个拷贝，互不影响（灵活）。

 

2、静态方法

        静态方法可以直接通过类名调用，任何的实例也都可以调用，因此静态方法中不能用this和super关键字，不能直接访问所属类的实例变量和实例方法(就是不带static的成员变量和成员成员方法)，只能访问所属类的静态成员变量和成员方法。因为实例成员与特定的对象关联！这个需要去理解，想明白其中的道理，不是记忆！！！

        因为static方法独立于任何实例，因此static方法必须被实现，而不能是抽象的abstract。

 

3、static代码块

        static代码块也叫静态代码块，是在类中独立于类成员的static语句块，可以有多个，位置可以随便放，它不在任何的方法体内，JVM加载类时会执行这些静态的代码块，如果static代码块有多个，JVM将按照它们在类中出现的先后顺序依次执行它们，每个代码块只会被执行一次。例如：

 

        利用静态代码块可以对一些static变量进行赋值，最后再看一眼这些例子，都一个static的main方法，这样JVM在运行main方法的时候可以直接调用而不用创建实例。

 

4、static和final一块用表示什么

        static final用来修饰成员变量和成员方法，可简单理解为“全局常量”！

        对于变量，表示一旦给值就不可修改，并且通过类名可以访问。

        对于方法，表示不可覆盖，并且可以通过类名直接访问。

       

        特别要注意一个问题：

        对于被static和final修饰过的实例常量，实例本身不能再改变了，但对于一些容器类型（比如，ArrayList、HashMap）的实例变量，不可以改变容器变量本身，但可以修改容器中存放的对象，这一点在编程中用到很多。

        也许说了这么多，反倒把你搞晕了，还是看个例子吧：

 

 

看了上面这个例子，就清楚很多了，但必须明白：通过static final修饰的容器类型变量中所“装”的对象是可改变的。这是和一般基本类型和类类型变量差别很大的地方。