深入理解锁，同步器以及线程池

ThreadPoolExecutor线程池中线程不能超过核心线程数量的问题

    int arg1=2;//核心线程
    int arg2=40;//最大线程数量
    int arg3=100;//空余保留时间
    
    ThreadPoolExecutor pool=new ThreadPoolExecutor(arg1, arg2, arg3,TimeUnit.MILLISECONDS, // 时间单位
    
    new LinkedBlockingQueue<Runnable>());//默认构造的队列大小为Integer.Max, 可指定大小new LinkedBlockingQueue<Runnable>(3)，队列容量为3
    for(int i=0;i<10;i++){
       pool.execute(new Mythread(String.valueOf(i))); 
    }  

---

在自定义的Mythread类的run方法中休眠一段时间（5秒），来模拟执行的任务，我原以为循环了10次，执行10个任务，由于小于最大线程数量40，线程池应该会新建10个线程来执行这10个任务，但是实验结果发现线程池中只有2个线程（即两个核心线程）来执行这10个任务，所以共执行了5*10/2=25s时间，而不是我想象中的5s。

原因在于，LinkedBlockingQueue的容量默认大小是Integer.Max，在任务没有填满这个容量之前线程池大小是不会超过设定的核心线程数量2的。

当制定LinkedBlockingQueue长度为3时，这10个线程任务有两个在核心线程中执行，有3个放在任务队列中，另外5个任务将另起新线程来执行。

定义线程池的四种常用方式

1. Executors.newSingleThreadExecutor()： 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。线程池中只有一个核心线程，当有任务提交时，若该核心线程空闲，则用来处理该请求。若当先线程池中的线程已被占用，则将该请求放置在任务队列中，等待线程空闲时调用。

public static ExecutorService newSingleThreadExecutor() {
        return new FinalizableDelegatedExecutorService(new ThreadPoolExecutor(corePoolSize:1, maximumPoolSize:1, KeepAliveTime:0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>()));
    }  

2. Executors.newFixedThreadPool(int n)： 创建一个可重用固定个数的线程池，以共享的无界队列方式来运行这些线程。线程池中只有数量固定的核心线程，没有非核心线程。

public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,keepAliveTime:0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>());
    }

3. Executors.newCacheThreadPool()： 可缓存线程池，先查看池中有没有以前建立的线程，如果有，就直接使用。如果没有，就建一个新的线程加入池中，缓存型池子通常用于执行一些生存期很短的异步型任务。线程池中核心线程数量为0，当有任务提交时，若线程池中有空闲线程，则处理请求，若没有空闲线程，则创建一个新的线程放入到线程池中。

 public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(corePoolSize:0, Integer.MAX_VALUE,KeepAliveTime:60L, TimeUnit.SECONDS,new SynchronousQueue<Runnable>());
    }

4. Executors.newScheduledThreadPool(int n)： 创建一个定长线程池，支持定时及周期性任务执行。（定义线程池时）指定核心线程数量，非核心线程数量不固定。有请求提交时，先判断是否有核心线程空闲，若有核心线程空闲则处理请求。若没有，则判断是否超出任务队列的长度，没有则放置在任务队列中，若超出任务队列长度，则先将任务队列填满，其余的将新建非核心线程来进行处理。

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
    return new ScheduledThreadPoolExecutor(corePoolSize);
}

为什么阿里java开发手册要求使用ThreadPoolExecutor 的方式来创建线程池？

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue) {
    this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
         Executors.defaultThreadFactory(), defaultHandler);
}  

  通过定义时指定核心线程数量，最大线程池容量，keepAliveTime以及BlockingQueue的大小来避免资源耗尽的风险。

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

   FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致OOM。

  CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。

