并发之java.util.concurrent.atomic原子操作类包

 

15.JDK1.8的Java.util.concurrent.atomic包小结

14.Java中Atomic包的原理和分析

13.java.util.concurrent.atomic原子操作类包

11.java并发之原子性、可见性、有序性 

=====

 

15.JDK1.8的Java.util.concurrent.atomic包小结

Atomic意为原子的,JUC包又是并发包，所以不必多说。

Atomic的特点

①多线程环境下,无所的进行原子操作。 
②不能绝对保证线程不被阻塞。(因不同CPU的原子指令不同,可能需要某种形式的内部锁)

总结

J.U.C(java.util.concurrent)原子类分类
根据修改的数据类型，可以将JUC包中的原子操作类可以分为4类。
1. 基本类型: AtomicInteger, AtomicLong, AtomicBoolean ;
2. 数组类型: AtomicIntegerArray, AtomicLongArray, AtomicReferenceArray ;
3. 引用类型: AtomicReference, AtomicStampedRerence, AtomicMarkableReference ;
4. 对象的属性修改类型: AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, AtomicReferenceFieldUpdater 。

JDK1.5中:

原子性更新基本类型: 
AtomicBoolean：原子更新布尔类型。 
AtomicInteger：原子更新整型。 
AtomicLong：原子更新长整型。

原子更新基本类型数组:

AtomicIntegerArray：原子更新整型数组里的元素。 
AtomicLongArray：原子更新长整型数组里的元素。

更新字段:

抽象类:AtomicIntegerFieldUpdater: 原子更新整型字段的更新器。 
抽象类:AtomicLongFieldUpdater: 原子更新长整型字段的更新器。 
抽象类:AtomicReferenceFieldUpdater：原子更新引用类型里的字段。

更新引用类型:

AtomicReference：原子更新引用类型。

AtomicMarkableReference 原子更新带有标记位的引用类型

AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于原子的更数据和数据的版本号，可以解决使用CAS进行原子更新时，可能出现的ABA问题。

更新引用类型数组: 
AtomicReferenceArray：原子更新引用类型数组里的元素。

JDK1.8中：

Striped64 
JDK 8 的 java.util.concurrent.atomic 下有一个包本地的类 Striped64 ，它持有常见表示和机制用于类支持动态 striping 到 64bit 值上。

strping: 
数据 striping 就是把逻辑上连续的数据分为多个段，使这一序列的段存储在不同的物理设备上。通过把段分散到多个设备上可以增加访问并发性，从而提升总体的吞吐量。

累加器：

DoubleAccumulator

DoubleAdder

LongAccumulator

LongAdder

1.8中的Double和Long累加器 将原本的

如Integer中

  do {
            prev = get();
            next = accumulatorFunction.applyAsInt(prev, x);
        } while (!compareAndSet(prev, next));

do while体系 变为

    public void add(long x) {
        Cell[] as; long b, v; int m; Cell a; if ((as = cells) != null || !casBase(b = base, b + x)) { boolean uncontended = true; if (as == null || (m = as.length - 1) < 0 || (a = as[getProbe() & m]) == null || !(uncontended = a.cas(v = a.value, v + x))) longAccumulate(x, null, uncontended); } }

参考:http://www.cnblogs.com/davidwang456/p/4670777.html

1. 
在标量 如 boolean,integer,long,reference. 
其底层是CAS (compare and swap) + volatile和native方法，从而避免了synchronized的高开销，执行效率大为提升

2. 
AtomicIntegerArray，AtomicLongArray还有AtomicReferenceArray类进一步扩展了原子操作，对这些类型的数组提供了支持。这些类在为其数组元素提供 volatile 访问语义方面也引人注目，这对于普通数组来说是不受支持的。

他们内部并不是像AtomicInteger一样维持一个valatile变量，而是全部由native方法实现，如下 
AtomicIntegerArray的实现片断

3. 
AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater基于反射的实用工具，可以对指定类的指定 volatile 字段进行原子更新。API非常简单，但是也是有一些约束：

（1）字段必须是volatile类型的

（2）字段的描述类型（修饰符public/protected/default/private）是与调用者与操作对象字段的关系一致。也就是说 调用者能够直接操作对象字段，那么就可以反射进行原子操作。但是对于父类的字段，子类是不能直接操作的，尽管子类可以访问父类的字段。

（3）只能是实例变量，不能是类变量，也就是说不能加static关键字。

（4）只能是可修改变量，不能使final变量，因为final的语义就是不可修改。实际上final的语义和volatile是有冲突的，这两个关键字不能同时存在。

（5）对于AtomicIntegerFieldUpdater 和AtomicLongFieldUpdater 只能修改int/long类型的字段，不能修改其包装类型（Integer/Long）。如果要修改包装类型就需要使用AtomicReferenceFieldUpdater 。

netty5.0中类ChannelOutboundBuffer统计发送的字节总数，由于使用volatile变量已经不能满足，所以使用AtomicIntegerFieldUpdater 来实现的，看下面代码：

Atomic下有哪些类

13个实现类:

AtomicBoolean

@since 1.5

/**
 * A {@code boolean} value that may be updated atomically. See the
 * {@link java.util.concurrent.atomic} package specification for * description of the properties of atomic variables. An * {@code AtomicBoolean} is used in applications such as atomically * updated flags, and cannot be used as a replacement for a * {@link java.lang.Boolean}. * * @since 1.5 * @author Doug Lea */ 自己翻译： 一、可能以原子方式更新。 二、不能当作Boolean的替代品

AtomicInteger

@since 1.5

 However, this class does extend {@code Number} to allow uniform access by tools and utilities that deal with numerically-based classes. 特点: 自己翻译： 一、可能以原子方式更新。 二、不能当作Integer的替代品 三、类继承自Number，允许被以数值为基础的 classes文件 当做工具类去使用

AtomicIntegerArray

@since 1.5

特点:
自己翻译： 可能以原子方式更新。

这个类通常被用作

AtomicLong

@since 1.5

特点:
自己翻译： 一、可能以原子方式更新。
          二、不能当作Long的替代品
          三、类继承自Number，允许被以数值为基础的 classes文件 当做工具类去使用

AtomicLongArray

@since 1.5

特点:
自己翻译： 可能以原子方式更新。

这个类通常被用作

AtomicMarkableReference

@since 1.5

/**
 * An {@code AtomicMarkableReference} maintains an object reference
 * along with a mark bit, that can be updated atomically.
 *
 * <p>Implementation note: This implementation maintains markable
 * references by creating internal objects representing "boxed"
 * [reference, boolean] pairs.
 *
 * @since 1.5 * @author Doug Lea * @param <V> The type of object referred to by this reference */ 一、维护一个对象引用,加上一个标记位，除了标记位外，还可以进行原子更新。 二、该实现通过创建表示“装箱”(引用、布尔)对的内部对象来保持标记引用。

