【Java并发】五、锁的优化和注意事项

素颜马尾好姑娘i 2022-04-05 04:25 173阅读 0赞

# 【Java并发】五、锁的优化和注意事项 #

### 文章目录 ###

*  【Java并发】五、锁的优化和注意事项
 *   *  提高锁的性能
     *   *  减少锁的持有时间
         *  减小锁粒度
         *  读写分离锁替换独占锁
         *  锁分离
         *  锁粗化
     *  Java虚拟机对锁优化所做的努力
     *   *  偏向锁
         *  轻量级锁
         *  自旋锁
         *  锁消除
     *  ThreadLocal
     *  无锁
     *   *  CAS
         *   *  ABA问题
             *  使用CAS更新对象的非\`Atomic\`属性
     *  AQS：锁的实现原理
     *  死锁

## 提高锁的性能 ##

多线程可以提高应用的性能，但是为了保证数据的一致性，需要引入锁，这样多线程又会因为激烈的锁竞争导致性能下降，而且锁、线程的维护本身也需要消耗系统资源，因此并不是多线程一定能提高系统性能，我们需要在锁的使用上更加注意。

### 减少锁的持有时间 ###

很容易理解：如果单个线程对锁的战友时间过长，那么势必导致其他线程长时间等待，竞争激烈。从而系统性能下降。所以在使用锁的时候，应该尽可能地拆分出可并行和必须同步的部分，让锁竞争真正发生在最需要同步的地方，而不是把整个过程加锁，让一些耗时的、不需要同步的过程也参与锁竞争。

### 减小锁粒度 ###

JDK1.7中的`ConcurrentHashMap`使用`synchronized + segment`实现，是一个典型的减小锁粒度的例子。先把`HashMap`的数据分成若干个段，当需要做`put()`操作时，首先计算出数据将要往哪个段中插入，然后只对相应的段作插入操作，不会阻塞其他段的数据操作，这样大大增加了吞吐量。

但是，减小锁粒度会带来一个新问题：假设我需要获得全局的锁，那么小号的资源就会更多，比如我要访问`ConcurrentHashMap`的`size()`方法，这个时候就需要获取所有段的锁，求出每个段的长度，然后求和，最后释放所有段的锁，这会导致全局操作时所有段的数据操作都被阻塞，虽然`ConcurrentHashMap`会先尝试使用无锁方式求和，如果失败了才会再次使用加锁方式求和，但是性能肯定要低于`HashMap`，只有在`size()`类似的全局操作很少的情况下，才能真正意义上提高系统的吞吐量。

但对于读写操作频繁的系统，减小锁粒度是非常有必要的，比如Mysql数据库，当需要对某一行做更新时，只需要数据库行锁，而不是锁住整个表，让在其他不受影响的行上的操作做不必要的等待。

### 读写分离锁替换独占锁 ###

在记录`ReadWriteLock`时有提到读写锁可以使用在读多写少的系统，特别是写操作非常耗时的情况下。相较于减小锁粒度对数据结构进行分割，读写分离锁是通过对系统功能进行分割实现的。

### 锁分离 ###

相较于读写分离锁是对不同系统功能的分割，锁分离是基于同一系统功能的不同场景分离。

比如`LinkedBlockingQueue`中`take()`和`put()`操作分别实现了从队列中获取数据和往队列中增加数据的功能，但是由于`LinkedBlockingQueue`是基于链表实现的，那么`take()/put()`操作虽然操作的是同一个链表，但是一个是操作队首元素，一个是操作队尾元素，大多数情况下并不冲突，因此完全可以使用两把锁来实现阻塞(`ReentrantLock takeLock,putLock`)，从而实现更高的吞吐量。

### 锁粗化 ###

这似乎和锁优化的目的是背离的，然而并不是。假设有一下一段代码：

public void doSth(){ 
    	Object lock = new Object();
    	for(int i = 0;i < 100;i ++){ 
    		synchronized(lock){ 
    			System.out.println(i);
    		}
    	}
    }
    
    public void doSth2(){ 
    	Object lock = new Object();
    	synchronized(lock){ 
    		System.out.println("m1...");
    	}
    	synchronized(lock){ 
    		System.out.println("m2...");
    	}
    	synchronized(lock){ 
    		System.out.println("m3...");
    	}
    }

上面两个方法频繁的加锁是没有必要的，而且对同一把锁频繁的加锁和释放，本身就会消耗系统资源，这非常不利于性能优化。注意到这种情况，JVM会将第二种情况整合变成：

public void doSth2(){ 
    	Object lock = new Object();
    	synchronized(lock){ 
    		System.out.println("m1...");
    		System.out.println("m2...");
    		System.out.println("m3...");
    	}
    }

而第一种场景似乎只能自己做优化了。

## Java虚拟机对锁优化所做的努力 ##

### 偏向锁 ###

偏向锁设计针对加锁操作的优化，它的核心思想是：如果一个线程获得了锁，那么锁就进入了偏向模式，如果当前线程再次请求锁，就无需再做任何同步操作，如果请求来自于其它线程，那么退出偏向锁模式。下面演示使用偏向锁和不使用偏向锁的差别：

public class BiasedLockTest { 
    
        public static void main(String[] args) throws InterruptedException { 
            long s = System.currentTimeMillis();
            for (int i = 0; i < 10000000; i++) { 
                compute();
            }
            System.out.println(System.currentTimeMillis() - s);
        }
    
        private static void compute() throws InterruptedException { 
            Object o = new Object();
            o.hashCode();
        }
    }

不使用同步时，用时`302`毫秒；在`compute()`方法前加上`synchronized`，用时`512`毫秒；修改VM参数，添加`-XX:+UseBiasedLocking`参数打开偏向锁后，`484`毫秒。  
因此在锁竞争不是很激烈的情况下，可以使用偏向锁策略提高系统效率，因为大部分时间同步方法都被同一个线程调用，完全不需要做额外的同步，但是一旦线程很多，就没有很好的效果，因为同步总是在线程间跳动，不会有很长的时间来自同一个线程。

### 轻量级锁 ###

如果偏向锁失败，线程并不会立即挂起，JVM还会使用一种轻量级锁的优化手段：JVM现在当前线程的栈针中创建`Displaced Mark Word`存储锁的头部信息(`Mark Word`)[Java并发编程：Synchronized底层优化（偏向锁、轻量级锁）][Java_Synchronized]，然后使用`CAS`尝试从锁对象中拷贝头部信息到栈中，如果拷贝成功，就把锁的头部指向栈中的存储，当前线程获得锁；如果拷贝，先检查锁对象的头部信息是否指向当前线程的`Displaced Mark Word`，如果是说明当前线程已经获得锁，开始进入同步块执行，否则说明有其他线程已经获取过锁，锁膨胀为重量级，当前线程会尝试使用自旋来获取锁。

### 自旋锁 ###

在轻量级锁获取失败的时候，当前线程会通过自旋尝试获取锁。自旋的意思是：与其让当前线程直接挂起，不如做一个赌注，假设这个线程会在不久后获取到锁，虚拟机会让当前线程做几次空循环(自旋)，假设在若干个循环后获取到锁，就开始进入临界区执行，否则才真正挂起。这样做的好处是可以减少一次内核和上下文的切换以及一次线程切换的维护，但假设别的线程占用锁的时间太长，一直自旋下去也不是办法，可能出现多个线程在自旋状态占用cpu资源。因此自旋一般都是有次数限制的，[自适应自旋][Link 1]。

### 锁消除 ###

有些情况下其实并不需要锁，但是我们在使用Java内置的一些API时，会用到锁，比如`Vector`等，假设一个`Vector`只是某个线程的局部变量，绝对不可能出现竞争，那么JIT编译时会直接消除锁。这是根据代码逃逸技术实现的：如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么可以认为这段代码是线程安全的，不必要加锁。消除锁的效果肯定是肉眼可见的，因为加锁和不加锁的性能差别还是比较明显的，JVM中使用`-XX:+EliminateLocks`参数可以打开锁消除，使用`-XX:+DoEscapeAnalysis`可以打开逃逸分析。

## ThreadLocal ##

同步的核心思想是用时间换空间：可以牺牲一点性能，延长整个任务的时间，但是必须留出足够的(共享但是同一时间只能独占)空间给每一个线程。`ThreadLocal`可以看作是用空间换时间：给每个线程一个单独的数据空间(不共享只独占)，保证每个线程能早第一时间执行，线程之间的数据空间无法访问彼此，也没有必要访问彼此的数据。

这种情况出现在一些线程内有效的数据传输，比如一次web请求的request传递，或者某些数据需要多线程共享但是只需要读取和使用但不需要写回，但要命的是使用时还必须独占加锁否则异常的场景，比如多线程的`DataFormat`：

public class SimpleDateFormatTest { 
    
        private final static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    
        public static void main(String[] args) { 
            for (int i = 0; i < 10; i++) { 
                new Thread(() -> { 
                    try { 
                        System.out.println(sdf.parse("2018-12-11 21:03:30").toString());
                    } catch (ParseException e) { 
                        e.printStackTrace();
                    }
                }).start();
            }
        }
    }

上面的程序一般都会报错`java.lang.NumberFormatException: For input string: "E112"`或`java.lang.NumberFormatException: multiple points`等，原因在于调用`parse`方法并不是线程安全的，多线程访问会导致一些共享变量的混乱。解决这个问题其实也很简单，用传统的加锁即可：

public class SimpleDateFormatTest { 
    
        private final static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        private final static ReentrantLock lock = new ReentrantLock();
    
        public static void main(String[] args) { 
            for (int i = 0; i < 10; i++) { 
                new Thread(() -> { 
                    try { 
                        lock.lock();
                        System.out.println(sdf.parse("2018-12-11 21:03:30").toString());
                    } catch (ParseException e) { 
                        e.printStackTrace();
                    }finally { 
                        lock.unlock();
                    }
                }).start();
            }
        }
    
    }

但是这样没有必要：第一，我们只是需要一个结果而已，并没有改变`sdf`的值，根本没有改坏的可能性，反而要我来维护一个锁降低系统的性能，这对程序和程序员来说是不公平的；第二，加锁会给程序性能带来影响，这是一个不必要的竞争。因此我们可以给每一个使用`sdf`的线程都分配一个`sdf`对象，这些对象只能被对应的线程访问，互不影响，这也是`ThreadLocal`的核心：

public class SimpleDateFormatTest { 
    
        private final static ThreadLocal<SimpleDateFormat> tl = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-ddHH:mm:ss"));
    
        public static void main(String[] args) { 
            for (int i = 0; i < 10; i++) { 
                new Thread(() -> { 
                    try { 
                        SimpleDateFormat sdf = tl.get();
                        System.out.println(sdf.parse("2018-12-11 21:03:30").toString());
    
                        doAgain();
    
                    } catch (ParseException e) { 
                        e.printStackTrace();
                    }
    
                }).start();
            }
    
        }
    
        private static void doAgain() throws ParseException { 
            SimpleDateFormat sdf = tl.get();
            System.out.println("[DO AGAIN] " + sdf.parse("2018-12-11 21:03:30").toString());
        }
    }
    /** * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 * Tue Dec 11 21:03:30 CST 2018 * [DO AGAIN] Tue Dec 11 21:03:30 CST 2018 */

可以看出`ThreadLocal`会在每个线程中单独保存一份数据，而且同一个线程中任何地方都可以直接使用。web项目中，当一次请求的数据交给另外一个县城处理，并且处理数据的线程需要这次请求的`Request`信息时就非常有用。启动数据处理线程时，`Request`信息并不会传入到新的线程，一种有效的办法是从主线程传入，但假设我们没法控制`Request`主动传入呢？比如`spring-boot-cloud`中调用`FeignClient`的时候就会丢失`Header`信息，这时候可以写一个拦截器，拦截器拦截所有`FeignClient`请求，在请求中加入从`ThreadLocal`中获取到的`header`信息即可；如果`ThreadLocal`中没有`header`信息，那么说明该调用仍在`Request`线程中，可以使用`RequestContextHolder`直接获取，否则需要在异步调用的时候主动将`header`信息加入`ThreadLocal`。

`ThreadLocal`原理不是特别复杂，每个`Thread`都有一个`threadLocals`域，可以看做一个简易的`Map`，当向`ThreadLocal`设置值时，先获取`Thread`的`threadLocals`域，如果为空就初始化`threadLocals`；然后将这个`ThreadLocal`对象本身作为键、设置的值为value放入`threadLocals`；在A线程从`ThreadLocal`获取值的时候，先得到A线程的`threadLocals`域，然后把`ThreadLocal`对象作为键从`threadLocals`获取对应的值；之所以把`threadLocals`设置成`Map`，是因为一个线程可能有多个`ThreadLocal`，而`ThreadLocal<T>`只能存储一个类型的值，在多个`ThreadLocal`的情况下就可以通过不同的键获取到不同的值。

可以发现，如果线程不结束，而且`ThreadLocal`中的对象有十分大，那么很可能出现OOM，因为这个可是每个线程一个对象啊；但是`threadLocals`的`Entry`是一个`WeakReference<ThreadLocal<?>>`，当线程中不再持有`Entry`的强引用的时候，JVM会在下一次`GC`回收这个对象；线程结束的时候也会主动置空触发`GC`，但最好还是在线程使用完`ThreadLocal`主动调用`ThreadLocal.remove()`清理一下。

`ThreadLocal`能对性能带来多大的提升取决于线程中对`ThreadLocal`引用的次数，或者说同一线程中对同一个“共享资源”访问的次数越多，就更应该考虑从共享更改为`ThreadLocal`（上面参数传递的情况除外，仅仅是为了保留线主线程中的数据，供其它线程使用而已）：

public class RandomTest { 
    
        private static Random random = new Random(100);
        private static ThreadLocal<Random> randomThreadLocal = ThreadLocal.withInitial(() -> new Random(100));
        private static ThreadLocalRandom threadLocalRandom = ThreadLocalRandom.current();
    
        public static void main(String[] args) { 
    
            List<Future<Long>> futures = new ArrayList<>();
            //写代码验证的时候没想透彻，我这里线程池不小心设置了很大的值，并在for循环中添加了差不多数量的线程，把CPU跑死了3次...太傻了
            ExecutorService executorService = Executors.newFixedThreadPool(4);
            for (int i = 0; i < 4; i++) { 
                futures.add(executorService.submit(() -> { 
                    long s = System.currentTimeMillis();
                    for (int j = 0; j < 10000000; j++) { 
                        random.nextInt();
                    }
                    return System.currentTimeMillis() - s;
                }));
            }
            System.out.println("normal: " + futures.stream().map(future -> { 
                try { 
                    return future.get();
                } catch (InterruptedException | ExecutionException e) { 
                    e.printStackTrace();
                    return 0L;
                }
            }).mapToLong(a -> a).sum());
    
            futures.clear();
            for (int i = 0; i < 4; i++) { 
                futures.add(executorService.submit(() -> { 
                    long s = System.currentTimeMillis();
                    for (int j = 0; j < 10000000; j++) { 
                        randomThreadLocal.get().nextInt();
                    }
                    return System.currentTimeMillis() - s;
                }));
            }
            System.out.println("thread local: " + futures.stream().map(future -> { 
                try { 
                    return future.get();
                } catch (InterruptedException | ExecutionException e) { 
                    e.printStackTrace();
                    return 0L;
                }
            }).mapToLong(a -> a).sum());
    
            futures.clear();
            for (int i = 0; i < 4; i++) { 
                futures.add(executorService.submit(() -> { 
                    long s = System.currentTimeMillis();
                    for (int j = 0; j < 10000000; j++) { 
                        threadLocalRandom.nextInt();
                    }
                    return System.currentTimeMillis() - s;
                }));
            }
            System.out.println("thread local random: " + futures.stream().map(future -> { 
                try { 
                    return future.get();
                } catch (InterruptedException | ExecutionException e) { 
                    e.printStackTrace();
                    return 0L;
                }
            }).mapToLong(a -> a).sum());
        }
    
    }
    /** * normal: 12425 * thread local: 511 * thread local random: 60 */

其中`ThreadLocalRandom`是专门针对多线程使用的随机数生成方案，性能是最好的。

## 无锁 ##

锁可以分为悲观锁和乐观锁，悲观锁认为每一次操作都可能会出现冲突，必须在每次操作上加锁，保证万无一失；而乐观锁并不这样思考，乐观锁认为冲突的概率是很小的，每个线程一开始都当做没有锁肆无忌惮地进行，一旦发现真的冲突再用相应的策略改正或重试。

并发控制是悲观的，它认为每次进入临界区一定会产生冲突，所以每个线程必须独占资源；无锁是一种乐观的策略，它假设每次对临界资源的访问都是没有冲突的，当真正遇到冲突的时候再通过一定的策略重试。

### CAS ###

`CAS(Compare and Swap)`，JDK8中很多用同步实现的逻辑都被改用`CAS`实现了，比如`ConcurrentHashMap`、`AtomicInteger`等。`CAS`算法需要三个参数`CAS(V,E,N)`，V表示将要更新的变量，E表示变量的预期值，N表示将要更新成的新值，只有V的真实值E’和预期值E相等时，才表示V的只可以被更新为N，否则说明V已经被其它线程更新了，当前线程什么都不做。CAS会返回V的真实值，那么我们可以把这个真实值设置为新的期望值进行重试，直到成功为止。

在硬件方面，大部分处理器都支持原子化的CAS指令，JVM可以根据这个指令来实现并发情况下的CAS操作。JDK中的CAS操作是在`Unsafe`类中的`public final native boolean compareAndSwapObject(Object o, long valueOffset, Object expect, Object update);`和`compareAndSwapLong()/compareAndSwapInt()`这几个本地方法实现的，o是要更新的对象(并不是更新的目标值，而时包裹目标值的外层对象，比如包装类、数组等，而要更新的是包装类的value或数组的某个元素)，valueOffset表示被更新值在o中的偏移量(由`Unsafe.objectFieldOffset()`计算得出)，expect表示期望值，update表示将要更新的新值。

`Usafe`类的初始化方法为`Unsafe.getUnsafe()`，但是这个方法：

@CallerSensitive
    public static Unsafe getUnsafe() { 
        Class var0 = Reflection.getCallerClass();
        if(!VM.isSystemDomainLoader(var0.getClassLoader())) { 
            throw new SecurityException("Unsafe");
        } else { 
            return theUnsafe;
        }
    }

不是一般人能用的，任何应用级别的类初始化获取`Unsafe`都会抛出异常，但是JDK内部的类可以使用，因为Java应用程序的类由`AppClassLoader`加载，系统核心类由`Bootstrap`加载，`Bootstrap`是本地代码实现的，所以获取核心类的`ClassLoader`会返回空，所以核心类是可以使用`Unsafe`类的，比如rt.jar里的类，其它的类就不行。因此，我们只能使用JDK提供的提供的CAS实现，却不能自己使用CAS实现其它功能，CAS相关的方法都是`final`的，连重写都不可能，在Java中要使用CAS操作，只能用`Atomic`相关的类开放出来的`compareAndSet()`方法。

因为无锁不会导致线程阻塞、不需要主动通信也能感知其它线程的操作、不需要维护锁消耗额外的系统资源，因此带来了一些性能提升。下面写一个使用同步和无锁的例子，看看无锁带来了多少性能提升：

public class AtomicIntegerTest { 
        static long sum = 0L;
    
        public static void main(String[] args) throws InterruptedException { 
            ReentrantLock lock = new ReentrantLock();
            Thread[] threads = new Thread[100000];
            for (int i = 0; i < 100000; i++) { 
                int finalI = i;
                Thread thread = new Thread(() -> { 
                    lock.lock();
                    sum += finalI;
                    lock.unlock();
                });
                threads[i] = thread;
            }
    
            long s = System.currentTimeMillis();
            for (Thread thread : threads) { 
                thread.start();
            }
            for (Thread thread : threads) { 
                thread.join();
            }
            System.out.println("lock :" + (System.currentTimeMillis() - s));
    
            AtomicLong atomicSum = new AtomicLong(0L);
            for (int i = 0; i < 100000; i++) { 
                int finalI = i;
                Thread thread = new Thread(() -> atomicSum.addAndGet(finalI));
                threads[i] = thread;
            }
            s = System.currentTimeMillis();
            for (Thread thread : threads) { 
                thread.start();
            }
            for (Thread thread : threads) { 
                thread.join();
            }
            System.out.println("cas :" + (System.currentTimeMillis() - s));
    
        }
    
    }
    /** * lock :8116 * cas :7564 */

除了`AtomicInteger/Long/Boolean/IntegerArray/LongArray`等类以外，还有`AotimicReference<V>`可以引用对象，完成对对象的无锁并发更新。还有两种`AtomicStampedReference/AtomicMarkableReference`类，这两个类用于解决下面的ABA问题。

#### ABA问题 ####

假设一个数值是1的对象X正在被多线程修改，线程A读取到X的值为1，做了一个操作，准备将X改为2，但是就在修改之前，恰好有两个线程对X做了修改，他们先后将X改为2又改为1；线程A发现X的值是1，高高兴兴地将值改为2，这就是ABA问题，从A->B和B->A这两次修改被忽略了，好像没有发生一样。

大多数情况下，这种情况是没有问题的，因为大部分场景都不关心数据的过程状态，只关心数据的当前状态，但是在一些需要关注过程状态的情况下，就会出问题，比如充值、消费这种跟过程状态相关的场景，这时候就需要用`AtomicStampedReference`来解决了，对这个对象的值做修改，不仅会更新值，还会更新一个更新次数，当有线程想要更新的时候，除了值满足期望，更新次数也满足期望。另一种`AtomicMarkableReference`原理类似，只不过更新次数换成了`true/false`，两者的区别是`AtomicStampedReference`可以得到两次更新之间更新了多少次，`AtomicMarkableReference`只关心有没有更新过。很明显后者依然不能保证解决ABA问题，因为仅有`true/false`两种状态的来回切换，只能解决简单的AA问题。

public class ABATest { 
    
        private static AtomicReference<Integer> atomicReference = new AtomicReference<>(0);
        private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(0,0);
        private static AtomicMarkableReference<Integer> atomicMarkableReference = new AtomicMarkableReference<>(0,false);
    
        public static void main(String[] args) { 
            testAtomicReference();
            testAtomicStampedReference();
            testAtomicMarkableReference();
        }
    
        private static void testAtomicMarkableReference() { 
            System.out.println("atomicMarkableReference--------------------------------------------------");
            //A
            Integer expectReference = atomicMarkableReference.getReference();
            boolean expectMark = atomicMarkableReference.isMarked();
            //B
            System.out.println("thread0 read expect reference = 0, 0->1: " + atomicMarkableReference.compareAndSet(
                    expectReference,
                    expectReference+1,
                    expectMark,
                    !expectMark)
            );//true
            //A
            System.out.println("thread1 read expect reference = 1, 1->0: " + atomicMarkableReference.compareAndSet(
                    atomicMarkableReference.getReference(),
                    atomicMarkableReference.getReference()-1,
                    atomicMarkableReference.isMarked(),
                    !atomicMarkableReference.isMarked())
            );//true
            System.out.println("thread2 read expect reference = 0, 0->1: " + atomicMarkableReference.compareAndSet(
                    expectReference,
                    expectReference+1,
                    expectMark,
                    !expectMark)
            );//true,其实已经被修改过，无法解决ABA问题
            System.out.println();
        }
    
        private static void testAtomicStampedReference() { 
            System.out.println("atomicStampedReference--------------------------------------------------");
            //A
            Integer expectReference = atomicStampedReference.getReference();
            Integer expectStamp = atomicStampedReference.getStamp();
            //B
            System.out.println("thread0 read expect reference = 0, 0->1: " + atomicStampedReference.compareAndSet(
                    expectReference,
                    expectReference+1,
                    expectStamp,
                    expectStamp+1)
            );//true
            //A
            System.out.println("thread1 read expect reference = 1, 1->0: " + atomicStampedReference.compareAndSet(
                    atomicStampedReference.getReference(),
                    atomicStampedReference.getReference()-1,
                    atomicStampedReference.getStamp(),
                    atomicStampedReference.getStamp()+1)
            );//true
            System.out.println("thread2 read expect reference = 0, 0->1: " + atomicStampedReference.compareAndSet(
                    expectReference,
                    expectReference+1,
                    expectStamp,
                    expectStamp+1)
            );//false，可以解决ABA问题
            System.out.println();
        }
    
        private static void testAtomicReference() { 
            System.out.println("atomicReference--------------------------------------------------");
            //A
            Integer expect = atomicReference.get();
            //B
            System.out.println("thread0 read expect = 0, 0->1: " + atomicReference.compareAndSet(
                    expect,
                    expect + 1)
            );//true
            //A
            System.out.println("thread1 read expect = 1, 1->0: " + atomicReference.compareAndSet(
                    atomicReference.get(),
                    atomicReference.get() - 1)
            );//true
            System.out.println("thread2 read expect = 0, 0->1: " + atomicReference.compareAndSet(
                    expect,
                    expect + 1)
            );//true,其实已经被修改过，无法解决ABA问题
            System.out.println();
        }
    
    }

#### 使用CAS更新对象的非`Atomic`属性 ####

有这样的场景：一个变量存储在对象A的a属性中，一开始各个线程只会读这个值，所以没有使用相关`Aotimic`类包装，但是后来业务变更，会有多线程来并发更新这个值，这时候有多种解决方案。一是直接用`Automic`类包装一下a属性，二是添加一个同步方法来更新a，三是使用`AtomicReferenceFieldUpdater`来保证线程安全。这三者的优缺点其实一目了然，最差的是方法一，虽然有很好的心梗但违反了软件的开闭原则，修改属性必然导致多处关联的修改；其次是方法二，但同步或加锁在高并发下性能并不是最好；最好的是方法三，结合了前两个方法的有点，是最优解。

public class AtomicReferenceFieldUpdaterTest { 
    
        public static void main(String[] args) throws InterruptedException { 
            ExecutorService executorService = Executors.newFixedThreadPool(10);
            TestObj testObj = new TestObj();
            for (int i = 0; i <= 100; i++) { 
                int finalI = i;
                executorService.execute(() -> { 
                    while(true){ 
                        Integer a = testObj.getA();
                        if(TestObj.updateA(testObj,a,a + finalI)){ 
                            break;
                        }
                    }
                });
    
            }
            executorService.shutdown();
            while(! executorService.isTerminated()){ 
                Thread.sleep(10L);
            }
            System.out.println(testObj.getA());
        }
    
        private static class TestObj { 
            public final static AtomicReferenceFieldUpdater<TestObj,Integer> atomicReferenceFieldUpdater = AtomicReferenceFieldUpdater.newUpdater(TestObj.class, Integer.class,"a");
    
            private volatile Integer a = 0;
    
            public Integer getA() { 
                return a;
            }
    
            public static boolean updateA(TestObj testObj, Integer expect, Integer update){ 
                return atomicReferenceFieldUpdater.compareAndSet(testObj, expect, update);
            }
        }
    
    }

上面的程序始终会输出5050，而且修改对于`TestObj`的侵入性并不算大，只是增加了一个方法并将a属性用`volitale`修饰了而已。同时使用`AtomicReferenceFieldUpdater`必须注意：一、属性必须用`volitale`修饰，保证每一次修改对其它线程是可见的；二、对对象属性的CAS操作是通过直接修改属性对应的对象在实例中的偏移量实现的，而计算偏移量的方法是`Unsafe.objectFieldOffset()`，这个方法不支持计算静态变量的偏移量，因此`static`修饰的变量无法使用这个方法进行CAS操作。

## AQS：锁的实现原理 ##

`AQS(AbstractQueuedSynchronizer)`定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的`ReentrantLock/Semaphore/CountDownLatch`。

[Java并发之AQS详解][Java_AQS]

这篇文章已经讲得非常详细了，记录一下。

## 死锁 ##

死锁的出现一般是因为一个线程需要占用多个资源，如果一个线程先占用了部分资源，而另一个线程占用了剩下的资源，就会出现这两个线程之间都在等待彼此释放资源，如果没有外力介入，等待将永远存在，程序出现卡死、崩溃，下面是一个简单的产生死锁的例子：

public class DeadLockTest { 
    
        private static ReentrantLock lock1 = new ReentrantLock();
        private static ReentrantLock lock2 = new ReentrantLock();
    
        public static void main(String[] args) { 
            for (int i = 0; i < 100; i++) { 
                new Thread(() -> { 
                    try { 
                        lock1.lock();
                        Thread.sleep(1L);
                        lock2.lock();
                        System.out.println("1->2 finish...");
                    } catch (InterruptedException e) { 
                        e.printStackTrace();
                    } finally { 
                        lock1.unlock();
                        lock2.unlock();
                    }
                }).start();
                new Thread(() -> { 
                    try { 
                        lock2.lock();
                        Thread.sleep(1L);
                        lock1.lock();
                        System.out.println("2->1 finish...");
                    } catch (InterruptedException e) { 
                        e.printStackTrace();
                    } finally { 
                        lock2.unlock();
                        lock1.unlock();
                    }
                }).start();
            }
        }
    
    }

上面的程序可能什么都打印不出来而且还一直不会结束，因为加锁顺序的原因，一个线程先获取`lock1`的锁，另一个线程先获取`lock2`的锁，很容易就出现两个线程一个线程拿到了`lock1`，一个线程拿到了`lock2`，导致两个线程都带等待彼此释放需要的另外一个锁，如果严格地按照相同的加锁顺序，是不会出现死锁的，因为资源的加锁顺序一致，某一个线程获取到第一个锁，其它线程就不可能再获取到这个锁了。

我们用`jstack`查看一下堆栈信息：

...
    Found one Java-level deadlock:
    =============================
    "Thread-199":
      waiting for ownable synchronizer 0x00000000d5f60a80, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
      which is held by "Thread-1"
    "Thread-1":
      waiting for ownable synchronizer 0x00000000d5f60a50, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
      which is held by "Thread-0"
    "Thread-0":
      waiting for ownable synchronizer 0x00000000d5f60a80, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
      which is held by "Thread-1"
    ...

可以看出检测到了死锁，并且是`Thread-1`在等待被`Thread-0`持有的锁，`Thread-0`在等待被`Thread-1`持有的锁，然后就可以从其它信息中看看这两个线程到底在干嘛，最后解决死锁问题。

CAS并不会造成死锁，因为CAS不持有任和锁，自然也就不会产生死锁问题啦。

[Java_Synchronized]: https://www.cnblogs.com/paddix/p/5405678.html
[Link 1]: https://blog.csdn.net/zqz_zqz/article/details/70233767
[Java_AQS]: https://www.cnblogs.com/waterystone/p/4920797.html