ThreadPoolExecutor相关参数详解

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
    if (corePoolSize < 0 ||
        maximumPoolSize <= 0 ||
        maximumPoolSize < corePoolSize ||
        keepAliveTime < 0)
        throw new IllegalArgumentException();
    if (workQueue == null || threadFactory == null || handler == null)
        throw new NullPointerException();
    this.corePoolSize = corePoolSize;
    this.maximumPoolSize = maximumPoolSize;
    this.workQueue = workQueue;
    this.keepAliveTime = unit.toNanos(keepAliveTime);
    this.threadFactory = threadFactory;
    this.handler = handler;
}  

corePoolSize： 核心池的大小，在创建了线程池后，线程池中的线程数为0，当有任务来之后，就会创建一个线程去执行任务，当线程池中的线程数目达到corePoolSize后，就会把到达的任务放到缓存队列当中;

maximumPoolSize： 线程池最大线程数，它表示在线程池中最多能创建多少个线程；这个参数是跟后面的阻塞队列联系紧密的；只有当阻塞队列满了，如果还有任务添加到线程池的话，会尝试new 一个Thread的进行救急处理，立马执行对应的runnable任务；如果继续添加任务到线程池，且线程池中的线程数已经达到了maximumPoolSize，那么线程就会就会执行reject操作（这里后面会提及到）

keepAliveTime： 表示线程没有任务执行时最多保持多久时间会终止；默认情况下，只有当线程池中的线程数大于corePoolSize时，keepAliveTime才会起作用；即当线程池中的线程数大于corePoolSize时，如果一个线程空闲的时间达到keepAliveTime，则会终止，直到线程池中的线程数不超过corePoolSize。但是如果调用了allowCoreThreadTimeOut(boolean)方法并设置了参数为true，在线程池中的线程数不大于corePoolSize时，keepAliveTime参数也会起作用，直到线程池中的阻塞队列大小为0；（这部分通过查看ThreadPoolExecutor的源码分析–getTask()部分）；

unit： 参数keepAliveTime的时间单位，有7种取值，在TimeUnit类中有7种静态属性（时间单位）

workQueue： 一个阻塞队列，用来存储等待执行的任务，这个参数的选择也很重要，会对线程池的运行过程产生重大影响，一般来说，这里的阻塞队列有以下几种选择

ArrayBlockingQueue;

LinkedBlockingQueue;

SynchronousQueue;

ArrayBlockingQueue和PriorityBlockingQueue使用较少，一般使用LinkedBlockingQueue和Synchronous。线程池的排队策略与BlockingQueue有关。

threadFactory： 线程工厂，主要用来创建线程：默认值 DefaultThreadFactory；

handler： 表示当拒绝处理任务时的策略，就是上面提及的reject操作；有以下四种取值：

ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。（默认handle）

ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常。

ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）

ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务

通俗易懂的参数解释

corePoolSize、maximumPoolSize、largestPoolSize

假如有一个工厂，工厂里面有10个工人，每个工人同时只能做一件任务。

因此只要当10个工人中有工人是空闲的，来了任务就分配给空闲的工人做；

当10个工人都有任务在做时，如果还来了任务，就把任务进行排队等待；

如果说新任务数目增长的速度远远大于工人做任务的速度，那么此时工厂主管可能会想补救措施，比如重新招4个临时工人进来；

然后就将任务也分配给这4个临时工人做；

如果说着14个工人做任务的速度还是不够，此时工厂主管可能就要考虑不再接收新的任务或者抛弃前面的一些任务了。

当这14个工人当中有人空闲时，而新任务增长的速度又比较缓慢，工厂主管可能就考虑辞掉4个临时工了，只保持原来的10个工人，毕竟请额外的工人是要花钱的。

这个例子中的corePoolSize就是10，而maximumPoolSize就是14（10+4）。

也就是说corePoolSize就是线程池大小，maximumPoolSize在我看来是线程池的一种补救措施，即任务量突然过大时的一种补救措施。

不过为了方便理解，在本文后面还是将corePoolSize翻译成核心池大小。

