为何需要多线程

一个运行的程序往往需要三个模块的协调运行：CPU，内存，IO设备。众所周知，这三者的速度差异是较大的，所以为了平衡差异，操作系统、计算机体系结构、编译程序都采取了相关措施：

• CPU增加了缓存，以均衡与内存的速度差异。导致了 可见性 问题。
• 操作系统增加了进程、线程的概念，分时复用CPU，均衡CPU与IO设备的速度差异。导致了 原子性 问题。
• 编译程序优化指令执行的顺序，使缓存能够更合理地利用。导致了 有序性 的问题。

Java中线程的6种状态

通过 Thread.State 的源码可以看到，线程分为6个状态：

/**
 * 高内聚资源
 * 所有资源只由自己操作
 */
class Ticket {
  private int number = 30;
  private Lock lock = new ReentrantLock();
  // 对外暴露接口
  public void sale() {
    lock.lock();
    try {   // 加锁后，此块代码只能由一个线程同步访问
      if (number > 0) {
        System.out.println(Thread.currentThread().getName() 
                           + " sold the" + number + "th ticket, left" + number);
          number--;
      }
    } catch (Exception e) {
      e.printStackTrace();
    } finally {
      lock.unlock();
    }
  }
}
/**
 *
 * 三个售票员    卖出  30张票
 * 如何编写企业级 高内聚低耦合 的多线程代码
 * 固定的编程套路+模板是什么
 *
 * 1. 在高内聚低耦合的前提下   线程  操作  资源类
 *      先创建一个资源类
 * 2. 不要再 Thread t = new Thread()啦，要与时俱进使用java8的新特性
 *      直接lambda表达式
 */
public class SaleTicketDemo {
  public static void main(String[] args) { // 主线程，main只是程序的入口，业务逻辑写外边
    testSafe();
  }
  private static void testSafe() {
    // 创建资源类
    Ticket tickets = new Ticket();
    // 线程操作资源类
    new Thread(() -> { for (int i = 0; i < 40; ++i) tickets.sale(); }, "A").start();
    new Thread(() -> { for (int i = 0; i < 40; ++i) tickets.sale(); }, "B").start();
    new Thread(() -> { for (int i = 0; i < 40; ++i) tickets.sale(); }, "C").start();
  }
}

设计规范

原则：高内聚低耦合，线程操作资源类。

就是将资源类高度封装，所有对资源的直接操作都由资源类自己内部操作，而尽量不依赖外部操作，对外只暴露方法接口。业务逻辑部分由多个线程来分别操作资源。

生产者消费者模型

线程操作资源类

多个线程操作资源类，一部分线程作为生产者生产资源；一部分线程作为消费者消费资源；且对于资源的数量是有约束的。

使用四个线程来操作一个数字，两个线程用来增加数字，两个线程用来减少数字，要求数字的范围约束在0和1，每个线程都操作10轮。

题目中的数字就是资源，加数的线程就是生产者，减数的线程就是消费者。由于要约束资源的数量，所以我们需要线程之间的相互通信。

Java的线程库中有两种方式：

• 比较老的版本，synchroninzed关键字锁住资源，线程访问的时候使用循环判断，若不能操作则wait()等待，注意wait()的等待时线程交出资源的控制权，而sleep()的等待是单纯阻塞，不会交出资源控制权；若能操作，则操作完之后用notifyAll()通知唤醒其余线程。
• 比较新的版本，使用Lock类来加锁。从官方的API可以知道Lock类是比synchronized更加强大的新技术。其线程之间通信的API也有更新：
  • 不再使用Object类提供的wait() notify()方法，使用Condition类的await() signal()方法。

总的原则

• 线程操作资源类。
• 判断 -> 操作 -> 通知。
• 多线程交互，防止线程的虚假唤醒，使用循环判断。

class NumSource {
  private int number = 0;
  Lock lock = new ReentrantLock();
  Condition condition = lock.newCondition();
  public void increment() {
    lock.lock();
    try {
      while (number != 0) {
        condition.await();
      }
      number++;
      condition.signalAll();
      System.out.println(Thread.currentThread().getName() + "\t" + number);
    } catch (Exception e) { e.printStackTrace(); } finally {
      lock.unlock();
    }
  }
  public void decrement() {
    lock.lock();
    try {
      while (number == 0) {
        condition.await();
      }
      number--;
      condition.signalAll();
      System.out.println(Thread.currentThread().getName() + "\t" + number);
    } catch (Exception e) { e.printStackTrace(); } finally {
      lock.unlock();
    }
  }
}
public class WaitNotifyDemo {
  public static void main(String[] args) {
    NumSource src = new NumSource();
    new Thread(() -> { for (int i = 0; i < 10; ++i) src.increment(); }, "A").start();
    new Thread(() -> { for (int i = 0; i < 10; ++i) src.decrement(); }, "B").start();
    new Thread(() -> { for (int i = 0; i < 10; ++i) src.increment(); }, "C").start();
    new Thread(() -> { for (int i = 0; i < 10; ++i) src.decrement(); }, "D").start();
  }
}

