Java内存模型（Java Memory Model，简称JMM）是一种抽象概念，并不真实存在。它的主要目的是围绕原子性、可见性和有序性这几种并发问题定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。

此处的变量与Java编程中所说的变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不会存在竞争问题。

JVM的运行实体

JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存（有些地方称为栈空间），用于存储线程私有的数据，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝，前面说过，工作内存是每个线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成。

主内存

主内存主要存储的是Java实例对象，所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量还是方法中的本地变量（也称局部变量），当然也包括了共享的类信息、常量、静态变量。由于是共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题。

工作内存

工作内存主要存储当前方法的所有本地变量信息（工作内存中存储着主内存中的变量副本拷贝），每个线程只能访问自己的工作内存，即线程中的本地变量对其它线程是不可见的，就算是两个线程执行的是同一段代码，它们也会各自在自己的工作内存中创建属于当前线程的本地变量，当然也包括了字节码行号指示器、相关Native方法的信息。注意由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题。

主内存与工作内存的数据存储类型以及操作方式

根据JVM虚拟机规范主内存与工作内存的数据存储类型以及操作方式，对于一个实例对象中的成员方法而言，如果方法中包含本地变量是基本数据类型（boolean,byte,short,char,int,long,float,double），将直接存储在工作内存的帧栈结构中，但倘若本地变量是引用类型，那么该变量的引用会存储在功能内存的帧栈中，而对象实例将存储在主内存（共享数据区域，堆）中。但对于实例对象的成员变量，不管它是基本数据类型或者包装类型（Integer、Double等）还是引用类型，都会被存储到堆区。至于static变量以及类本身相关信息将会存储在主内存中。

总结

Java内存模型是一个抽象的概念，它并不真实存在，但它对Java程序的并发编程至关重要。通过定义程序中各种变量的访问规则，Java内存模型有助于防止竞争条件和其他并发问题。理解Java内存模型是编写健壮、可扩展的并发Java程序的关键。

---

深入Java核心 Java内存分配原理精讲