largestPoolSize只是一个用来起记录作用的变量，用来记录线程池中曾经有过的最大线程数目，跟线程池的容量没有任何关系。

Lock和synchronized的区别

区别：
  1. 首先synchronized是java内置关键字，在jvm层面，Lock是个java接口；
  2. synchronized无法判断是否获取锁的状态，Lock可以判断是否获取到锁；
  3. synchronized会自动（被动释放锁）释放锁(a 线程执行完同步代码会释放锁 ；b 线程执行过程中发生异常会释放锁)，Lock需在finally中手工（主动释放锁）释放锁（unlock()方法释放锁），否则容易造成线程死锁；
  4. 用synchronized关键字的两个线程1和线程2，如果当前线程1获得锁，线程2线程等待。如果线程1阻塞，线程2则会一直等待下去，而Lock锁就不一定会等待下去，如果尝试获取不到锁，线程可以不用一直等待就结束了；
  5. synchronized的锁可重入、不可中断、非公平，而Lock锁可重入、可判断、可公平（两者皆可）
  6. Lock锁适合大量同步的代码的同步问题，synchronized锁适合代码少量的同步问题。

Lock的实现原理

  Lock完全是由java写成的的接口，具有很多的实现类（都是依赖java.util.concurrent.AbstactQueuedSynchronizer类来实现的）。是基于API层面的，提供更多的方法。

AQS(AbstractQueuedSynchronizer)：
  Lock之所以能实现线程安全的锁，主要的核心是  AQS,AQS提供了一个FIFO队列，可以看做是一个用来实现锁以及其他需要同步功能的框架。AQS的使用依靠继承来完成，子类通过继承自AQS并实现所需的方法来管理同步状态。例如常见的ReentrantLock，CountDownLatch等。

  从使用上来说，AQS的功能可以分为两种：独占和共享。

  独占锁模式下，每次只能有一个线程持有锁，ReentrantLock就是以独占方式实现的互斥锁。

  共享锁模式下，允许多个线程同时获取锁，并发访问共享资源，比如ReentrantReadWriteLock。

AQS的内部实现：
  同步器依赖内部的（CLH）同步队列（一个FIFO双向队列）来完成同步状态的管理，当前线程获取同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点（Node）并将其加入同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点中的线程唤醒，使其再次尝试获取同步状态。

CAS
  在AQS中，除了本身的链表结构以外，还有一个很关键的功能，就是CAS。这个功能可以保证线程在高并发的情况下能安全的加入到AQS队列中。

  在AQS设置首节点和尾节点的方法中，都用到了unsafe.compareAndSwapObject方法。Unsafe类是在sun.misc包下，不属于Java标准，但是很多Java的基础类库，包括一些被广泛使用的高性能开发库都是基于Unsafe类开发的，比如Netty、Hadoop、Kafka等，Unsafe类可认为是Java中留下的后门，提供了一些底层操作，如直接内存访问、线程调度等。ompareAndSwapObject是一个native方法.

ReentrantLock的实现原理

public void lock() {
    sync.lock();
}

这个是获取锁的入口。sync是一个实现了AQS的抽象类，这个类的主要作用是用来实现同步控制的，sync有两个实现，一个是NonfairSync(非公平锁)、另一个是FailSync(公平锁)。

Lock的锁实现（加锁）

  简单来说，AQS会把所有的请求线程构成一个CLH队列，当一个线程执行完毕（lock.unlock()）时会激活自己的后继节点，但正在执行的线程不在队列中，而那些等待执行的线程全部处于阻塞状态，而且线程的显式阻塞是通过调用LockSupport.park()完成的，而LockSupport.park()则调用sun.misc.Unsafe.park()本地方法，再进一步，Hotsport在Linux中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。
  与synchronized相似，CLH队列也是一个虚拟的双向队列，不存在队列实例，仅存在节点间的前后关系。https://wenku.baidu.com/view/41480552f01dc281e53af090.html