精确通知

新API中Lock和Condition的结合使用相比起synchronized，最大的不同就在于其能够支持线程之间的精确通知（即同步），即A线程执行完后可以指定下一个执行的线程必须为B，增强了线程操作的可控性。

多个线程之间按照顺序调用，实现 A->B->C。三个线程的启动要求如下：AA打印5次，BB打印10次，CC打印15次；AA打印5次，BB打印10次，CC打印15次……一共来10轮。

多线程之间的精确通知可以通过一个标志位来辅助实现，基本原则：

• 线程操作资源类
• 判断、操作、通知
• 多线程交互，防止虚假唤醒，循环判断
• 标志位修改和定位

/**
 * Lock主要和Condition结合使用
 * 精准通知，精准唤醒
 */
class ConditionSource {
  private Lock lock = new ReentrantLock();
  private Condition condition1 = lock.newCondition();    // 每一个条件服务一个线程
  private Condition condition2 = lock.newCondition();
  private Condition condition3 = lock.newCondition();
  private int flag = 1;   // 标志位
  // 精确唤醒，实现同步
  public void Asay() {
    lock.lock();
    try {
      while (flag != 1) {
        condition1.await();
      }
      for(int i = 1; i <= 5; ++i)
        System.out.println(Thread.currentThread().getName() + "\t" + i);
      flag = 2;
      condition2.signal();
    } catch (Exception e) { e.printStackTrace(); } finally {
      lock.unlock();
    }
  }
  public void Bsay() {
    lock.lock();
    try {
      while (flag != 2) {
        condition2.await();
      }
      for(int i = 1; i <= 10; ++i)
        System.out.println(Thread.currentThread().getName() + "\t" + i);
      flag = 3;
      condition3.signal();
    } catch (Exception e) { e.printStackTrace(); } finally {
      lock.unlock();
    }
  }
  public void Csay() {
    lock.lock();
    try {
      while (flag != 3) {
        condition3.await();
      }
      for(int i = 1; i <= 15; ++i)
        System.out.println(Thread.currentThread().getName() + "\t" + i);
      flag = 1;
      condition1.signal();
    } catch (Exception e) { e.printStackTrace(); } finally {
      lock.unlock();
    }
  }
}
public class ConditionDemo {
  public static void main(String[] args) {
    ConditionSource source = new ConditionSource();
    for (int i = 0; i < 10; ++i) new Thread(source::Asay, "A").start();
    for (int i = 0; i < 10; ++i) new Thread(source::Bsay, "B").start();
    for (int i = 0; i < 10; ++i) new Thread(source::Csay, "C").start();
  }
}

获得多线程的方式

实现Runnable接口

public class MyRunnable implements Runnable {
    @Override
    public void run() {
    }
}
public static void main(String[] args) {
    MyRunnable inst = new MyRunnable();
    Thread thread = new Thread(inst);
    thread.start();    // 创建一个线程并启动
}

继承Thread类

public class MyThread extends Thread {
    @Override
    public void run() {
    }
}
public static void main(String[] args) {
    MyThread th = new MyThread();
    th.start();
}

实现Callable接口并用FutureTask包装

class MyCall implements Callable<Integer> {
    @Override
    public Integer call() throws XXXException {
        return XXX;
    }
}
public class CallableDemo {
    public test() throws XXXException {
        FutureTask<Integer> task = new FutureTask<>(new MyCall());
        new Thread(task).start();
        task.get();    // 阻塞，等待线程执行完后的返回值
    }
}

注意点：

• .start()创建一个线程执行run()方法；
• .run()只是调用run()方法。

JMM

Java内存模型是一种多线程访问共享变量的规范，屏蔽了各种硬件和操作系统内存访问的差异，以实现Java在各个平台下都能达到一致的内存访问效果。规范要求保证可见性、原子性、有序性。

