1. synchronized 关键字

1.1. 说一说自己对于 synchronized 关键字的了解

synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。
另外，在 Java 早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

1.2. 说说自己是怎么使用 synchronized 关键字，在项目中用到了吗

synchronized关键字最主要的三种使用方式：

  • 修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
  • 修饰静态方法: :也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
  • 修饰代码块: 指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

总结： synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。synchronized 关键字加到实例方法上是给对象实例上锁。尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓存功能！
下面我以一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。
面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！”
双重校验锁实现对象单例（线程安全）

  1. public class Singleton {

  3. private volatile static Singleton uniqueInstance;

  5. private Singleton() {
  6. }

  8. public static Singleton getUniqueInstance() {
  9. //先判断对象是否已经实例过，没有实例化过才进入加锁代码
  10. if (uniqueInstance == null) {
  11. //类对象加锁
  12. synchronized (Singleton.class) {
  13. if (uniqueInstance == null) {
  14. uniqueInstance = new Singleton();
  15. }
  16. }
  17. }
  18. return uniqueInstance;
  19. }
  20. }

另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。
uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：

  1. 为 uniqueInstance 分配内存空间
  2. 初始化 uniqueInstance
  3. 将 uniqueInstance 指向分配的内存地址

但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

1.3. 讲一下 synchronized 关键字的底层原理

synchronized 关键字底层原理属于 JVM 层面。
① synchronized 同步语句块的情况

  1. public class SynchronizedDemo {
  2. public void method() {
  3. synchronized (this) {
  4. System.out.println("synchronized 代码块");
  5. }
  6. }
  7. }

通过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件，然后执行javap -c -s -v -l SynchronizedDemo.class。
Java 并发知识 - 图1
从上面我们可以看出：
synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权。当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。
② synchronized 修饰方法的的情况

  1. public class SynchronizedDemo2 {
  2. public synchronized void method() {
  3. System.out.println("synchronized 方法");
  4. }
  5. }

Java 并发知识 - 图2
synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

1.4. 说说 JDK1.6 之后的synchronized 关键字底层做了哪些优化，可以详细介绍一下这些优化吗

JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。
锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。
关于这几种优化的详细信息可以查看笔主的这篇文章：synchronized 关键字使用及底层原理

1.5. 谈谈 synchronized和ReentrantLock 的区别

① 两者都是可重入锁
两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
② synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API
synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
③ ReentrantLock 比 synchronized 增加了一些高级功能
相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：①等待可中断；②可实现公平锁；③可实现选择性通知（锁可以绑定多个条件）

  • ReentrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
  • ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。 ReentrantLock默认情况是非公平的，可以通过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来制定是否是公平的。
  • synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify()/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知” ，这个功能非常重要，而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。

如果你想使用上述功能，那么选择ReentrantLock是一个不错的选择。
④ 性能已不是选择标准

2. volatile关键字

2.1. 讲一下Java内存模型

在 JDK1.2 之前，Java的内存模型实现总是从主存（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存本地内存比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。
Java 并发知识 - 图3
要解决这个问题，就需要把变量声明为volatile，这就指示 JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。
说白了， volatile 关键字的主要作用就是保证变量的可见性然后还有一个作用是防止指令重排序。
Java 并发知识 - 图4

2.2. 说说 synchronized 关键字和 volatile 关键字的区别

synchronized关键字和volatile关键字比较

  • volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized关键字要好。但是volatile关键字只能用于变量而synchronized关键字可以修饰方法以及代码块。synchronized关键字在JavaSE1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各种优化之后执行效率有了显著提升，实际开发中使用 synchronized 关键字的场景还是更多一些。
  • 多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞
  • volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字两者都能保证。
  • volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。

    3. ThreadLocal

    3.1. ThreadLocal简介

    通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？ JDK中提供的ThreadLocal类正是为了解决这样的问题。 ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。
    如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是ThreadLocal变量名的由来。他们可以使用 get（） 和 set（） 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。
    再举个简单的例子：
    比如有两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么ThreadLocal就是用来避免这两个线程竞争的。

    3.2. ThreadLocal示例

    相信看了上面的解释，大家已经搞懂 ThreadLocal 类是个什么东西了。
  1. import java.text.SimpleDateFormat;
  2. import java.util.Random;

  4. public class ThreadLocalExample implements Runnable{

  6. // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
  7. private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));

  9. public static void main(String[] args) throws InterruptedException {
  10. ThreadLocalExample obj = new ThreadLocalExample();
  11. for(int i=0 ; i<10; i++){
  12. Thread t = new Thread(obj, ""+i);
  13. Thread.sleep(new Random().nextInt(1000));
  14. t.start();
  15. }
  16. }

  18. @Override
  19. public void run() {
  20. System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());
  21. try {
  22. Thread.sleep(new Random().nextInt(1000));
  23. } catch (InterruptedException e) {
  24. e.printStackTrace();
  25. }
  26. //formatter pattern is changed here by thread, but it won't reflect to other threads
  27. formatter.set(new SimpleDateFormat());

  29. System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
  30. }

  32. }

Output:

  1. Thread Name= 0 default Formatter = yyyyMMdd HHmm
  2. Thread Name= 0 formatter = yy-M-d ah:mm
  3. Thread Name= 1 default Formatter = yyyyMMdd HHmm
  4. Thread Name= 2 default Formatter = yyyyMMdd HHmm
  5. Thread Name= 1 formatter = yy-M-d ah:mm
  6. Thread Name= 3 default Formatter = yyyyMMdd HHmm
  7. Thread Name= 2 formatter = yy-M-d ah:mm
  8. Thread Name= 4 default Formatter = yyyyMMdd HHmm
  9. Thread Name= 3 formatter = yy-M-d ah:mm
  10. Thread Name= 4 formatter = yy-M-d ah:mm
  11. Thread Name= 5 default Formatter = yyyyMMdd HHmm
  12. Thread Name= 5 formatter = yy-M-d ah:mm
  13. Thread Name= 6 default Formatter = yyyyMMdd HHmm
  14. Thread Name= 6 formatter = yy-M-d ah:mm
  15. Thread Name= 7 default Formatter = yyyyMMdd HHmm
  16. Thread Name= 7 formatter = yy-M-d ah:mm
  17. Thread Name= 8 default Formatter = yyyyMMdd HHmm
  18. Thread Name= 9 default Formatter = yyyyMMdd HHmm
  19. Thread Name= 8 formatter = yy-M-d ah:mm
  20. Thread Name= 9 formatter = yy-M-d ah:mm

从输出中可以看出，Thread-0已经改变了formatter的值，但仍然是thread-2默认格式化程序与初始化值相同，其他线程也一样。
上面有一段代码用到了创建 ThreadLocal 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA会提示你转换为Java8的格式(IDEA真的不错！)。因为ThreadLocal类在Java 8中扩展，使用一个新的方法withInitial()，将Supplier功能接口作为参数。

  1. private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
  2. @Override
  3. protected SimpleDateFormat initialValue()
  4. {
  5. return new SimpleDateFormat("yyyyMMdd HHmm");
  6. }

  7. };

    3.3. ThreadLocal原理

    从 Thread类源代码入手。

  8. public class Thread implements Runnable {

  9. ......
  10. //与此线程有关的ThreadLocal值。由ThreadLocal类维护
  11. ThreadLocal.ThreadLocalMap threadLocals = null;

  13. //与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护
  14. ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
  15. ......
  16. }

从上面Thread类 源代码可以看出Thread 类中有一个 threadLocals 和 一个 inheritableThreadLocals 变量，它们都是 ThreadLocalMap 类型的变量,我们可以把 ThreadLocalMap 理解为ThreadLocal 类实现的定制化的 HashMap。默认情况下这两个变量都是null，只有当前线程调用 ThreadLocal 类的 set或get方法时才创建它们，实际上调用这两个方法的时候，我们调用的是ThreadLocalMap类对应的 get()、set()方法。
ThreadLocal类的set()方法

  1. public void set(T value) {
  2. Thread t = Thread.currentThread();
  3. ThreadLocalMap map = getMap(t);
  4. if (map != null)
  5. map.set(this, value);
  6. else
  7. createMap(t, value);
  8. }
  9. ThreadLocalMap getMap(Thread t) {
  10. return t.threadLocals;
  11. }

通过上面这些内容，我们足以通过猜测得出结论：最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，ThreadLocal 可以理解为只是ThreadLocalMap的封装，传递了变量值。 ThrealLocal 类中可以通过Thread.currentThread()获取到当前线程对象后，直接通过getMap(Thread t)可以访问到该线程的ThreadLocalMap对象。
每个Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal为key的键值对。 比如我们在同一个线程中声明了两个 ThreadLocal 对象的话，会使用 Thread内部都是使用仅有那个ThreadLocalMap 存放数据的，ThreadLocalMap的 key 就是 ThreadLocal对象，value 就是 ThreadLocal 对象调用set方法设置的值。ThreadLocal 是 map结构是为了让每个线程可以关联多个 ThreadLocal变量。这也就解释了 ThreadLocal 声明的变量为什么在每一个线程都有自己的专属本地变量。
ThreadLocalMap是ThreadLocal的静态内部类。
Java 并发知识 - 图5

3.4. ThreadLocal 内存泄露问题

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用,而 value 是强引用。所以，如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会 key 会被清理掉，而 value 不会被清理掉。这样一来，ThreadLocalMap 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal方法后 最好手动调用remove()方法

  1. static class Entry extends WeakReference<ThreadLocal<?>> {
  2. /** The value associated with this ThreadLocal. */
  3. Object value;

  5. Entry(ThreadLocal<?> k, Object v) {
  6. super(k);
  7. value = v;
  8. }
  9. }

弱引用介绍：

如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

4. 线程池

4.1. 为什么要用线程池？

线程池提供了一种限制和管理资源（包括执行一个任务）。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。
这里借用《Java并发编程的艺术》提到的来说一下使用线程池的好处：

  • 降低资源消耗。 通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
  • 提高响应速度。 当任务到达时，任务可以不需要的等到线程创建就能立即执行。
  • 提高线程的可管理性。 线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

    4.2. 实现Runnable接口和Callable接口的区别

    如果想让线程池执行任务的话需要实现的Runnable接口或Callable接口。 Runnable接口或Callable接口实现类都可以被ThreadPoolExecutor或ScheduledThreadPoolExecutor执行。两者的区别在于 Runnable 接口不会返回结果但是 Callable 接口可以返回结果。
    备注： 工具类Executors可以实现Runnable对象和Callable对象之间的相互转换。（Executors.callable（Runnable task）或Executors.callable（Runnable task，Object resule））。

    4.3. 执行execute()方法和submit()方法的区别是什么呢？

    1)execute() 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；
    2)submit() 方法用于提交需要返回值的任务。线程池会返回一个Future类型的对象，通过这个Future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用 get（long timeout，TimeUnit unit）方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。

    4.4. 如何创建线程池

    《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

    Executors 返回线程池对象的弊端如下：

    • FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列长度为 Integer.MAX_VALUE ，可能堆积大量的请求，从而导致OOM。
    • CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。

方式一：通过构造方法实现 Java 并发知识 - 图6
我们以最后一个构造方法（参数最多的那个），对其参数进行解释：

  1. public ThreadPoolExecutor(int corePoolSize, // 1
  2.                               int maximumPoolSize,  // 2
  3.                               long keepAliveTime,  // 3
  4.                               TimeUnit unit,  // 4
  5.                               BlockingQueue<Runnable> workQueue, // 5
  6.                               ThreadFactory threadFactory,  // 6
  7.                               RejectedExecutionHandler handler ) { //7
  8.         if (corePoolSize < 0 ||
  9.             maximumPoolSize <= 0 ||
  10.             maximumPoolSize < corePoolSize ||
  11.             keepAliveTime < 0)
  12.             throw new IllegalArgumentException();
  13.         if (workQueue == null || threadFactory == null || handler == null)
  14.             throw new NullPointerException();
  15.         this.corePoolSize = corePoolSize;
  16.         this.maximumPoolSize = maximumPoolSize;
  17.         this.workQueue = workQueue;
  18.         this.keepAliveTime = unit.toNanos(keepAliveTime);
  19.         this.threadFactory = threadFactory;
  20.         this.handler = handler;
  21.     }
序号 名称 类型 含义
1 corePoolSize int 核心线程池大小
2 maximumPoolSize int 最大线程池大小
3 keepAliveTime long 线程最大空闲时间
4 unit TimeUnit 时间单位
5 workQueue BlockingQueue 线程等待队列
6 threadFactory ThreadFactory 线程创建工厂
7 handler RejectedExecutionHandler 拒绝策略

一、Core and maximum pool sizes 核心和最大线程池数量

参数 翻译
corePoolSize 核心线程池数量
maximumPoolSize 最大线程池数量