为什么要采用双向CLH队列？

  当有线程竞争锁时，该线程会首先尝试获得锁，这对于那些已经在队列中排队的线程来说显得不公平，这也是非公平锁的由来，与synchronized实现类似，这样会极大的提高吞吐量。
  如果已经存在Running线程，则新的竞争线程会被追加到队列尾部，具体是采用基于CAS的Lock-Free算的，因为线程并发对tail代用CAS可能会导致其他线程的CAS操作失败，解决办法是循环CAS直至成功。AQS的实现非常精巧，令人叹为观止。

1. Sync.nonfairTryAcquire：
     该方法将是lock方法间接调用的第一个方法，每次请求锁时都会首先调用该方法。

view plain 
    final boolean nonfairTryAcquire(int acquires) {
         final Thread current = Thread.currentThread();
         int c = getState();
         if (c == 0) {   
            if (compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
         }   
         else if (current == getExclusiveOwnerThread()) {
             int nextc = c + acquires;
             if (nextc < 0) // overflow   
                 throw new Error("Maximum lock count exceeded");
             setState(nextc);
             return true;
         }   
         return false;
    }   

  该方法会首先判断当前状态，如果c0说明没有线程正在竞争该锁，如果不c !=0 说明有线程正拥有了该锁。
  如 果发现c0，则通过CAS设置该状态值为acquires,acquires的初始调用值为1，每次线程重入该锁都会+1，每次unlock都会 -1，但为0时释放锁。如果CAS设置成功，则可以预计其他任何线程调用CAS都不会再成功，也就认为当前线程得到了该锁，也作为Running线程，很 显然这个Running线程并未进入等待队列。
  如果c !=0 但发现自己已经拥有锁，只是简单地++acquires，并修改status值，但因为没有竞争，所以通过setStatus修改，而非CAS，也就是说这段代码实现了偏向锁的功能，并且实现的非常漂亮。

2.AbstractQueuedSynchronizer.addWaiter
  addWaiter方法负责把当前无法获得锁的线程包装为一个Node添加到队尾。

private Node addWaiter(Node mode){
    ......
}  

其中参数mode是独占锁还是共享锁，默认为null，独占锁。追加到队尾的动作分两步： 如果当前队尾已经存在(tail!=null)，则使用CAS把当前线程更新为Tail
如果当前Tail为null或则线程调用CAS设置队尾失败，则通过enq方法继续设置Tail。该方法就是循环调用CAS，即使有高并发的场景，无限循环将会最终成功把当前线程追加到队尾（或设置队头）。总而言之，addWaiter的目的就是通过CAS把当前现在追加到队尾，并返回包装后的Node实例。

3.AbstractQueuedSynchronizer.acquireQueued
  acquireQueued的主要作用是把已经追加到队列的线程节点（addWaiter方法返回值）进行阻塞，但阻塞前又通过tryAccquire重试是否能获得锁，如果重试成功能则无需阻塞，直接返回

Lock的锁实现（解锁）

  请求锁不成功的线程会被挂起在acquireQueued方法的第12行，12行以后的代码必须等线程被解锁锁才能执行，假如被阻塞的线程得到解锁，则执行第13行，即设置interrupted = true，之后又进入无限循环。
  从无限循环的代码可以看出，并不是得到解锁的线程一定能获得锁，必须在第6行中调用tryAccquire重新竞争，因为锁是非公平的，有可能被新加入的线 程获得，从而导致刚被唤醒的线程再次被阻塞，这个细节充分体现了“非公平”的精髓。通过之后将要介绍的解锁机制会看到，第一个被解锁的线程就是Head，因此p == head的判断基本都会成功。
解锁代码相对简单，主要体现在AbstractQueuedSynchronizer.release和Sync.tryRelease方法中：

class AbstractQueuedSynchronizer 
view plain 
public final boolean release(int arg) {
   if (tryRelease(arg)) {
       Node h = head;
       if (h != null && h.waitStatus != 0)
           unparkSuccessor(h);
       return true;
   }   
return false;
}
class Sync view plain 
protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}    