• 可见性问题，一是由于 CPU、缓存、内存等存储结构的速度差异所造成；二是由于线程工作在自己的私有工作内存中，使得某一个线程对某个变量的更新不能够立即又其他线程看见。
• 原子性问题，是由于多线程/多进程情况下分时复用CPU所造成；
• 有序性问题，是编译器尝试优化程序而对指令重排列所造成。

JMM 规范内容

1. 所有变量都存储在主内存中。
2. 每一个线程都有一个私有的工作内存，工作内存存储了线程要读写的共享变量副本。
3. 线程不能够直接操作主内存，必须通过拷贝到私有工作内存的方式来进行操作。
4. 不同线程的私有内存相互之间不可见。

以上就是 Java 内存模型的基本内容，具体采用了 8 种操作来进行实现。

volatile 实现原理

可见性

volatile 底层实际上就是 MESI 协议来实现共享变量的可见性：CPU 监听总线，一旦发现共享变量发生改变，则将私有内存的拷贝失效，下一次使用的时候就是从主内存得到的最新值。

给变量加上 volatile 关键字，会在修改变量的时候多一个 lock 前缀指令，保证变量变动后立即执行写回到主内存操作（store write），在 store 的时候通过总线，其他 CPU 能够感知到变量的变化。

可以发现这个加锁的点在 store、write，这样子保证了其他 CPU 读主存的时候，最新的变量已经 write 到了主存。

与 synchronized 进一步比较，synchronized 相当于把锁加在了 read 开始，所以整个过程包括 use、assign 等都被一个线程独占，必然保证了可见性、原子性，但是锁的粒度太大，若 use 是一个耗时操作则大大降低了整体的并发度；相比之下，volatile 在只锁住了 store write，大大减小了锁的粒度，所以 volatile 是一个轻量级锁，同时解决了并发与性能问题！

有序性

happens-before 是一系列重排序的原则，让 CPU 在不影响单线程执行结果的前提下，重排序指令来最大限度发挥机器性能。as-if-serial 也是类似，要求在单线程下 CPU 对指令重排序后最终的执行结果，要和顺序执行是一样的。

happens-before 原则的例子，比如 volatile 变量完全写入内存必须在下一次读之前完成；同步代码块不能与其前后的语句调换顺序；存在依赖关系的指令不能调换顺序。

在单线程条件下，依赖以上原则能够保证结果的正确，多线程环境下则会出现问题。所以需要使用 volatile 来禁止指令重排序。

volatile VS synchronized

synchronized 由于锁的粒度从 read 开始，所以能够完全保证原子性、可见性、有序性；volatile 不能保证原子性。

之前与 synchronized 比较的过程中其实已经提到过，volatile 仅仅锁住了 store write 这个过程，所以 use 等修改操作可能会丢失。比如，两个 CPU 同时修改变量 num，其中一个 CPU 先修改完成并进行 store write，则另一个 CPU 检测到这个 num 变化后就将自己工作内存的 num 失效，导致了修改的丢失。

所以，对于这种情况，应该进一步拓大锁的范围，使用 synchronized 或其他手段在 read 的时候就进行锁定。

public class Test {
     private volatile int flag = 0;
    public void incr() {
        // 由于++不是原子操作，多线程操作时，修改可能会丢失
         flag++;   
    }
    public void safeAssign() {
         // 赋值是原子操作，多线程操作是安全的
        flag = 2;   
    }
    public synchronized void safeIncr1() {
        // synchronized 从 read 开始就加锁，保证修改不会丢失
         flag += 1;   
    }
}

创建对象重排序问题

DCL单例模式

class Singleton {
  private static volatile Singleton instance = null;
  public Singleton getInstance() {
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
      }
    }
    return instance;
  }
}

在这个 DCL 单例中如果 instance 对象不使用 volatile 修饰，则存在指令重排序的风险。一个对象在创建的时候分为三步：

instance  = new XXXX();
==> 伪代码
    memory = allocate();    // 1. 内存中分配对象空间
    instance_init(memory);    // 2. 初始化对象
    instance = memory;        // 3. 获取对象的引用，接着instance != null

可以发现步骤2和步骤3是不存在数据依赖关系的，所以是有可能调换顺序的，即先获取引用后初始化对象，这样就会有操作部分初始化对象的风险！也就是说，另外一个线程可能引用到一个部分初始化的 singleton 对象。

所以需要增加 volatile，这样就使得 instance = new Singleton() 这条语句不会重排序，最终完整地初始完对象后才返回引用。