Java内存分配与管理是Java的核心技术之一，今天我们深入Java核心，详细介绍一下Java在内存分配方面的知识。 一般Java在内存分配时会涉及到以下区域：◆寄存器：我们在程序中无法控制◆栈：存放基本类型的数据和对象的引用，但对象本身不存放在栈中，而是存放在堆中◆堆：存放用new产生的数据◆静态域：存放在对象中用static定义的静态成员◆常量池：存放常量◆非RAM存储：硬盘等永久存储空间Java内存分配中的栈在函数中定义的一些基本类型的变量数据和对象的引用变量都在函数的栈内存中分配。 当在一段代码块定义一个变量时，Java就在栈中 为这个变量分配内存空间，当该变量退出该作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。 Java内存分配中的堆堆内存用来存放由new创建的对象和数组。 在堆中分配的内存，由Java虚拟机的自动废品回收器来管理。 在堆中产生了一个数组或对象后，还可以 在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。 引用变量就相当于是 为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。 引用变量就相当于是为数组或者对象起的一个名称。 引用变量是普通的变量，定义时在栈中分配，引用变量在程序运行到其作用域之外后被释放。 而数组和对象本身在堆中分配，即使程序 运行到使用 new 产生数组或者对象的语句所在的代码块之外，数组和对象本身占据的内存不会被释放，数组和对象在没有引用变量指向它的时候，才变为废品，不能在被使用，但仍 然占据内存空间不放，在随后的一个不确定的时间被废品回收器收走（释放掉）。 这也是 Java 比较占内存的原因。 实际上，栈中的变量指向堆内存中的变量，这就是Java中的指针！常量池 (constant pool)常量池指的是在编译期被确定，并被保存在已编译的文件中的一些数据。 除了包含代码中所定义的各种基本类型（如int、long等等）和对象型（如String及数组）的常量值(final)还包含一些以文本形式出现的符号引用，比如：◆类和接口的全限定名；◆字段的名称和描述符；◆方法和名称和描述符。 虚拟机必须为每个被装载的类型维护一个常量池。 常量池就是该类型所用到常量的一个有序集和，包括直接常量（string,integer和 floating point常量）和对其他类型，字段和方法的符号引用。 对于String常量，它的值是在常量池中的。 而JVM中的常量池在内存当中是以表的形式存在的， 对于String类型，有一张固定长度的CONSTANT_String_info表用来存储文字字符串值，注意：该表只存储文字字符串值，不存储符号引 用。 说到这里，对常量池中的字符串值的存储位置应该有一个比较明了的理解了。 在程序执行的时候,常量池 会储存在Method Area,而不是堆中。 堆与栈Java的堆是一个运行时数据区,类的(对象从中分配空间。 这些对象通过new、newarray、 anewarray和multianewarray等指令建立，它们不需要程序代码来显式的释放。 堆是由废品回收来负责的，堆的优势是可以动态地分配内存 大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的，Java的废品收集器会自动收走这些不再使用的数据。 但缺点是，由于要在运行时动态 分配内存，存取速度较慢。 栈的优势是，存取速度比堆要快，仅次于寄存器，栈数据可以共享。 但缺点是，存在栈中的数据大小与生存期必须是 确定的，缺乏灵活性。 栈中主要存放一些基本类型的变量数据（int, short, long, byte, float, double, boolean, char）和对象句柄(引用)。 栈有一个很重要的特殊性，就是存在栈中的数据可以共享。 假设我们同时定义：int a = 3; int b = 3； 编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。 接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。 这样，就出现了a与b同时均指向3的情况。 这时，如果再令 a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。 因此a值的改变不会影响 到b的值。 要注意这种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。 而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。 String是一个特殊的包装类数据。 可以用：String str = new String(abc); String str = abc; 两种的形式来创建，第一种是用new()来新建对象的，它会在存放于堆中。 每调用一次就会创建一个新的对象。 而第二种是先在栈中创建一个对String类的对象引用变量str，然后通过符号引用去字符串常量池 里找有没有abc,如果没有，则将abc存放进字符串常量池 ，并令str指向”abc”，如果已经有”abc” 则直接令str指向“abc”。 比较类里面的数值是否相等时，用equals()方法；当测试两个包装类的引用是否指向同一个对象时，用==，下面用例子说明上面的理论。 String str1 = abc; String str2 = abc; (str1==str2); //true 可以看出str1和str2是指向同一个对象的。 String str1 =new String (abc); String str2 =new String (abc); (str1==str2); // false 用new的方式是生成不同的对象。 每一次生成一个。 因此用第二种方式创建多个”abc”字符串,在内存中 其实只存在一个对象而已. 这种写法有利与节省内存空间. 同时它可以在一定程度上提高程序的运行速度，因为JVM会自动根据栈中数据的实际情况来决定是否有必要创建新对象。 而对于String str = new String(abc)；的代码，则一概在堆中创建新对象，而不管其字符串值是否相等，是否有必要创建新对象，从而加重了程序的负担。 另 一方面, 要注意: 我们在使用诸如String str = abc；的格式定义类时，总是想当然地认为，创建了String类的对象str。 担心陷阱！对象可能并没有被创建！而可能只是指向一个先前已经创建的 对象。 只有通过new()方法才能保证每次都创建一个新的对象。 由于String类的immutable性质，当String变量需要经常变换 其值时，应该考虑使用StringBuffer类，以提高程序效率。 1. 首先String不属于8种基本数据类型，String是一个对象。 因为对象的默认值是null，所以String的默认值也是null；但它又是一种特殊的对象，有其它对象没有的一些特性。 2. new String()和new String(”)都是申明一个新的空字符串，是空串不是null；3. String str=”kvill”；String str=new String (”kvill”)的区别示例：String s0=kvill; String s1=kvill; String s2=kv + ill; ( s0==s1 ); ( s0==s2 ); 结果为：truetrue首先，我们要知结果为道Java 会确保一个字符串常量只有一个拷贝。 因为例子中的 s0和s1中的”kvill”都是字符串常量，它们在编译期就被确定了，所以s0==s1为true；而”kv”和”ill”也都是字符串常量，当一个字 符串由多个字符串常量连接而成时，它自己肯定也是字符串常量，所以s2也同样在编译期就被解析为一个字符串常量，所以s2也是常量池中” kvill”的一个引用。 所以我们得出s0==s1==s2；用new String() 创建的字符串不是常量，不能在编译期就确定，所以new String() 创建的字符串不放入常量池中，它们有自己的地址空间。 示例：String s0=kvill; String s1=new String(kvill); String s2=kv + new String(ill); ( s0==s1 ); ( s0==s2 ); ( s1==s2 ); 结果为：falsefalsefalse例2中s0还是常量池 中kvill”的应用，s1因为无法在编译期确定，所以是运行时创建的新对象”kvill”的引用，s2因为有后半部分 new String(”ill”)所以也无法在编译期确定，所以也是一个新创建对象”kvill”的应用;明白了这些也就知道为何得出此结果了。 4. ()：再补充介绍一点：存在于文件中的常量池，在运行期被JVM装载，并且可以扩充。 String的 intern()方法就是扩充常量池的 一个方法；当一个String实例str调用intern()方法时，Java 查找常量池中 是否有相同Unicode的字符串常量，如果有，则返回其的引用，如果没有，则在常 量池中增加一个Unicode等于str的字符串并返回它的引用；看示例就清楚了示例：String s0= kvill; String s1=new String(kvill); String s2=new String(kvill); ( s0==s1 ); ( ********** ); (); s2=(); //把常量池中kvill的引用赋给s2 ( s0==s1); ( s0==() ); ( s0==s2 ); 结果为：falsefalse //虽然执行了(),但它的返回值没有赋给s1true //说明()返回的是常量池中kvill的引用true最后我再破除一个错误的理解：有人说，“使用 () 方法则可以将一个 String 类的保存到一个全局 String 表中 ，如果具有相同值的 Unicode 字符串已经在这个表中，那么该方法返回表中已有字符串的地址，如果在表中没有相同值的字符串，则将自己的地址注册到表中”如果我把他说的这个全局的 String 表理解为常量池的话，他的最后一句话，”如果在表中没有相同值的字符串，则将自己的地址注册到表中”是错的：示例：String s1=new String(kvill); String s2=(); ( s1==() ); ( s1+ +s2 ); ( s2==() ); 结果：falsekvill kvilltrue在这个类中我们没有声名一个”kvill”常量，所以常量池中一开始是没有”kvill”的，当我们调用()后就在常量池中新添加了一 个”kvill”常量，原来的不在常量池中的”kvill”仍然存在，也就不是“将自己的地址注册到常量池中”了。 s1==() 为false说明原来的”kvill”仍然存在；s2现在为常量池中”kvill”的地址，所以有s2==()为true。 5. 关于equals()和==:这个对于String简单来说就是比较两字符串的Unicode序列是否相当，如果相等返回true;而==是 比较两字符串的地址是否相同，也就是是否是同一个字符串的引用。 6. 关于String是不可变的这一说又要说很多，大家只 要知道String的实例一旦生成就不会再改变了，比如说：String str=”kv”+”ill”+” “+”ans”; 就是有4个字符串常量，首先”kv”和”ill”生成了”kvill”存在内存中，然后”kvill”又和” ” 生成 “kvill “存在内存中，最后又和生成了”kvill ans”;并把这个字符串的地址赋给了str,就是因为String的”不可变”产生了很多临时变量，这也就是为什么建议用StringBuffer的原 因了，因为StringBuffer是可改变的。 下面是一些String相关的常见问题：String中的final用法和理解final StringBuffer a = new StringBuffer(111);final StringBuffer b = new StringBuffer(222);a=b;//此句编译不通过final StringBuffer a = new StringBuffer(111);(222);// 编译通过可见，final只对引用的值(即内存地址)有效，它迫使引用只能指向初始指向的那个对象，改变它的指向会导致编译期错误。 至于它所指向的对象 的变化，final是不负责的。 String常量池问题的几个例子下面是几个常见例子的比较分析和理解：String a = a1; String b = a + 1; ((a == b)); //result = true String a = atrue; String b = a + true; ((a == b)); //result = true String a = a3.4; String b = a + 3.4; ((a == b)); //result = true 分析：JVM对于字符串常量的+号连接，将程序编译期，JVM就将常量字符串的+连接优化为连接后的值，拿a + 1来说，经编译器优化后在class中就已经是a1。 在编译期其字符串常量的值就确定下来，故上面程序最终的结果都为true。 String a = ab; String bb = b; String b = a + bb; ((a == b)); //result = false 分析：JVM对于字符串引用，由于在字符串的+连接中，有字符串引用存在，而引用的值在程序编译期是无法确定的，即a + bb无法被编译器优化，只有在程序运行期来动态分配并将连接后的新地址赋给b。 所以上面程序的结果也就为false。 String a = ab; final String bb = b; String b = a + bb; ((a == b)); //result = true 分析：和[3]中唯一不同的是bb字符串加了final修饰，对于final修饰的变量，它在编译时被解析为常量值的一个本地拷贝存储到自己的常量 池中或嵌入到它的字节码流中。 所以此时的a + bb和a + b效果是一样的。 故上面程序的结果为true。 String a = ab; final String bb = getBB(); String b = a + bb; ((a == b)); //result = false private static String getBB() { return b; } 分析：JVM对于字符串引用bb，它的值在编译期无法确定，只有在程序运行期调用方法后，将方法的返回值和a来动态连接并分配地址为b，故上面 程序的结果为false。 通过上面4个例子可以得出得知：String s = a + b + c;就等价于String s = abc;String a = a;String b = b;String c = c;String s = a + b + c;这个就不一样了，最终结果等于：StringBuffer temp = new StringBuffer(); (a)(b)(c); String s = (); 由上面的分析结果，可就不难推断出String 采用连接运算符（+）效率低下原因分析，形如这样的代码：public class Test { public static void main(String args[]) { String s = null; for(int i = 0; i100; i++) { s += a; } } } 每做一次 + 就产生个StringBuilder对象，然后append后就扔掉。 下次循环再到达时重新产生个StringBuilder对象，然后 append 字符串，如此循环直至结束。 如果我们直接采用 StringBuilder 对象进行 append 的话，我们可以节省 N - 1 次创建和销毁对象的时间。 所以对于在循环中要进行字符串连接的应用，一般都是用StringBuffer或StringBulider对象来进行 append操作。 String对象的intern方法理解和分析：public class Test4 { private static String a = ab; public static void main(String[] args){ String s1 = a; String s2 = b; String s = s1 + s2; (s == a);//false (() == a);//true } } 这里用到Java里面是一个常量池的问题。 对于s1+s2操作，其实是在堆里面重新创建了一个新的对象,s保存的是这个新对象在堆空间的的内容，所 以s与a的值是不相等的。 而当调用()方法，却可以返回s在常量池中的地址值，因为a的值存储在常量池中，故和a的值相等。 总结栈中用来存放一些原始数据类型的局部变量数据和对象的引用(String,数组.对象等等)但不存放对象内容堆中存放使用new关键字创建的对象.字符串是一个特殊包装类,其引用是存放在栈里的,而对象内容必须根据创建方式不同定(常量池和堆).有的是编译期就已经创建好，存放在字符串常 量池中，而有的是运行时才被创建.使用new关键字，存放在堆中。

看了这篇文章，你还敢说你了解volatile关键字吗？

想要理解volatile为什么能确保可见性，就要先理解Java中的内存模型是什么样的。

Java内存模型规定了 所有的变量都存储在主内存中 。 每条线程中还有自己的工作内存，线程的工作内存中保存了被该线程所使用到的变量（这些变量是从主内存中拷贝而来） 。 线程对变量的所有操作（读取，赋值）都必须在工作内存中进行。不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成 。

基于此种内存模型，便产生了多线程编程中的数据“脏读”等问题。

举个简单的例子：在java中，执行下面这个语句：

执行线程必须先在自己的工作线程中对变量i所在的缓存行进行赋值操作，然后再写入主存当中。而不是直接将数值10写入主存当中。

比如同时有2个线程执行这段代码，假如初始时i的值为10，那么我们希望两个线程执行完之后i的值变为12。但是事实会是这样吗？

可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的工作内存当中，然后线程1进行加1操作，然后把i的最新值11写入到内存。此时线程2的工作内存当中i的值还是10，进行加1操作之后，i的值为11，然后线程2把i的值写入内存。

最终结果i的值是11，而不是12。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。

那么如何确保共享变量在多线程访问时能够正确输出结果呢？

在解决这个问题之前，我们要先了解并发编程的三大概念： 原子性，有序性，可见性 。

1.定义

原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

2.实例

一个很经典的例子就是银行账户转账问题：

比如从账户A向账户B转1000元，那么必然包括2个操作：从账户A减去1000元，往账户B加上1000元。

试想一下，如果这2个操作不具备原子性，会造成什么样的后果。假如从账户A减去1000元之后，操作突然中止。这样就会导致账户A虽然减去了1000元，但是账户B没有收到这个转过来的1000元。

所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。

同样地反映到并发编程中会出现什么结果呢？

举个最简单的例子，大家想一下假如为一个32位的变量赋值过程不具备原子性的话，会发生什么后果？

假若一个线程执行到这个语句时，我暂且假设为一个32位的变量赋值包括两个过程：为低16位赋值，为高16位赋值。

那么就可能发生一种情况：当将低16位数值写入之后，突然被中断，而此时又有一个线程去读取i的值，那么读取到的就是错误的数据。

中的原子性

在Java中， 对基本数据类型的变量的读取和赋值操作是原子性操作 ，即这些操作是不可被中断的，要么执行，要么不执行。

上面一句话虽然看起来简单，但是理解起来并不是那么容易。看下面一个例子i：

请分析以下哪些操作是原子性操作：

x = 10; //语句1

y = x; //语句2

x++; //语句3

x = x + 1; //语句4

咋一看，可能会说上面的4个语句中的操作都是原子性操作。其实只有语句1是原子性操作，其他三个语句都不是原子性操作。

语句1是直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中。

语句2实际上包含2个操作，它先要去读取x的值，再将x的值写入工作内存 ，虽然读取x的值以及 将x的值写入工作内存 这2个操作都是原子性操作，但是合起来就不是原子性操作了。

同样的， x++和 x = x+1包括3个操作：读取x的值，进行加1操作，写入新的值 。

所以上面4个语句只有语句1的操作具备原子性。

也就是说， 只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

从上面可以看出，Java内存模型只保证了基本读取和赋值是原子性操作， 如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

1.定义

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

2.实例

举个简单的例子，看下面这段代码：

//线程1执行的代码

//线程2执行的代码

由上面的分析可知，当线程1执行 i =10这句时，会先把i的初始值加载到工作内存中，然后赋值为10，那么在线程1的工作内存当中i的值变为10了，却没有立即写入到主存当中。

此时线程2执行 j = i，它会先去主存读取i的值并加载到线程2的工作内存当中，注意此时内存当中i的值还是0，那么就会使得j的值为0，而不是10.

这就是可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。

中的可见性

对于可见性，Java提供了volatile关键字来保证可见性。

当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。

而普通的共享变量不能保证可见性， 因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且 在释放锁之前会将对变量的修改刷新到主存当中 。因此可以保证可见性。

1.定义

有序性：即程序执行的顺序按照代码的先后顺序执行。

2.实例

举个简单的例子，看下面这段代码：

boolean flag = false;

i = 1; //语句1

flag = true; //语句2

上面代码定义了一个int型变量，定义了一个boolean类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）。

下面解释一下什么是指令重排序， 一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

比如上面的代码中，语句1和语句2谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句2先执行而语句1后执行。

但是要注意，虽然处理器会对指令进行重排序，但是它会保证程序最终结果会和代码顺序执行结果相同，那么它靠什么保证的呢？再看下面一个例子：

int a = 10; //语句1

int r = 2; //语句2

a = a + 3; //语句3

r = a*a; //语句4

这段代码有4个语句，那么可能的一个执行顺序是：

那么可不可能是这个执行顺序呢： 语句2 语句1 语句4 语句3

不可能，因为处理器在进行重排序时是会考虑指令之间的数据依赖性，如果一个指令Instruction 2必须用到Instruction 1的结果，那么处理器会保证Instruction 1会在Instruction 2之前执行。

虽然重排序不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：

上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomethingwithconfig(context)方法，而此时context并没有被初始化，就会导致程序出错。

从上面可以看出， 指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。

也就是说， 要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。

中的有序性

在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。

在Java里面，可以通过volatile关键字来保证一定的“有序性”。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

另外，Java内存模型具备一些先天的“有序性”， 即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。

下面就来具体介绍下happens-before原则（先行发生原则）：

①程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作

②锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作

③volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作

④传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C

⑤线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作

⑥线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生

⑦线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过()方法结束、()的返回值手段检测到线程已经终止执行

⑧对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

这8条规则中，前4条规则是比较重要的，后4条规则都是显而易见的。

下面我们来解释一下前4条规则：

对于程序次序规则来说，就是一段程序代码的执行 在单个线程中看起来是有序的 。注意，虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”，这个应该是程序看起来执行的顺序是按照代码顺序执行的， 但是虚拟机可能会对程序代码进行指令重排序 。虽然进行重排序，但是最终执行的结果是与程序顺序执行的结果一致的，它只会对不存在数据依赖性的指令进行重排序。因此， 在单个线程中，程序执行看起来是有序执行的 ，这一点要注意理解。事实上， 这个规则是用来保证程序在单线程中执行结果的正确性，但无法保证程序在多线程中执行的正确性。

第二条规则也比较容易理解，也就是说无论在单线程中还是多线程中， 同一个锁如果处于被锁定的状态，那么必须先对锁进行了释放操作，后面才能继续进行lock操作。

第三条规则是一条比较重要的规则。直观地解释就是， 如果一个线程先去写一个变量，然后一个线程去进行读取，那么写入操作肯定会先行发生于读操作。

第四条规则实际上就是体现happens-before原则 具备传递性 。

保证可见性

一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

1）保证了 不同线程对这个变量进行操作时的可见性 ，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。

2） 禁止进行指令重排序。

先看一段代码，假如线程1先执行，线程2后执行：

这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过，每个线程在运行过程中都有自己的工作内存，那么线程1在运行的时候，会将stop变量的值拷贝一份放在自己的工作内存当中。

那么当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。

但是用volatile修饰之后就变得不一样了：

第一：使用volatile关键字会 强制将修改的值立即写入主存 ；

第二：使用volatile关键字的话，当线程2进行修改时， 会导致线程1的工作内存中缓存变量stop的缓存行无效 （反映到硬件层的话，就是CPU的L1或者L2缓存中对应的缓存行无效）；

第三：由于线程1的工作内存中缓存变量stop的缓存行无效，所以 线程1再次读取变量stop的值时会去主存读取 。

那么在线程2修改stop值时（当然这里包括2个操作，修改线程2工作内存中的值，然后将修改后的值写入内存），会使得线程1的工作内存中缓存变量stop的缓存行无效，然后线程1读取时，发现自己的缓存行无效，它会等待缓存行对应的主存地址被更新之后，然后去对应的主存读取最新的值。

那么线程1读取到的就是最新的正确的值。

不能确保原子性

下面看一个例子：

大家想一下这段程序的输出结果是多少？也许有些朋友认为是。但是事实上运行它会发现每次运行结果都不一致，都是一个小于的数字。

可能有的朋友就会有疑问，不对啊，上面是对变量inc进行自增操作，由于volatile保证了可见性，那么在每个线程中对inc自增完之后，在其他线程中都能看到修改后的值啊，所以有10个线程分别进行了1000次操作，那么最终inc的值应该是1000*10=。

这里面就有一个误区了， volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。 可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。

在前面已经提到过， 自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存 。那么就是说自增操作的三个子操作可能会分割开执行，就有可能导致下面这种情况出现：

假如某个时刻变量inc的值为10，

线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了 ；

然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值， 由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，也不会导致主存中的值刷新， 所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。

然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。

那么两个线程分别进行了一次自增操作后，inc只增加了1。

根源就在这里，自增操作不是原子性操作，而且volatile也无法保证对变量的任何操作都是原子性的。

解决方案：可以通过synchronized或lock，进行加锁，来保证操作的原子性。也可以通过AtomicInteger。

在java 1.5的包下提供了一些 原子操作类 ，即对基本数据类型的 自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。 atomic是利用CAS来实现原子性操作的（Compare And Swap） ，CAS实际上是 利用处理器提供的CMPXCHG指令实现的，而处理器执行CMPXCHG指令是一个原子性操作。

保证有序性

在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。

volatile关键字禁止指令重排序有两层意思：

1）当程序执行到volatile变量的读操作或者写操作时， 在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行 ；

2）在进行指令优化时， 不能将在对volatile变量的读操作或者写操作的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

可能上面说的比较绕，举个简单的例子：

由于 flag变量为volatile变量 ，那么在进行指令重排序的过程的时候， 不会将语句3放到语句1、语句2前面，也不会讲语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。

并且volatile关键字能保证， 执行到语句3时，语句1和语句2必定是执行完毕了的，且语句1和语句2的执行结果对语句3、语句4、语句5是可见的。

那么我们回到前面举的一个例子：

//线程1:

context = loadContext(); //语句1

inited = true; //语句2

//线程2:

while(!inited ){

doSomethingwithconfig(context);

前面举这个例子的时候，提到有可能语句2会在语句1之前执行，那么久可能导致context还没被初始化，而线程2中就使用未初始化的context去进行操作，导致程序出错。

这里如果用volatile关键字对inited变量进行修饰，就不会出现这种问题了， 因为当执行到语句2时，必定能保证context已经初始化完毕。

1.可见性

处理器为了提高处理速度，不直接和内存进行通讯，而是将系统内存的数据独到内部缓存后再进行操作，但操作完后不知什么时候会写到内存。

2.有序性

Lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），它确保 指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面； 即在执行到内存屏障这句指令时，在它前面的操作已经全部完成。

synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下2个条件：

1）对变量的写操作不依赖于当前值

2）该变量没有包含在具有其他变量的不变式中

下面列举几个Java中使用volatile的几个场景。

①.状态标记量

volatile boolean flag = false;

//线程1

while(!flag){

doSomething();

//线程2

public void setFlag() {

flag = true;

根据状态标记，终止线程。

②.单例模式中的double check

为什么要使用volatile 修饰instance？

主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情:

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

自己是从事了七年开发的Android工程师，不少人私下问我，2019年Android进阶该怎么学，方法有没有？

没错，年初我花了一个多月的时间整理出来的学习资料，希望能帮助那些想进阶提升Android开发，却又不知道怎么进阶学习的朋友。【 包括高级UI、性能优化、架构师课程、NDK、Kotlin、混合式开发（ReactNative+Weex）、Flutter等架构技术资料 】，希望能帮助到您面试前的复习且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。