第四天深挖线程池原理

阻塞队列和线程池原理

阻塞队列

队列

队列是一种特殊的线性表，特殊之处在于它只允许在表的前端（front）进行删除操作，而在表的后端（rear）进行插入操作。和栈一样，队列是一种操作受限制的线性表。进行插入操作的端称为队尾，进行删除操作的端称为队头。

在队列中插入一个队列元素称为入队，从队列中删除一个队列元素称为出队。因为队列只允许在一端插入，在另一端删除，所以只有最早进入队列的元素才能最先从队列中删除，故队列又称为先进先出（FIFO—First In First Out）线性表。

什么是阻塞队列？

1）支持阻塞的插入方法：意思是当队列满时，队列会阻塞插入元素的线程，直到队列不满。

2）支持阻塞的移除方法：意思是在队列为空时，获取元素的线程会等待队列变为非空。

在并发编程中使用生产者和消费者模式能够解决绝大部分并发问题。该模式通过平衡生产线程和消费线程的工作能力来提高程序的整体处理数据的速度。

在线程世界里，生产者就是生产数据的线程，消费者就是消费数据的线程。在多线程开发中，如果生产者处理速度很快，而消费者处理速度很慢，那么生产者就必须等待消费者处理完，才能继续生产数据。同样的道理，如果消费者的处理能力大于生产者，那么消费者就必须等待生产者。

为了解决这种生产消费能力的不均衡的问题，便有了生产者和消费者模式。生产者和消费者模式是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通信，而是通过阻塞队列来进行通信。所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列中取，阻塞队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。

阻塞队列常用于生产者和消费者的场景，生产者是向队列里添加元素的线程，消费者是从队列里取元素的线程。阻塞队列就是生产者用来存放元素，消费者用来获取元素的容器。

常用阻塞队列

ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列
LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列
PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列
DelayQueue：一个使用优先级队列实现的无界阻塞队列
SynchronousQueue：一个不存储元素的阻塞队列
LinkedTransferQueue：一个由链表结构组成的无界阻塞队列
LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列

以上的阻塞队列均实现了BlockingQueue接口，也都是线程安全的。

有界无界

有限队列就是长度有限，满了以后生产者会阻塞，无界队列就是里面能放无数的东西而不会因为队列长度限制被阻塞，当然空间限制来源于系统资源的限制，如果处理不及时，导致队列越来越大越来越大，超出一定的限制致使内存超限，操作系统或者JVM帮你解决烦恼，直接把你 OOM kill 省事了。

无界也会阻塞，为何？因为阻塞不仅仅体现在生产者放入元素时会阻塞，消费者拿取元素时，如果没有元素，同样也会阻塞。

ArrayBlockingQueue

是一个用数组实现的有界阻塞队列。此队列按照先进先出（FIFO）的原则对元素进行排序。默认情况下不保证线程公平的访问队列，所谓公平访问队列是指阻塞的线程，可以按照阻塞的先后顺序访问队列，即先阻塞线程先访问队列。非公平性是对先等待的线程是非公平的，当队列可用时，阻塞的线程都可以争夺访问队列的资格，有可能先阻塞的线程最后才访问队列。初始化时有参数可以设置

LinkedBlockingQueue

是一个用链表实现的有界阻塞队列。此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。

Array实现和Linked实现的区别

队列中锁的实现不同
ArrayBlockingQueue实现的队列中的锁是没有分离的，即生产和消费用的是同一个锁；
LinkedBlockingQueue实现的队列中的锁是分离的，即生产用的是putLock，消费是takeLock。
在生产或消费时操作不同
ArrayBlockingQueue实现的队列中在生产和消费的时候，是直接将枚举对象插入或移除的；
LinkedBlockingQueue实现的队列中在生产和消费的时候，需要把枚举对象转换为Node进行插入或移除，会影响性能。
队列大小初始化方式不同
ArrayBlockingQueue实现的队列中必须指定队列的大小；
LinkedBlockingQueue实现的队列中可以不指定队列的大小，但是默认是Integer.MAX_VALUE。

PriorityBlockingQueue

PriorityBlockingQueue是一个支持优先级的无界阻塞队列。默认情况下元素采取自然顺序升序排列。也可以自定义类实现compareTo()方法来指定元素排序规则，或者初始化PriorityBlockingQueue时，指定构造参数Comparator来对元素进行排序。需要注意的是不能保证同优先级元素的顺序。