CAS

比较并交换，是一种操作系统的原语。原子包装类中的许多操作底层就是通过unsafe类调用操作系统cas原语。

这个原语的基本逻辑就是：通过内存寻址获取工作内存变量，比较当前工作内存的值是否与主内存中的值相同，相同则说明变量没有被其他线程修改，可以进行操作；否则不进行修改，再循环来判断直至成功。

• var1：工作内存中的值；
• var2：内存偏移量；
• var4：expect；
• var5：update；

public final native boolean compareAndSwapInt(Object val, long offset, int expect, int update);

问题缺陷

1. 更改失败，变成自旋锁一直循环。

2. 出现ABA问题，即值被修改过，过程中出现过变化，但最初值和当前值一样。由于cas只进行值比较，所以不能够检测出中间过程的变化。
   解决方法：使用带有版本号的原子引用创建对象，AtomicStampedReference, 这样再cas的过程中就不仅比较值而且比较对象的当前修改版本。

   public void test() {
   AtomicStampedReference<Integer> ref = new AtomicStampedReference<>(100, 1);
   new Thread(() -> {
    int stamp = ref.getStamp();
    ref.compareAndSet(100, 101, ref.getStamp(), ref.getStamp() + 1); // AB
    ref.compareAndSet(101, 100, ref.getStamp(), ref.getStamp() + 1); // BA
   }).start();
   int stamp = ref.getStamp();
   new Thread(() -> {
    System.out.println("获取版本号\t" + stamp);
    // 。。。sleep for a while
    ref.compareAndSet(100, 111, stamp, stamp + 1);
   }).start();
   }

线程的同步机制

synchronize和ReentrantLock

1. 构成：
   synchronized是JVM提供的同步机制关键字，底层是管程对象来管理；
   ReentranrLock则是API层面的一个Lock接口实现类。
2. 使用：
   synchronized一切由底层的管程控制；
   ReentantLock需要用户主动释放锁，否则可能会出现阻塞、死锁等状况。
3. 中断：
   synchronized不可中断，除非抛出异常或者运行完成；
   ReentrantLock可以中断, trylock(timeout, unit), lock.lockInterruptibly()。
4. 公平：
   • synchronized非公平；
   • ReentrantLock默认非公平，但可以设置参数改变。
5. 通知：
   • synchronized只能够随机通知；``
   • ReentrantLock可以和Condition接口结合使用，实现精确通知。

使用选择

除非要使用ReentrantLock的一些高级功能，否则优先使用synchronized。因为synchronized是JVM实现的一种锁机制，JVM原生支持，而且由于用户对线程的可控度更小，意味着使用起来更加简单，误操作的概率更小。

并发中的集合类

List

线程不安全：ArrayList, LinkedList

故障现象：ConcurrentModificationException，并发修改异常

解决方案

1. Vector: 内部方法加了重锁synchronized，不推荐使用
2. Conllections.synchronizedList(new ArrayList)：内部方法内使用synchronized封锁代码块。
3. CopyOnWriteArrayList，写时复制，并发读。写操作使用lock接口锁住代码块：将共享数组拷贝一份，在副本上进行修改之后将修改后的数组设置为共享数组。

Map

线程不安全：HashMap

解决方案

1. Collections.synchronizedMap() （使用synchronized在方法内部进行代码块封锁）
2. ConcurrentHashMap （实现基本和HashMap一致，在修改操作部分使用synchronized来封锁代码）

Set

线程不安全：HashSet

解决方案

1. Collections.synchronizedSet()，底层其实就是CopyOnWriteArrayList。
2. CopyOnWriteArraySet。

BlockingQueue接口

实现类有：

1. ArrayBlockingQueue:底层Object数组。
2. LinkedBlockingQueue:链表结构的有界阻塞队列(默认大小Integer.MAX_VALUE)。
3. PriorityBlockingQueue.
4. DelayQueue.
5. SynchronizedQueue:不存储元素的阻塞队列，每一个take操作要等待一个put操作，反之亦然。可以用于实现线程间的某个变量的传递。
6. LinkedTransferQueue.
7. LinkedBlockingDeque:链表结构的双向阻塞队列。

阻塞队列很好地表现出了生产者消费者的模型，队列的大小就是资源的的数目上界。其内部的底层就是利用Lock和Condition实现的，已经设计好了线程的操作时的阻塞唤醒，不再需要设计者控制这些线程的细节。最好使用设置超时类型。

手动实现

