JUC是java.util.concurrent包的简称，该包提供了并发编程的解决方案（当然，JAVA并发编程的解决方案还有synchronized）。从概括的层面来说，JUC包有两大核心：CAS和AQS。其中CAS是java.util.concurrent.atomic包的基础，AQS是java.util.concurrent.locks包以及一些常用类比如Semophore等类的基础。我们先来说说CAS。
CAS的全称为Compare-And-Swap，它是一条CPU并发原语。它的功能是判断内存某个位置的值是否为预期值，如果是则更改为新的值，这个过程是原子的。CAS并发原语体现在JAVA语言中就是sun.misc.Unsafe类中的各个方法。调用UnSafe类中的CAS方法，JVM会帮我们实现出CAS汇编指令。这是一种完全依赖于硬件的功能。那么为什么CAS会出现呢？它的作用是怎样的？
实现并发的传统方式是加锁，JAVA中的锁有synchronized和Lock。Lock是基于AQS和CAS实现的，在此先不叙述。对于synchronized锁，JVM在执行它的时候会依赖操作系统的临界区机制。这样的话，每次执行到synchronized锁，都会经历用户态和内核态之间的切换。这个过程的消耗是很大的。而且，大多数时候synchronized锁住的操作是很细粒度的。为了细粒度的操作去经历用户态和内核态之间的切换是低效的做法。
说到这，我想到了线程池。大家知道，当线程创建和销毁的时间大于任务执行的时间时，就需要考虑使用线程池了。但如果和任务执行时间相比，线程创建和销毁的时间很少，那么线程池也可不用。
在synchronized中就是这个问题，当需要同步的操作粒度很细时，使用synchronized是不高效的，这时就有CAS存在的意义了。比如对于i++这种并发计数功能，使用synchronized就大材小用了，而使用CAS来实现就会更加的轻量级，性能更好。因此可以看到java.util.concurrent.atomic包中有类似AtomicInteger这种类。我们来看下AtomicInteger类的核心源码：
public class AtomicInteger extends Number implements java.io.Serializable {
private static final long serialVersionUID = 6214790243416807050L;
// setup to use Unsafe.compareAndSwapInt for updates
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;
public AtomicInteger(int initialValue) {
value = initialValue;
}
public AtomicInteger() {
}
public final int get() {
return value;
}
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
public final int incrementAndGet() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}
}
在上面的代码中Unsafe类负责执行CAS并发原语，由JVM转化为汇编。在代码中使用CAS自旋volatile变量的形式实现非阻塞并发。这种方式是CAS的主要使用方式。
CAS操作包含三个操作数——内存位置（V）、预期原值（A）和新值(B)。如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在CAS指令之前返回该位置的值。CAS有效地说明了“我认为位置V应该包含值A；如果包含该值，则将B放到这个位置；否则，不要更改该位置。无论如何，告诉我原值。
Java.util.concurrent.atomic包为开发者提供了比synchronized更加细粒度的并发代码控制方式。实际上也是最细粒度的并发代码控制方式。
CAS是乐观锁，是一种冲突重试的机制，在并发竞争不是很激烈的情况下(也是大多数情况)，他的性能要好于基于锁的并发性能。因为并发竞争激烈的话，冲突重试的过程很多。
下面是基于AtomicReference实现的并发的非阻塞栈：
import java.util.concurrent.atomic.AtomicReference;
public class ConcurrentStack <E>{
private AtomicReference<Node<E>> top=new AtomicReference<Node<E>>();
public void push(E value){
Node<E> newTop=new Node<E>(value);
Node<E> oldTop=null;
do{
oldTop=top.get();
newTop.next=oldTop;
}while(!top.compareAndSet(oldTop,newTop));
}
public E pop(){
Node<E> node=null;
Node<E> newTop=null;
do{
node=top.get();
if(node==null)
return null;
newTop=node.next;
node.next=null;
}while(!top.compareAndSet(node, newTop));
return node.value;
}
private class Node<E>{
public Node<E> next;
public final E value;
public Node(E value){
this.value=value;
}
}
}
CAS的典型步骤如下：
while(true){
int A=V.get();//mark1
if(A==V.compareAndSwap(A,newA))//mark2
return A;
}
在上面代码的mark1行，首先获取V的值为A，然后在mark2行会重新判断V的值是否还是A。现实中有这样的情况：在mark1行之后mark2行之前，V的值可能从A变成B又变成A。这个时候，现有的代码仍然认为V的值没有改变，而有些情况下，我们需要识别V的这种改变。这就是ABA问题。
解决ABA问题的一种思路就是在CAS操作的时候更新两个值，包括引用和该值的版本号，JUC中提供了这个类AtomicStampedReferance以及AtomicMarkedReference。这两个类支持在两个变量上执行CAS操作，用于解决ABA问题。