DelayQueue

是一个支持延时获取元素的无界阻塞队列。队列使用PriorityQueue来实现。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。只有在延迟期满时才能从队列中提取元素。

DelayQueue非常有用，可以将DelayQueue运用在以下应用场景。

缓存系统的设计：可以用DelayQueue保存缓存元素的有效期，使用一个线程循环查询DelayQueue，一旦能从DelayQueue中获取元素时，表示缓存有效期到了。

SynchronousQueue

是一个不存储元素的阻塞队列。每一个put操作必须等待一个take操作，否则不能继续添加元素。SynchronousQueue可以看成是一个传球手，负责把生产者线程处理的数据直接传递给消费者线程。队列本身并不存储任何元素，非常适合传递性场景。

LinkedTransferQueue

多了tryTransfer和transfer方法：

l’如果当前有消费者正在等待接收元素（消费者使用take()方法或带时间限制的poll()方法时），transfer方法可以把生产者传入的元素立刻transfer（传输）给消费者。如果没有消费者在等待接收元素，transfer方法会将元素存放在队列的tail节点，并等到该元素被消费者消费了才返回。

（2）tryTransfer方法
tryTransfer方法是用来试探生产者传入的元素是否能直接传给消费者。如果没有消费者等待接收元素，则返回false。和transfer方法的区别是tryTransfer方法无论消费者是否接收，方法立即返回，而transfer方法是必须等到消费者消费了才返回。

LinkedBlockingDeque

LinkedBlockingDeque是一个由链表结构组成的双向阻塞队列。所谓双向队列指的是可以从队列的两端插入和移出元素。双向队列因为多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。

多了addFirst、addLast、offerFirst、offerLast、peekFirst和peekLast等方法，以First单词结尾的方法，表示插入、获取（peek）或移除双端队列的第一个元素。以Last单词结尾的方法，表示插入、获取或移除双端队列的最后一个元素。另外，插入方法add等同于addLast，移除方法remove等效于removeFirst。但是take方法却等同于takeFirst，不知道是不是JDK的bug，使用时还是用带有First和Last后缀的方法更清楚。在初始化LinkedBlockingDeque时可以设置容量防止其过度膨胀。另外，双向阻塞队列可以运用在“工作窃取”模式中。

线程池

为什么要用线程池

Java中的线程池是运用场景最多的并发框架，几乎所有需要异步或并发执行任务的程序都可以使用线程池。在开发过程中，合理的使用线程池能够带来3个好处：

1）降低资源消耗 通过重复利用已创建的线程降低线程创建和销毁造成的消耗。

2）提高响应速度 当任务到达时，任务可以不需要等到线程创建就立即执行。

假设一个服务器完成一项任务所需时间为：T1创建线程时间，T2在线程中执行任务的时间，T3销毁线程时间。

如果T1+T3远大于T2，则可以采用线程池，以提高服务器性能。线程池技术正是关注如何缩短或调整T1、T3时间的技术，从而提高服务器程序性能的。它把T1 和 T3分别安排在服务器程序的启动和结束的时间段或者一些空闲的时间段，这样在服务器程序处理客户请求时，不会有T1 和 T3的开销了。

3）提高线程的可管理性 线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一分配、调优和监控。

ThreadPoolExecutor 的类关系

Executor是一个接口，它是Executor框架的基础，它将任务的提交和任务的执行分离开来。

ExecutorService接口继承了Executor，在此之上做了一些shutdown() 和 submit()的扩展，可以说是真正的线程池接口。

AbstractExecutorService抽象类实现了ExecutorService接口中的大部分方法。

ThreadPoolExecutor是线程池的核心实现类，用来执行被提交的任务。

ScheduledExecutorService接口继承了ExecutorService接口，提供了带“周期执行”功能的ExecutorService。

ScheduledThreadPoolExecutor是一个实现类，可以在给定的延迟后运行命令，或者定期执行命令。ScheduledThreadPoolExecutor比Timer更灵活，功能更强大。

线程池的创建

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, 
                              TimeUnit  unit, BlockingQueue<Runnable> workQueue, 
                                  ThreadFactory threadFactory, RejectedExecutionHandler handler)

corePoolSize

线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize。

如果当前线程数改为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行。

如果执行了线程池的 prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程。

maximumPoolSize

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

keepAliveTime

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

TimeUnit

keepAliveTime的时间单位。