线程池执行器将会根据corePoolSize和maximumPoolSize自动地调整线程池大小。
当在execute(Runnable)方法中提交新任务并且少于corePoolSize线程正在运行时，即使其他工作线程处于空闲状态，也会创建一个新线程来处理该请求。 如果有多于corePoolSize但小于maximumPoolSize线程正在运行，则仅当队列已满时才会创建新线程。 通过设置corePoolSize和maximumPoolSize相同，您可以创建一个固定大小的线程池。 通过将maximumPoolSize设置为基本上无界的值，例如Integer.MAX_VALUE，您可以允许池容纳任意数量的并发任务。 通常，核心和最大池大小仅在构建时设置，但也可以使用setCorePoolSize和setMaximumPoolSize进行动态更改。
这段话详细了描述了线程池对任务的处理流程，这里用个图总结一下

image.png
二、prestartCoreThread 核心线程预启动**
在默认情况下，只有当新任务到达时，才开始创建和启动核心线程，但是我们可以使用 prestartCoreThread() 和 prestartAllCoreThreads() 方法动态调整。
如果使用非空队列构建池，则可能需要预先启动线程。

方法 作用
prestartCoreThread() 创一个空闲任务线程等待任务的到达
prestartAllCoreThreads() 创建核心线程池数量的空闲任务线程等待任务的到达

三、ThreadFactory 线程工厂
新线程使用ThreadFactory创建。 如果未另行指定，则使用Executors.defaultThreadFactory默认工厂，使其全部位于同一个ThreadGroup中，并且具有相同的NORM_PRIORITY优先级和非守护进程状态。
通过提供不同的ThreadFactory，您可以更改线程的名称，线程组，优先级，守护进程状态等。如果ThreadCactory在通过从newThread返回null询问时未能创建线程，则执行程序将继续，但可能无法执行任何任务。
线程应该有modifyThread权限。 如果工作线程或使用该池的其他线程不具备此权限，则服务可能会降级：配置更改可能无法及时生效，并且关闭池可能会保持可终止但尚未完成的状态。
四、Keep-alive times 线程存活时间
如果线程池当前拥有超过corePoolSize的线程，那么多余的线程在空闲时间超过keepAliveTime时会被终止 ( 请参阅getKeepAliveTime(TimeUnit) )。这提供了一种在不积极使用线程池时减少资源消耗的方法。
如果池在以后变得更加活跃，则应构建新线程。 也可以使用方法setKeepAliveTime(long，TimeUnit)进行动态调整。
防止空闲线程在关闭之前终止，可以使用如下方法：

setKeepAliveTime(Long.MAX_VALUE，TimeUnit.NANOSECONDS);

默认情况下，keep-alive策略仅适用于存在超过corePoolSize线程的情况。 但是，只要keepAliveTime值不为零，方法allowCoreThreadTimeOut(boolean)也可用于将此超时策略应用于核心线程。
五、Queuing 队列
BlockingQueu用于存放提交的任务，队列的实际容量与线程池大小相关联。

  • 如果当前线程池任务线程数量小于核心线程池数量，执行器总是优先创建一个任务线程，而不是从线程队列中取一个空闲线程。
  • 如果当前线程池任务线程数量大于核心线程池数量，执行器总是优先从线程队列中取一个空闲线程，而不是创建一个任务线程。
  • 如果当前线程池任务线程数量大于核心线程池数量，且队列中无空闲任务线程，将会创建一个任务线程，直到超出maximumPoolSize，如果超时maximumPoolSize，则任务将会被拒绝。

这个过程参考[线程任务处理流程图.png]
主要有三种队列策略：

  1. Direct handoffs 直接握手队列
    Direct handoffs 的一个很好的默认选择是 SynchronousQueue，它将任务交给线程而不需要保留。这里，如果没有线程立即可用来运行它，那么排队任务的尝试将失败，因此将构建新的线程。
    此策略在处理可能具有内部依赖关系的请求集时避免锁定。Direct handoffs 通常需要无限制的maximumPoolSizes来避免拒绝新提交的任务。 但得注意，当任务持续以平均提交速度大余平均处理速度时，会导致线程数量会无限增长问题。
  2. Unbounded queues 无界队列
    当所有corePoolSize线程繁忙时，使用无界队列（例如，没有预定义容量的LinkedBlockingQueue）将导致新任务在队列中等待，从而导致maximumPoolSize的值没有任何作用。当每个任务互不影响，完全独立于其他任务时，这可能是合适的; 例如，在网页服务器中， 这种队列方式可以用于平滑瞬时大量请求。但得注意，当任务持续以平均提交速度大余平均处理速度时，会导致队列无限增长问题。
  3. Bounded queues 有界队列
    一个有界的队列（例如，一个ArrayBlockingQueue）和有限的maximumPoolSizes配置有助于防止资源耗尽，但是难以控制。队列大小和maximumPoolSizes需要 相互权衡：
  • 使用大队列和较小的maximumPoolSizes可以最大限度地减少CPU使用率，操作系统资源和上下文切换开销，但会导致人为的低吞吐量。如果任务经常被阻塞（比如I/O限制），那么系统可以调度比我们允许的更多的线程。
  • 使用小队列通常需要较大的maximumPoolSizes，这会使CPU更繁忙，但可能会遇到不可接受的调度开销，这也会降低吞吐量。
    这里主要为了说明有界队列大小和maximumPoolSizes的大小控制，若何降低资源消耗的同时，提高吞吐量

六、Rejected tasks 拒绝任务
拒绝任务有两种情况：1. 线程池已经被关闭；2. 任务队列已满且maximumPoolSizes已满；
无论哪种情况，都会调用RejectedExecutionHandler的rejectedExecution方法。预定义了四种处理策略：

  1. AbortPolicy：默认测策略，抛出RejectedExecutionException运行时异常；
  2. CallerRunsPolicy：这提供了一个简单的反馈控制机制，可以减慢提交新任务的速度；
  3. DiscardPolicy：直接丢弃新提交的任务；
  4. DiscardOldestPolicy：如果执行器没有关闭，队列头的任务将会被丢弃，然后执行器重新尝试执行任务（如果失败，则重复这一过程）；
    我们可以自己定义RejectedExecutionHandler，以适应特殊的容量和队列策略场景中。

七、Hook methods 钩子方法
ThreadPoolExecutor为提供了每个任务执行前后提供了钩子方法，重写beforeExecute(Thread，Runnable)和afterExecute(Runnable，Throwable)方法来操纵执行环境； 例如，重新初始化ThreadLocals，收集统计信息或记录日志等。此外，terminated()在Executor完全终止后需要完成后会被调用，可以重写此方法，以执行任殊处理。
注意：如果hook或回调方法抛出异常，内部的任务线程将会失败并结束。
八、Queue maintenance 维护队列
getQueue()方法可以访问任务队列，一般用于监控和调试。绝不建议将这个方法用于其他目的。当在大量的队列任务被取消时，remove()和purge()方法可用于回收空间。
九、Finalization 关闭
如果程序中不在持有线程池的引用，并且线程池中没有线程时，线程池将会自动关闭。如果您希望确保即使用户忘记调用 shutdown()方法也可以回收未引用的线程池，使未使用线程最终死亡。那么必须通过设置适当的 keep-alive times 并设置allowCoreThreadTimeOut(boolean) 或者 使 corePoolSize下限为0 。
一般情况下，线程池启动后建议手动调用shutdown()关闭。

方式二：通过Executor 框架的工具类Executors来实现 我们可以创建三种类型的ThreadPoolExecutor：

  • FixedThreadPool ： 该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
  • SingleThreadExecutor： 方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
  • CachedThreadPool： 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。

对应Executors工具类中的方法如图所示： Java 并发知识 - 图8

5. Atomic 原子类

5.1. 介绍一下Atomic 原子类

Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。
所以，所谓原子类说简单点就是具有原子/原子操作特征的类。
并发包 java.util.concurrent 的原子类都存放在java.util.concurrent.atomic下,如下图所示。
Java 并发知识 - 图9

5.2. JUC 包中的原子类是哪4类?

基本类型
使用原子的方式更新基本类型

  • AtomicInteger：整形原子类
  • AtomicLong：长整型原子类
  • AtomicBoolean：布尔型原子类

数组类型
使用原子的方式更新数组里的某个元素

  • AtomicIntegerArray：整形数组原子类
  • AtomicLongArray：长整形数组原子类
  • AtomicReferenceArray：引用类型数组原子类

引用类型

  • AtomicReference：引用类型原子类
  • AtomicStampedReference：原子更新引用类型里的字段原子类
  • AtomicMarkableReference ：原子更新带有标记位的引用类型

对象的属性修改类型

  • AtomicIntegerFieldUpdater：原子更新整形字段的更新器
  • AtomicLongFieldUpdater：原子更新长整形字段的更新器
  • AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。

    5.3. 讲讲 AtomicInteger 的使用

    AtomicInteger 类常用方法
  1. public final int get() //获取当前的值
  2. public final int getAndSet(int newValue)//获取当前的值，并设置新的值
  3. public final int getAndIncrement()//获取当前的值，并自增
  4. public final int getAndDecrement() //获取当前的值，并自减
  5. public final int getAndAdd(int delta) //获取当前的值，并加上预期的值
  6. boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将该值设置为输入值（update）
  7. public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。

AtomicInteger 类的使用示例
使用 AtomicInteger 之后，不用对 increment() 方法加锁也可以保证线程安全。

  1. class AtomicIntegerTest {
  2. private AtomicInteger count = new AtomicInteger();
  3. //使用AtomicInteger之后，不需要对该方法加锁，也可以实现线程安全。
  4. public void increment() {
  5. count.incrementAndGet();
  6. }

  8. public int getCount() {
  9. return count.get();
  10. }

  11. }

    5.4. 能不能给我简单介绍一下 AtomicInteger 类的原理

    AtomicInteger 线程安全原理简单分析
    AtomicInteger 类的部分源码：

  12. // setup to use Unsafe.compareAndSwapInt for updates（更新操作时提供“比较并替换”的作用）

  13. private static final Unsafe unsafe = Unsafe.getUnsafe();
  14. private static final long valueOffset;

  16. static {
  17. try {
  18. valueOffset = unsafe.objectFieldOffset
  19. (AtomicInteger.class.getDeclaredField("value"));
  20. } catch (Exception ex) { throw new Error(ex); }
  21. }

  23. private volatile int value;

AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。
CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个volatile变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。
关于 Atomic 原子类这部分更多内容可以查看我的这篇文章：并发编程面试必备：JUC 中的 Atomic 原子类总结

6. AQS

6.1. AQS 介绍

AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。
Java 并发知识 - 图10
AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。

6.2. AQS 原理分析

AQS 原理这部分参考了部分博客，在5.2节末尾放了链接。

在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于AQS原理的理解”。下面给大家一个示例供大家参加，面试不是背题，大家一定要加入自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。

下面大部分内容其实在AQS类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话可以看看源码。

6.2.1. AQS 原理概览

AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。

看个AQS(AbstractQueuedSynchronizer)原理图：
Java 并发知识 - 图11
AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该同步状态进行原子操作实现对其值的修改。

  1. private volatile int state;//共享变量，使用volatile修饰保证线程可见性

状态信息通过protected类型的getState，setState，compareAndSetState进行操作


  2. //返回同步状态的当前值
  3. protected final int getState() {
  4. return state;
  5. }
  6. // 设置同步状态的值
  7. protected final void setState(int newState) {
  8. state = newState;
  9. }
  10. //原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
  11. protected final boolean compareAndSetState(int expect, int update) {
  12. return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
  13. }

    6.2.2. AQS 对资源的共享方式

    AQS定义两种资源共享方式
  • Exclusive（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁：
    • 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
    • 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
  • Share（共享）：多个线程可同时执行，如Semaphore/CountDownLatch。Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。

ReentrantReadWriteLock 可以看成是组合式，因为ReentrantReadWriteLock也就是读写锁允许多个线程同时对某一资源进行读。
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。

6.2.3. AQS底层使用了模板方法模式

同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：

  1. 使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
  2. 将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。

这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。
AQS使用了模板方法模式，自定义同步器时需要重写下面几个AQS提供的模板方法：

  1. isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
  2. tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
  3. tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
  4. tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
  5. tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。

默认情况下，每个方法都抛出 UnsupportedOperationException。 这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。
以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。
再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。
推荐两篇 AQS 原理和相关源码分析的文章：

  • http://www.cnblogs.com/waterystone/p/4920797.html

  • https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html

    6.3. AQS 组件总结

  • Semaphore(信号量)-允许多个线程同时访问： synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。

  • CountDownLatch （倒计时器）： CountDownLatch是一个同步工具类，用来协调多个线程之间的同步。这个工具通常用来控制线程等待，它可以让某一个线程等待直到倒计时结束，再开始执行。

  • CyclicBarrier(循环栅栏)： CyclicBarrier 和 CountDownLatch 非常类似，它也可以实现线程间的技术等待，但是它的功能比 CountDownLatch 更加复杂和强大。主要应用场景和 CountDownLatch 类似。CyclicBarrier 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。CyclicBarrier默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用await()方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

    7 Reference

  • 《深入理解 Java 虚拟机》

  • 《实战 Java 高并发程序设计》
  • 《Java并发编程的艺术》
  • http://www.cnblogs.com/waterystone/p/4920797.html
  • https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html
  • https://www.journaldev.com/1076/java-threadlocal-example

