其实，入列和出列都是要锁的。完全不锁那不乱了套了？只不过Java使用了一种叫做非阻塞的方式加锁。CAS算法利用了一些CPU的指令，可以提高并发效率。在CPU的内部其实还是要“加锁”的。比如一个8核的机器里，CPU 1 如果要做一个CAS操作，那么就必须确保这个值存在自己的高速缓存中，同时还要确保这个interconnet不存在在其他7个CPU的高速缓存中，为此它要通过System Interconnect的模块和其他7个CPU协同。在最好的情况下一般的锁消耗为60纳秒，而CAS只需要消耗40纳秒（这指所要操作的这个interconnect正好就处于自己这个CPU中，8分之1的概率？），的确可以大大提高效率。但是问题是CAS还存在一个争用重试的问题。也就是一旦线程发现所使用变量已经被其他线程所修改，那么它就必须重新做CAS，重新尝试写入队列。在这种情况下，如果程序是一种高并发状态的话，CAS的效率也会比正常的锁效率更低。

上面写了那么多，其实也是废话。只是想说一点，原子操作不等于无开销的操作。只是加锁方式的不同。希望未来还会有更多的方式吧。

当然是变reference，对象都已经告诉你是immutable的了，你还变什么变？只是前面的争论在于immutable对象有没有可能在这种方式下使用而已。我认为会有，geekcode认为不会有。这个就不用争辩了，用法不同，不用也无所谓。
举一个例子，比如讲Java自己对于incrementAndGet方法的实现

public final int incrementAndGet() {
for (;;) { // 这里就是乐观锁的表现。它假设自己应该是能够成功的，所以不怕这个for
int current = get(); //这里，你可以把current就定义成final，那就是immutable对象。
int next = current + 1; //这里，如果把next定义为final，那就是一个新建的immutable对象
if (compareAndSet(current, next)) //此处加锁，改reference
return current;
}
}

public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update); //原子操作，你改reference是一定要加这个锁的。不加锁是绝对不可能实现的。
}