workQueue

workQueue必须是BlockingQueue类型的阻塞队列。当线程池中的线程数超过它的corePoolSize的时候，线程会进入阻塞队列，进行阻塞等待。通过workQueue，线程池实现了阻塞功能。

1）当线程池中的线程数达到了corePoolSize后，新任务将在无界队列中等待，因此线程中的线程数不会超过corePoolSize。

2）由于1的原因，使用无界队列时maximumPoolSize将是一个无效的参数。

3）由于1和2，使用无界队列时，keepAliveTime将是一个无效的参数。

4）更重要的是，使用无界队列可能会耗尽系统资源，有界队列则有助于防止资源耗尽，同时即使使用有界队列，也要尽量控制队列的大小在一个合适的范围。

threadFactory

创建线程的工厂，通过自定义的线程工厂可以给每个新建的线程设置一个具有识别度的线程名，当然还可以更加自由的对线程做更多的设置，比如设置所有的线程为守护线程。

Executors静态工厂里默认的threadFactory，线程的命名规则是“pool-数字-thread-数字”。

RejectedExecutionHandler

线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：

（1）AbortPolicy：直接抛出异常，默认策略

（2）CallerRunsPolicy：用调用者所在线程执行该任务

（3）DiscardOldestPolicy：丢弃阻塞队列中最靠前的任务，并执行当前任务

（4）DiscardPolicy：直接丢弃任务

当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务。

线程池的工作机制

（1）如果当前运行的线程数少于corePoolSize，则创建新线程来执行任务（注意，执行这一步骤需要获取全剧锁）

（2）如果运行的线程等于或多于corePoolSize，则将任务加入到BlockingQueue。

（3）如果无法将任务加入BlockingQueue（队列已满），则创建新的线程来处理任务。

（4）如果创建新线程将使当前的运行线程数超过maximumPoolSize，任务将被拒绝，并调用RejectedExecutionHandler.rejetedExecution()方法。

提交任务

executor()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。

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

关闭线程池

可以通过调用线程池的shutdown()或shutdownNow()方法来关闭线程池，它们的原理是遍历线程池中的工作线程，然后逐个调用线程的 interrupt() 方法来中断线程，所以无法响应中断任务的线程可能永远无法停止，但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成 STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表；而shutdown只是将线程池的状态设置为 SHUTDOWN 状态，然后中断所有没有正在执行任务的线程。

只要调用了这两个关闭方法中的任意一个，isShutDown() 方法就会返回 true，当所有的任务都已关闭后，才表示线程池关闭成功，这时调用 isTerminaled() 方法则会返回 true。至于应该调用哪一种方法来关闭线程池，应该由提交到线程池任务特性来决定的，通常调用 shutdown 方法来关闭线程池，如果任务不一定要执行完，则可以调用shutdownNow() 方法。

合理化线程池配置

要想合理的配置线程池，就必须首先分析任务特性，可以从以下几个角度老看：

任务的性质：CPU密集型任务、IO密集型任务和混合型任务
任务的优先级：高、中和低
任务的执行时间：长、中和短
任务的依赖性：是否依赖其他的系统资源，如数据库连接

性质不同的任务可以使用不同规模的线程池分开处理

CPU密集型任务：应配置尽可能小的线程，如配置Ncpu+1个线程的线程池。

IO密集型任务：因为该任务并不一定是一直在执行任务，则应配置尽可能多的线程，如2*Ncpu

混合型的任务：如果可以拆分，将其拆分成一个CPU密集型任务和一个IO密集型任务，只要这两个任务的时间相差不是太大，那么分解后执行的吞吐量将高于串行执行的吞吐量，如果这两个任务执行时间相差过大，则没必要进行分解。可以通过Runtime.getRuntime().availableProcessors()方法获得当前CPU个数。

优先级不同的任务：可以使用优先级队列 PriorityBlockingQueue来处理，它可以让优先级高的任务先执行。

执行时间不同的任务：可以交给不同规模的线程池来处理，或者可以使用优先级队列，让执行时间短的任务先执行。

建议：建议使用有界队列，有界队列能增加系统的稳定性和预警能力，可以根据需要设置大一点，比如几千；如果我们设置成无界队列，那么线程池的队列会越来越多，有可能会撑爆内存，导致整个系统不可用，这是致命的。

AbstractQueuedSynchronizer

学习AQS的必要性