Java CAS 原理分析

1.简介

CAS 全称是 compare and swap，是一种用于在多线程环境下实现同步功能的机制。CAS 操作包含三个操作数 — 内存位置、预期数值和新值。CAS 的实现逻辑是将内存位置处的数值与预期数值想比较，若相等，则将内存位置处的值替换为新值。若不相等，则不做任何操作。
在 Java 中，Java 并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的。Java 代码需通过 JNI 才能调用。关于实现上的细节，我将会在第3章进行分析。
前面说了 CAS 操作的流程，并不是很难。但仅有上面的说明还不够，接下来我将会再介绍一点其他的背景知识。有这些背景知识，才能更好的理解后续的内容。

2.背景介绍

我们都知道，CPU 是通过总线和内存进行数据传输的。在多核心时代下，多个核心通过同一条总线和内存以及其他硬件进行通信。如下图：
Java 并发知识 - 图12
图片出处：《深入理解计算机系统》
上图是一个较为简单的计算机结构图，虽然简单，但足以说明问题。在上图中，CPU 通过两个蓝色箭头标注的总线与内存进行通信。大家考虑一个问题，CPU 的多个核心同时对同一片内存进行操作，若不加以控制，会导致什么样的错误？这里简单说明一下，假设核心1经32位带宽的总线向内存写入64位的数据，核心1要进行两次写入才能完成整个操作。若在核心1第一次写入32位的数据后，核心2从核心1写入的内存位置读取了64位数据。由于核心1还未完全将64位的数据全部写入内存中，核心2就开始从该内存位置读取数据，那么读取出来的数据必定是混乱的。
不过对于这个问题，实际上不用担心。通过 Intel 开发人员手册，我们可以了解到自奔腾处理器开始，Intel 处理器会保证以原子的方式读写按64位边界对齐的四字（quadword）。
根据上面的说明，我们可总结出，Intel 处理器可以保证单次访问内存对齐的指令以原子的方式执行。但如果是两次访存的指令呢？答案是无法保证。比如递增指令inc dword ptr [...]，等价于DEST = DEST + 1。该指令包含三个操作读->改->写，涉及两次访存。考虑这样一种情况，在内存指定位置处，存放了一个为1的数值。现在 CPU 两个核心同时执行该条指令。两个核心交替执行的流程如下：

  1. 核心1 从内存指定位置出读取数值1，并加载到寄存器中
  2. 核心2 从内存指定位置出读取数值1，并加载到寄存器中
  3. 核心1 将寄存器中值递减1
  4. 核心2 将寄存器中值递减1
  5. 核心1 将修改后的值写回内存
  6. 核心2 将修改后的值写回内存

经过执行上述流程，内存中的最终值时2，而我们期待的是3，这就出问题了。要处理这个问题，就要避免两个或多个核心同时操作同一片内存区域。那么怎样避免呢？这就要引入本文的主角 - lock 前缀。关于该指令的详细描述，可以参考 Intel 开发人员手册 Volume 2 Instruction Set Reference，Chapter 3 Instruction Set Reference A-L。我这里引用其中的一段，如下： LOCK—Assert LOCK# Signal PrefixCauses the processor’s LOCK# signal to be asserted during execution of the accompanying instruction (> turns the instruction into an atomic instruction). In a multiprocessor environment, the LOCK# signal > ensures that the processor has exclusive use of any shared memory while the signal is asserted. 上面描述的重点已经用黑体标出了，在多处理器环境下，LOCK# 信号可以确保处理器独占使用某些共享内存。lock 可以被添加在下面的指令前：
ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG.
通过在 inc 指令前添加 lock 前缀，即可让该指令具备原子性。多个核心同时执行同一条 inc 指令时，会以串行的方式进行，也就避免了上面所说的那种情况。那么这里还有一个问题，lock 前缀是怎样保证核心独占某片内存区域的呢？答案如下：
在 Intel 处理器中，有两种方式保证处理器的某个核心独占某片内存区域。第一种方式是通过锁定总线，让某个核心独占使用总线，但这样代价太大。总线被锁定后，其他核心就不能访问内存了，可能会导致其他核心短时内停止工作。第二种方式是锁定缓存，若某处内存数据被缓存在处理器缓存中。处理器发出的 LOCK# 信号不会锁定总线，而是锁定缓存行对应的内存区域。其他处理器在这片内存区域锁定期间，无法对这片内存区域进行相关操作。相对于锁定总线，锁定缓存的代价明显比较小。关于总线锁和缓存锁，更详细的描述请参考 Intel 开发人员手册 Volume 3 Software Developer’s Manual，Chapter 8 Multiple-Processor Management。

3.源码分析

有了上面的背景知识，现在我们就可以从容不迫的阅读 CAS 的源码了。本章的内容将对 java.util.concurrent.atomic 包下的原子类 AtomicInteger 中的 compareAndSet 方法进行分析，相关分析如下：

  1. public class AtomicInteger extends Number implements java.io.Serializable {
  2.     // setup to use Unsafe.compareAndSwapInt for updates
  3.     private static final Unsafe unsafe = Unsafe.getUnsafe();
  4.     private static final long valueOffset;
  5.     static {
  6.         try {
  7.             // 计算变量 value 在类对象中的偏移
  8.             valueOffset = unsafe.objectFieldOffset
  9.                 (AtomicInteger.class.getDeclaredField("value"));
  10.         } catch (Exception ex) { throw new Error(ex); }
  11.     }
  12.     private volatile int value;
  14.     public final boolean compareAndSet(int expect, int update) {
  15.         /*
  16.          * compareAndSet 实际上只是一个壳子，主要的逻辑封装在 Unsafe 的 
  17.          * compareAndSwapInt 方法中
  18.          */
  19.         return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
  20.     }
  22.     // ......
  23. }
  24. public final class Unsafe {
  25.     // compareAndSwapInt 是 native 类型的方法，继续往下看
  26.     public final native boolean compareAndSwapInt(Object o, long offset,
  27.                                                   int expected,
  28.                                                   int x);
  29.     // ......
  30. }
  1. // unsafe.cpp
  2. /*
  3.  * 这个看起来好像不像一个函数，不过不用担心，不是重点。UNSAFE_ENTRY 和 UNSAFE_END 都是宏，
  4.  * 在预编译期间会被替换成真正的代码。下面的 jboolean、jlong 和 jint 等是一些类型定义（typedef）：
  5.  * 
  6.  * jni.h
  7.  *     typedef unsigned char   jboolean;
  8.  *     typedef unsigned short  jchar;
  9.  *     typedef short           jshort;
  10.  *     typedef float           jfloat;
  11.  *     typedef double          jdouble;
  12.  * 
  13.  * jni_md.h
  14.  *     typedef int jint;
  15.  *     #ifdef _LP64 // 64-bit
  16.  *     typedef long jlong;
  17.  *     #else
  18.  *     typedef long long jlong;
  19.  *     #endif
  20.  *     typedef signed char jbyte;
  21.  */
  22. UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
  23.   UnsafeWrapper("Unsafe_CompareAndSwapInt");
  24.   oop p = JNIHandles::resolve(obj);
  25.   // 根据偏移量，计算 value 的地址。这里的 offset 就是 AtomaicInteger 中的 valueOffset
  26.   jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
  27.   // 调用 Atomic 中的函数 cmpxchg，该函数声明于 Atomic.hpp 中
  28.   return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
  29. UNSAFE_END
  30. // atomic.cpp
  31. unsigned Atomic::cmpxchg(unsigned int exchange_value,
  32.                          volatile unsigned int* dest, unsigned int compare_value) {
  33.   assert(sizeof(unsigned int) == sizeof(jint), "more work to do");
  34.   /*
  35.    * 根据操作系统类型调用不同平台下的重载函数，这个在预编译期间编译器会决定调用哪个平台下的重载
  36.    * 函数。相关的预编译逻辑如下：
  37.    * 
  38.    * atomic.inline.hpp：
  39.    *    #include "runtime/atomic.hpp"
  40.    *    
  41.    *    // Linux
  42.    *    #ifdef TARGET_OS_ARCH_linux_x86
  43.    *    # include "atomic_linux_x86.inline.hpp"
  44.    *    #endif
  45.    *   
  46.    *    // 省略部分代码
  47.    *    
  48.    *    // Windows
  49.    *    #ifdef TARGET_OS_ARCH_windows_x86
  50.    *    # include "atomic_windows_x86.inline.hpp"
  51.    *    #endif
  52.    *    
  53.    *    // BSD
  54.    *    #ifdef TARGET_OS_ARCH_bsd_x86
  55.    *    # include "atomic_bsd_x86.inline.hpp"
  56.    *    #endif
  57.    * 
  58.    * 接下来分析 atomic_windows_x86.inline.hpp 中的 cmpxchg 函数实现
  59.    */
  60.   return (unsigned int)Atomic::cmpxchg((jint)exchange_value, (volatile jint*)dest,
  61.                                        (jint)compare_value);
  62. }

上面的分析看起来比较多，不过主流程并不复杂。如果不纠结于代码细节，还是比较容易看懂的。接下来，我会分析 Windows 平台下的 Atomic::cmpxchg 函数。继续往下看吧。

  1. // atomic_windows_x86.inline.hpp
  2. #define LOCK_IF_MP(mp) __asm cmp mp, 0  \
  3.                        __asm je L0      \
  4.                        __asm _emit 0xF0 \
  5.                        __asm L0:
  7. inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
  8.   // alternative for InterlockedCompareExchange
  9.   int mp = os::is_MP();
  10.   __asm {
  11.     mov edx, dest
  12.     mov ecx, exchange_value
  13.     mov eax, compare_value
  14.     LOCK_IF_MP(mp)
  15.     cmpxchg dword ptr [edx], ecx
  16.   }
  17. }

上面的代码由 LOCK_IF_MP 预编译标识符和 cmpxchg 函数组成。为了看到更清楚一些，我们将 cmpxchg 函数中的 LOCK_IF_MP 替换为实际内容。如下：

  1. inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
  2.   // 判断是否是多核 CPU
  3.   int mp = os::is_MP();
  4.   __asm {
  5.     // 将参数值放入寄存器中
  6.     mov edx, dest    // 注意: dest 是指针类型，这里是把内存地址存入 edx 寄存器中
  7.     mov ecx, exchange_value
  8.     mov eax, compare_value
  10.     // LOCK_IF_MP
  11.     cmp mp, 0
  12.     /*
  13.      * 如果 mp = 0，表明是线程运行在单核 CPU 环境下。此时 je 会跳转到 L0 标记处，
  14.      * 也就是越过 _emit 0xF0 指令，直接执行 cmpxchg 指令。也就是不在下面的 cmpxchg 指令
  15.      * 前加 lock 前缀。
  16.      */
  17.     je L0
  18.     /*
  19.      * 0xF0 是 lock 前缀的机器码，这里没有使用 lock，而是直接使用了机器码的形式。至于这样做的
  20.      * 原因可以参考知乎的一个回答：
  21.      *     https://www.zhihu.com/question/50878124/answer/123099923
  22.      */ 
  23.     _emit 0xF0
  24. L0:
  25.     /*
  26.      * 比较并交换。简单解释一下下面这条指令，熟悉汇编的朋友可以略过下面的解释:
  27.      *   cmpxchg: 即“比较并交换”指令
  28.      *   dword: 全称是 double word，在 x86/x64 体系中，一个 
  29.      *          word = 2 byte，dword = 4 byte = 32 bit
  30.      *   ptr: 全称是 pointer，与前面的 dword 连起来使用，表明访问的内存单元是一个双字单元
  31.      *   [edx]: [...] 表示一个内存单元，edx 是寄存器，dest 指针值存放在 edx 中。
  32.      *          那么 [edx] 表示内存地址为 dest 的内存单元
  33.      *          
  34.      * 这一条指令的意思就是，将 eax 寄存器中的值（compare_value）与 [edx] 双字内存单元中的值
  35.      * 进行对比，如果相同，则将 ecx 寄存器中的值（exchange_value）存入 [edx] 内存单元中。
  36.      */
  37.     cmpxchg dword ptr [edx], ecx
  38.   }
  39. }

到这里 CAS 的实现过程就讲完了，CAS 的实现离不开处理器的支持。以上这么多代码，其实核心代码就是一条带lock 前缀的 cmpxchg 指令，即lock cmpxchg dword ptr [edx], ecx。

4.ABA 问题

谈到 CAS，基本上都要谈一下 CAS 的 ABA 问题。CAS 由三个步骤组成，分别是“读取->比较->写回”。考虑这样一种情况，线程1和线程2同时执行 CAS 逻辑，两个线程的执行顺序如下：

  1. 时刻1：线程1执行读取操作，获取原值 A，然后线程被切换走
  2. 时刻2：线程2执行完成 CAS 操作将原值由 A 修改为 B
  3. 时刻3：线程2再次执行 CAS 操作，并将原值由 B 修改为 A
  4. 时刻4：线程1恢复运行，将比较值（compareValue）与原值（oldValue）进行比较，发现两个值相等。然后用新值（newValue）写入内存中，完成 CAS 操作