① 使用Lock和condition（jdk源码的实现方法）

public class MyBlockingQueue1<T> {
    private Queue<T> queue;
    private final int capacity;
    private int size;
    private Lock lock = new ReentrantLock();
    private Condition notFull = lock.newCondition();
    private Condition notEmpty = lock.newCondition();
    public MyBlockingQueue1(int capacity) {
        this.capacity = capacity;
        queue = new LinkedList<>();
    }
    public void put(T data) {
        lock.lock();
        try {
            while (size == capacity) {
                notFull.await();
            }
            queue.add(data);
            size++;
            notEmpty.signal();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }
    public T take() {
        T e = null;
        lock.lock();
        try {
            while (size == 0) {
                notEmpty.await();
            }
            e = queue.remove();
            size--;
            notFull.signal();
        } catch (InterruptedException interruptedException) {
            interruptedException.printStackTrace();
        } finally {
            lock.unlock();
        }
        return e;
    }
}

② 使用信号量Semaphore实现 最简洁的方式，因为临界的判断已经封装在Semaphore内部，只需要在初始化信号量的时候指定阈值即可。

public class MyBlockingQueue2<T> {
    private final Semaphore empty;
    private final Semaphore full;
    private final Semaphore mutex = new Semaphore(1);
    private Queue<T> queue = new LinkedList<>();
    public MyBlockingQueue2(int capacity) {
        this.full = new Semaphore(0);            // 初始可以取的内容
        this.empty = new Semaphore(capacity);    // 初始的可供选择的空位置
    }
    public void put(T data) {
        try {
            empty.acquire();    // 先同步后互斥，防止死锁
            mutex.acquire();
            queue.add(data);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            mutex.release();
            full.release();
        }
    }
    public T take() {
        T t = null;
        try {
            full.acquire();
            mutex.acquire();
            t = queue.remove();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            mutex.release();
            empty.release();
        }
        return t;
    }
}

③ 最传统的方式，使用synchronized关键字

public class MyBlockingQueue3<T> {
    private final int capacity;
    private int size = 0;
    private Queue<T> queue = new LinkedList<>();
    public MyBlockingQueue3(int capacity) {
        this.capacity = capacity;
    }
    public void put(T data) {
        synchronized (this) {
            try {
                while (size == capacity) {
                    this.wait();
                }
                queue.add(data);
                size++;
                this.notifyAll();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
    public T take() {
        T t = null;
        synchronized (this) {
            try {
                while (size == 0) {
                    this.wait();
                }
                t = queue.remove();
                size--;
                this.notifyAll();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        return t;
    }
}

lambda

Stream

Java8之后的一个重要新特性就是链式编程、流式计算。stream是一种数据的渠道，有些类似管道将每一段处理的结果往后传，最终获得一个新的结果。

基本的使用套路就是：

1. 创建一个Stream：一个数据源（数组、集合）。
2. 中间计算操作：处理数据源。
3. 终止操作：一个终止操作，执行中间操作链，产生最终的结果。

四大函数接口

lambda用于简化实现函数式接口，函数式接口需要保证其中的方法无二义性，即只能有一个未定义的方法，可以有多个static、default方法。

Java中将常用的接口的类型高度封装成了四大类型：

线程池

为什么用

在普通情况下，一个线程的使用过程基本就是创建、使用、销毁，但是当我们使用的线程较多的时候就会有较多的时间消耗在创建和销毁这两个对工作无用的过程，同时过多的线程会使系统不堪负重，所以引入了线程池的概念，来增加线程的复用性。

优势作用

线程池的工作就是维护一定运行线程的数量，接受到任务后，从池中派出空闲的线程去处理，处理完后不销毁线程而是留着之后复用。如果请求的线程数超出了限定的数量，超出的线程排队等待，等其他线程执行完任务后，在从阻塞队列中取出任务来执行。

主要的特点就是：

1. 降低系统资源消耗。复用线程，减少创建和销毁的消耗。
2. 提高响应速度。任务到达时，不需要再等待线程的创建，而是直接使用已经创建好的线程。
3. 提高可管理性，控制最大并发数。线程是稀缺资源，如果无限制地创建，不仅会消耗系统资源，还会降低系统的稳定性。线程池则可以将限定数量的多个线程进行统一的管理分配。

如何使用

架构说明

Java中的线程池基于Executor接口，进一步基于ExecutorService接口。最终线程池用到的就是ThreadPoolExecutor类。

三种常用实现

利用线程的工具类Executors来实现创建线程池。

1. 固定长度的线程池。

   Executors.newFixedThreadPool(5); // 一池5个线程

2. 一个池一个线程。

   Executors.newSingleThreadExecutor(); // 一个池1个线程，一个任务一个任务地执行

3. 可伸缩的线程池。

   Executors.newCachedThreadPool();   // 可伸缩的线程池

以上三种的底层本质都是ThreadPoolExecutor

线程池7个重要参数

1. corePoolSize: 线程池中的常驻核心线程。
2. maximumPoolSize: 池中最大线程数，即并发上限。
3. keepAlive: 拓容后，多于常驻数量的空闲线程的最大存活时间，用于控制线程池的伸缩。最终线程的数量维护在corePoolSize的水平。
4. unit: 计量的时间单位。
5. workQueue: 等待执行的任务阻塞队列。
6. threadFactory: 创建线程池中线程的工厂，一般使用默认的即可。
7. handler: 当池子和阻塞队列都已经满后，对于新的请求的拒绝策略。默认为AbortPolicy，即中断程序。

设置合理参数

1. 线程池的最大容量。一般对于CPU密集型的系统，最大容量设置在CPU核数+1左右。因为线程就是处理的分配单位，过多的线程会使得机器忙不过来。
2. 拒绝策略。拒绝策略作为ThreadPoolExecutor的内部类有四种
   • AbortPolicy: 直接抛出RejectedExecutionException异常，终止程序运行。
   • CallerRunsPolicy: 一种向上一级返回任务的处理机制，若当前任务处理不过来，不抛出异常，而是将某些任务回退给调用者处理，从而降低新任务的流量。

• DiscardOldestPoicy: 直接抛弃阻塞队列中等待得最久的任务，然后把当前任务加入阻塞队列中。长江后浪推前浪，前浪死在沙滩上。
• DiscardPolicy: 默默丢弃无法处理的任务，无异常抛出。如果运行任务可丢失，这是最好的一种策略。

线程池底层工作原理

step1：主线程通过execute()方法提交任务请求给线程池，线程池优先使用corePool中的核心常驻线程来处理任务。(corePool中的线程是随着任务的提交逐个建立起来的)

step2：若核心线程池满了，将多余的任务请求放入阻塞队列。

step3：若阻塞队列也满了，立即拓容到最大容量，先处理阻塞队列中的任务。

step4：拓展到最大容量后仍然满，开始启用饱和拒绝策略，不再接受新任务。

step5：拓容后，空闲的线程存活时间达到keepAliveTime，则将其销毁，逐渐收缩回核心池的大小。

线程池的配置

1. CPU密集型：任务需要大量的运算，基本没有阻塞，所以最大池容量可设为（CPU核数+1）。
2. IO密集型：任务需要大量的IO，意味着大量的阻塞，所以尽可能配置更多的线程，一个参考配置是（CPU核数/1-阻塞系数）

小注意点

• shutdown(): 停止接收任务，并且会完成已经接收的任务。

AQS

AbstractQueuedSynchronizer 抽象队列同步器，将多线程情况下基本的获取锁、释放锁的行为封装，供构建其他同步器组件时复用。

内置双向队列来完成线程获取资源的排队机制，使用一个volatile int变量state来表示资源的当前状态。

• state=0，表示资源没有被占用；
• state=1，表示资源被占用。

CountDownLatch

倒计数

用来控制一个或者多个线程等待多个线程。维护了一个计数器cnt，每一次调用countDown()方法，计数器值减1，当减到0时，await之后的代码就可以执行。

CountDownLatch countDownLatch = new CountDownLatch(6);
for (int i = 0; i < 6; i++) {
    int finalI = i;
    new Thread(() -> {
        System.out.println(finalI + " get out");
        countDownLatch.countDown();    // 计数器减一
    }).start();
}
try {
    countDownLatch.await(); // 阻塞之后的代码，当计数器<=0时放行
    System.out.println("count down finish");
} catch (InterruptedException e) {
    e.printStackTrace();
}

CyclicBarrier

正计数

控制多个线程相互等待，当多个线程都同时到达时，之后的任务才继续执行。

public class CyclicBarrierDemo {
    public static void main(String[] args) {
        CyclicBarrier barrier = new CyclicBarrier(5);
        ExecutorService executorService = Executors.newCachedThreadPool();
        for (int i = 0; i < 5; i++) {
            executorService.execute(() -> {
                System.out.println("before...");
                try {
                    barrier.await();
                } catch (InterruptedException | BrokenBarrierException e) {
                    e.printStackTrace();
                }
                System.out.println("after barrier await");
            });
        }
        executorService.shutdown();
    }
}

Semaphore

信号量的Java封装版本，初始化的时候指定阈值即可，api 有 acquire release

Java锁

公平锁、非公平锁

公平锁就是满足先来后到地获取锁，维护一个等待队列；

非公平锁允许插队抢锁，抢锁失败才排到队尾 ==> 效率更高，但会出现饿死。

ReentrantLock默认就是非公平锁，synchronized也是非公平锁。

可重入锁（递归锁）

锁的粒度是线程，而不是调用，所以一个线程可以进入任何一个它拥有的锁同步的代码块。这样做的好处是可以减少死锁的出现。

class Test {
  public void test() {
    synchronized (this) { // 第一次申请锁之后，monitor会维护一个计数器
      ...
        synchronized (this) { ... } 
    }
  }
  public void test2() {
    synchronized (this) {
      test();
    }
  }
  Lock lock = new ReentrantLock();
  public void sendMS(int count) {
    if (count == 4) return;
    lock.lock();
    try {
      sendMS(count + 1);
    } finally {
      lock.unlock();
    }
  }
}

自旋锁

自旋锁就是不阻塞而循环尝试获取锁，循环的时候占用着处理机，使得处理机的利用率下降，但是减少了线程上下文切换的开销。其本质就是while和CAS。

// 手写自旋锁
// 本质 while + CAS，锁的粒度为线程
public class SpinLock {
  AtomicReference<Thread> threadRef = new AtomicReference<>();
  public void lock() {
    Thread thread = Thread.currentThread();
    while (!threadRef.compareAndSet(null, thread)) {
      // 自旋
    }
  }
  // 解锁不需要while
  // 需要解锁说明已经获得了锁，否则就是非法操作
  public void unlock() {
    Thread thread = Thread.currentThread();
    threadRef.compareAndSet(thread, null);
  }
}

独占锁、共享锁

独占锁（互斥锁）指该锁一次只能被一个线程持有，ReentrantLock和synchronized都是独占锁。

共享锁指一个锁能够被多个线程共同持有。

加锁的原本目的就是保证在高并发的情况下数据的一致性，然而读操作并不会修改数据，所以读操作往往使用共享锁；写操作会改变数据，所以写操作需要独占锁。故读读无需互斥，可以提高并发性。juc包中提供的ReentrantReadWriteLock中的读锁就是共享锁，写锁就是独占锁。

死锁处理

排查

死锁是指多个线程在占有着锁/资源的同时又去申请另一个线程占有的锁/资源，导致互相等待。排查方式可以使用jdk提供的命令

$ jps -l        # 查看当前jvm运行的进程，定位进程号
$ jstack [pid]    # 通过进程id查看进程的栈情况，找到死锁查看

public class DeadLockDemo {
  public void acquireLock(String lock1, String lock2) {
    synchronized (lock1) {
      try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace(); }
      synchronized (lock2) { ... }
    }
  }
  public static void main(String[] args) {
    String lock1 = "lock1";
    String lock2 = "lock2";
    DeadLockDemo source = new DeadLockDemo();
    new Thread(() -> { source.acquireLock(lock1, lock2); }).start();
    new Thread(() -> { source.acquireLock(lock2, lock1); }).start();
  }
}

处理

处理没什么好说的，重启吧。

虚拟机内部锁优化

我们知道一个JVM提供的一个同步关键字synchronized，其底层是一个管程进行锁访问计数：

• monitorenter尝试获取锁成功则计数器+1。
  • 第一次获取该锁，则线程持有该锁对象。
  • 已经持有该锁，则直接访问。
• monitorexit释放锁，则计数器-1。一旦计数器的值=0，则该锁对象就背释放了。

但从执行成本来看，获取锁是一个重量级的操作。因为Java的线程本质上是映射到操作系统的原生内核线程之上的，所以如果要对线程进行操作，底层实际上是要申请操作系统来进行管理，即涉及到系统调用接着就是用户态和核心态的转换，这种状态的转换对处理器的资源开销是很大的。

然而，有时候同步块执行时间并不长，所以这种对互斥量的申请开销就显得更加大了。

自旋锁、自适应自旋

自旋忙等开销与线程切换开销的权衡。

针对上述提到的问题：在许多应用上，共享数据的锁定状态持续时间很短。那么，为了这段时间而进行线程的挂起、恢复就非常不值得，所以可以使用让线程自旋忙等一会的方式，不放弃处理机的时间进行短时间的等待。

这就是对自旋忙等开销与线程切换开销的一种权衡。一旦自旋的次数超过一定范围，再恢复进行传统的方式挂起线程。

所谓的自适应自旋就是在自旋次数上的一种调配，根据之前成功访问锁定状态的自旋次数，来合理分配当前次数。例如，若上一次的自旋很快就成功进入临界区，那么本次的自旋也就认为能够比较快成功，故设定的等待时间就会更加长。

锁消除

锁消除就是指虚拟机编译器在运行时，对于一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。这个判断依据主要源于逃逸分析的数据支持，若发现在堆上的所有数据都不会逃逸出去被其他线程访问，则可以去掉同步措施。只有对象线程逃逸时，才需要保留同步措施。

锁粗化

锁粗化的意思就是：如果一系列的连续操作都是对一个对象反复加锁、解锁，且对象的作用域限定在这一系列操作范围内，通过扩大加锁同步的范围来减小连续加锁、减锁的开销。

public String concatString(String s1, String s2, String s3) {
    StringBuffer b = new StringBuffer();
    b.append(s1);
    b.append(s2);
    b.append(s3);
    return b.toString();
}

典型的例子就是拼接字符串，append操作内部就是一个互斥同步的过程，所以这一系列连续的append操作就相当于连续进行同步互斥，这么频繁的互斥同步操作导致了不必要的开销。所以虚拟机检测到这种情况，就会把加锁同步的范围拓展到整个操作序列外部。

但是有一个重要的前提就是：b的作用域是限定在这一系列操作范围内的，外部不会再对b进行引用。

锁定 {
    b.append(s1)
    b.append(s2)
    b.append(s3)
}

偏向锁

当前锁对象认为只会有一个线程来访问它。

线程只在最初始的时候通过CAS修改对象偏向的线程ID，之后访问都只需要比对ID，消除了所有同步操作。没有第二个线程来，就一直不会释放偏向锁。一旦有另一个线程来临，就会检查当前偏向锁的持有线程是否执行完，执行完则对象恢复到无锁状态重新偏向，否则偏向锁升级为轻量级锁。

轻量级锁

没有多线程，就不同步

线程通过CAS来获取一个锁对象，通过CAS来释放锁对象。在执行同步代码块的时候，一律都不进行同步互斥的操作。

• 一旦另一条线程自旋忙等超过一定时间，则锁升级。
• 一旦有两条以上的线程竞争同一个锁对象，那么轻量级锁就要升级为重量级锁，即进行同步互斥操作，调用操作系统的服务阻塞竞争失败的线程。

所谓的获取锁对象就是将对象的Mark Word更新为指向线程私有栈中的Lock Record字段的指针。

锁升级

偏向锁，轻量级锁都是乐观锁，所谓乐观就是认为不存在竞争或者是竞争很小，通过自旋就能够解决； 重量级锁是悲观锁，认为竞争有必要让操作系统来处理，阻塞竞争失败的线程。

偏向锁 -> 轻量级锁

一个对象刚开始实例化的时候，没有任何线程来访问它，它是可偏向的，认为只可能有一个线程来访问它。那么。当第一个线程来访问它的时候，线程通过CAS修改对象头的锁状态、ThreadID为自己的ID，之后该线程就可以通过ID来顺利访问该对象，虚拟机不再进行任何同步操作（加锁、解锁、修改Mark Word）。此时的对象就偏向了这个线程

因为偏向锁不会主动释放，所以第二个线程来访问此对象的时候就会发现偏向锁不是偏向自己，就会检查该锁的持有线程是否还在同步块中工作：

• 如果不在，则可以将对象变为无锁状态，然后重新偏向新的线程；
• 否则，存在竞争，修改Mark Word升级为轻量级锁，进行自旋等待。

轻量级锁 -> 重量级锁

轻量级锁认为竞争存在，但是竞争的程度很轻，一个线程可以通过自旋忙等来稍微等待另一个线程完成任务。 但是当自旋超过一定的次数；或者有第三个线程参与竞争，轻量级锁升级为重量级锁。重量级锁就开始调用操作系统的服务，阻塞竞争失败的线程。

锁升级带来的好处

能够不使用同步互斥措施就不使用，实在需要一定措施的话就尽量在用户态解决同步问题，减少操作系统级别的同步互斥的开销。