队列同步器 AbstractQueuedSynchronizer（以下简称同步器或AQS），是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，并发包的大师（Doug Lea）期望它能够成为实现大部分同步需求的基础。

AQS使用方式和其中的设计模式

AQS的主要使用方式是继承，子类通过继承AQS并实现它的抽象方法来管理同步状态，在AQS里由一个int类型的state来代表这个状态，在抽象方法的实现过程当中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法（getState()、setState(int newState) 和 compareAndSetState(int expect, int update)）来进行操作，因为它们能够保证状态的改变是安全的。

/**
 * The synchronization state
 */
 private volatile int state;

在实现上，子类推荐被定义为自定义同步组件的静态内部类，AQS自身没有实现任何同步的接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式的获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件（ReentrantLock、ReentrantReadWriteLock 和 CountDownLatch等）。

同步器是实现锁（也可以是任意同步组件）的关键，在锁的实现中聚合同步器。可以这样理解二者之间的关系：

锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；

同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所需关注的领域。

实现者需要继承同步器并重写指定的方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些模板方法将会调用使用者重写的方法。

模板方法模式

同步器的设计基于模板方法模式。模板方法模式的意图是，定义一个操作中的算法的骨架，而将一些步骤的实现延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，我们最常见的就是Spring框架中的Template。

举例说明
假设，我们开了个蛋糕店，蛋糕店不能只卖一种蛋糕，于是我们决定先卖奶油蛋糕、芝士蛋糕和慕斯蛋糕，三种蛋糕在制作方式上一致，都包括造型、烘培和涂抹蛋糕，所以可以定义一个抽象蛋糕类型：

public abstract class AbstractCake{
    protected abstract void shape();
    protected abstract void apply();
    protected abstract void brake();

    /**模板方法**/
    public final void run(){
        this.shape();
        this.apply();
        this.brake();
    }
}

然后就可以批量生产三种蛋糕了

public class CheeseCake extends AbstractCake{

      @Override
      protected void shape(){
          System.out.println("芝士蛋糕造型");
      }

      @Override
      protected void apply(){
          System.out.println("芝士蛋糕涂抹");
      }

      @Override
      protected void brake(){
          System.out.println("芝士蛋糕烘培");
      }
}

public class CreamCake extends AbstractCake{

      @Override
      protected void shape(){
          System.out.println("奶油蛋糕造型");
      }

      @Override
      protected void apply(){
          System.out.println("奶油蛋糕涂抹");
      }

      @Override
      protected void brake(){
          System.out.println("奶油蛋糕烘培");
      }
}

public class MuseCake extends AbstractCake{

      @Override
      protected void shape(){
          System.out.println("慕斯蛋糕造型");
      }

      @Override
      protected void apply(){
          System.out.println("慕斯蛋糕涂抹");
      }

      @Override
      protected void brake(){
          System.out.println("慕斯蛋糕烘培");
      }
}

AbstractCake cake = new CheeseCake();
//AbstractCake cake = new CreamCake();
//AbstractCake cake = new MuseCake();
cake.run();
``` 

这样一来，不但可以批量生产三种蛋糕，而且如果日后有扩展，只需要继承抽象蛋糕方法就可以了，十分方便，我们天天生意做得越来越赚钱。突然有一天，我们发现市面有一种最简单的小蛋糕销量很好，这种蛋糕就是简单烘烤成型就可以卖，并不需要涂抹什么食材，由于制作简单销售量大，这个品种也很赚钱，于是我们也想要生产这种蛋糕。但是我们发现了一个问题，抽象蛋糕是定义了抽象的涂抹方法的，也就是说扩展的这种蛋糕是必须要实现涂抹方法，这就很鸡儿蛋疼了。怎么办？我们可以将原来的模板修改为带钩子的模板。

```java
public abstract class AbstractCake{
    protected abstract void shape();
    protected abstract void apply();
    protected abstract void brake();

    /**模板方法**/
    public final void run(){
        this.shape();
        if(this.isShouldApply()){}
            this.apply();
        }
        this.brake();
    }
}

做小蛋糕的时候通过flag来控制是否涂抹，其余已有的蛋糕制作不需要任何修改可以照常进行。

public class SmallCake extends AbstractCake{

    private boolean flag = false;
    public void setFlag(boolean shouldApply){
        flag = shouldApply;
    }

    @Override
    protected void shouldApply(){
        return this.flag;
    }