如上流程，线程1并不知道原值已经被修改过了，在它看来并没什么变化，所以它会继续往下执行流程。对于 ABA 问题，通常的处理措施是对每一次 CAS 操作设置版本号。java.util.concurrent.atomic 包下提供了一个可处理 ABA 问题的原子类 AtomicStampedReference，具体的实现这里就不分析了，有兴趣的朋友可以自己去看看。

5.总结

写到这里，这篇文章总算接近尾声了。虽然 CAS 本身的原理，包括实现都不是很难，但是写起来真的不太好写。这里面涉及到了一些底层的知识，虽然能看懂，但想说明白，还是有点难度的。由于我底层的知识比较欠缺，上面的一些分析难免会出错。所以如有错误，请轻喷，当然最好能说明怎么错的，感谢。
好了，本篇文章就到这里。感谢阅读，再见。

参考

文件名 路径
Unsafe.java openjdk/jdk/src/share/classes/sun/misc/Unsafe.java
unsafe.cpp openjdk/hotspot/src/share/vm/prims/unsafe.cpp
atomic.cpp openjdk/hotspot/src/share/vm/runtime/atomic.cpp
atomic_windows_x86.inline.hpp openjdk/hotspot/src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp

本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处作者：coolblog本文同步发布在我的个人博客：> http://www.coolblog.xyz Java 并发知识 - 图13
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

Java并发编程：Callable、Future和FutureTask

　　在前面的文章中我们讲述了创建线程的2种方式，一种是直接继承Thread，另外一种就是实现Runnable接口。
　　这2种方式都有一个缺陷就是：在执行完任务之后无法获取执行结果。
　　如果需要获取执行结果，就必须通过共享变量或者使用线程通信的方式来达到效果，这样使用起来就比较麻烦。
　　而自从Java 1.5开始，就提供了Callable和Future，通过它们可以在任务执行完毕之后得到任务执行结果。
　　今天我们就来讨论一下Callable、Future和FutureTask三个类的使用方法。以下是本文的目录大纲：
　　一.Callable与Runnable
　　二.Future
　　三.FutureTask
　　四.使用示例
　　若有不正之处请多多谅解，并欢迎批评指正。
　　请尊重作者劳动成果，转载请标明原文链接：
　　http://www.cnblogs.com/dolphin0520/p/3949310.html

一.Callable与Runnable

　　先说一下java.lang.Runnable吧，它是一个接口，在它里面只声明了一个run()方法：

public interface Runnable {
``public abstract void run();
}

　　由于run()方法返回值为void类型，所以在执行完任务之后无法返回任何结果。
　　Callable位于java.util.concurrent包下，它也是一个接口，在它里面也只声明了一个方法，只不过这个方法叫做call()：

public interface Callable<V> {
``/**
``* Computes a result, or throws an exception if unable to do so.
``*
``* @return computed result
``* @throws Exception if unable to compute a result
``*/
``V call() ``throws Exception;
}

　　可以看到，这是一个泛型接口，call()函数返回的类型就是传递进来的V类型。
　　那么怎么使用Callable呢？一般情况下是配合ExecutorService来使用的，在ExecutorService接口中声明了若干个submit方法的重载版本：

<T> Future<T> submit(Callable<T> task);
<T> Future<T> submit(Runnable task, T result);
Future<?> submit(Runnable task);

　　第一个submit方法里面的参数类型就是Callable。
　　暂时只需要知道Callable一般是和ExecutorService配合来使用的，具体的使用方法讲在后面讲述。
　　一般情况下我们使用第一个submit方法和第三个submit方法，第二个submit方法很少使用。

二.Future

　　Future就是对于具体的Runnable或者Callable任务的执行结果进行取消、查询是否完成、获取结果。必要时可以通过get方法获取执行结果，该方法会阻塞直到任务返回结果。
　　Future类位于java.util.concurrent包下，它是一个接口：

public interface Future<V> {
``boolean cancel(``boolean mayInterruptIfRunning);
``boolean isCancelled();
``boolean isDone();
``V get() ``throws InterruptedException, ExecutionException;
``V get(``long timeout, TimeUnit unit)
``throws InterruptedException, ExecutionException, TimeoutException;
}

　　在Future接口中声明了5个方法，下面依次解释每个方法的作用：

  • cancel方法用来取消任务，如果取消任务成功则返回true，如果取消任务失败则返回false。参数mayInterruptIfRunning表示是否允许取消正在执行却没有执行完毕的任务，如果设置true，则表示可以取消正在执行过程中的任务。如果任务已经完成，则无论mayInterruptIfRunning为true还是false，此方法肯定返回false，即如果取消已经完成的任务会返回false；如果任务正在执行，若mayInterruptIfRunning设置为true，则返回true，若mayInterruptIfRunning设置为false，则返回false；如果任务还没有执行，则无论mayInterruptIfRunning为true还是false，肯定返回true。
  • isCancelled方法表示任务是否被取消成功，如果在任务正常完成前被取消成功，则返回 true。
  • isDone方法表示任务是否已经完成，若任务完成，则返回true；
  • get()方法用来获取执行结果，这个方法会产生阻塞，会一直等到任务执行完毕才返回；
  • get(long timeout, TimeUnit unit)用来获取执行结果，如果在指定时间内，还没获取到结果，就直接返回null。

　　也就是说Future提供了三种功能：
　　1）判断任务是否完成；
　　2）能够中断任务；
　　3）能够获取任务执行结果。
　　因为Future只是一个接口，所以是无法直接用来创建对象使用的，因此就有了下面的FutureTask。

三.FutureTask

　　我们先来看一下FutureTask的实现：

public class FutureTask<V> ``implements RunnableFuture<V>

　　FutureTask类实现了RunnableFuture接口，我们看一下RunnableFuture接口的实现：

public interface RunnableFuture<V> ``extends Runnable, Future<V> {
``void run();
}

　　可以看出RunnableFuture继承了Runnable接口和Future接口，而FutureTask实现了RunnableFuture接口。所以它既可以作为Runnable被线程执行，又可以作为Future得到Callable的返回值。
　　FutureTask提供了2个构造器：

public FutureTask(Callable<V> callable) {
}
public FutureTask(Runnable runnable, V result) {
}

　　事实上，FutureTask是Future接口的一个唯一实现类。

四.使用示例

　　1.使用Callable+Future获取执行结果

