无锁实现单例模式+cas、乐观锁、悲观锁、自旋锁的理解

在我们平常中的单例模式之懒汉式的实现下，为了线程安全，我们一般都是通过加锁的形式实现的，有双重检查锁，synchronized、静态内部内（通过类的加载机制实现的，在类加载中加了synchronized）等等，大家有兴趣可以去看我的另一篇文章实现单例模式的常规形式

那如果我们在面试中遇到：如何无锁实现懒汉式呢？

这里我提供一种思路：

我们可以借助于cas进行无锁实现

cas(compare and set)：这是一个原子性的操作，属于乐观锁的行列，它包含 3 个参数CAS（V，E，N），V表示要更新变量的值，E表示预期值，N表示新值。仅当 V值等于E值时，才会将V的值设为N，如果V值和E值不同，则说明已经有其他线程做两个更新，则当前线程则什么都不做。

那有的小伙伴就问了：cas属于乐观锁，不也是锁吗？怎么会是无锁呢？

这里我们明确一个观点，如何判断一个锁是否是无锁？

判断一个是否是无锁的特征，在于判断其对资源操作前后是否有锁。比如乐观锁，其是直接操作资源（共享资源），并没有对其他线程操作该资源进行任何限制，所以其实质上是属于无锁状态的。

而悲观锁，则是在对该共享资源操作前，先给该共享资源上锁，限制其它线程来获取修改该共享资源，所以这就有一个很明显的上锁操作。

这样也变解释了cas属于乐观锁，也即无锁状态。

这里延申一个问题：

那自旋锁为什么又是悲观锁呢？自旋锁不是基于cas操作的吗？

这个问题其实很好，我们借助于synchronized来了解一下。我们知道重量级锁synchronized经过jdk1.6及以后的优化，性能有了很大的提升。我大致画了一个图，以供解释

 每当我们的拥有锁的线程释放锁后，外部未进入等候线程的线程则会在自旋，与就绪线程进行一个锁的竞争，这里也体现了synchronized的不公平锁的特性。而我们的自旋锁在底层是通过cas实现的，但在此基础上通过while()循环 trylock()不断获取锁，也就是竞争synchronized内部释放的锁，所以就体现出了一个悲观锁的特征。

（如果有兴趣想了解更多synchronized的伙伴可以留言，留言的人多的话我找个时间单独写一写synchronized，包括锁膨胀、锁优化之类的）

这里我们也就借助于cas不获取锁实现单例模式

这里我们要保证实例的操作是原子性的，所以我们通过AtomicReference这个类对实例类包装，保证对其操作是原子性的

public class Singleton {
    /** 利用AtomicReference */
    private static final AtomicReference<Singleton> INSTANCE = new AtomicReference<Singleton>();
    /**
     * 私有化
     */
    private Singleton(){
    }
    /**
     * 用CAS确保线程安全
     */
    public static final Singleton getInstance(){
        for (;;) {
            Singleton current = INSTANCE.get();
            if (current != null) {
                return current;
            }
            current = new Singleton();
            if (INSTANCE.compareAndSet(null, current)) {//cas
                return current;
            }
        }
    }