    @Override
    protected void shape(){
        System.out.println("精致小蛋糕造型");
    }

    @Override
    protected void apply(){
        System.out.println("精致小蛋糕涂抹");
    }

    @Override
    protected void brake(){
        System.out.println("精致小蛋糕烘培");
    }
}

AQS中的方法

模板方法

实现自定义同步组件时，将会调用同步器提供的模板方法：

这些模板方法同步器提供的模板方法基本上分为3类：独占式获取与释放同步状态、共享式获取与释放、同步状态和查询同步队列中的等待线程情况

可重写的方法

访问或修改同步状态的方法

重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。

getState()：获取当前同步状态。
setState(int newState)：设置当前同步状态。
compareAndSetState(int expect,int update)：使用CAS设置当前状态，该方法能够保证状态设置的原子性。

CLH队列锁

CLH队列锁即Craig, Landin, and Hagersten (CLH) locks。

CLH队列锁也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程仅仅在本地的变量上自旋，它不断轮训前驱的状态，假设发现了前驱释放了锁就结束自旋，当一个线程需要获取锁时：

1、创建一个QNode，将其中的locked设置为true，表示需要获取锁，myPred表示对其前驱结点的引用。

2、线程A对tail域调用getAndSet()方法，使自己成为队列的尾部，同时获取一个指向其前驱结点的引用myPred。

线程B需要获得锁，同样的流程再来一遍

3、线程就在前驱结点的locked字段上旋转，直到前驱结点释放锁（前驱结点的锁值 locked==false）

4、当一个线程需要释放锁时，将当前结点的locked域设置为false，同时回收前驱结点

如上图所示，前驱结点释放锁，线程A的myPred所指向的前驱结点的locked字段变为false，线程A就可以获取到锁。

CLH队列锁的优点

空间复杂度低（如果有n个线程，L个锁，每个线程每次只获取一个锁，那么需要的存储空间是 O(L+n)，n个线程有n个myNode，L个锁有L个tail）。CLH队列锁常用在SMP体系结构下。

Java中的AQS是CLH队列锁的一种变体实现。

ReentrantLock 的实现

锁的可重入

重进入是指任意线程在获取到锁之后，能够再次获取该锁而不会被锁阻塞，该特性的实现需要解决以下两个问题：

1）线程再次获取锁，锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取；

2）锁的最终释放。线程重复n次获取了锁，随后在第n次释放了锁，其他线程能够获取到该锁，锁的最终释放要求锁对于获取进行进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

nonfairTryAcquire() 方法增加了再次获取同步状态的处理逻辑：通过判断当前线程是否为获取锁的线程来决定获取操作是否成功，如果是获取锁的线程再次请求，则将同步状态值进行增加并返回true，表示获取同步状态成功，同步状态表示锁被一个线程重复获取的次数。

如果该锁被获取了n次，那么前（n-1）次tryRelease(int releases)方法必须返回false，而只有同步状态完全释放了，才能返回true，可以看到，该方法将同步状态是否为0作为最终释放的条件，当同步状态为0时，将占有线程设置为null，并返回true，表示释放成功。

公平和非公平锁

ReentrantLock的构造函数中，默认的无参构造函数会把Sync对象创建为NonfairSync对象，这是一个“非公平锁”；而另一个构造函数ReentrantLock(boolean fair)传入参数为true时，会把Sync对象创建为“公平锁”FairSync。

nonfairTryAcquire(int acquires)方法，对于非公平锁，只要CAS设置同步状态成功，则表示当前线程获取了锁，而公平锁则不同。

tryAcquire方法，该方法与nonfairTryAcquire(int acquires)比较，唯一不同的位置为判断条件多了hasQueuedPredecessors()方法，即加入了同步队列中当前节点是否有前驱节点的判断，如果该方法返回true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。

深入理解并发编程

JMM基础-计算机原理

Java内存模型即Java Memory Model，简称JMM。JMM定义了Java 虚拟机(JVM)在计算机内存(RAM)中的工作方式。JVM是整个计算机虚拟模型，所以JMM是隶属于JVM的。Java1.5版本对其进行了重构，现在的Java仍沿用了Java1.5的版本。JMM遇到的问题与现代计算机中遇到的问题是差不多的。

物理计算机中的并发问题，物理机遇到的并发问题与虚拟机中的情况有不少相似之处，物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。