AtomicReference

@since 1.5

一、可以以原子方式更新的对象引用

AtomicReferenceArray

@since 1.5
一、可以以原子方式更新的对象引用

AtomicStampedReference

@since 1.5

一、保持一个对象引用和一个整数“戳记”，可以以原子的方式更新。
二、实现说明:这个实现通过创建表示“装箱”(引用、整数)对的内部对象来维护标记引用。

DoubleAccumulator

@since 1.8

/**
 * One or more variables that together maintain a running {@code double} * value updated using a supplied function. When updates (method * {@link #accumulate}) are contended across threads, the set of variables * may grow dynamically to reduce contention. Method {@link #get} * (or, equivalently, {@link #doubleValue}) returns the current value * across the variables maintaining updates. * * <p>This class is usually preferable to alternatives when multiple * threads update a common value that is used for purposes such as * summary statistics that are frequently updated but less frequently * read. * * <p>The supplied accumulator function should be side-effect-free, * since it may be re-applied when attempted updates fail due to * contention among threads. The function is applied with the current * value as its first argument, and the given update as the second * argument. For example, to maintain a running maximum value, you * could supply {@code Double::max} along with {@code * Double.NEGATIVE_INFINITY} as the identity. The order of * accumulation within or across threads is not guaranteed. Thus, this * class may not be applicable if numerical stability is required, * especially when combining values of substantially different orders * of magnitude. * * <p>Class {@link DoubleAdder} provides analogs of the functionality * of this class for the common special case of maintaining sums. The * call {@code new DoubleAdder()} is equivalent to {@code new * DoubleAccumulator((x, y) -> x + y, 0.0)}. * * <p>This class extends {@link Number}, but does <em>not</em> define * methods such as {@code equals}, {@code hashCode} and {@code * compareTo} because instances are expected to be mutated, and so are * not useful as collection keys. * * @since 1.8 * @author Doug Lea */ 一个或多个变量，共同维护一个运行的{@ code double}值，使用提供的函数更新。当更新(方法{@ link #积累})在线程之间进行争用时，变量集可以动态增长以减少争用。方法{@ link # get}(或者，相当地，{@ link # doubleValue})返回当前的值，以保持更新。 当多个线程更新一个共同的值时，这个类通常比其他方法更可取，比如经常更新但不经常读取的汇总统计信息。 提供的累加器函数应该是无副作用的，因为在尝试更新失败时，由于线程之间的争用，它可能会被重新应用。函数以当前值作为其第一个参数，而给定的update作为第二个参数。例如，为了维持一个运行最大值，您可以提供{@ code Double::max}和{@ code Double。NEGATIVE_INFINITY }的身份。在线程内部或跨线程中积累的顺序没有保证。因此,这 如果需要数值稳定性，则类可能不适用，特别是当组合了大量不同的值时 的大小。类{@ link DoubleAdder}为维护和的共同特殊情况提供了该类的类似功能。调用{@ code新的DoubleAdder()}相当于{@ code new double累加器((x,y)- > x + y,0.0)}。 这个类扩展了{@ link Number}，但是< em >不是< /em >定义了诸如{@ code =}、{@ code hashCode}和{@ code compareTo}之类的方法，因为实例被期望发生突变，因此不作为集合键有用。

DoubleAdder

@since 1.8

/**
 * One or more variables that together maintain an initially zero
 * {@code double} sum.  When updates (method {@link #add}) are * contended across threads, the set of variables may grow dynamically * to reduce contention. Method {@link #sum} (or, equivalently {@link * #doubleValue}) returns the current total combined across the * variables maintaining the sum. The order of accumulation within or * across threads is not guaranteed. Thus, this class may not be * applicable if numerical stability is required, especially when * combining values of substantially different orders of magnitude. * * <p>This class is usually preferable to alternatives when multiple * threads update a common value that is used for purposes such as * summary statistics that are frequently updated but less frequently * read. * * <p>This class extends {@link Number}, but does <em>not</em> define * methods such as {@code equals}, {@code hashCode} and {@code * compareTo} because instances are expected to be mutated, and so are * not useful as collection keys. * * @since 1.8 * @author Doug Lea */ 一个或多个变量一起维护一个初始的零{@ code double} sum。当更新(方法{@ link # add})在线程之间进行争用时，变量集可以动态增长以减少争用。方法{@ link # sum}(或者，等价{@ link # doubleValue})将当前的总数组合在维持总和的变量上。在线程内部或跨线程中积累的顺序没有保证。因此，如果需要数值稳定性，这个类可能不适用，特别是当组合了大量不同数量级的值时。 当多个线程更新一个共同的值时，这个类通常比其他方法更可取，比如经常更新但不太频繁的汇总统计数据 这个类扩展了{@ link Number}，但是< em >不是< /em >定义了诸如{@ code =}、{@ code hashCode}和{@ code compareTo}之类的方法，因为实例被期望发生突变，因此不作为集合键有用。

LongAccumulator

@since 1.8

/**
 * One or more variables that together maintain a running {@code long} * value updated using a supplied function. When updates (method * {@link #accumulate}) are contended across threads, the set of variables * may grow dynamically to reduce contention. Method {@link #get} * (or, equivalently, {@link #longValue}) returns the current value * across the variables maintaining updates. * * <p>This class is usually preferable to {@link AtomicLong} when * multiple threads update a common value that is used for purposes such * as collecting statistics, not for fine-grained synchronization * control. Under low update contention, the two classes have similar * characteristics. But under high contention, expected throughput of * this class is significantly higher, at the expense of higher space * consumption. * * <p>The order of accumulation within or across threads is not * guaranteed and cannot be depended upon, so this class is only * applicable to functions for which the order of accumulation does * not matter. The supplied accumulator function should be * side-effect-free, since it may be re-applied when attempted updates * fail due to contention among threads. The function is applied with * the current value as its first argument, and the given update as * the second argument. For example, to maintain a running maximum * value, you could supply {@code Long::max} along with {@code * Long.MIN_VALUE} as the identity. * * <p>Class {@link LongAdder} provides analogs of the functionality of * this class for the common special case of maintaining counts and * sums. The call {@code new LongAdder()} is equivalent to {@code new * LongAccumulator((x, y) -> x + y, 0L}. * * <p>This class extends {@link Number}, but does <em>not</em> define * methods such as {@code equals}, {@code hashCode} and {@code * compareTo} because instances are expected to be mutated, and so are * not useful as collection keys. * * @since 1.8 * @author Doug Lea */

LongAdder

@since 1.8
/**
 * One or more variables that together maintain an initially zero
 * {@code long} sum.  When updates (method {@link #add}) are contended * across threads, the set of variables may grow dynamically to reduce * contention. Method {@link #sum} (or, equivalently, {@link * #longValue}) returns the current total combined across the * variables maintaining the sum. * * <p>This class is usually preferable to {@link AtomicLong} when * multiple threads update a common sum that is used for purposes such * as collecting statistics, not for fine-grained synchronization * control. Under low update contention, the two classes have similar * characteristics. But under high contention, expected throughput of * this class is significantly higher, at the expense of higher space * consumption. * * <p>LongAdders can be used with a {@link * java.util.concurrent.ConcurrentHashMap} to maintain a scalable * frequency map (a form of histogram or multiset). For example, to * add a count to a {@code ConcurrentHashMap<String,LongAdder> freqs}, * initializing if not already present, you can use {@code * freqs.computeIfAbsent(k -> new LongAdder()).increment();} * * <p>This class extends {@link Number}, but does <em>not</em> define * methods such as {@code equals}, {@code hashCode} and {@code * compareTo} because instances are expected to be mutated, and so are * not useful as collection keys. * * @since 1.8 * @author Doug Lea */

4个抽象类 

AtomicIntegerFieldUpdater

@since 1.5
/**
 * A reflection-based utility that enables atomic updates to
 * designated {@code volatile int} fields of designated classes. * This class is designed for use in atomic data structures in which * several fields of the same node are independently subject to atomic * updates. * * <p>Note that the guarantees of the {@code compareAndSet} * method in this class are weaker than in other atomic classes. * Because this class cannot ensure that all uses of the field * are appropriate for purposes of atomic access, it can * guarantee atomicity only with respect to other invocations of * {@code compareAndSet} and {@code set} on the same updater. * * @since 1.5 * @author Doug Lea * @param <T> The type of the object holding the updatable field */

AtomicLongFieldUpdater

@since 1.5
/**
 * A reflection-based utility that enables atomic updates to
 * designated {@code volatile long} fields of designated classes. * This class is designed for use in atomic data structures in which * several fields of the same node are independently subject to atomic * updates. * * <p>Note that the guarantees of the {@code compareAndSet} * method in this class are weaker than in other atomic classes. * Because this class cannot ensure that all uses of the field * are appropriate for purposes of atomic access, it can * guarantee atomicity only with respect to other invocations of * {@code compareAndSet} and {@code set} on the same updater. * * @since 1.5 * @author Doug Lea * @param <T> The type of the object holding the updatable field */

AtomicReferenceFieldUpdater

@since 1.5
/**
 * A reflection-based utility that enables atomic updates to
 * designated {@code volatile} reference fields of designated
 * classes.  This class is designed for use in atomic data structures * in which several reference fields of the same node are * independently subject to atomic updates. For example, a tree node * might be declared as * * <pre> {@code * class Node { * private volatile Node left, right; * * private static final AtomicReferenceFieldUpdater<Node, Node> leftUpdater = * AtomicReferenceFieldUpdater.newUpdater(Node.class, Node.class, "left"); * private static AtomicReferenceFieldUpdater<Node, Node> rightUpdater = * AtomicReferenceFieldUpdater.newUpdater(Node.class, Node.class, "right"); * * Node getLeft() { return left; } * boolean compareAndSetLeft(Node expect, Node update) { * return leftUpdater.compareAndSet(this, expect, update); * } * // ... and so on * }}</pre> * * <p>Note that the guarantees of the {@code compareAndSet} * method in this class are weaker than in other atomic classes. * Because this class cannot ensure that all uses of the field * are appropriate for purposes of atomic access, it can * guarantee atomicity only with respect to other invocations of * {@code compareAndSet} and {@code set} on the same updater. * * @since 1.5 * @author Doug Lea * @param <T> The type of the object holding the updatable field * @param <V> The type of the field */

Striped64

1.8加入的
/**
 * A package-local class holding common representation and mechanics
 * for classes supporting dynamic striping on 64bit values. The class
 * extends Number so that concrete subclasses must publicly do so.
 */

 

14.Java中Atomic包的原理和分析

Atomic简介

Atomic包是Java.util.concurrent下的另一个专门为线程安全设计的Java包，包含多个原子操作类。这个包里面提供了一组原子变量类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由JVM从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。实际上是借助硬件的相关指令来实现的，不会阻塞线程(或者说只是在硬件级别上阻塞了)。可以对基本数据、数组中的基本数据、对类中的基本数据进行操作。原子变量类相当于一种泛化的volatile变量，能够支持原子的和有条件的读-改-写操作。——  引自@chenzehe 的博客。

传统锁的问题

我们先来看一个例子：计数器（Counter），采用Java里比较方便的锁机制synchronized关键字，初步的代码如下：

1. class Counter {   
2.     private int value;  
3.   
4.     public synchronized int getValue() {  
5.         return value;  
6.     }  
7.   
8.     public synchronized int increment() {  
9.         return ++value;  
10.     }  
11.   
12.     public synchronized int decrement() {  
13.         return --value;  
14.     }  
15. }   

其实像这样的锁机制，满足基本的需求是没有问题的了，但是有的时候我们的需求并非这么简单，我们需要更有效，更加灵活的机制，synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁，这里会有些问题：首先，如果被阻塞的线程优先级很高很重要怎么办？其次，如果获得锁的线程一直不释放锁怎么办？（这种情况是非常糟糕的）。还有一种情况，如果有大量的线程来竞争资源，那CPU将会花费大量的时间和资源来处理这些竞争（事实上CPU的主要工作并非这些），同时，还有可能出现一些例如死锁之类的情况，最后，其实锁机制是一种比较粗糙，粒度比较大的机制，相对于像计数器这样的需求有点儿过于笨重，因此，对于这种需求我们期待一种更合适、更高效的线程安全机制。

硬件同步策略

现在的处理器都支持多重处理，当然也包含多个处理器共享外围设备和内存，同时，加强了指令集以支持一些多处理的特殊需求。特别是几乎所有的处理器都可以将其他处理器阻塞以便更新共享变量。

Compare and swap(CAS)

当前的处理器基本都支持CAS，只不过每个厂家所实现的算法并不一样罢了，每一个CAS操作过程都包含三个运算符：一个内存地址V，一个期望的值A和一个新值B，操作的时候如果这个地址上存放的值等于这个期望的值A，则将地址上的值赋为新值B，否则不做任何操作。CAS的基本思路就是，如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。我们来看一个例子，解释CAS的实现过程（并非真实的CAS实现）：

1. class SimulatedCAS {  
2.     private int value;  
3.   
4.     public synchronized int getValue() {  
5.         return value;  
6.     }  
7.     public synchronized int compareAndSwap(int expectedValue, int newValue) {  
8.         int oldValue = value;  
9.         if (value == expectedValue)  
10.             value = newValue;  
11.         return oldValue;  
12.     }  
13. }  

下面是一个用CAS实现的Counter

1. public class CasCounter {  
2.     private SimulatedCAS value;  
3.   
4.     public int getValue() {  
5.         return value.getValue();  
6.     }  
7.   
8.     public int increment() {  
9.         int oldValue = value.getValue();  
10.         while (value.compareAndSwap(oldValue, oldValue + 1) != oldValue)  
11.             oldValue = value.getValue();  
12.         return oldValue + 1;  
13.     }  
14. }  

示例如下：

1. public class Counter implements Runnable {  
2.     private final AtomicInteger count = new AtomicInteger(0);  
3.       
4.     public void run() {  
5.         System.out.println(Thread.currentThread().getName()   
6.                 + ":" + count.incrementAndGet());  
7.     }  
8.       
9.     public static void main(String[] args){  
10.         Counter counter = new Counter();  
11.         Thread t1 = new Thread(counter);  
12.         Thread t2 = new Thread(counter);  
13.         Thread t3 = new Thread(counter);  
14.         Thread t4 = new Thread(counter);  
15.         t1.start();  
16.         t2.start();  
17.         t3.start();  
18.         t4.start();  
19.     }  
20. }  

看看源代码中究竟是如何实现的

1. private volatile int value;  
2. public AtomicInteger(int initialValue) {  
3.     value = initialValue;  
4. }  
5.   
6. public final int incrementAndGet() {  
7.     for (;;) {  
8.         int current = get();  
9.         int next = current + 1;  
10.         if (compareAndSet(current, next))  
11.             return next;  
12.     }  
13. }  
14.   
15. /** 
16.     * Atomically sets the value to the given updated value 
17.     * if the current value {@code ==} the expected value. 
18.     * 
19.     * @param expect the expected value 
20.     * @param update the new value 
21.     * @return true if successful. False return indicates that 
22.     * the actual value was not equal to the expected value. 
23.     */  
24. public final boolean compareAndSet(int expect, int update) {  
25.     return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  
26. }  
27.       
28. public final int get() {  
29.   return value;  
30. }  

是不是和乐观锁很像，如果结果符合预期结果，就将结果返回，否则不断进行重试，并没有进行同步，兼顾了安全性和性能

java.util.concurrent.atomic包下还有很多类，使用这些类可以保证对这些类的诸如“获取-更新”操作是原子性的，从而避发生竞态条件

1. AtomicBoolean 可以用原子方式更新的 boolean 值。   
2. AtomicInteger 可以用原子方式更新的 int 值。   
3. AtomicIntegerArray 可以用原子方式更新其元素的 int 数组。   
4. AtomicIntegerFieldUpdater<T> 基于反射的实用工具，可以对指定类的指定 volatile int 字段进行原子更新。   
5. AtomicLong 可以用原子方式更新的 long 值。   
6. AtomicLongArray 可以用原子方式更新其元素的 long 数组。   
7. AtomicLongFieldUpdater<T> 基于反射的实用工具，可以对指定类的指定 volatile long 字段进行原子更新。   
8. AtomicMarkableReference<V> AtomicMarkableReference 维护带有标记位的对象引用，可以原子方式对其进行更新。   
9. AtomicReference<V> 可以用原子方式更新的对象引用。   
10. AtomicReferenceArray<E> 可以用原子方式更新其元素的对象引用数组。   
11. AtomicReferenceFieldUpdater<T,V> 基于反射的实用工具，可以对指定类的指定 volatile 字段进行原子更新。   
12. AtomicStampedReference<V> AtomicStampedReference 维护带有整数“标志”的对象引用，可以用原子方式对其进行更新。   

Atomic类

在JDK5.0之前，想要实现无锁无等待的算法是不可能的，除非用本地库，自从有了Atomic变量类后，这成为可能。下面这张图是java.util.concurrent.atomic包下的类结构。

• 标量类：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
• 数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
• 更新器类：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater
• 复合变量类：AtomicMarkableReference，AtomicStampedReference

第一组AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference这四种基本类型用来处理布尔，整数，长整数，对象四种数据，其内部实现不是简单的使用synchronized，而是一个更为高效的方式CAS (compare and swap) + volatile和native方法，从而避免了synchronized的高开销，执行效率大为提升。我们来看个例子，与我们平时i++所对应的原子操作为：getAndIncrement()

1. public static void main(String[] args) {  
2.     AtomicInteger ai = new AtomicInteger();  
3.     System.out.println(ai);  
4.     ai.getAndIncrement();  
5.     System.out.println(ai);  
6. }  

我们可以看一下AtomicInteger的实现：

1. /** 
2.  * Atomically increments by one the current value. 
3.  * 
4.  * @return the previous value 
5.  */  
6. public final int getAndIncrement() {  
7.     return unsafe.getAndAddInt(this, valueOffset, 1);  
8. }  

这里直接调用一个叫Unsafe的类去处理，看来我们还需要继续看一下unsafe类的源码了。JDK8中sun.misc下UnSafe类，点击 查看源码

从源码注释得知，这个类是用于执行低级别、不安全操作的方法集合。尽管这个类和所有的方法都是公开的（public），但是这个类的使用仍然受限，你无法在自己的java程序中直接使用该类，因为只有授信的代码才能获得该类的实例。所以我们平时的代码是无法使用这个类的，因为其设计的操作过于偏底层，如若操作不慎可能会带来很大的灾难，所以直接禁止普通代码的访问，当然JDK使用是没有问题的。 

Atomic中的CAS

从前面的解释得知，CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值，此处这个“原本的一个值”怎么来，我们看看AtomicInteger里的实现：

1.     // setup to use Unsafe.compareAndSwapInt for updates  
2.     private static final Unsafe unsafe = Unsafe.getUnsafe();  
3.     private static final long valueOffset;  
4.   
5.     static {  
6.         try {  
7.             valueOffset = unsafe.objectFieldOffset  
8.                 (AtomicInteger.class.getDeclaredField("value"));  
9.         } catch (Exception ex) { throw new Error(ex); }  
10.     }  

这里用到UnSafe的一个方法objectFieldOffset()，查看源码：

 

1. /** 
2.      * Report the location of a given static field, in conjunction with {@link 
3.      * #staticFieldBase}. 
4.      * <p>Do not expect to perform any sort of arithmetic on this offset; 
5.      * it is just a cookie which is passed to the unsafe heap memory accessors. 
6.      * 
7.      * <p>Any given field will always have the same offset, and no two distinct 
8.      * fields of the same class will ever have the same offset. 
9.      * 
10.      * <p>As of 1.4.1, offsets for fields are represented as long values, 
11.      * although the Sun JVM does not use the most significant 32 bits. 
12.      * It is hard to imagine a JVM technology which needs more than 
13.      * a few bits to encode an offset within a non-array object, 
14.      * However, for consistency with other methods in this class, 
15.      * this method reports its result as a long value. 
16.      * @see #getInt(Object, long) 
17.      */  
18.     public native long objectFieldOffset(Field f);  

这个方法是用来拿到我们上文提到的这个“原来的值”的内存地址。是一个本地方法，返回值是valueOffset。它的参数field就是AtomicInteger里定义的value属性：

1. private volatile int value;  
2.   
3. /** 
4.  * Creates a new AtomicInteger with the given initial value. 
5.  * 
6.  * @param initialValue the initial value 
7.  */  
8. public AtomicInteger(int initialValue) {  
9.     value = initialValue;  
10. }  
11.   
12. /** 
13.  * Creates a new AtomicInteger with initial value {@code 0}. 
14.  */  
15. public AtomicInteger() {  
16. }  

value是一个volatile变量，在内存中可见，任何线程都不允许对其进行拷贝，因此JVM可以保证任何时刻任何线程总能拿到该变量的最新值。此处value的值，可以在AtomicInteger类初始化的时候传入，也可以留空，留空则自动赋值为0。 

我们再回到CAS，看看getAndIncrement()方法是怎么利用CAS实现的。

1.    /** 
2.     * Atomically increments by one the current value. 
3.     * 
4.     * @return the previous value 
5.     */  
6.    public final int getAndIncrement() {  
7.        return unsafe.getAndAddInt(this, valueOffset, 1);  
8.    }  

继续：

1. public final int getAndAddInt(Object o, long offset, int delta) {  
2.         int v;  
3.         do {  
4.             v = getIntVolatile(o, offset);//------------0---------------  
5.         } while (!compareAndSwapInt(o, offset, v, v + delta));//-------------1-------------  
6.         return v;  
7.     }  

1. /** 
2.    * Atomically update Java variable to <tt>x</tt> if it is currently 
3.    * holding <tt>expected</tt>. 
4.    * @return <tt>true</tt> if successful 
5.    */  
6.   public final native boolean compareAndSwapInt(Object o, long offset,//---------------2--------------  
7.                                                 int expected,  
8.                                                 int x);  

我稍微解释一下，其实compareAndSwapInt的注释解释的很明确，原子的将变量的值更新为x，如果成功了返回true，我们知道，如果我们创建AtomicInteger实例时不传入参数，则原始变量的值即为0，所以上面//----------0-----------处得到的v的值即为0,1处的代码为：

while(!compareAndSwapInt(o, offset, 0, 1))我们知道offset指向的地址对应的值就是原始变量的初值0，所以与期望的值0相同，所以将初值赋值为1，返回true，取反后为false，循环结束，返回v即更新之前的值0. 这就是类似于i++操作的原子操作的实现，当然最终CAS的实现都是native的，用C语言实现的，我们这里看不到源码，有时间我会反编译一下这段代码看看。

CAS线程安全

说了半天，我们要回归到最原始的问题了：这样怎么实现线程安全呢？请大家自己先考虑一下这个问题，其实我们在语言层面是没有做任何同步的操作的，大家也可以看到源码没有任何锁加在上面，可它为什么是线程安全的呢？这就是Atomic包下这些类的奥秘：语言层面不做处理，我们将其交给硬件—CPU和内存，利用CPU的多处理能力，实现硬件层面的阻塞，再加上volatile变量的特性即可实现基于原子操作的线程安全。所以说，CAS并不是无阻塞，只是阻塞并非在语言、线程方面，而是在硬件层面，所以无疑这样的操作会更快更高效！

总结

虽然基于CAS的线程安全机制很好很高效，但要说的是，并非所有线程安全都可以用这样的方法来实现，这只适合一些粒度比较小，型如计数器这样的需求用起来才有效，否则也不会有锁的存在了。

 

13.java.util.concurrent.atomic原子操作类包

这个包里面提供了一组原子变量类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由JVM从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。实际上是借助硬件的相关指令来实现的，不会阻塞线程(或者说只是在硬件级别上阻塞了)。可以对基本数据、数组中的基本数据、对类中的基本数据进行操作。原子变量类相当于一种泛化的volatile变量，能够支持原子的和有条件的读-改-写操作。

    java.util.concurrent.atomic中的类可以分成4组：

• 标量类（Scalar）：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
• 数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
• 更新器类：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater
• 复合变量类：AtomicMarkableReference，AtomicStampedReference

第一组AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference这四种基本类型用来处理布尔，整数，长整数，对象四种数据，其内部实现不是简单的使用synchronized，而是一个更为高效的方式CAS (compare and swap) + volatile和native方法，从而避免了synchronized的高开销，执行效率大为提升。如AtomicInteger的实现片断为：

Java代码  

1. private static final Unsafe unsafe = Unsafe.getUnsafe();  
2. private volatile int value;  
3. public final int get() {  
4.         return value;  
5. }  
6. public final void set(int newValue) {  
7.         value = newValue;  
8. }  
9. public final boolean compareAndSet(int expect, int update) {  
10.     return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  
11. }  

• 构造函数（两个构造函数）
  • 默认的构造函数：初始化的数据分别是false，0，0，null
  • 带参构造函数：参数为初始化的数据
• set( )和get( )方法：可以原子地设定和获取atomic的数据。类似于volatile，保证数据会在主存中设置或读取
• void set()和void lazySet()：set设置为给定值，直接修改原始值；lazySet延时设置变量值，这个等价于set()方法，但是由于字段是volatile类型的，因此次字段的修改会比普通字段（非volatile字段）有稍微的性能延时（尽管可以忽略），所以如果不是想立即读取设置的新值，允许在“后台”修改值，那么此方法就很有用。
• getAndSet( )方法
  • 原子的将变量设定为新数据，同时返回先前的旧数据
  • 其本质是get( )操作，然后做set( )操作。尽管这2个操作都是atomic，但是他们合并在一起的时候，就不是atomic。在Java的源程序的级别上，如果不依赖synchronized的机制来完成这个工作，是不可能的。只有依靠native方法才可以。
  Java代码  

  1. public final int getAndSet(int newValue) {  
  2.     for (;;) {  
  3.         int current = get();  
  4.         if (compareAndSet(current, newValue))  
  5.             return current;  
  6.     }  
  7. }  
• compareAndSet( ) 和weakCompareAndSet( )方法
  • 这 两个方法都是conditional modifier方法。这2个方法接受2个参数，一个是期望数据(expected)，一个是新数据(new)；如果atomic里面的数据和期望数据一 致，则将新数据设定给atomic的数据，返回true，表明成功；否则就不设定，并返回false。JSR规范中说：以原子方式读取和有条件地写入变量但不 创建任何 happen-before 排序，因此不提供与除 weakCompareAndSet 目标外任何变量以前或后续读取或写入操作有关的任何保证。大意就是说调用weakCompareAndSet时并不能保证不存在happen-  before的发生（也就是可能存在指令重排序导致此操作失败）。但是从Java源码来看，其实此方法并没有实现JSR规范的要求，最后效果和 compareAndSet是等效的，都调用了unsafe.compareAndSwapInt()完成操作。
  Java代码  

  1. public final boolean compareAndSet(int expect, int update) {  
  2.     return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  
  3. }  
  4. public final boolean weakCompareAndSet(int expect, int update) {  
  5.     return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  
  6. }  
   
• 对于 AtomicInteger、AtomicLong还提供了一些特别的方法。
  getAndIncrement( )：以原子方式将当前值加 1，相当于线程安全的i++操作。 
  incrementAndGet( )：以原子方式将当前值加 1， 相当于线程安全的++i操作。
  getAndDecrement( )：以原子方式将当前值减 1， 相当于线程安全的i--操作。
  decrementAndGet ( )：以原子方式将当前值减 1，相当于线程安全的--i操作。 
  addAndGet( )： 以原子方式将给定值与当前值相加， 实际上就是等于线程安全的i =i+delta操作。
  getAndAdd( )：以原子方式将给定值与当前值相加， 相当于线程安全的t=i;i+=delta;return t;操作。
  以实现一些加法，减法原子操作。(注意 --i、++i不是原子操作，其中包含有3个操作步骤：第一步，读取i；第二步，加1或减1；第三步：写回内存)

使用AtomicReference创建线程安全的堆栈

Java代码  

1. package thread;  
2. import java.util.concurrent.atomic.AtomicReference;  
3. public class ConcurrentStack<T> {  
4.     private AtomicReference<Node<T>>    stacks  = new AtomicReference<Node<T>>();  
5.     public T push(T e) {  
6.         Node<T> oldNode, newNode;  
7.         for (;;) { // 这里的处理非常的特别，也是必须如此的。  
8.             oldNode = stacks.get();  
9.             newNode = new Node<T>(e, oldNode);  
10.             if (stacks.compareAndSet(oldNode, newNode)) {  
11.                 return e;  
12.             }  
13.         }  
14.     }     
15.     public T pop() {  
16.         Node<T> oldNode, newNode;  
17.         for (;;) {  
18.             oldNode = stacks.get();  
19.             newNode = oldNode.next;  
20.             if (stacks.compareAndSet(oldNode, newNode)) {  
21.                 return oldNode.object;  
22.             }  
23.         }  
24.     }     
25.     private static final class Node<T> {  
26.         private T       object;       
27.         private Node<T>   next;         
28.         private Node(T object, Node<T> next) {  
29.             this.object = object;  
30.             this.next = next;  
31.         }  
32.     }     
33. }  

    虽然原子的标量类扩展了Number类，但并没有扩展一些基本类型的包装类，如Integer或Long，事实上他们也不能扩展：基本类型的包装类是不可以修改的，而原子变量类是可以修改的。在原子变量类中没有重新定义hashCode或equals方法，每个实例都是不同的，他们也不宜用做基于散列容器中的键值。 

      第二组AtomicIntegerArray，AtomicLongArray还有AtomicReferenceArray类进一步扩展了原子操作，对这些类型的数组提供了支持。这些类在为其数组元素提供 volatile 访问语义方面也引人注目，这对于普通数组来说是不受支持的。

他们内部并不是像AtomicInteger一样维持一个valatile变量，而是全部由native方法实现，如下
AtomicIntegerArray的实现片断：

Java代码 

1. private static final Unsafe unsafe = Unsafe.getUnsafe();  
2. private static final int base = unsafe.arrayBaseOffset(int[].class);  
3. private static final int scale = unsafe.arrayIndexScale(int[].class);  
4. private final int[] array;  
5. public final int get(int i) {  
6.         return unsafe.getIntVolatile(array, rawIndex(i));  
7. }  
8. public final void set(int i, int newValue) {  
9.         unsafe.putIntVolatile(array, rawIndex(i), newValue);  
10. }  

第三组AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater基于反射的实用工具，可以对指定类的指定 volatile 字段进行原子更新。API非常简单，但是也是有一些约束：

（1）字段必须是volatile类型的

（2）字段的描述类型（修饰符public/protected/default/private）是与调用者与操作对象字段的关系一致。也就是说 调用者能够直接操作对象字段，那么就可以反射进行原子操作。但是对于父类的字段，子类是不能直接操作的，尽管子类可以访问父类的字段。

（3）只能是实例变量，不能是类变量，也就是说不能加static关键字。

（4）只能是可修改变量，不能使final变量，因为final的语义就是不可修改。实际上final的语义和volatile是有冲突的，这两个关键字不能同时存在。

（5）对于AtomicIntegerFieldUpdater 和AtomicLongFieldUpdater 只能修改int/long类型的字段，不能修改其包装类型（Integer/Long）。如果要修改包装类型就需要使用AtomicReferenceFieldUpdater 。

 netty5.0中类ChannelOutboundBuffer统计发送的字节总数，由于使用volatile变量已经不能满足，所以使用AtomicIntegerFieldUpdater 来实现的，看下面代码：

Java代码  

1. 1. //定义  
   2.     private static final AtomicLongFieldUpdater<ChannelOutboundBuffer> TOTAL_PENDING_SIZE_UPDATER =  
   3.             AtomicLongFieldUpdater.newUpdater(ChannelOutboundBuffer.class, "totalPendingSize");  
   4.   
   5.     private volatile long totalPendingSize;  
   7. //使用  
   8.         long oldValue = totalPendingSize;  
   9.         long newWriteBufferSize = oldValue + size;  
   10.         while (!TOTAL_PENDING_SIZE_UPDATER.compareAndSet(this, oldValue, newWriteBufferSize)) {  
   11.             oldValue = totalPendingSize;  
   12.             newWriteBufferSize = oldValue + size;  
   13.         }  

11.java并发之原子性、可见性、有序性 

Java内存模型是围绕着并发过程中如何处理原子性、可见性、有序性这三个特征来建立的，下面是这三个特性的实现原理：

1.原子性(Atomicity) 由Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store和write六个，大致可以认为基础数据类型的访问和读写是具备原子性的。如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock与unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐匿地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块---synchronized关键字，因此在synchronized块之间的操作也具备原子性。

原子性
原子是世界上的最小单位，具有不可分割性。比如 a=0；（a非long和double类型） 这个操作是不可分割的，那么我们说这个操作时原子操作。再比如：a++； 这个操作实际是a = a + 1；是可分割的，所以他不是一个原子操作。非原子操作都会存在线程安全问题，需要我们使用同步技术（sychronized）来让它变成一个原子操作。一个操作是原子操作，那么我们称它具有原子性。java的concurrent包下提供了一些原子类，我们可以通过阅读API来了解这些原子类的用法。比如：AtomicInteger、AtomicLong、AtomicReference等。

1、原子性（Atomicity）
原子性是指在一个操作中就是cpu不可以在中途暂停然后再调度，既不被中断操作，要不执行完成，要不就不执行。
如果一个操作时原子性的，那么多线程并发的情况下，就不会出现变量被修改的情况
比如 a=0；（a非long和double类型） 这个操作是不可分割的，那么我们说这个操作时原子操作。再比如：a++； 这个操作实际是a = a + 1；是可分割的，所以他不是一个原子操作。
非原子操作都会存在线程安全问题，需要我们使用同步技术（sychronized）来让它变成一个原子操作。一个操作是原子操作，那么我们称它具有原子性。java的concurrent包下提供了一些原子类，我们可以通过阅读API来了解这些原子类的用法。比如：AtomicInteger、AtomicLong、AtomicReference等。

（由Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store和write六个，大致可以认为基础数据类型的访问和读写是具备原子性的。如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock与unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐匿地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块—synchronized关键字，因此在synchronized块之间的操作也具备原子性。）

一.原子性是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其它线程干扰。
Java中的原子操作包括：
1）除long和double之外的基本类型的赋值操作
2）所有引用reference的赋值操作
3）java.concurrent.Atomic.* 包中所有类的一切操作。
但是java对long和double的赋值操作是非原子操作！！long和double占用的字节数都是8，也就是64bits。在32位操作系统上对64位的数据的读写要分两步完成，每一步取32位数据。这样对double和long的赋值操作就会有问题：如果有两个线程同时写一个变量内存，一个进程写低32位，而另一个写高32位，这样将导致获取的64位数据是失效的数据。因此需要使用volatile关键字来防止此类现象。volatile本身不保证获取和设置操作的原子性，仅仅保持修改的可见性。但是java的内存模型保证声明为volatile的long和double变量的get和set操作是原子的。

public class UnatomicLong implements Runnable {
private static long test = 0;

private final long val;

public UnatomicLong(long val) {
this.val = val;
}

@Override
public void run() {
while (!Thread.interrupted()) {
test = val; //两个线程都试图将自己的私有变量val赋值给类私有静态变量test
}
}

public static void main(String[] args) {
Thread t1 = new Thread(new UnatomicLong(-1));
Thread t2 = new Thread(new UnatomicLong(0));
System.out.println(Long.toBinaryString(-1));
System.out.println(pad(Long.toBinaryString(0), 64));
t1.start();
t2.start();
long val;
while ((val = test) == -1 || val == 0) {
//如果静态成员test的值是-1或0，说明两个线程操作没有交叉
}
System.out.println(pad(Long.toBinaryString(val), 64));
System.out.println(val);
t1.interrupt();
t2.interrupt();
}
// prepend 0s to the string to make it the target length
private static String pad(String s, int targetLength) {
int n = targetLength - s.length();
for (int x = 0; x < n; x++) {
s = "0" + s;
}
return s;
}
}
运行发现程序在while循环时进入了死循环，这是因为使用的JVM是64bits。在64位JVM中double和long的赋值操作是原子操作。
在eclipse中修改jre为一个32bit的JVM地址，则会有如下运行结果：
1111111111111111111111111111111111111111111111111111111111111111
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000011111111111111111111111111111111
//很明显test的值被破坏了
4294967295

原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。
在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的操作具备原子性。
　　也就是说，只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。
不过这里有一点需要注意：在32位平台下，对64位数据的读取和赋值是需要通过两个操作来完成的，不能保证其原子性。但是好像在最新的JDK中，JVM已经保证对64位数据的读取和赋值也是原子性操作了。
　　从上面可以看出，Java内存模型只保证了基本读取和赋值是原子性操作，如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

2.可见性(Visibility)
可见性就是指当一个线程修改了线程共享变量的值，其它线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是volatile的特殊规则保证了新值能立即同步到主内存，以及每使用前立即从内存刷新。因为我们可以说volatile保证了线程操作时变量的可见性，而普通变量则不能保证这一点。
除了volatile之外，Java还有两个关键字能实现可见性，它们是synchronized。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store和write操作)”这条规则获得的，而final关键字的可见性是指：被final修饰的字段是构造器一旦初始化完成，并且构造器没有把“this”引用传递出去，那么在其它线程中就能看见final字段的值。

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
于可见性，Java提供了volatile关键字来保证可见性。
volatile保证可见性的原理是在每次 访问变量时都会进行一次刷新，因此每次访问都是主内存中最新的版本。
　　当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。
　　而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。
　　另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

2.可见性
可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
可见性，Java提供了volatile关键字来保证可见性。
当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。
而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。
另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

2、可见性(Visibility)

可见性就是指当一个线程修改了线程共享变量的值，其它线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是volatile的特殊规则保证了新值能立即同步到主内存，以及每使用前立即从内存刷新。因为我们可以说volatile保证了线程操作时变量的可见性，而普通变量则不能保证这一点。

除了volatile之外，Java还有两个关键字能实现可见性，它们是synchronized。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(执行store和write操作)”这条规则获得的，而final关键字的可见性是指：被final修饰的字段是构造器一旦初始化完成，并且构造器没有把“this”引用传递出去，那么在其它线程中就能看见final字段的值。
（可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。比如：用volatile修饰的变量，就会具有可见性。volatile修饰的变量不允许线程内部缓存和重排序，即直接修改内存。所以对其他线程是可见的。但是这里需要注意一个问题，volatile只能让被他修饰内容具有可见性，但不能保证它具有原子性。比如 volatile int a = 0；之后有一个操作 a++；这个变量a具有可见性，但是a++ 依然是一个非原子操作，也就这这个操作同样存在线程安全问题。）

可见性
可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。比如：用volatile修饰的变量，就会具有可见性。volatile修饰的变量不允许线程内部缓存和重排序，即直接修改内存。所以对其他线程是可见的。但是这里需要注意一个问题，volatile只能让被他修饰内容具有可见性，但不能保证它具有原子性。比如 volatile int a = 0；之后有一个操作 a++；这个变量a具有可见性，但是a++ 依然是一个非原子操作，也就这这个操作同样存在线程安全问题。

3.有序性
有序性即程序执行的顺序按照代码的先后顺序执行。
在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。（例如：重排的时候某些赋值会被提前）
在Java里面，可以通过volatile关键字来保证一定的“有序性”（具体原理在下一节讲述）。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

3、有序性(Ordering)
Java内存模型中的程序天然有序性可以总结为一句话：如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有操作都是无序的。前半句是指“线程内表现为串行语义”，后半句是指“指令重排序”现象和“工作内存中主内存同步延迟”现象。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则来获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。
先行发生原则：
如果Java内存模型中所有的有序性都只靠volatile和synchronized来完成，那么有一些操作将会变得很啰嗦，但是我们在编写Java并发代码的时候并没有感觉到这一点，这是因为Java语言中有一个“先行发生”(Happen-Before)的原则。这个原则非常重要，它是判断数据是否存在竞争，线程是否安全的主要依赖。

先行发生原则是指Java内存模型中定义的两项操作之间的依序关系，如果说操作A先行发生于操作B，其实就是说发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包含了修改了内存中共享变量的值、发送了消息、调用了方法等。它意味着什么呢？如下例：
//线程A中执行
i = 1;
//线程B中执行
j = i;
//线程C中执行
i = 2;
假设线程A中的操作”i=1“先行发生于线程B的操作”j=i“，那么我们就可以确定在线程B的操作执行后，变量j的值一定是等于1，结出这个结论的依据有两个，一是根据先行发生原则，”i=1“的结果可以被观察到；二是线程C登场之前，线程A操作结束之后没有其它线程会修改变量i的值。现在再来考虑线程C，我们依然保持线程A和B之间的先行发生关系，而线程C出现在线程A和B操作之间，但是C与B没有先行发生关系，那么j的值可能是1，也可能是2，因为线程C对应变量i的影响可能会被线程B观察到，也可能观察不到，这时线程B就存在读取到过期数据的风险，不具备多线程的安全性。

下面是Java内存模型下一些”天然的“先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随意地重排序。

a.程序次序规则(Pragram Order Rule)：
在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环结构。
b.管程锁定规则(Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而”后面“是指时间上的先后顺序。
c.volatile变量规则(Volatile Variable Rule)：对一个volatile变量的写操作先行发生于后面对这个变量的读取操作，这里的”后面“同样指时间上的先后顺序。
d.线程启动规则(Thread Start Rule)：Thread对象的start()方法先行发生于此线程的每一个动作。
e.线程终于规则(Thread Termination Rule)：
线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束，Thread.isAlive()的返回值等作段检测到线程已经终止执行。
f.线程中断规则(Thread Interruption Rule)：
对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生。
g.对象终结规则(Finalizer Rule)：一个对象初始化完成(构造方法执行完成)先行发生于它的finalize()方法的开始。
g.传递性(Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
一个操作”时间上的先发生“不代表这个操作会是”先行发生“，那如果一个操作”先行发生“是否就能推导出这个操作必定是”时间上的先发生“呢？也是不成立的，一个典型的例子就是指令重排序。所以时间上的先后顺序与先生发生原则之间基本没有什么关系，所以衡量并发安全问题一切必须以先行发生原则为准。

3.有序性(Ordering)
Java内存模型中的程序天然有序性可以总结为一句话：如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有操作都是无序的。前半句是指“线程内表现为串行语义”，后半句是指“指令重排序”现象和“工作内存主主内存同步延迟”现象。 Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则来获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。

先行发生原则： 如果Java内存模型中所有的有序性都只靠volatile和synchronized来完成，那么有一些操作将会变得很啰嗦，但是我们在编写Java并发代码的时候并没有感觉到这一点，这是因为Java语言中有一个“先行发生”(Happen-Before)的原则。这个原则非常重要，它是判断数据是否存在竞争，线程是否安全的主要依赖。
先行发生原则是指Java内存模型中定义的两项操作之间的依序关系，如果说操作A先行发生于操作B，其实就是说发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包含了修改了内存中共享变量的值、发送了消息、调用了方法等。它意味着什么呢？如下例：
//线程A中执行
i = 1;
//线程B中执行
j = i;

//线程C中执行
i = 2;
假设线程A中的操作”i=1“先行发生于线程B的操作”j=i“，那么我们就可以确定在线程B的操作执行后，变量j的值一定是等于1，结出这个结论的依据有两个，一是根据先行发生原则，”i=1“的结果可以被观察到；二是线程C登场之前，线程A操作结束之后没有其它线程会修改变量i的值。现在再来考虑线程C，我们依然保持线程A和B之间的先行发生关系，而线程C出现在线程A和B操作之间，但是C与B没有先行发生关系，那么j的值可能是1，也可能是2，因为线程C对应变量i的影响可能会被线程B观察到，也可能观察不到，这时线程B就存在读取到过期数据的风险，不具备多线程的安全性。
下面是Java内存模型下一些”天然的“先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随意地重排序。
a.程序次序规则(Pragram Order Rule)：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环结构。
b.管程锁定规则(Monitor Lock Rule)：
一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而”后面“是指时间上的先后顺序。
c.volatile变量规则(Volatile Variable Rule)：对一个volatile变量的写操作先行发生于后面对这个变量的读取操作，这里的”后面“同样指时间上的先后顺序。
d.线程启动规则(Thread Start Rule)：Thread对象的start()方法先行发生于此线程的每一个动作。
e.线程终于规则(Thread Termination Rule)：
线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束，Thread.isAlive()的返回值等作段检测到线程已经终止执行。
f.线程中断规则(Thread Interruption Rule)：
对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生。
g.对象终结规则(Finalizer Rule)：一个对象初始化完成(构造方法执行完成)先行发生于它的finalize()方法的开始。
g.传递性(Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
一个操作”时间上的先发生“不代表这个操作会是”先行发生“，那如果一个操作”先行发生“是否就能推导出这个操作必定是”时间上的先发生“呢？也是不成立的，一个典型的例子就是指令重排序。所以时间上的先后顺序与先生发生原则之间基本没有什么关系，所以衡量并发安全问题一切必须以先行发生原则为准。

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

在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
　　在Java里面，可以通过volatile关键字来保证一定的“有序性”（具体原理在下一节讲述）。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。
很多介绍JVM并发的书或文章都会谈到JVM为了优化性能，采用了指令重排序，但是对于什么是指令重排序，为什么重排序会优化性能却很少有提及，其实道理很简单，假设有这么两个共享变量a和b：
private int a;
private int b;
在线程A中有两条语句对这两个共享变量进行赋值操作：
a=1;
b=2;
假设当线程A对a进行复制操作的时候发现这个变量在主内存已经被其它的线程加了访问锁，那么此时线程A怎么办？等待释放锁？不，等待太浪费时间了，它会去尝试进行b的赋值操作，b这时候没被人占用，因此就会先为b赋值，再去为a赋值，那么执行的顺序就变成了：
b=2;
a=1;
对于在同一个线程内，这样的改变是不会对逻辑产生影响的，但是在多线程的情况下指令重排序会带来问题，看下面这个情景：
在线程A中：
context = loadContext();
inited = true;
在线程B中：
while(!inited ){
sleep
}
doSomethingwithconfig(context);
假设A中发生了重排序：
inited = true;
context = loadContext();
那么B中很可能就会拿到一个尚未初始化或尚未初始化完成的context,从而引发程序错误。
先要保证程序的正确然后再去优化性能。此处由于重排序产生的错误显然要比重排序带来的性能优化要重 要的多。要解决重排序问题还是通过volatile关键字，volatile关键字能确保变量在线程中的操作不会被重排序而是按照代码中规定的顺序进行访 问。

 

 

转载于:https://www.cnblogs.com/awkflf11/p/9216988.html