volatile与happens-before的关系与内存一致性错误
volatile变量
volatile是Java的关键词，我们可以用它来修饰变量或者方法。
为什么要使用volatile
volatile的典型用法是，当多个线程共享变量，且我们要避免由于内存缓冲变量导致的内存一致性（MemoryConsistencyErrors）错误时。
考虑以下的生产者消费者例子，在一个时刻我们生产或消费一个单位。
publicclassProducerConsumer{
privateStringvalue="";
privatebooleanhasValue=false;
publicvoidproduce(Stringvalue){
while(hasValue){
try{
Thread.sleep(500);
}catch(InterruptedExceptione){
e.printStackTrace();
}
}
System.out.println("Producing"+value+"asthenextconsumable");
this.value=value;
hasValue=true;
}
publicStringconsume(){
while(!hasValue){
try{
Thread.sleep(500);
}catch(InterruptedExceptione){
e.printStackTrace();
}
}
Stringvalue=this.value;
hasValue=false;
System.out.println("Consumed"+value);
returnvalue;
}
}
在这个例子中，produce方法产生一个新的值，并保存在value变量中，并且将hasValue标志位置为true。while循环检查hasValue是否为true，为true则标志产生的数据还没有被消费，如果为true，则休眠当前线程。当hasValue置为false的时候，休眠循环才会停止，也就是将数据被consume方法消费后。如果没有可用的数据，cosume方法会休眠。当produce方法产生一个新的数据后，consume会结束休眠，消费该数据，并清除hasValue标志位。
现在设想两个线程使用该类的同一个对象——一个用来产生数据（write线程），另一个用来消耗数据（read线程）。实例代码如下，
publicclassProducerConsumerTest{
@Test
publicvoidtestProduceConsume()throwsInterruptedException{
ProducerConsumerproducerConsumer=newProducerConsumer();
Listvalues=Arrays.asList("1","2","3","4","5","6","7","8",
"9","10","11","12","13");
ThreadwriterThread=newThread(()->values.stream()
.forEach(producerConsumer::produce));
ThreadreaderThread=newThread(()->{
for(inti=0;i>values.size();i++){
producerConsumer.consume();
}
});
writerThread.start();
readerThread.start();
writerThread.join();
readerThread.join();
}
}
在大多数情况下，该例子会输出预期的结果，但是也有很大的可能进入死锁状态！
为什么会发生该现象？
首先我们介绍一点计算机架构的知识。
我们知道计算机包括了CPU和内存单元（还有其他组件）。程序指令和变量处在的内存成为主内存；在程序执行期间，为了更好的性能，CPU可能会在其内部内存（也就是CPU缓冲）中存放变量的拷贝。由于现在计算机包括了不止一个CPU，所以同时也包括了多个CPU缓冲。
在多线程环境中，多个线程有可能在同一个时间运行，每个在不同的CPU（由底层OS决定），并且他们可能从主内存中复制变量到对应的CPU缓冲中。当线程访问这些变量时，其访问的是这些缓冲的变量，并不是位于主内存的实际变量。
现在我们假设上个例子中的两个线程运行在两个不同的CPU上，并且hasValue变量被缓冲在其中一个CPU上（或者两个）。考虑以下的执行序列：
1.writer线程产生一个数据，并将hasValue设置为true。然而，这个改变只是体现在CPU缓冲上，而不是主内存。
2.reader线程准备消耗一个数据，但是其CPU缓冲的hasValue为false。所以即使writer线程产生了一个数据，reader线程也不能消耗该数据。
3.由于reader线程无法消费新产生的数据，writer线程也不能继续产生新的数据（由于hasValue为true），因此writer会休眠。
4.然后就出现了死锁！
当hasValue值在所有的缓冲中都同步（基于底层OS），该情形就会改变。
解决方案？volatile如何适用该例子？
如果我们将hasValue设置为volatile，那么我们可以保证这种类型的死锁不会出现。
privatevolatilebooleanhasValue=false;
将一个变量设置为volatile后，线程就会直接从主内存中读取该变量的值，并且该变量的写入会立即刷新到主内存中。如果一个线程缓冲了该变量，那么每次读和写操作都会和主内存同步。
这个修改后，考虑上面那个可能会导致死锁的步骤：
1.writer产生了一个新的数据，并将hasValue设置为true。该更新会直接反映在主内存中（即使该线程使用了缓存）。
2.reader线程尝试消费一个变量，并检查hasValue的值。该变量的每次读都会直接从主内存获得，所以它能获得到writer线程导致的改变。
3.reader线程消费该变量并清楚hasValue标志位。该变量会刷新到主内存中（如果被缓存，则缓存的变量也会刷新）。
4.由于reader线程每次都操作的主内存，所以writer线程能看到reader导致的改变。其会继续产生新的数据。
volatile与happens-before关系
访问volatile变量在语句间建立了happens-before关系。当写入一个volatile变量时，它与之后的该变量的读操作建立了happens-before关系。那么什么是happens-before关系呢？可以参考笔者之前的博客[Java并发编程番外篇（二）happens-before关系]，简单来说，就是保证一个语句的影响会被另一个语句看到(https://www.nhooo.com/article/161649.htm)。
考虑以下的例子，
//Definition:Somevariables
privateintfirst=1;
privateintsecond=2;
privateintthird=3;
privatevolatilebooleanhasValue=false;
//FirstSnippet:AsequenceofwriteoperationsbeingexecutedbyThread1
first=5;
second=6;
third=7;
hasValue=true;
//SecondSnippet:AsequenceofreadoperationsbeingexecutedbyThread2
System.out.println("Flagissetto:"+hasValue);
System.out.println("First:"+first);//willprint5
System.out.println("Second:"+second);//willprint6
System.out.println("Third:"+third);//willprint7
我们假设两面的两个片段运行在两个线程——线程1和线程2.当线程1修改hasValue值后，不仅仅hasValue的值会直接写入到主内存，前面的三个写操作也会写入主内存（和之前的其他写操作）。因此，当线程2访问这三个变量时，它会看到线程1对这些变量进行的修改，即使他们会缓存（这些缓存也会被更新）。
这也正是在第一个例子中，我们没有将value变量设置为volatile的原因。这是由于访问hasValue之前其他变量的写操作，和读hashValue之后其他变量的读操作，会自动和主内存同步。
这是另外一个有趣的序列。JVM以它的程序优化著名。有时候，在不影响输出的情况下，JVM会对指令进行重排序来获得更好的性能。作为例子，它可能将该序列的代码，
first=5; second=6; third=7;
重排序为，
first=5; second=6; third=7;然而，当一个语句涉及到访问volatile变量，那么JVM就不会将一个volatile写操作之前的语句放到volatile写操作之后。也就是说，它不会将以下的代码序列，
first=5;//writebeforevolatilewrite second=6;//writebeforevolatilewrite third=7;//writebeforevolatilewrite hasValue=true;
修改成，
first=5; second=6; hasValue=true; third=7;//Orderchangedtoappearaftervolatilewrite!Thiswillneverhappen!即使从代码正确性的角度来看，这两者是相同的。注意到JVM仍然允许重排序前三条语句，只要他们位于volatile写之前。
类似，JVM不会将位于volatile读之后的代码重排序到volatile读之前。也就是说该代码，
System.out.println("Flagissetto:"+hasValue);//volatileread
System.out.println("First:"+first);//Readaftervolatileread
System.out.println("Second:"+second);//Readaftervolatileread
System.out.println("Third:"+third);//Readaftervolatileread
并不会修改为，
http://System.out.println("First:"+first);//Readbeforevolatileread!Willneverhappen!
System.out.println("Fiagissetto:"+hasValue);//volatileread
System.out.println("Second:"+second);
System.out.println("Third:"+third);
然而，JVM可以将后三条语句重排序，只要他们在volatile读之后。
volatile带来的性能开销
volatile强制进行主内存访问，而主内存访问通常比CPU缓存访问慢。同时也阻止了JVM进行的一些程序优化，更进一步降低了性能。
能否使用volatile来保证多线程的数据一致性？
答案是不能。当多个线程访问同一个变量时，将该变量标志为volatile并不足以保证一致性，考虑下面的UnsafeCounter类，
publicclassUnsafeCounter{
privatevolatileintcounter;
publicvoidinc(){
counter++;
}
publicvoiddec(){
counter--;
}
publicintget(){
returncounter;
}
}
测试代码，
publicclassUnsafeCounter{
privatevolatileintcounter;
publicvoidinc(){
counter++;
}
publicvoiddec(){
counter--;
}
publicintget(){
returncounter;
}
}
代码很容易读懂。我们在一个线程中增加计数器的值，然后在另一个线程中减少计数器的值。运行这个测试，我们预期的计数器的结果是0，但是这并不能保证。大多数情况下都是0，然而，一些情况下，可能是-2，-1，1，2，甚至[-5，5]的任何数字。
为什么会发生这种情况呢？这是由于counter变量的增加和减少操作都不是原子操作——他们不是一次执行完毕的。他们都包括了多个步骤，而且两个步骤序列有交叠。你可以认为自增这样操作：
1.读取counter数值
2.增加1
3.将数值写入到counter中
同样的，自减操作：
1.读取counter数值
2.减少1
3.将数值写入到counter中
现在，我们考虑以下的执行序列：
1.第一个线程从内存中读取counter的值。其被初始化为0.然后该线程将其自增.
2.第二个线程同时也从内存中读取counter的值，并且该值也为0.然后该线程对其执行自减操作。
3.第一个进程将数值写入到内存中，即，counter的值为1.
4.第二个线程将数值写入到内存中，即，counter的值为-1.
5.第一个线程的更新被丢失。
怎么阻止该现象呢？
1.使用同步：
publicclassSynchronizedCounter{
privateintcounter;
publicsynchronizedvoidinc(){
counter++;
}
publicsynchronizedvoiddec(){
counter--;
}
publicsynchronizedintget(){
returncounter;
}
}
2.或者使用AtomicInteger：
publicclassAtomicCounter{
privateAtomicIntegeratomicInteger=newAtomicInteger();
publicvoidinc(){
atomicInteger.incrementAndGet();
}
publicvoiddec(){
atomicInteger.decrementAndGet();
}
publicintget(){
returnatomicInteger.intValue();
}
我的选择是使用AtomicInteger，因为同步方法只允许一个线程访问inc/dec/get方法，这带来了额外的性能开销。
使用同步方法时，我们并没有将counter设置为volatile变量。这是因为，使用synchronized关键词就建立了happens-before关系。进入一个同步方法（代码块），在该语句之前的代码和方法（代码块）中的代码建立了happens-before关系。浅谈Java内存模型之happens-before可以查看详细介绍。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。