根据《Jeff Dean在Google全体工程大会的报告》我们可以看到

计算机在做一些我们平时的基本操作时，需要的响应时间是不一样的。
（以下案例仅做说明，并不代表真实情况。）

如果从内存中读取1M的int型数据由CPU进行累加，耗时要多久？

做个简单的计算，1M的数据，Java里int型为32位，4个字节，共有10241024/4 = 262144个整数，则CPU 计算耗时：262144 0.6 = 157 286 纳秒，而我们知道从内存读取1M数据需要250000纳秒，两者虽然有差距（当然这个差距并不小，十万纳秒的时间足够CPU执行将近二十万条指令了），但是还在一个数量级上。但是，没有任何缓存机制的情况下，意味着每个数都需要从内存中读取，这样加上CPU读取一次内存需要100纳秒，262144个整数从内存读取到CPU加上计算时间一共需要262144*100+250000 = 26 464 400 纳秒，这就存在着数量级上的差异了。

而且现实情况中绝大多数的运算任务都不可能只靠处理器“计算”就能完成，处理器至少要与内存交互，如读取运算数据、存储运算结果等，这个I/O操作是基本上是无法消除的（无法仅靠寄存器来完成所有运算任务）。早期计算机中cpu和内存的速度是差不多的，但在现代计算机中，cpu的指令速度远超内存的存取速度,由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

在计算机系统中，寄存器划是L0级缓存，接着依次是L1，L2，L3（接下来是内存，本地磁盘，远程存储）。越往上的缓存存储空间越小，速度越快，成本也更高；越往下的存储空间越大，速度更慢，成本也更低。从上至下，每一层都可以看做是更下一层的缓存，即：L0寄存器是L1一级缓存的缓存，L1是L2的缓存，依次类推；每一层的数据都是来至它的下一层，所以每一层的数据是下一层的数据的子集。

在现代CPU上，一般来说L0， L1，L2，L3都集成在CPU内部，而L1还分为一级数据缓存（Data Cache，D-Cache，L1d）和一级指令缓存（Instruction Cache，I-Cache，L1i），分别用于存放数据和执行数据的指令解码。每个核心拥有独立的运算处理单元、控制器、寄存器、L1、L2缓存，然后一个CPU的多个核心共享最后一层CPU缓存L3。

Java内存模型（JMM）

从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

可见性

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

由于线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量，那么对于共享变量V，它们首先是在自己的工作内存中，之后再同步到主内存中，可是并不会即时的刷入主内存中，而是会有一定的时差，很明显这个时候线程A对变量V的操作对于线程B而言就不具备可见性了。

要解决共享对象可见性的问题，我们可以使用volatile关键字或者加锁。

原子性

原子性：即一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

我们都知道CPU资源的分配都是以线程为单位的，并且是分时调用，操作系统允许某个进程执行一小段时间，例如50毫秒，过了50毫秒操作系统就会重新选择一个进程来执行（即我们所说的“任务切换”），这个50毫秒称为“时间片”。而任务的切换大多数是在时间片段结束以后。

那么线程切换为什么会带来问题呢？因为操作系统做任务切换，可以发生在任何一条CPU指令执行完！注意，是CPU指令！CPU指令！CPU指令！而不是高级语言里的一条语句，比如 count++，在Java里就是一条语句，但是高级语言里的一条语句往往需要多条CPU指令完成。其实count++至少包含了3条CPU指令！

volatile详解

volatile特性

可以把volatile变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步

可以看成

所以volatile本身具有以下这些特性：

可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。

原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作则不具备原子性。

volatile虽然能保证执行完并及时把变量刷到主内存中，但对于count++这种非原子性、多指令的情况，由于线程切换，线程A刚把 count=0 加载到主内存，线程B就可以开始工作了，这样就会导致线程A和B执行完的结果都是1，都写到主内存中，主内存的值还是1却不是2。

volatile的实现原理

volatile关键字修饰的变量会存在一个“lock:”的前缀。

Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。LockLock会对CPU总线和高速缓存枷锁，可以理解为CPU指令级的一种锁。

同时该指令会将当前处理器缓存行的数据直接写回到系统内存中，且这个写回到内存的操作会使在其他CPU里缓存了该地址的数据无效。

synchronized 的实现原理

Synchronized在JVM里的实现都是基于进入和退出Monitor对象来实现方法同步和代码块同步的，虽然具体实现细节不大一样，但是都可以通过成对的MonitorEnter 和 MonitorExit 指令来实现。