public class Test {
``public static void main(String[] args) {
``ExecutorService executor = Executors.newCachedThreadPool();
``Task task = ``new Task();
``Future<Integer> result = executor.submit(task);
``executor.shutdown();
`<br /> try` `{`<br />` Thread.sleep(1000);<br /> }catch`(InterruptedException e1) {
``e1.printStackTrace();
``}
`<br /> System.out.println(“主线程在执行任务”);`<br />` `<br />` try`{
``System.out.println(``"task运行结果"``+result.get());
``} ``catch (InterruptedException e) {
``e.printStackTrace();
``} ``catch (ExecutionException e) {
``e.printStackTrace();
``}
`<br /> System.out.println(“所有任务执行完毕”);`<br />` }<br />}<br />class`Task ``implements Callable<Integer>{
``@Override
``public Integer call() ``throws Exception {
``System.out.println(``"子线程在进行计算"``);
``Thread.sleep(``3000``);
``int sum = ``0``;
``for``(``int i=``0``;i<``100``;i++)
``sum += i;
``return sum;
``}
}

　　执行结果：
Java 并发知识 - 图14子线程在进行计算
主线程在执行任务
task运行结果4950
所有任务执行完毕

　　2.使用Callable+FutureTask获取执行结果

public class Test {
``public static void main(String[] args) {
``//第一种方式
``ExecutorService executor = Executors.newCachedThreadPool();
``Task task = ``new Task();
``FutureTask<Integer> futureTask = ``new FutureTask<Integer>(task);
``executor.submit(futureTask);
``executor.shutdown();
`<br /> //第二种方式，注意这种方式和第一种方式效果是类似的，只不过一个使用的是ExecutorService，一个使用的是Thread`<br />` /Task task = new Task();<br /> FutureTask<Integer> futureTask = new FutureTask<Integer>(task);`<br />` Thread thread = new Thread(futureTask);<br /> ``thread.start();/<br /> <br /> try` `{`<br />` Thread.sleep(1000);<br /> }catch`(InterruptedException e1) {
``e1.printStackTrace();
``}
`<br /> System.out.println(“主线程在执行任务”);`<br />` `<br />` try`{
``System.out.println(``"task运行结果"``+futureTask.get());
``} ``catch (InterruptedException e) {
``e.printStackTrace();
``} ``catch (ExecutionException e) {
``e.printStackTrace();
``}
`<br /> System.out.println(“所有任务执行完毕”);`<br />` }<br />}<br />class`Task ``implements Callable<Integer>{
``@Override
``public Integer call() ``throws Exception {
``System.out.println(``"子线程在进行计算"``);
``Thread.sleep(``3000``);
``int sum = ``0``;
``for``(``int i=``0``;i<``100``;i++)
``sum += i;
``return sum;
``}
}

　　如果为了可取消性而使用 Future 但又不提供可用的结果，则可以声明 Future<?> 形式类型、并返回 null 作为底层任务的结果。
作者：Matrix海子
出处：http://www.cnblogs.com/dolphin0520/
本博客中未标明转载的文章归作者Matrix海子和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

深入分析java线程池的实现原理

前言

线程是稀缺资源，如果被无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，合理的使用线程池对线程进行统一分配、调优和监控，有以下好处：
1、降低资源消耗；
2、提高响应速度；
3、提高线程的可管理性。
Java1.5中引入的Executor框架把任务的提交和执行进行解耦，只需要定义好任务，然后提交给线程池，而不用关心该任务是如何执行、被哪个线程执行，以及什么时候执行。

demo

Java 并发知识 - 图15
1、Executors.newFixedThreadPool(10)初始化一个包含10个线程的线程池executor；
2、通过executor.execute方法提交20个任务，每个任务打印当前的线程名；
3、负责执行任务的线程的生命周期都由Executor框架进行管理；

ThreadPoolExecutor

Executors是java线程池的工厂类，通过它可以快速初始化一个符合业务需求的线程池，如Executors.newFixedThreadPool方法可以生成一个拥有固定线程数的线程池。
Java 并发知识 - 图16
其本质是通过不同的参数初始化一个ThreadPoolExecutor对象，具体参数描述如下：

corePoolSize

线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize；如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；如果执行了线程池的prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程。

maximumPoolSize

线程池中允许的最大线程数。如果当前阻塞队列满了，且继续提交任务，则创建新的线程执行任务，前提是当前线程数小于maximumPoolSize；

keepAliveTime

线程空闲时的存活时间，即当线程没有任务执行时，继续存活的时间；默认情况下，该参数只在线程数大于corePoolSize时才有用；

unit

keepAliveTime的单位；

workQueue

用来保存等待被执行的任务的阻塞队列，且任务必须实现Runable接口，在JDK中提供了如下阻塞队列：
1、ArrayBlockingQueue：基于数组结构的有界阻塞队列，按FIFO排序任务；
2、LinkedBlockingQuene：基于链表结构的阻塞队列，按FIFO排序任务，吞吐量通常要高于ArrayBlockingQuene；
3、SynchronousQuene：一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQuene；
4、priorityBlockingQuene：具有优先级的无界阻塞队列；

threadFactory

创建线程的工厂，通过自定义的线程工厂可以给每个新建的线程设置一个具有识别度的线程名。
Java 并发知识 - 图17

handler

线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：
1、AbortPolicy：直接抛出异常，默认策略；
2、CallerRunsPolicy：用调用者所在的线程来执行任务；
3、DiscardOldestPolicy：丢弃阻塞队列中靠最前的任务，并执行当前任务；
4、DiscardPolicy：直接丢弃任务；
当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务。

Exectors

Exectors工厂类提供了线程池的初始化接口，主要有如下几种：

newFixedThreadPool

Java 并发知识 - 图18
初始化一个指定线程数的线程池，其中corePoolSize == maximumPoolSize，使用LinkedBlockingQuene作为阻塞队列，不过当线程池没有可执行任务时，也不会释放线程。

newCachedThreadPool

Java 并发知识 - 图19
1、初始化一个可以缓存线程的线程池，默认缓存60s，线程池的线程数可达到Integer.MAX_VALUE，即2147483647，内部使用SynchronousQueue作为阻塞队列；
2、和newFixedThreadPool创建的线程池不同，newCachedThreadPool在没有任务执行时，当线程的空闲时间超过keepAliveTime，会自动释放线程资源，当提交新任务时，如果没有空闲线程，则创建新线程执行任务，会导致一定的系统开销；
所以，使用该线程池时，一定要注意控制并发的任务数，否则创建大量的线程可能导致严重的性能问题。

newSingleThreadExecutor

Java 并发知识 - 图20
初始化的线程池中只有一个线程，如果该线程异常结束，会重新创建一个新的线程继续执行任务，唯一的线程可以保证所提交任务的顺序执行，内部使用LinkedBlockingQueue作为阻塞队列。

newScheduledThreadPool

Java 并发知识 - 图21
初始化的线程池可以在指定的时间内周期性的执行所提交的任务，在实际的业务场景中可以使用该线程池定期的同步数据。

实现原理

除了newScheduledThreadPool的内部实现特殊一点之外，其它几个线程池都是基于ThreadPoolExecutor类实现的。

线程池内部状态

Java 并发知识 - 图22
其中AtomicInteger变量ctl的功能非常强大：利用低29位表示线程池中线程数，通过高3位表示线程池的运行状态：
1、RUNNING：-1 << COUNT_BITS，即高3位为111，该状态的线程池会接收新任务，并处理阻塞队列中的任务；
2、SHUTDOWN： 0 << COUNT_BITS，即高3位为000，该状态的线程池不会接收新任务，但会处理阻塞队列中的任务；
3、STOP ： 1 << COUNT_BITS，即高3位为001，该状态的线程不会接收新任务，也不会处理阻塞队列中的任务，而且会中断正在运行的任务；
4、TIDYING ： 2 << COUNT_BITS，即高3位为010；
5、TERMINATED： 3 << COUNT_BITS，即高3位为011；

任务提交

线程池框架提供了两种方式提交任务，根据不同的业务需求选择不同的方式。

Executor.execute()

Java 并发知识 - 图23
通过Executor.execute()方法提交的任务，必须实现Runnable接口，该方式提交的任务不能获取返回值，因此无法判断任务是否执行成功。

ExecutorService.submit()

Java 并发知识 - 图24
通过ExecutorService.submit()方法提交的任务，可以获取任务执行完的返回值。

任务执行

当向线程池中提交一个任务，线程池会如何处理该任务？

execute实现

Java 并发知识 - 图25
具体的执行流程如下：
1、workerCountOf方法根据ctl的低29位，得到线程池的当前线程数，如果线程数小于corePoolSize，则执行addWorker方法创建新的线程执行任务；否则执行步骤（2）；
2、如果线程池处于RUNNING状态，且把提交的任务成功放入阻塞队列中，则执行步骤（3），否则执行步骤（4）；
3、再次检查线程池的状态，如果线程池没有RUNNING，且成功从阻塞队列中删除任务，则执行reject方法处理任务；
4、执行addWorker方法创建新的线程执行任务，如果addWoker执行失败，则执行reject方法处理任务；
Java 并发知识 - 图26

addWorker实现

从方法execute的实现可以看出：addWorker主要负责创建新的线程并执行任务，代码实现如下：
Java 并发知识 - 图27
这只是addWoker方法实现的前半部分：
1、判断线程池的状态，如果线程池的状态值大于或等SHUTDOWN，则不处理提交的任务，直接返回；
2、通过参数core判断当前需要创建的线程是否为核心线程，如果core为true，且当前线程数小于corePoolSize，则跳出循环，开始创建新的线程，具体实现如下：
Java 并发知识 - 图28
线程池的工作线程通过Woker类实现，在ReentrantLock锁的保证下，把Woker实例插入到HashSet后，并启动Woker中的线程，其中Worker类设计如下：
1、继承了AQS类，可以方便的实现工作线程的中止操作；
2、实现了Runnable接口，可以将自身作为一个任务在工作线程中执行；
3、当前提交的任务firstTask作为参数传入Worker的构造方法；
Java 并发知识 - 图29
从Woker类的构造方法实现可以发现：线程工厂在创建线程thread时，将Woker实例本身this作为参数传入，当执行start方法启动线程thread时，本质是执行了Worker的runWorker方法。

runWorker实现

Java 并发知识 - 图30
runWorker方法是线程池的核心：
1、线程启动之后，通过unlock方法释放锁，设置AQS的state为0，表示运行中断；
2、获取第一个任务firstTask，执行任务的run方法，不过在执行任务之前，会进行加锁操作，任务执行完会释放锁；
3、在执行任务的前后，可以根据业务场景自定义beforeExecute和afterExecute方法；
4、firstTask执行完成之后，通过getTask方法从阻塞队列中获取等待的任务，如果队列中没有任务，getTask方法会被阻塞并挂起，不会占用cpu资源；

getTask实现

Java 并发知识 - 图31
整个getTask操作在自旋下完成：
1、workQueue.take：如果阻塞队列为空，当前线程会被挂起等待；当队列中有任务加入时，线程被唤醒，take方法返回任务，并执行；
2、workQueue.poll：如果在keepAliveTime时间内，阻塞队列还是没有任务，则返回null；
所以，线程池中实现的线程可以一直执行由用户提交的任务。

Future和Callable实现

通过ExecutorService.submit()方法提交的任务，可以获取任务执行完的返回值。
Java 并发知识 - 图32
在实际业务场景中，Future和Callable基本是成对出现的，Callable负责产生结果，Future负责获取结果。
1、Callable接口类似于Runnable，只是Runnable没有返回值。
2、Callable任务除了返回正常结果之外，如果发生异常，该异常也会被返回，即Future可以拿到异步执行任务各种结果；
3、Future.get方法会导致主线程阻塞，直到Callable任务执行完成；

submit实现

Java 并发知识 - 图33
通过submit方法提交的Callable任务会被封装成了一个FutureTask对象。

FutureTask

Java 并发知识 - 图34
1、FutureTask在不同阶段拥有不同的状态state，初始化为NEW；
2、FutureTask类实现了Runnable接口，这样就可以通过Executor.execute方法提交FutureTask到线程池中等待被执行，最终执行的是FutureTask的run方法；

FutureTask.get实现

Java 并发知识 - 图35
内部通过awaitDone方法对主线程进行阻塞，具体实现如下：
Java 并发知识 - 图36
1、如果主线程被中断，则抛出中断异常；
2、判断FutureTask当前的state，如果大于COMPLETING，说明任务已经执行完成，则直接返回；
3、如果当前state等于COMPLETING，说明任务已经执行完，这时主线程只需通过yield方法让出cpu资源，等待state变成NORMAL；
4、通过WaitNode类封装当前线程，并通过UNSAFE添加到waiters链表；
5、最终通过LockSupport的park或parkNanos挂起线程；

FutureTask.run实现

Java 并发知识 - 图37
FutureTask.run方法是在线程池中被执行的，而非主线程
1、通过执行Callable任务的call方法；
2、如果call执行成功，则通过set方法保存结果；
3、如果call执行有异常，则通过setException保存异常；

set

Java 并发知识 - 图38

setException

Java 并发知识 - 图39
set和setException方法中，都会通过UnSAFE修改FutureTask的状态，并执行finishCompletion方法通知主线程任务已经执行完成；

finishCompletion

Java 并发知识 - 图40
1、执行FutureTask类的get方法时，会把主线程封装成WaitNode节点并保存在waiters链表中；
2、FutureTask任务执行完成后，通过UNSAFE设置waiters的值，并通过LockSupport类unpark方法唤醒主线程；

作者：占小狼
链接：https://www.jianshu.com/p/87bff5cc8d8c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Lock锁子类了解一下

上一篇已经将Lock锁的基础AQS简单地过了一遍了，因此本篇主要是讲解Lock锁主要的两个子类：

  • ReentrantLock
  • ReentrantReadWriteLock

那么接下来我们就开始吧~

一、ReentrantLock锁

首先我们来看看ReentrantLock锁的顶部注释，来看看他的相关特性呗：
Java 并发知识 - 图41
来总结一下要点吧：

  • 比synchronized更有伸缩性(灵活)
  • 支持公平锁(是相对公平的)

  • 使用时最标准用法是在try之前调用lock方法，在finally代码块释放锁

    1. class X {
    2.   private final ReentrantLock lock = new ReentrantLock();
    3.   // ...
    4.   public void m() { 
    5.       lock.lock();  // block until condition holds
    6.       try {
    7.           // ... method body
    8.       } finally {
    9.           lock.unlock()
    10.       }
    11.   }
    12. }

    1.1内部类

    首先我们可以看到有三个内部类：
    Java 并发知识 - 图42
    这些内部类都是AQS的子类，这就印证了我们之前所说的：AQS是ReentrantLock的基础，AQS是构建锁、同步器的框架

  • 可以很清晰的看到，我们的ReentrantLock锁是支持公平锁和非公平锁的~

Java 并发知识 - 图43

1.2构造方法

Java 并发知识 - 图44

1.3非公平lock方法

尝试获取锁，获取失败的话就调用AQS的acquire(1)方法
Java 并发知识 - 图45
acquire(1)方法我们在AQS时简单看过，其中tryAcquire()是子类来实现的
Java 并发知识 - 图46
我们去看看tryAcquire()：
Java 并发知识 - 图47

1.4公平lock方法

公平的lock方法其实就多了一个状态条件：
image.gif
这个方法主要是判断当前线程是否位于CLH同步队列中的第一个。如果是则返回flase，否则返回true。
image.gif

1.5unlock方法

image.gif
unlock方法也是在AQS中定义的：
image.gif
去看看tryRelease(arg)是怎么实现的：
image.gif

二、ReentrantReadWriteLock

我们知道synchronized内置锁和ReentrantLock都是互斥锁(一次只能有一个线程进入到临界区(被锁定的区域))
而ReentrantReadWriteLock是一个读写锁：

  • 在读取数据的时候，可以多个线程同时进入到到临界区(被锁定的区域)
  • 在写数据的时候，无论是读线程还是写线程都是互斥的

一般来说：我们大多数都是读取数据得多，修改数据得少。所以这个读写锁在这种场景下就很有用了！
读写锁有一个接口ReadWriteLock，定义的方法就两个：
Java 并发知识 - 图53
我们还是来看看顶部注释说得啥吧：
Java 并发知识 - 图54
其实大概也是说明了：在读的时候可以共享，在写的时候是互斥的
接下来我们还是来看看对应的实现类吧：
Java 并发知识 - 图55
按照惯例也简单看看它的顶部注释：
Java 并发知识 - 图56
于是我们可以总结出读写锁的一些要点了：

  • 读锁不支持条件对象，写锁支持条件对象
  • 读锁不能升级为写锁，写锁可以降级为读锁
  • 读写锁也有公平和非公平模式

  • 读锁支持多个读线程进入临界区，写锁是互斥的

    2.1ReentrantReadWriteLock内部类

    ReentrantReadWriteLock比ReentrantLock锁多了两个内部类(都是Lock实现)来维护读锁和写锁，但是主体还是使用Syn：

  • WriteLock

  • ReadLock

image.gif

2.2读锁和写锁的状态表示

在ReentrantLock锁上使用的是state来表示同步状态(也可以表示重入的次数)，而在ReentrantReadWriteLock是这样代表读写状态的：
image.gif

2.3写锁的获取

主要还是调用syn的acquire(1)：
image.gif
进去看看实现：
Java 并发知识 - 图60

2.4读锁获取

写锁的获取调用的是acquireShared(int arg)方法：
Java 并发知识 - 图61
内部调用的是：doAcquireShared(arg);方法(实现也是在Syn的)，我们来看看：
Java 并发知识 - 图62

三、最后

这里就简单总结一下本文的内容吧：

  • AQS是ReentrantReadWriteLock和ReentrantLock的基础，因为默认的实现都是在内部类Syn中，而Syn是继承AQS的~
  • ReentrantReadWriteLock和ReentrantLock都支持公平和非公平模式，公平模式下会去看FIFO队列线程是否是在队头，而非公平模式下是没有的
  • ReentrantReadWriteLock是一个读写锁，如果读的线程比写的线程要多很多的话，那可以考虑使用它。它使用state的变量高16位是读锁，低16位是写锁
  • 写锁可以降级为读锁，读锁不能升级为写锁
  • 写锁是互斥的，读锁是共享的。

总的来说看多线程源码难度系数还是好高啊，我目前的水平只能过一过了….
多线程后面还有挺多高深的知识点：Future、同步容器啊、阻塞队列、各种原子类啊等等等，这里我打算就先放一放了，目前的水平有限啊~

从ReentrantLock的实现看AQS的原理及应用

2019年12月05日 作者: 李卓 文章链接 7519字 16分钟阅读

前言

Java中的大部分同步类（Lock、Semaphore、ReentrantLock等）都是基于AbstractQueuedSynchronizer（简称为AQS）实现的。AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。本文会从应用层逐渐深入到原理层，并通过ReentrantLock的基本特性和ReentrantLock与AQS的关联，来深入解读AQS相关独占锁的知识点，同时采取问答的模式来帮助大家理解AQS。由于篇幅原因，本篇文章主要阐述AQS中独占锁的逻辑和Sync Queue，不讲述包含共享锁和Condition Queue的部分（本篇文章核心为AQS原理剖析，只是简单介绍了ReentrantLock，感兴趣同学可以阅读一下ReentrantLock的源码）。
下面列出本篇文章的大纲和思路，以便于大家更好地理解：
Java 并发知识 - 图63

1 ReentrantLock

1.1 ReentrantLock特性概览

ReentrantLock意思为可重入锁，指的是一个线程能够对一个临界资源重复加锁。为了帮助大家更好地理解ReentrantLock的特性，我们先将ReentrantLock跟常用的Synchronized进行比较，其特性如下（蓝色部分为本篇文章主要剖析的点）：
Java 并发知识 - 图64
下面通过伪代码，进行更加直观的比较：

  1. // **************************Synchronized的使用方式**************************
  2. // 1.用于代码块
  3. synchronized (this) {}
  4. // 2.用于对象
  5. synchronized (object) {}
  6. // 3.用于方法
  7. public synchronized void test () {}
  8. // 4.可重入
  9. for (int i = 0; i < 100; i++) {
  10.     synchronized (this) {}
  11. }
  12. // **************************ReentrantLock的使用方式**************************
  13. public void test () throw Exception {
  14.     // 1.初始化选择公平锁、非公平锁
  15.     ReentrantLock lock = new ReentrantLock(true);
  16.     // 2.可用于代码块
  17.     lock.lock();
  18.     try {
  19.         try {
  20.             // 3.支持多种加锁方式，比较灵活; 具有可重入特性
  21.             if(lock.tryLock(100, TimeUnit.MILLISECONDS)){ }
  22.         } finally {
  23.             // 4.手动释放锁
  24.             lock.unlock()
  25.         }
  26.     } finally {
  27.         lock.unlock();
  28.     }
  29. }

1.2 ReentrantLock与AQS的关联

通过上文我们已经了解，ReentrantLock支持公平锁和非公平锁（关于公平锁和非公平锁的原理分析，可参考《不可不说的Java“锁”事》），并且ReentrantLock的底层就是由AQS来实现的。那么ReentrantLock是如何通过公平锁和非公平锁与AQS关联起来呢？ 我们着重从这两者的加锁过程来理解一下它们与AQS之间的关系（加锁过程中与AQS的关联比较明显，解锁流程后续会介绍）。
非公平锁源码中的加锁流程如下：

  1. // java.util.concurrent.locks.ReentrantLock#NonfairSync
  2. // 非公平锁
  3. static final class NonfairSync extends Sync {
  4.     ...
  5.     final void lock() {
  6.         if (compareAndSetState(0, 1))
  7.             setExclusiveOwnerThread(Thread.currentThread());
  8.         else
  9.             acquire(1);
  10.         }
  11.   ...
  12. }

这块代码的含义为：

  • 若通过CAS设置变量State（同步状态）成功，也就是获取锁成功，则将当前线程设置为独占线程。
  • 若通过CAS设置变量State（同步状态）失败，也就是获取锁失败，则进入Acquire方法进行后续处理。

第一步很好理解，但第二步获取锁失败后，后续的处理策略是怎么样的呢？这块可能会有以下思考：

  • 某个线程获取锁失败的后续流程是什么呢？有以下两种可能：

(1) 将当前线程获锁结果设置为失败，获取锁流程结束。这种设计会极大降低系统的并发度，并不满足我们实际的需求。所以就需要下面这种流程，也就是AQS框架的处理流程。
(2) 存在某种排队等候机制，线程继续等待，仍然保留获取锁的可能，获取锁流程仍在继续。

  • 对于问题1的第二种情况，既然说到了排队等候机制，那么就一定会有某种队列形成，这样的队列是什么数据结构呢？
  • 处于排队等候机制中的线程，什么时候可以有机会获取锁呢？
  • 如果处于排队等候机制中的线程一直无法获取锁，还是需要一直等待吗，还是有别的策略来解决这一问题？

带着非公平锁的这些问题，再看下公平锁源码中获锁的方式：

  1. // java.util.concurrent.locks.ReentrantLock#FairSync
  2. static final class FairSync extends Sync {
  3.   ...  
  4.     final void lock() {
  5.         acquire(1);
  6.     }
  7.   ...
  8. }

看到这块代码，我们可能会存在这种疑问：Lock函数通过Acquire方法进行加锁，但是具体是如何加锁的呢？
结合公平锁和非公平锁的加锁流程，虽然流程上有一定的不同，但是都调用了Acquire方法，而Acquire方法是FairSync和UnfairSync的父类AQS中的核心方法。
对于上边提到的问题，其实在ReentrantLock类源码中都无法解答，而这些问题的答案，都是位于Acquire方法所在的类AbstractQueuedSynchronizer中，也就是本文的核心——AQS。下面我们会对AQS以及ReentrantLock和AQS的关联做详细介绍（相关问题答案会在2.3.5小节中解答）。

2 AQS

首先，我们通过下面的架构图来整体了解一下AQS框架：
Java 并发知识 - 图65

  • 上图中有颜色的为Method，无颜色的为Attribution。
  • 总的来说，AQS框架共分为五层，自上而下由浅入深，从AQS对外暴露的API到底层基础数据。
  • 当有自定义同步器接入时，只需重写第一层所需要的部分方法即可，不需要关注底层具体的实现流程。当自定义同步器进行加锁或者解锁操作时，先经过第一层的API进入AQS内部方法，然后经过第二层进行锁的获取，接着对于获取锁失败的流程，进入第三层和第四层的等待队列处理，而这些处理方式均依赖于第五层的基础数据提供层。

下面我们会从整体到细节，从流程到方法逐一剖析AQS框架，主要分析过程如下：
Java 并发知识 - 图66

2.1 原理概览

AQS核心思想是，如果被请求的共享资源空闲，那么就将当前请求资源的线程设置为有效的工作线程，将共享资源设置为锁定状态；如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是CLH队列的变体实现的，将暂时获取不到锁的线程加入到队列中。
CLH：Craig、Landin and Hagersten队列，是单向链表，AQS中的队列是CLH变体的虚拟双向队列（FIFO），AQS是通过将每条请求共享资源的线程封装成一个节点来实现锁的分配。
主要原理图如下：
Java 并发知识 - 图67
AQS使用一个Volatile的int类型的成员变量来表示同步状态，通过内置的FIFO队列来完成资源获取的排队工作，通过CAS完成对State值的修改。

2.1.1 AQS数据结构

先来看下AQS中最基本的数据结构——Node，Node即为上面CLH变体队列中的节点。
Java 并发知识 - 图68
解释一下几个方法和属性值的含义：

方法和属性值 含义
waitStatus 当前节点在队列中的状态
thread 表示处于该节点的线程
prev 前驱指针
predecessor 返回前驱节点，没有的话抛出npe
nextWaiter 指向下一个处于CONDITION状态的节点（由于本篇文章不讲述Condition Queue队列，这个指针不多介绍）
next 后继指针

线程两种锁的模式：

模式 含义
SHARED 表示线程以共享的模式等待锁
EXCLUSIVE 表示线程正在以独占的方式等待锁

waitStatus有下面几个枚举值：

枚举 含义
0 当一个Node被初始化的时候的默认值
CANCELLED 为1，表示线程获取锁的请求已经取消了
CONDITION 为-2，表示节点在等待队列中，节点线程等待唤醒
PROPAGATE 为-3，当前线程处在SHARED情况下，该字段才会使用
SIGNAL 为-1，表示线程已经准备好了，就等资源释放了

2.1.2 同步状态State

在了解数据结构后，接下来了解一下AQS的同步状态——State。AQS中维护了一个名为state的字段，意为同步状态，是由Volatile修饰的，用于展示当前临界资源的获锁情况。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private volatile int state;

下面提供了几个访问这个字段的方法：

方法名 描述
protected final int getState() 获取State的值
protected final void setState(int newState) 设置State的值
protected final boolean compareAndSetState(int expect, int update) 使用CAS方式更新State

这几个方法都是Final修饰的，说明子类中无法重写它们。我们可以通过修改State字段表示的同步状态来实现多线程的独占模式和共享模式（加锁过程）。
Java 并发知识 - 图69Java 并发知识 - 图70
对于我们自定义的同步工具，需要自定义获取同步状态和释放状态的方式，也就是AQS架构图中的第一层：API层。

2.2 AQS重要方法与ReentrantLock的关联

从架构图中可以得知，AQS提供了大量用于自定义同步器实现的Protected方法。自定义同步器实现的相关方法也只是为了通过修改State字段来实现多线程的独占模式或者共享模式。自定义同步器需要实现以下方法（ReentrantLock需要实现的方法如下，并不是全部）：

方法名 描述
protected boolean isHeldExclusively() 该线程是否正在独占资源。只有用到Condition才需要去实现它。
protected boolean tryAcquire(int arg) 独占方式。arg为获取锁的次数，尝试获取资源，成功则返回True，失败则返回False。
protected boolean tryRelease(int arg) 独占方式。arg为释放锁的次数，尝试释放资源，成功则返回True，失败则返回False。
protected int tryAcquireShared(int arg) 共享方式。arg为获取锁的次数，尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
protected boolean tryReleaseShared(int arg) 共享方式。arg为释放锁的次数，尝试释放资源，如果释放后允许唤醒后续等待结点返回True，否则返回False。

一般来说，自定义同步器要么是独占方式，要么是共享方式，它们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。ReentrantLock是独占锁，所以实现了tryAcquire-tryRelease。
以非公平锁为例，这里主要阐述一下非公平锁与AQS之间方法的关联之处，具体每一处核心方法的作用会在文章后面详细进行阐述。
Java 并发知识 - 图71
为了帮助大家理解ReentrantLock和AQS之间方法的交互过程，以非公平锁为例，我们将加锁和解锁的交互流程单独拎出来强调一下，以便于对后续内容的理解。
Java 并发知识 - 图72
加锁：

  • 通过ReentrantLock的加锁方法Lock进行加锁操作。
  • 会调用到内部类Sync的Lock方法，由于Sync#lock是抽象方法，根据ReentrantLock初始化选择的公平锁和非公平锁，执行相关内部类的Lock方法，本质上都会执行AQS的Acquire方法。
  • AQS的Acquire方法会执行tryAcquire方法，但是由于tryAcquire需要自定义同步器实现，因此执行了ReentrantLock中的tryAcquire方法，由于ReentrantLock是通过公平锁和非公平锁内部类实现的tryAcquire方法，因此会根据锁类型不同，执行不同的tryAcquire。
  • tryAcquire是获取锁逻辑，获取失败后，会执行框架AQS的后续逻辑，跟ReentrantLock自定义同步器无关。

解锁：

  • 通过ReentrantLock的解锁方法Unlock进行解锁。
  • Unlock会调用内部类Sync的Release方法，该方法继承于AQS。
  • Release中会调用tryRelease方法，tryRelease需要自定义同步器实现，tryRelease只在ReentrantLock中的Sync实现，因此可以看出，释放锁的过程，并不区分是否为公平锁。
  • 释放成功后，所有处理由AQS框架完成，与自定义同步器无关。

通过上面的描述，大概可以总结出ReentrantLock加锁解锁时API层核心方法的映射关系。
Java 并发知识 - 图73

2.3 通过ReentrantLock理解AQS

ReentrantLock中公平锁和非公平锁在底层是相同的，这里以非公平锁为例进行分析。
在非公平锁中，有一段这样的代码：

  1. // java.util.concurrent.locks.ReentrantLock
  2. static final class NonfairSync extends Sync {
  3.     ...
  4.     final void lock() {
  5.         if (compareAndSetState(0, 1))
  6.             setExclusiveOwnerThread(Thread.currentThread());
  7.         else
  8.             acquire(1);
  9.     }
  10.   ...
  11. }

看一下这个Acquire是怎么写的：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. public final void acquire(int arg) {
  3.     if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  4.         selfInterrupt();
  5. }

再看一下tryAcquire方法：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. protected boolean tryAcquire(int arg) {
  3.     throw new UnsupportedOperationException();
  4. }

可以看出，这里只是AQS的简单实现，具体获取锁的实现方法是由各自的公平锁和非公平锁单独实现的（以ReentrantLock为例）。如果该方法返回了True，则说明当前线程获取锁成功，就不用往后执行了；如果获取失败，就需要加入到等待队列中。下面会详细解释线程是何时以及怎样被加入进等待队列中的。

2.3.1 线程加入等待队列

2.3.1.1 加入队列的时机

当执行Acquire(1)时，会通过tryAcquire获取锁。在这种情况下，如果获取锁失败，就会调用addWaiter加入到等待队列中去。

2.3.1.2 如何加入队列

获取锁失败后，会执行addWaiter(Node.EXCLUSIVE)加入等待队列，具体实现方法如下：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private Node addWaiter(Node mode) {
  3.     Node node = new Node(Thread.currentThread(), mode);
  4.     // Try the fast path of enq; backup to full enq on failure
  5.     Node pred = tail;
  6.     if (pred != null) {
  7.         node.prev = pred;
  8.         if (compareAndSetTail(pred, node)) {
  9.             pred.next = node;
  10.             return node;
  11.         }
  12.     }
  13.     enq(node);
  14.     return node;
  15. }
  16. private final boolean compareAndSetTail(Node expect, Node update) {
  17.     return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
  18. }

主要的流程如下：

  • 通过当前的线程和锁模式新建一个节点。
  • Pred指针指向尾节点Tail。
  • 将New中Node的Prev指针指向Pred。

  • 通过compareAndSetTail方法，完成尾节点的设置。这个方法主要是对tailOffset和Expect进行比较，如果tailOffset的Node和Expect的Node地址是相同的，那么设置Tail的值为Update的值。

    1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
    2. static {
    3.   try {
    4.       stateOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("state"));
    5.       headOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("head"));
    6.       tailOffset = unsafe.objectFieldOffset(AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
    7.       waitStatusOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("waitStatus"));
    8.       nextOffset = unsafe.objectFieldOffset(Node.class.getDeclaredField("next"));
    9.   } catch (Exception ex) { 
    10.   throw new Error(ex); 
    11. }
    12. }

    从AQS的静态代码块可以看出，都是获取一个对象的属性相对于该对象在内存当中的偏移量，这样我们就可以根据这个偏移量在对象内存当中找到这个属性。tailOffset指的是tail对应的偏移量，所以这个时候会将new出来的Node置为当前队列的尾节点。同时，由于是双向链表，也需要将前一个节点指向尾节点。

  • 如果Pred指针是Null（说明等待队列中没有元素），或者当前Pred指针和Tail指向的位置不同（说明被别的线程已经修改），就需要看一下Enq的方法。

    1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
    2. private Node enq(final Node node) {
    3.   for (;;) {
    4.       Node t = tail;
    5.       if (t == null) { // Must initialize
    6.           if (compareAndSetHead(new Node()))
    7.               tail = head;
    8.       } else {
    9.           node.prev = t;
    10.           if (compareAndSetTail(t, node)) {
    11.               t.next = node;
    12.               return t;
    13.           }
    14.       }
    15.   }
    16. }

    如果没有被初始化，需要进行初始化一个头结点出来。但请注意，初始化的头结点并不是当前线程节点，而是调用了无参构造函数的节点。如果经历了初始化或者并发导致队列中有元素，则与之前的方法相同。其实，addWaiter就是一个在双端链表添加尾节点的操作，需要注意的是，双端链表的头结点是一个无参构造函数的头结点。
    总结一下，线程获取锁的时候，过程大体如下：

  1. 当没有线程获取到锁时，线程1获取锁成功。
  2. 线程2申请锁，但是锁被线程1占有。

Java 并发知识 - 图74

  1. 如果再有线程要获取锁，依次在队列中往后排队即可。

回到上边的代码，hasQueuedPredecessors是公平锁加锁时判断等待队列中是否存在有效节点的方法。如果返回False，说明当前线程可以争取共享资源；如果返回True，说明队列中存在有效节点，当前线程必须加入到等待队列中。

  1. // java.util.concurrent.locks.ReentrantLock
  2. public final boolean hasQueuedPredecessors() {
  3.     // The correctness of this depends on head being initialized
  4.     // before tail and on head.next being accurate if the current
  5.     // thread is first in queue.
  6.     Node t = tail; // Read fields in reverse initialization order
  7.     Node h = head;
  8.     Node s;
  9.     return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());
  10. }

看到这里，我们理解一下h != t && ((s = h.next) == null || s.thread != Thread.currentThread());为什么要判断的头结点的下一个节点？第一个节点储存的数据是什么？

双向链表中，第一个节点为虚节点，其实并不存储任何信息，只是占位。真正的第一个有数据的节点，是在第二个节点开始的。当h != t时： 如果(s = h.next) == null，等待队列正在有线程进行初始化，但只是进行到了Tail指向Head，没有将Head指向Tail，此时队列中有元素，需要返回True（这块具体见下边代码分析）。 如果(s = h.next) != null，说明此时队列中至少有一个有效节点。如果此时s.thread == Thread.currentThread()，说明等待队列的第一个有效节点中的线程与当前线程相同，那么当前线程是可以获取资源的；如果s.thread != Thread.currentThread()，说明等待队列的第一个有效节点线程与当前线程不同，当前线程必须加入进等待队列。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer#enq
  2. if (t == null) { // Must initialize
  3.     if (compareAndSetHead(new Node()))
  4.         tail = head;
  5. } else {
  6.     node.prev = t;
  7.     if (compareAndSetTail(t, node)) {
  8.         t.next = node;
  9.         return t;
  10.     }
  11. }

节点入队不是原子操作，所以会出现短暂的head != tail，此时Tail指向最后一个节点，而且Tail指向Head。如果Head没有指向Tail（可见5、6、7行），这种情况下也需要将相关线程加入队列中。所以这块代码是为了解决极端情况下的并发问题。

2.3.1.3 等待队列中线程出队列时机

回到最初的源码：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. public final void acquire(int arg) {
  3.     if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  4.         selfInterrupt();
  5. }

上文解释了addWaiter方法，这个方法其实就是把对应的线程以Node的数据结构形式加入到双端队列里，返回的是一个包含该线程的Node。而这个Node会作为参数，进入到acquireQueued方法中。acquireQueued方法可以对排队中的线程进行“获锁”操作。
总的来说，一个线程获取锁失败了，被放入等待队列，acquireQueued会把放入队列中的线程不断去获取锁，直到获取成功或者不再需要获取（中断）。
下面我们从“何时出队列？”和“如何出队列？”两个方向来分析一下acquireQueued源码：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. final boolean acquireQueued(final Node node, int arg) {
  3.     // 标记是否成功拿到资源
  4.     boolean failed = true;
  5.     try {
  6.         // 标记等待过程中是否中断过
  7.         boolean interrupted = false;
  8.         // 开始自旋，要么获取锁，要么中断
  9.         for (;;) {
  10.             // 获取当前节点的前驱节点
  11.             final Node p = node.predecessor();
  12.             // 如果p是头结点，说明当前节点在真实数据队列的首部，就尝试获取锁（别忘了头结点是虚节点）
  13.             if (p == head && tryAcquire(arg)) {
  14.                 // 获取锁成功，头指针移动到当前node
  15.                 setHead(node);
  16.                 p.next = null; // help GC
  17.                 failed = false;
  18.                 return interrupted;
  19.             }
  20.             // 说明p为头节点且当前没有获取到锁（可能是非公平锁被抢占了）或者是p不为头结点，这个时候就要判断当前node是否要被阻塞（被阻塞条件：前驱节点的waitStatus为-1），防止无限循环浪费资源。具体两个方法下面细细分析
  21.             if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
  22.                 interrupted = true;
  23.         }
  24.     } finally {
  25.         if (failed)
  26.             cancelAcquire(node);
  27.     }
  28. }

注：setHead方法是把当前节点置为虚节点，但并没有修改waitStatus，因为它是一直需要用的数据。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private void setHead(Node node) {
  3.     head = node;
  4.     node.thread = null;
  5.     node.prev = null;
  6. }
  7. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  8. // 靠前驱节点判断当前线程是否应该被阻塞
  9. private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
  10.     // 获取头结点的节点状态
  11.     int ws = pred.waitStatus;
  12.     // 说明头结点处于唤醒状态
  13.     if (ws == Node.SIGNAL)
  14.         return true; 
  15.     // 通过枚举值我们知道waitStatus>0是取消状态
  16.     if (ws > 0) {
  17.         do {
  18.             // 循环向前查找取消节点，把取消节点从队列中剔除
  19.             node.prev = pred = pred.prev;
  20.         } while (pred.waitStatus > 0);
  21.         pred.next = node;
  22.     } else {
  23.         // 设置前任节点等待状态为SIGNAL
  24.         compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
  25.     }
  26.     return false;
  27. }