tryRelease与tryAcquire语义相同，把如何释放的逻辑延迟到子类中。tryRelease语义很明确：如果线程多次锁定，则进行多次释放，直至status==0则真正释放锁，所谓释放锁即设置status为0，因为无竞争所以没有使用CAS。

synchronized的原理

synchronized用的锁是存在java对象头里的，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步。

代码块同步

  使用monitorenter和monitorexit指令实现的，monitorenter指令是在编译后插入到同步代码块开始位置，而monitorexit是插入到方法结束后和异常处。任何对象都有一个monitor与之关联，当它的monitor被某个线程持有后，表示该线程处于锁定状态(在java层面表现为markwork记录当前线程的id)。

  根据虚拟机规范和要求：在执行monitorenter指令时，首先要去尝试获取锁，如果这个锁对象没有被占用 ，或者当前线程已经用了那个锁对象，那就把锁的计数器加1；相应的，在执行monitorexit指令时会将锁计数器减1，当计数器被减到0时，锁就释放了。如果获取锁失败了，那当前线程就要阻塞等待，直到锁对象被另一个线程释放。

同步方法

  从反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来完成（理论上其实也可以通过这两条指令来实现），而是被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在JVM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法。不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。

监视器锁monitor

  监视器锁本质是依赖于底层的操作系统的Mutex Lock(互斥锁)来实现的。每个对象都有一个可称为"互斥锁"的标记，这个标记用来保证在任一时刻，只能有一个线程访问该对象。

  互斥锁：用于保护临界区，确保同一时刻只有一个线程访问数据。对共享资源的访问，先对互斥量进行加锁，如果互斥量已经上锁，调用线程会阻塞直到互斥量被解锁。在完成了对共享资源访问后，要对互斥量进行解锁。

Mutex工作方式

(1)申请mutex

(2)如果成功，则持有该mutex

(3)如果失败，则进行自旋，自旋过程就是在线等待mutex，不断发起mutex gets，直到获得mutex或者达到自旋次数限制为止

(4)根据工作模式的不同选择yiled还是sleep

(5)若达到sleep限制或者被主动唤醒或者完成yield，则重复1-4步，直到获得为止

由于java的线程是映射到操作系统的原生线程之上的，如果要阻塞或唤醒一条线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间，所以synchronized是java语言中一个重量级操作。不过在jdk1.6之后引入了大量的优化，如锁粗化、锁消除、轻量级锁、偏向锁、适应性自旋等技术来减少锁操作的开销。

共享变量如何做到安全同步

内存可见性： 同步快的可见性是由“如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值”、“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store和write操作）”这两条规则获得的。

操作原子性： 持有同一个锁的两个同步块只能串行地进入

锁的内存语义：

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须从主内存中读取共享变量

Lock VS Synchronized

  AbstractQueuedSynchronizer通过构造一个基于阻塞的CLH队列容纳所有的阻塞线程，而对该队列的操作均通过Lock-Free（CAS）操作，但对已经获得锁的线程而言，ReentrantLock实现了偏向锁的功能。

  synchronized 的底层也是一个基于CAS操作的等待队列，但JVM实现的更精细，把等待队列分为ContentionList和EntryList，目的是为了降低线程的出列速度；当然也实现了偏向锁，从数据结构来说二者设计没有本质区别。但synchronized还实现了自旋锁，并针对不同的系统和硬件体系进行了优 化，而Lock则完全依靠系统阻塞挂起等待线程。

  当然Lock比synchronized更适合在应用层扩展，可以继承 AbstractQueuedSynchronizer定义各种实现，比如实现读写锁（ReadWriteLock），公平或不公平锁；同时，Lock对 应的Condition也比wait/notify要方便的多、灵活的多。