对同步块，MonitorEnter指令插入在同步代码块的开始位置，当代码执行到该指令时，将会尝试获取该对象Monitor的所有权，即尝试获得该对象的锁，而MonitorExit指令则插在方法结束处和异常处，JVM保证每个MonitorEnter必须有对应的MonitorExit。

对同步方法，从同步方法反编译的结果来看，方法的同步并没有通过MonitorEnter和MonitorExit来实现，相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标识符。（注：这个后面研究Java字节码再细入）

JVM就是根据该标识符来实现方法同步的：当方法被调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标识是否被设置，如果设置了，执行线程将先获取 monitor，获取成功之后才能执行方法体，方法执行完后再释放Monitor。在方法执行期间，其他任何线程都无法再获得同一个Monitor对象。

synchronized使用的锁是存放在Java对象头里的

具体位置是对象头的MarkWord，MarkWord里默认数据是存储对象的HashCode等信息

但是会随着对象的运行改变而发生变化，不同的锁状态对应着不同的记录存储方式

了解各种锁

自旋锁

原理

自旋锁原理非常简单，如果持有锁的线程能在很短的时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换消耗。

但是线程自旋是需要消耗CPU的，说白了就是让CPU在做无用功，线程不能一直占有CPU自旋做无用功，所以需要设置一个自旋等待的最大时间。

如果持有锁的线程执行的时间超过自旋等待的最大时间仍然没有释放锁，就会导致其他争用锁的线程在最大等待时间还是获取不到锁，这是争用线程就会停止自旋进入阻塞状态。

自旋锁的优缺点

自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能最大幅度的提升，因为自旋的消耗小于线程阻塞挂起操作的消耗！

但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用自旋锁了，因为自旋锁在获取锁之间一直都是占用CPU做无用功的，线程自旋的消耗大于线程阻塞挂起的操作消耗，其他需要CPU的线程又获取不到CPU，造成CPU的浪费。

自旋锁的时间阈值

自旋锁的目的是为了占着CPU的资源不释放，等到获取到锁立即进行处理。但是如何去选择自旋的执行时间呢？如果自旋执行时间太长，会有大量的线程处于自旋状态占用CPU资源，进而会影响整体系统的性能。因此自旋次数很重要。

JVM对于自旋次数的选择，jdk1.5默认为10次，在1.6引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间。

JDK1.6中-XX:+UseSpinning开启自旋锁； JDK1.7后，去掉此参数，由jvm控制；

锁的状态

一共有4种状态，无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，它会随着竞争情况逐渐升级，锁可以升级但不能降级，目的是为了提高获得锁和释放锁的效率。

偏向锁

引入背景：大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁，减少不必要的CAS操作。

偏向锁 顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，减少加锁/解锁的一些CAS操作（比如等待队列的一些CAS操作），这种情况下，就会给线程加一个偏向锁。如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁，它通过消除资源无竞争情况下的同步原语，进一步提高了程序的运行性能。

偏向锁获取过程：

步骤1、访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01，确认为可偏向状态。

步骤2、如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤5，否则进入步骤3。

步骤3、如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行5；如果竞争失败，执行4。

步骤4、如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。（撤销偏向锁的时候会导致stop the word）

步骤5、执行同步代码。

偏向锁的释放：

偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放偏向锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

偏向锁的适用场景：

始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去执行同步块，在锁无竞争的情况下使用，一旦有了竞争就升级为轻量级锁，升级为轻量级锁的时候需要撤销偏向锁，撤销偏向锁的时候会导致stop the word操作；

在有锁的竞争时，偏向锁会多做很多额外操作，尤其是撤销偏向所的时候会导致进入安全点，安全点会导致stw，导致性能下降，这种情况下应当禁用。

jvm开启/关闭偏向锁
开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：-XX:-UseBiasedLocking

轻量级锁

轻量级锁是由偏向锁升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁；

轻量级锁的加锁过程：

在代码进入同步块的时候，如果同步对象锁状态为无锁状态且不允许进行偏向（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。

拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤4，否则执行步骤5。

如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态；

如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，当竞争线程尝试占用轻量级锁失败多次之后，轻量级锁就会膨胀为重量级锁，重量级线程指针指向竞争线程，竞争线程也会阻塞，等待轻量级线程释放锁后唤醒他。锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。