parkAndCheckInterrupt主要用于挂起当前线程，阻塞调用栈，返回当前线程的中断状态。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private final boolean parkAndCheckInterrupt() {
  3.     LockSupport.park(this);
  4.     return Thread.interrupted();
  5. }

上述方法的流程图如下：
Java 并发知识 - 图75
从上图可以看出，跳出当前循环的条件是当“前置节点是头结点，且当前线程获取锁成功”。为了防止因死循环导致CPU资源被浪费，我们会判断前置节点的状态来决定是否要将当前线程挂起，具体挂起流程用流程图表示如下（shouldParkAfterFailedAcquire流程）：
Java 并发知识 - 图76
从队列中释放节点的疑虑打消了，那么又有新问题了：

  • shouldParkAfterFailedAcquire中取消节点是怎么生成的呢？什么时候会把一个节点的waitStatus设置为-1？

  • 是在什么时间释放节点通知到被挂起的线程呢？

    2.3.2 CANCELLED状态节点生成

    acquireQueued方法中的Finally代码：

    1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
    2. final boolean acquireQueued(final Node node, int arg) {
    3.   boolean failed = true;
    4.   try {
    5.   ...
    6.       for (;;) {
    7.           final Node p = node.predecessor();
    8.           if (p == head && tryAcquire(arg)) {
    9.               ...
    10.               failed = false;
    11.       ...
    12.           }
    13.           ...
    14.   } finally {
    15.       if (failed)
    16.           cancelAcquire(node);
    17.       }
    18. }

    通过cancelAcquire方法，将Node的状态标记为CANCELLED。接下来，我们逐行来分析这个方法的原理：

    1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
    2. private void cancelAcquire(Node node) {
    3. // 将无效节点过滤
    4.   if (node == null)
    5.       return;
    6. // 设置该节点不关联任何线程，也就是虚节点
    7.   node.thread = null;
    8.   Node pred = node.prev;
    9. // 通过前驱节点，跳过取消状态的node
    10.   while (pred.waitStatus > 0)
    11.       node.prev = pred = pred.prev;
    12. // 获取过滤后的前驱节点的后继节点
    13.   Node predNext = pred.next;
    14. // 把当前node的状态设置为CANCELLED
    15.   node.waitStatus = Node.CANCELLED;
    16. // 如果当前节点是尾节点，将从后往前的第一个非取消状态的节点设置为尾节点
    17. // 更新失败的话，则进入else，如果更新成功，将tail的后继节点设置为null
    18.   if (node == tail && compareAndSetTail(node, pred)) {
    19.       compareAndSetNext(pred, predNext, null);
    20.   } else {
    21.       int ws;
    22.   // 如果当前节点不是head的后继节点，1:判断当前节点前驱节点的是否为SIGNAL，2:如果不是，则把前驱节点设置为SINGAL看是否成功
    23.   // 如果1和2中有一个为true，再判断当前节点的线程是否为null
    24.   // 如果上述条件都满足，把当前节点的前驱节点的后继指针指向当前节点的后继节点
    25.       if (pred != head && ((ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) && pred.thread != null) {
    26.           Node next = node.next;
    27.           if (next != null && next.waitStatus <= 0)
    28.               compareAndSetNext(pred, predNext, next);
    29.       } else {
    30.     // 如果当前节点是head的后继节点，或者上述条件不满足，那就唤醒当前节点的后继节点
    31.           unparkSuccessor(node);
    32.       }
    33.       node.next = node; // help GC
    34.   }
    35. }

    当前的流程：

  • 获取当前节点的前驱节点，如果前驱节点的状态是CANCELLED，那就一直往前遍历，找到第一个waitStatus <= 0的节点，将找到的Pred节点和当前Node关联，将当前Node设置为CANCELLED。

  • 根据当前节点的位置，考虑以下三种情况：

(1) 当前节点是尾节点。
(2) 当前节点是Head的后继节点。
(3) 当前节点不是Head的后继节点，也不是尾节点。
根据上述第二条，我们来分析每一种情况的流程。
当前节点是尾节点。
Java 并发知识 - 图77
当前节点是Head的后继节点。
Java 并发知识 - 图78
当前节点不是Head的后继节点，也不是尾节点。
Java 并发知识 - 图79
通过上面的流程，我们对于CANCELLED节点状态的产生和变化已经有了大致的了解，但是为什么所有的变化都是对Next指针进行了操作，而没有对Prev指针进行操作呢？什么情况下会对Prev指针进行操作？

执行cancelAcquire的时候，当前节点的前置节点可能已经从队列中出去了（已经执行过Try代码块中的shouldParkAfterFailedAcquire方法了），如果此时修改Prev指针，有可能会导致Prev指向另一个已经移除队列的Node，因此这块变化Prev指针不安全。 shouldParkAfterFailedAcquire方法中，会执行下面的代码，其实就是在处理Prev指针。shouldParkAfterFailedAcquire是获取锁失败的情况下才会执行，进入该方法后，说明共享资源已被获取，当前节点之前的节点都不会出现变化，因此这个时候变更Prev指针比较安全。

  1. do {
  2.     node.prev = pred = pred.prev;
  3. } while (pred.waitStatus > 0);

2.3.3 如何解锁

我们已经剖析了加锁过程中的基本流程，接下来再对解锁的基本流程进行分析。由于ReentrantLock在解锁的时候，并不区分公平锁和非公平锁，所以我们直接看解锁的源码：

  1. // java.util.concurrent.locks.ReentrantLock
  2. public void unlock() {
  3.     sync.release(1);
  4. }

可以看到，本质释放锁的地方，是通过框架来完成的。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. public final boolean release(int arg) {
  3.     if (tryRelease(arg)) {
  4.         Node h = head;
  5.         if (h != null && h.waitStatus != 0)
  6.             unparkSuccessor(h);
  7.         return true;
  8.     }
  9.     return false;
  10. }

在ReentrantLock里面的公平锁和非公平锁的父类Sync定义了可重入锁的释放锁机制。

  1. // java.util.concurrent.locks.ReentrantLock.Sync
  2. // 方法返回当前锁是不是没有被线程持有
  3. protected final boolean tryRelease(int releases) {
  4.     // 减少可重入次数
  5.     int c = getState() - releases;
  6.     // 当前线程不是持有锁的线程，抛出异常
  7.     if (Thread.currentThread() != getExclusiveOwnerThread())
  8.         throw new IllegalMonitorStateException();
  9.     boolean free = false;
  10.     // 如果持有线程全部释放，将当前独占锁所有线程设置为null，并更新state
  11.     if (c == 0) {
  12.         free = true;
  13.         setExclusiveOwnerThread(null);
  14.     }
  15.     setState(c);
  16.     return free;
  17. }

我们来解释下述源码：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. public final boolean release(int arg) {
  3.     // 上边自定义的tryRelease如果返回true，说明该锁没有被任何线程持有
  4.     if (tryRelease(arg)) {
  5.         // 获取头结点
  6.         Node h = head;
  7.         // 头结点不为空并且头结点的waitStatus不是初始化节点情况，解除线程挂起状态
  8.         if (h != null && h.waitStatus != 0)
  9.             unparkSuccessor(h);
  10.         return true;
  11.     }
  12.     return false;
  13. }

这里的判断条件为什么是h != null && h.waitStatus != 0？

h == null Head还没初始化。初始情况下，head == null，第一个节点入队，Head会被初始化一个虚拟节点。所以说，这里如果还没来得及入队，就会出现head == null 的情况。 h != null && waitStatus == 0 表明后继节点对应的线程仍在运行中，不需要唤醒。 h != null && waitStatus < 0 表明后继节点可能被阻塞了，需要唤醒。

再看一下unparkSuccessor方法：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private void unparkSuccessor(Node node) {
  3.     // 获取头结点waitStatus
  4.     int ws = node.waitStatus;
  5.     if (ws < 0)
  6.         compareAndSetWaitStatus(node, ws, 0);
  7.     // 获取当前节点的下一个节点
  8.     Node s = node.next;
  9.     // 如果下个节点是null或者下个节点被cancelled，就找到队列最开始的非cancelled的节点
  10.     if (s == null || s.waitStatus > 0) {
  11.         s = null;
  12.         // 就从尾部节点开始找，到队首，找到队列第一个waitStatus<0的节点。
  13.         for (Node t = tail; t != null && t != node; t = t.prev)
  14.             if (t.waitStatus <= 0)
  15.                 s = t;
  16.     }
  17.     // 如果当前节点的下个节点不为空，而且状态<=0，就把当前节点unpark
  18.     if (s != null)
  19.         LockSupport.unpark(s.thread);
  20. }

为什么要从后往前找第一个非Cancelled的节点呢？原因如下。
之前的addWaiter方法：

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private Node addWaiter(Node mode) {
  3.     Node node = new Node(Thread.currentThread(), mode);
  4.     // Try the fast path of enq; backup to full enq on failure
  5.     Node pred = tail;
  6.     if (pred != null) {
  7.         node.prev = pred;
  8.         if (compareAndSetTail(pred, node)) {
  9.             pred.next = node;
  10.             return node;
  11.         }
  12.     }
  13.     enq(node);
  14.     return node;
  15. }

我们从这里可以看到，节点入队并不是原子操作，也就是说，node.prev = pred; compareAndSetTail(pred, node) 这两个地方可以看作Tail入队的原子操作，但是此时pred.next = node;还没执行，如果这个时候执行了unparkSuccessor方法，就没办法从前往后找了，所以需要从后往前找。还有一点原因，在产生CANCELLED状态节点的时候，先断开的是Next指针，Prev指针并未断开，因此也是必须要从后往前遍历才能够遍历完全部的Node。
综上所述，如果是从前往后找，由于极端情况下入队的非原子操作和CANCELLED节点产生过程中断开Next指针的操作，可能会导致无法遍历所有的节点。所以，唤醒对应的线程后，对应的线程就会继续往下执行。继续执行acquireQueued方法以后，中断如何处理？

2.3.4 中断恢复后的执行流程

唤醒后，会执行return Thread.interrupted();，这个函数返回的是当前执行线程的中断状态，并清除。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private final boolean parkAndCheckInterrupt() {
  3.     LockSupport.park(this);
  4.     return Thread.interrupted();
  5. }

再回到acquireQueued代码，当parkAndCheckInterrupt返回True或者False的时候，interrupted的值不同，但都会执行下次循环。如果这个时候获取锁成功，就会把当前interrupted返回。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. final boolean acquireQueued(final Node node, int arg) {
  3.     boolean failed = true;
  4.     try {
  5.         boolean interrupted = false;
  6.         for (;;) {
  7.             final Node p = node.predecessor();
  8.             if (p == head && tryAcquire(arg)) {
  9.                 setHead(node);
  10.                 p.next = null; // help GC
  11.                 failed = false;
  12.                 return interrupted;
  13.             }
  14.             if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
  15.                 interrupted = true;
  16.             }
  17.     } finally {
  18.         if (failed)
  19.             cancelAcquire(node);
  20.     }
  21. }

如果acquireQueued为True，就会执行selfInterrupt方法。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. static void selfInterrupt() {
  3.     Thread.currentThread().interrupt();
  4. }

该方法其实是为了中断线程。但为什么获取了锁以后还要中断线程呢？这部分属于Java提供的协作式中断知识内容，感兴趣同学可以查阅一下。这里简单介绍一下：

  1. 当中断线程被唤醒时，并不知道被唤醒的原因，可能是当前线程在等待中被中断，也可能是释放了锁以后被唤醒。因此我们通过Thread.interrupted()方法检查中断标记（该方法返回了当前线程的中断状态，并将当前线程的中断标识设置为False），并记录下来，如果发现该线程被中断过，就再中断一次。
  2. 线程在等待资源的过程中被唤醒，唤醒后还是会不断地去尝试获取锁，直到抢到锁为止。也就是说，在整个流程中，并不响应中断，只是记录中断记录。最后抢到锁返回了，那么如果被中断过的话，就需要补充一次中断。

这里的处理方式主要是运用线程池中基本运作单元Worder中的runWorker，通过Thread.interrupted()进行额外的判断处理，感兴趣的同学可以看下ThreadPoolExecutor源码。

2.3.5 小结

我们在1.3小节中提出了一些问题，现在来回答一下。

Q：某个线程获取锁失败的后续流程是什么呢？ A：存在某种排队等候机制，线程继续等待，仍然保留获取锁的可能，获取锁流程仍在继续。 Q：既然说到了排队等候机制，那么就一定会有某种队列形成，这样的队列是什么数据结构呢？ A：是CLH变体的FIFO双端队列。 Q：处于排队等候机制中的线程，什么时候可以有机会获取锁呢？ A：可以详细看下2.3.1.3小节。 Q：如果处于排队等候机制中的线程一直无法获取锁，需要一直等待么？还是有别的策略来解决这一问题？ A：线程所在节点的状态会变成取消状态，取消状态的节点会从队列中释放，具体可见2.3.2小节。 Q：Lock函数通过Acquire方法进行加锁，但是具体是如何加锁的呢？ A：AQS的Acquire会调用tryAcquire方法，tryAcquire由各个自定义同步器实现，通过tryAcquire完成加锁过程。

3 AQS应用

3.1 ReentrantLock的可重入应用

ReentrantLock的可重入性是AQS很好的应用之一，在了解完上述知识点以后，我们很容易得知ReentrantLock实现可重入的方法。在ReentrantLock里面，不管是公平锁还是非公平锁，都有一段逻辑。
公平锁：

  1. // java.util.concurrent.locks.ReentrantLock.FairSync#tryAcquire
  2. if (c == 0) {
  3.     if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
  4.         setExclusiveOwnerThread(current);
  5.         return true;
  6.     }
  7. }
  8. else if (current == getExclusiveOwnerThread()) {
  9.     int nextc = c + acquires;
  10.     if (nextc < 0)
  11.         throw new Error("Maximum lock count exceeded");
  12.     setState(nextc);
  13.     return true;
  14. }

非公平锁：

  1. // java.util.concurrent.locks.ReentrantLock.Sync#nonfairTryAcquire
  2. if (c == 0) {
  3.     if (compareAndSetState(0, acquires)){
  4.         setExclusiveOwnerThread(current);
  5.         return true;
  6.     }
  7. }
  8. else if (current == getExclusiveOwnerThread()) {
  9.     int nextc = c + acquires;
  10.     if (nextc < 0) // overflow
  11.         throw new Error("Maximum lock count exceeded");
  12.     setState(nextc);
  13.     return true;
  14. }

从上面这两段都可以看到，有一个同步状态State来控制整体可重入的情况。State是Volatile修饰的，用于保证一定的可见性和有序性。

  1. // java.util.concurrent.locks.AbstractQueuedSynchronizer
  2. private volatile int state;

接下来看State这个字段主要的过程：

  1. State初始化的时候为0，表示没有任何线程持有锁。
  2. 当有线程持有该锁时，值就会在原来的基础上+1，同一个线程多次获得锁是，就会多次+1，这里就是可重入的概念。
  3. 解锁也是对这个字段-1，一直到0，此线程对锁释放。

    3.2 JUC中的应用场景

    除了上边ReentrantLock的可重入性的应用，AQS作为并发编程的框架，为很多其他同步工具提供了良好的解决方案。下面列出了JUC中的几种同步工具，大体介绍一下AQS的应用场景：
同步工具 同步工具与AQS的关联
ReentrantLock 使用AQS保存锁重复持有的次数。当一个线程获取锁时，ReentrantLock记录当前获得锁的线程标识，用于检测是否重复获取，以及错误线程试图解锁操作时异常情况的处理。
Semaphore 使用AQS同步状态来保存信号量的当前计数。tryRelease会增加计数，acquireShared会减少计数。
CountDownLatch 使用AQS同步状态来表示计数。计数为0时，所有的Acquire操作（CountDownLatch的await方法）才可以通过。
ReentrantReadWriteLock 使用AQS同步状态中的16位保存写锁持有的次数，剩下的16位用于保存读锁的持有次数。
ThreadPoolExecutor Worker利用AQS同步状态实现对独占线程变量的设置（tryAcquire和tryRelease）。

3.3 自定义同步工具

了解AQS基本原理以后，按照上面所说的AQS知识点，自己实现一个同步工具。

  1. public class LeeLock  {
  2.     private static class Sync extends AbstractQueuedSynchronizer {
  3.         @Override
  4.         protected boolean tryAcquire (int arg) {
  5.             return compareAndSetState(0, 1);
  6.         }
  7.         @Override
  8.         protected boolean tryRelease (int arg) {
  9.             setState(0);
  10.             return true;
  11.         }
  12.         @Override
  13.         protected boolean isHeldExclusively () {
  14.             return getState() == 1;
  15.         }
  16.     }
  18.     private Sync sync = new Sync();
  20.     public void lock () {
  21.         sync.acquire(1);
  22.     }
  24.     public void unlock () {
  25.         sync.release(1);
  26.     }
  27. }

通过我们自己定义的Lock完成一定的同步功能。

  1. public class LeeMain {
  2.     static int count = 0;
  3.     static LeeLock leeLock = new LeeLock();
  4.     public static void main (String[] args) throws InterruptedException {
  5.         Runnable runnable = new Runnable() {
  6.             @Override
  7.             public void run () {
  8.                 try {
  9.                     leeLock.lock();
  10.                     for (int i = 0; i < 10000; i++) {
  11.                         count++;
  12.                     }
  13.                 } catch (Exception e) {
  14.                     e.printStackTrace();
  15.                 } finally {
  16.                     leeLock.unlock();
  17.                 }
  18.             }
  19.         };
  20.         Thread thread1 = new Thread(runnable);
  21.         Thread thread2 = new Thread(runnable);
  22.         thread1.start();
  23.         thread2.start();
  24.         thread1.join();
  25.         thread2.join();
  26.         System.out.println(count);
  27.     }
  28. }

上述代码每次运行结果都会是20000。通过简单的几行代码就能实现同步功能，这就是AQS的强大之处。

总结

我们日常开发中使用并发的场景太多，但是对并发内部的基本框架原理了解的人却不多。由于篇幅原因，本文仅介绍了可重入锁ReentrantLock的原理和AQS原理，希望能够成为大家了解AQS和ReentrantLock等同步器的“敲门砖”。

参考资料