Java并发编程（十一）：Java8 新增的并发

原子操作 CAS
LongAdder
JDK1.8 时，java.util.concurrent.atomic 包中提供了一个新的原子类：LongAdder。
根据 Oracle 官方文档的介绍，LongAdder 在高并发的场景下会比它的前辈———
—AtomicLong 具有更好的性能，代价是消耗更多的内存空间。
AtomicLong 是利用了底层的 CAS 操作来提供并发性的，调用了 Unsafe 类的
getAndAddLong 方法，该方法是个 native 方法，它的逻辑是采用自旋的方式不断
更新目标值，直到更新成功。
在并发量较低的环境下，线程冲突的概率比较小，自旋的次数不会很多。但
是，高并发环境下，N 个线程同时进行自旋操作，会出现大量失败并不断自旋的
情况，此时 AtomicLong 的自旋会成为瓶颈。
这就是 LongAdder 引入的初衷——解决高并发环境下 AtomicLong 的自旋瓶
颈问题。
AtomicLong 中有个内部变量 value 保存着实际的 long 值，所有的操作都是
针对该变量进行。也就是说，高并发环境下，value 变量其实是一个热点，也就
是 N 个线程竞争一个热点。
LongAdder 的基本思路就是分散热点，将 value 值分散到一个数组中，不同
线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行 CAS 操作，
这样热点就被分散了，冲突的概率就小很多。如果要获取真正的 long 值，只要
将各个槽中的变量值累加返回。
这种做法和 ConcurrentHashMap 中的“分段锁”其实就是类似的思路。
LongAdder 提供的 API 和 AtomicLong 比较接近，两者都能以原子的方式对
long 型变量进行增减。
但是 AtomicLong 提供的功能其实更丰富，尤其是 addAndGet、
decrementAndGet、compareAndSet 这些方法。
addAndGet、decrementAndGet 除了单纯的做自增自减外，还可以立即获取
增减后的值，而 LongAdder 则需要做同步控制才能精确获取增减后的值。如果业
务需求需要精确的控制计数，做计数比较，AtomicLong 也更合适。
另外，从空间方面考虑，LongAdder 其实是一种“空间换时间”的思想，从
这一点来讲 AtomicLong 更适合。
总之，低并发、一般的业务场景下 AtomicLong 是足够了。如果并发量很多，
存在大量写多读少的情况，那 LongAdder 可能更合适。适合的才是最好的，如果
真出现了需要考虑到底用 AtomicLong 好还是 LongAdder 的业务场景，那么这样
的讨论是没有意义的，因为这种情况下要么进行性能测试，以准确评估在当前业
务场景下两者的性能，要么换个思路寻求其它解决方案。
对于 LongAdder 来说，内部有一个 base 变量，一个 Cell[]数组。
base 变量：非竞态条件下，直接累加到该变量上。
Cell[]数组：竞态条件下，累加个各个线程自己的槽 Cell[i]中。
所以，最终结果的计算应该是
在实际运用的时候，只有从未出现过并发冲突的时候，base 基数才会使用
到，一旦出现了并发冲突，之后所有的操作都只针对 Cell[]数组中的单元 Cell。
而 LongAdder 最终结果的求和，并没有使用全局锁，返回值不是绝对准确的，
因为调用这个方法时还有其他线程可能正在进行计数累加，所以只能得到某个时
刻的近似值，这也就是 LongAdder 并不能完全替代 LongAtomic 的原因之一。
而且从测试情况来看，线程数越多，并发操作数越大，LongAdder 的优势越
大，线程数较小时，AtomicLong 的性能还超过了 LongAdder。 其他新增
除了新引入 LongAdder 外，还有引入了它的三个兄弟类：LongAccumulator、
DoubleAdder、DoubleAccumulator。
LongAccumulator 是 LongAdder 的增强版。LongAdder 只能针对数值的进行加
减运算，而 LongAccumulator 提供了自定义的函数操作。
通过 LongBinaryOperator，可以自定义对入参的任意操作，并返回结果
（LongBinaryOperator 接收 2 个 long 作为参数，并返回 1 个 long）。
LongAccumulator 内部原理和 LongAdder 几乎完全一样。
DoubleAdder 和 DoubleAccumulator 用于操作 double 原始类型。
StampLock
StampedLock是Java8引入的一种新的所机制,简单的理解,可以认为它是读写
锁的一个改进版本,读写锁虽然分离了读和写的功能,使得读与读之间可以完全并
发,但是读和写之间依然是冲突的,读锁会完全阻塞写锁,它使用的依然是悲观的
锁策略.如果有大量的读线程,他也有可能引起写线程的饥饿。
而 StampedLock 则提供了一种乐观的读策略,这种乐观策略的锁非常类似于
无锁的操作,使得乐观锁完全不会阻塞写线程。
它的思想是读写锁中读不仅不阻塞读，同时也不应该阻塞写。
读不阻塞写的实现思路：
在读的时候如果发生了写，则应当重读而不是在读的时候直接阻塞写！即读
写之间不会阻塞对方，但是写和写之间还是阻塞的！
StampedLock 的内部实现是基于 CLH 的。
参考代码，参见 cn.enjoyedu.cha. StampedLockDemo
CompleteableFuture
Future 的不足
Future 是Java 5添加的类，用来描述一个异步计算的结果。你可以使用 isDone
方法检查计算是否完成，或者使用 get 阻塞住调用线程，直到计算完成返回结果，
你也可以使用 cancel 方法停止任务的执行。
虽然 Future 以及相关使用方法提供了异步执行任务的能力，但是对于结果
的获取却是很不方便，只能通过阻塞或者轮询的方式得到任务的结果。阻塞的方
式显然和我们的异步编程的初衷相违背，轮询的方式又会耗费无谓的 CPU 资源，
而且也不能及时地得到计算结果，为什么不能用观察者设计模式当计算结果完成
及时通知监听者呢？。
Java 的一些框架，比如 Netty，自己扩展了 Java 的 Future 接口，提供了
addListener 等多个扩展方法，Google guava 也提供了通用的扩展
Future:ListenableFuture、SettableFuture 以及辅助类 Futures 等,方便异步编程。
同时 Future 接口很难直接表述多个 Future 结果之间的依赖性。实际开发中，
我们经常需要达成以下目的：
将两个异步计算合并为一个——这两个异步计算之间相互独立，同时第二个
又依赖于第一个的结果。
等待 Future 集合中的所有任务都完成。
仅等待 Future 集合中最快结束的任务完成（有可能因为它们试图通过不同
的方式计算同一个值），并返回它的结果。
应对 Future 的完成事件（即当 Future 的完成事件发生时会收到通知，并
能使用 Future 计算的结果进行下一步的操作，不只是简单地阻塞等待操作的结
果）
CompleteableFuture
JDK1.8 才新加入的一个实现类 CompletableFuture，实现了
Future，CompletionStage两个接口。实现了 Future 接口，意味着可以像以
前一样通过阻塞或者轮询的方式获得结果。
创建
除了直接 new 出一个 CompletableFuture 的实例，还可以通过工厂方法创建
CompletableFuture 的实例
工厂方法：
Asynsc表示异步,而supplyAsync与runAsync 不同在与前者异步返回一个结果, 后者是 void.第二个函数第二个参数表示是用我们自己创建的线程池,否则采用默
认的 ForkJoinPool.commonPool()作为它的线程池。
获得结果的方法
public T get()
public T get(long timeout, TimeUnit unit)
public T getNow(T valueIfAbsent)
public T join()
getNow 有点特殊，如果结果已经计算完则返回结果或者抛出异常，否则返
回给定的 valueIfAbsent 值。
join 返回计算的结果或者抛出一个 unchecked 异常(CompletionException)，它
和 get 对抛出的异常的处理有些细微的区别。
参见 cn.enjoyedu.cha.cfdemo 下 CFDemo 和 JoinAndGet
辅助方法
public static CompletableFuture allOf(CompletableFuture... cfs)
public static CompletableFuture