Java知识体系之线程

Java知识体系

基础知识

实现线程主要有3种方式：
1）使用内核线程实现
2）使用用户线程实现
3）使用用户线程加轻量级进程混合实现

内核线程(Kernel-Level Thread，KLT)

内核线程（Kernel-Level Thread）： 就是直接由操作系统内核（下称内核 Kernel）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。

多线程内核（Multi-Threads Kernel）：每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多个事情，支持多线程的内核就叫多线程内核。

轻量级进程（Light Weight Process，LWP）

程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1:1的关系称为一对一的线程模型。

轻量级进程与内核线程之间1:1的关系：

劣势：

• 由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换。
• 每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的。

用户线程（User Thread，UT）

用户线程（User Thread，UT），广义上，一个线程只要不是内核线程，就是用户线程，轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的，许多操作都要进行系统调用，效率会受到限制。
狭义上，用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。

这种进程与用户线程之间1:N的关系称为一对多的线程模型：

优势：

• 不需要系统内核支援。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。因此操作可以是非常快速且低消耗的，也可以支持规模更大的线程数量。部分高性能数据库中的多线程就是由用户线程实现的。

劣势：

• 也在于没有系统内核的支援。线程的创建、切换和调度，都需要用户程序自己处理，而且处理起来有各种问题，非常难解决。所以，Java、Ruby等语言都曾经使用过用户线程，最终又都放弃使用它。

用户线程加轻量级进程混合实现

在这种混合实现下，即存在用户线程，也存在轻量级进程。在这种混合模式中，用户线程与轻量级进程的数量比是不定的，即为N:M的关系：

优势：

• 用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。
• 轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级进程来完成，大大降低了整个进程被完全阻塞的风险。

java线程的实现

Java线程在JDK1.2之前，是基于称为绿色线程（Green Threads）的用户线程实现的，后来放弃了；而在JDK1.2中，线程模型替换为基于操作系统原生线程模型来实现。因此，在目前的JDK版本中，操作系统支持怎样的线程模型，在很大程度上决定了Java虚拟机的线程是怎样映射的。

对于Sun JDK来说，它的Windows版与Linux版都是使用一对一的线程模型实现的，一条Java线程就映射到一条轻量级进程之中，因为Windows和Linux系统提供的线程模型就是一对一的。

线程状态

在 Java 中，线程的状态和底层操作系统中线程的状态并不是一一对应的关系，我们所能见到的是 JVM 虚拟机层面暴露的状态。

操作系统线程状态

通常，在操作系统这一层面，线程存在五类状态，状态的转换关系如下图：

java线程状态

注意：这里说的线程状态，指的是JVM层面暴露给我们的状态，与操作系统底层的线程状态是两个不同层面的事儿。我们下面说的线程状态都是Thread.State明确定义的。

先上图：

我们来看一下 Thread.State的代码：

public enum State {
    /**
     * Thread state for a thread which has not yet started.
     */
    NEW,
    /**
     * Thread state for a runnable thread.  A thread in the runnable
     * state is executing in the Java virtual machine but it may
     * be waiting for other resources from the operating system
     * such as processor.
     */
    RUNNABLE,
    /**
     * Thread state for a thread blocked waiting for a monitor lock.
     * A thread in the blocked state is waiting for a monitor lock
     * to enter a synchronized block/method or
     * reenter a synchronized block/method after calling
     * {@link Object#wait() Object.wait}.
     */
    BLOCKED,
    /**
     * Thread state for a waiting thread.
     * A thread is in the waiting state due to calling one of the
     * following methods:
     * <ul>
     *   <li>{@link Object#wait() Object.wait} with no timeout</li>
     *   <li>{@link #join() Thread.join} with no timeout</li>
     *   <li>{@link LockSupport#park() LockSupport.park}</li>
     * </ul>
     *
     * <p>A thread in the waiting state is waiting for another thread to
     * perform a particular action.
     *
     * For example, a thread that has called <tt>Object.wait()</tt>
     * on an object is waiting for another thread to call
     * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
     * that object. A thread that has called <tt>Thread.join()</tt>
     * is waiting for a specified thread to terminate.
     */
    WAITING,
    /**
     * Thread state for a waiting thread with a specified waiting time.
     * A thread is in the timed waiting state due to calling one of
     * the following methods with a specified positive waiting time:
     * <ul>
     *   <li>{@link #sleep Thread.sleep}</li>
     *   <li>{@link Object#wait(long) Object.wait} with timeout</li>
     *   <li>{@link #join(long) Thread.join} with timeout</li>
     *   <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
     *   <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
     * </ul>
     */
    TIMED_WAITING,
    /**
     * Thread state for a terminated thread.
     * The thread has completed execution.
     */
    TERMINATED;
}

New

新建状态，新创建了一个线程对象。

Runnable

javadoc中的注释：

A thread in the runnable state is executing in the Java virtual machine but it may be waiting for other resources from the operating system such as processor.
处于 runnable 状态下的线程正在 Java 虚拟机中执行，但它可能正在等待来自于操作系统的其它资源，比如处理器。

实际上， Java 线程状态的Runnable包括了传统的 ready和running状态，并且还包含了一部分的waiting状态。

java中为什么没有区分ready和running呢？

操作系统架构通常都是用所谓的时间分片（time quantum or time slice）方式进行抢占式线程调度（Preemptive Threads-Scheduling）。正常情况下，这个时间分片通常是很小的，一个线程一次最多只能在 cpu 上运行比如10-20ms 的时间（此时处于 running状态），也即大概只有0.01秒这一量级，时间片用后就要被切换下来放入调度队列的末尾等待再次调度（也即回到 ready 状态）。
所以，线程切换得是如此之快，那么区分 ready 与 running 就没什么太大意义了。

为什么Runnable还包含一部分waiting状态？
这里的部分waiting，指的就是I/O阻塞。
先说结论： 当I/O阻塞的时候，操作系统的线程状态处于waiting，但是java线程状态处于Runnable。

再次看一下操作系统的线程状态图：

我们知道传统的I/O都是阻塞式（blocked）的，原因是I/O操作比起cpu来实在是太慢了，可能差到好几个数量级都说不定。如果让 cpu去等I/O 的操作，很可能时间片都用完了，I/O操作还没完成呢，不管怎样，它会导致 cpu 的利用率极低。

所以，解决办法就是：一旦线程中执行到 I/O 有关的代码，相应线程立马被切走，然后调度 ready 队列中另一个线程来运行。

这时执行了 I/O 的线程就不再运行，即所谓的被阻塞了。它也不会被放到调度队列中去，因为很可能再次调度到它时，I/O可能仍没有完成。

线程会被放到所谓的等待队列中，处于上图中的 waiting 状态。

当然了，我们所谓阻塞只是指这段时间 cpu 暂时不会理它了，但另一个部件比如硬盘则在努力地为它服务。cpu与硬盘间是并发的。当在 cpu 上是 waiting 时，在硬盘上却处于 running，只是我们在操作系统层面讨论线程状态时通常是围绕着 cpu这一中心去述说的。

而当 I/O 完成时，则用一种叫中断（interrupt）的机制来通知 cpu。
cpu 会收到一个比如说来自硬盘的中断信号，并进入中断处理流程，手头正在执行的线程因此被打断，回到 ready 队列。而先前因 I/O 而waiting 的线程，随着 I/O 的完成也再次回到 ready 队列，这时 cpu 可能会选择它来执行。

理解Runnable状态

当进行阻塞式的 IO 操作时，或许底层的操作系统线程确实处在阻塞状态，但我们关心的是 JVM 的线程状态。JVM 并不关心底层的实现细节，什么时间分片也好，什么 IO 时就要切换也好，它并不关心。

前面说到：

处于 runnable 状态下的线程正在 Java 虚拟机中执行，但它可能正在等待来自于操作系统的其它资源，比如处理器。

JVM 把哪些都视作资源呢？

cpu 也好，硬盘，网卡也罢，有东西在为线程服务，它就认为线程在“执行”。

处于 IO 阻塞，只是说 cpu 不执行线程了，但网卡可能还在监听呀，虽然可能暂时没有收到数据；或者硬盘可能在执行啊，所以 JVM 认为线程还在执行。

操作系统的线程状态是围绕着 cpu 这一核心去述说的，这与 JVM 的侧重点是有所不同的。

总结：
RUNNABLE 状态对应了传统的 ready， running 以及部分的 waiting 状态。如下图：

Blocked

BLOCKED 跟 I/O 阻塞是不同的，它不是一般意义上的阻塞，而是特指被 synchronized 块阻塞。

首先我们要明白java中对象锁的模型，JVM会为一个使用内部锁（synchronized）的对象维护两个集合，Entry Set和Wait Set，也有人翻译为锁池和等待池，意思基本一致。

对于Entry Set：如果线程A已经持有了对象锁，此时如果有其他线程也想获得该对象锁的话，它只能进入Entry Set，并且处于线程的BLOCKED状态。

对于Wait Set：如果线程A调用了wait()方法，那么线程A会释放该对象的锁，进入到Wait Set，并且处于线程的WAITING状态。

还有需要注意的是，某个线程B想要获得对象锁，一般情况下有两个先决条件，一是对象锁已经被释放了（如曾经持有锁的前任线程A执行完了synchronized代码块或者调用了wait()方法等等），二是线程B已处于RUNNABLE状态。

那么这两类集合中的线程都是在什么条件下可以转变为RUNNABLE呢？

对于Entry Set中的线程，当对象锁被释放的时候，JVM会唤醒处于Entry Set中的某一个线程，这个线程的状态就从BLOCKED转变为RUNNABLE。

对于Wait Set中的线程，当对象的notify()方法被调用时，JVM会唤醒处于Wait Set中的某一个线程，这个线程的状态就从WAITING转变为RUNNABLE；或者当notifyAll()方法被调用时，Wait Set中的全部线程会转变为RUNNABLE状态。所有Wait Set中被唤醒的线程会被转移到Entry Set中。

然后，每当对象的锁被释放后，那些所有处于RUNNABLE状态的线程会共同去竞争获取对象的锁，最终会有一个线程（具体哪一个取决于JVM实现，队列里的第一个？随机的一个？）真正获取到对象的锁，而其他竞争失败的线程继续在Entry Set中等待下一次机会。

作者：A_客
链接：https://www.jianshu.com/p/25e243850bd2
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

对上面的理解：

线程A得到锁之后，线程B和线程C就会进入锁对象的enrty set中去，当线程A wait()之后，进入锁对象的wait set中，然后假设线程B获取了锁，然后调用notifyAll()，这时，线程A会被唤醒进入到锁对象的enrty set中去，线程B退出同步代码块的时候，释放锁，这个时候，会唤醒entry set里面的某一个线程，这个线程就竞争到了锁。

javadoc中的注释：

1、A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method.
2、A thread in the blocked state is waiting for a monitor lock to reenter a synchronized block/method after calling Object.wait.

1、一个处于 blocked 状态的线程正在等待一个监视器锁以进入一个同步的块或方法。
2、一个处于 blocked 状态的线程正在等待一个监视器锁，在其调用 Object.wait 方法之后，以再次进入一个同步的块或方法。

先看第一句：
监视器锁用于同步访问，以达到多线程间的互斥。

所以一旦一个线程获取锁进入同步块，在其出来之前，如果其它线程想进入，就会因为获取不到锁而阻塞在同步块之外，这时的状态就是 BLOCKED。

注意，这一状态的进入及解除都不受我们控制，当锁可用时，线程即从阻塞状态中恢复。

再来看第二句：

一个处于 blocked 状态的线程正在等待一个监视器锁，在其调用 Object.wait 方法之后，以再次进入一个同步的块或方法。

这是一个Reenter的过程：

• 调用 wait 方法必须在同步块中，即是要先获取锁并进入同步块，这是第一次 enter。
• 而调用 wait 之后则会释放该锁，并进入此锁的等待队列（wait set）中。
• 当收到其它线程的 notify 或 notifyAll 通知之后，等待线程并不能立即恢复执行，因为停止的地方是在同步块内，而锁已经释放了，所以它要重新获取锁才能再次进入（reenter）同步块，然后从上次 wait 的地方恢复执行。这是第二次 enter，所以叫 reenter。
• 但锁并不会优先给它，该线程还是要与其它线程去竞争锁，这一过程跟 enter 的过程其实是一样的，因此也可能因为锁已经被其它线程据有而导致 BLOCKED。
  总结：
  
  1. reenter也还是 enter，当因为获取不到锁而无法进入同步块时，线程处于 BLOCKED状态。
  2. 如果有线程长时间处于 BLOCKED 状态，要考虑是否发生了死锁（deadlock）的状况
  3. BLOCKED 状态可以视作为一种特殊的 waiting，是传统 waiting 状态的一个细分：
     

WAITING

javadoc中的注释：

A thread that is waiting indefinitely for another thread to perform a particular action is in this state.
一个正在无限期等待另一个线程执行一个特别的动作的线程处于这一状态。

那么，这个"特别的动作"指的是什么呢？继续看javadoc:

A thread is in the waiting state due to calling one of the following methods:

Object.wait with no timeout
Thread.join with no timeout
LockSupport.park
A thread in the waiting state is waiting for another thread to perform a particular action. For example, a thread that has called Object.wait() on an object is waiting for another thread to call Object.notify() or Object.notifyAll() on that object. A thread that has called Thread.join() is waiting for a specified thread to terminate.

一个线程进入 WAITING 状态是因为调用了以下方法：
1、不带时限的 Object.wait()
2、不带时限的 Thread.join()
3、LockSupport.park()

然后会等其它线程执行一个特别的动作，比如：

1、一个调用了某个对象的 Object.wait()的线程会等待另一个线程调用此对象的 Object.notify() 或 Object.notifyAll()。
2、一个调用了 Thread.join()的线程会等待指定的线程结束。

很显然，WAITING 状态所涉及的不是单独一个线程，相反，它涉及多线程，具体地讲，这是多个线程间的一种协作机制(cooperate)。当然，多个线程间也会有竞争(race)。

首先，为什么要 wait 呢？简单讲，是因为条件(condition)不满足。那么什么是条件呢？为方便理解，我们设想一个场景：

有一节列车车厢，有很多乘客，每个乘客相当于一个线程；里面有个厕所，这是一个公共资源，且一次只允许一个线程进去访问（毕竟没人希望在上厕所期间还与他人共享~）。

竞争(race)

假如有多个乘客想同时上厕所，那么这里首先就会存在竞争的关系。如果将厕所视为一个对象，它有一把锁，想上厕所的乘客线程需要先获取到锁，然后才能进入厕所。

在Java中的同步机制，也即是 synchronized 关键字：

synchronized(expression) {……}

它的机制是这样的：对表达式（expresssion）求值（值的类型须是引用类型（reference type）），获取它所代表的对象，然后尝试获取这个对象的锁：

• 如果能获取锁，则进入同步块执行，执行完后退出同步块，并归还对象的锁（异常退出也会归还）；
• 如果不能获取锁，则阻塞在这里，直到能够获取锁。

说一下这个阻塞，当一个乘客线程还在厕所期间，也就是它已经获取到锁了，其它同时想上厕所的乘客线程就被阻塞了，处在该锁对象的 entry set 中，处于 BLOCKED 状态。

完事之后，退出厕所，归还锁。

之后，系统再在 entry set 中挑选一个乘客线程，将锁给到它。

这个整体流程，如下所示：

条件(condition)

现在，假设有个女乘客线程，她抢到了锁，进去之后裤子脱了一半，发现纸没了，于是拒绝尿。

那么这时，条件出现了：有纸没纸，这就是某种条件。

那么，现在条件不满足，这位女乘客线程该怎么办呢？如果只是在里面干等，显然是不行的：

• 一方面，外面 entry set 中可能好多群众还嗷嗷待尿呢（其中可能有很多男乘客线程，他们才不在乎有没有纸~）
• 另一方面，假定外面同时有乘务员线程，准备进去增加纸，可你在里面霸占着不出来，别人也没法进去，也就没法加纸。

所以，当条件不满足时，需要出来，要把锁还回去，以使得诸如乘务员线程的能进去增加纸张。

等待是必要的吗？

这里所谓“等待”，指的是使线程处于不再活动的状态，即是从调度队列中剔除。说白了就是不调用wait()，进入waiting状态，而是直接归还锁。

如果不等待，只是简单归还锁，也就是说，用一个反复的循环来判断条件是否满足，不满足，就归还锁，因为只是简单的归还了锁，那么还是可以再次回到调度队列，然后还是有机会被选中，继续获取到锁，但是这个时候条件依然还是有可能不满足。

现在让我们考虑一种比较极端的情况：厕所外一大堆的女乘客线程想进去方便，同时还有一个焦急的乘务员线程想进去增加厕纸。

如果线程都不等待，而厕所又是一个公共资源，无法并发访问。调度器每次挑一个线程进去，挑中乘务员线程的几率降低了。

所以，这会干扰正常工作的线程，挤占了资源，反而影响了自身条件的满足。

另外，乘务员线程可能这段时间根本没有启动，此时，不愿等待的女乘客线程不过是徒劳地进进出出，占用了 CPU 资源却没有办成正事。

协作机制(cooperate)

综上，等待还是有必要的，我们需要一种更高效的机制，也即是 wait/notify 的协作机制。

当条件不满足时，应该调用 wait()，这时线程释放锁，并进入所谓的 wait set中，具体的讲，是进入这个厕所对象的 wait set 中：

这时，线程不再活动，不再参与调度，因此不会浪费 CPU 资源，也不会去竞争锁了，这时的线程状态即是 WAITING。

现在的问题是：她们什么时候才能再次活动呢？显然，最佳的时机是当条件满足的时候。

之后，乘务员线程进去增加厕纸，当然，此时，它也不能只是简单加完厕纸就完了，它还要执行一个特别的动作，也即是通知（notify）在这个对象上等待的女乘客线程：

大概就是向她们喊一声：“有纸啦！赶紧去尿吧！”

所谓通知，也即是把女乘客线程从 wait set 中释放出来，重新进入到调度队列（ready queue）中。

• 如果是 notify，则选取所通知对象的 wait set 中的一个线程释放；
• 如果是 notifyAll，则释放所通知对象的 wait set 上的全部线程。

整个过程如下图所示：

对于上述过程，我们也给出以下 gif 动图演示：

注意：哪怕只通知了一个等待的线程，被通知线程也不能立即恢复执行，因为她当初中断的地方是在同步块内，而此刻她已经不持有锁，所以她需要再次尝试去获取锁（很可能面临其它线程的竞争），成功后才能在当初调用 wait()之后的地方恢复执行。（这也即是所谓的 reenter after calling Object.wait，在Blocked中曾详细的讨论了这一过程。）
1、如果能获取锁，线程就从 WAITING 状态变成 RUNNABLE 状态；
2、否则，从 wait set 出来，又进入 entry set，线程就从 WAITING 状态又变成 BLOCKED 状态。

综上，这是一个协作机制，女乘客线程和乘务员线程间存在一个协作关系。显然，这种协作关系的存在，女乘客线程可以避免在条件不满足时的盲目尝试，也为乘务员线程的顺利执行腾出了资源；同时，在条件满足时，又能及时得到通知。协作关系的存在使得彼此都能受益。

join 的场景
从定义中可知，除了 wait/notify 外，调用 join()也会让线程处于 WAITING 状态。

join 的机制中并没有显式的 wait/notify 的调用，但可以视作是一种特殊的，隐式的 wait/notify 机制。

假如有 a，b 两个线程，在 a 线程中执行 b.join()，相当于让 a 去等待 b，此时 a 停止执行，等 b 执行完了，系统内部会隐式地通知 a，使 a 解除等待状态，恢复执行。

换言之，a 等待的条件是 b 执行完毕，b完成后，系统会自动通知 a。

总结：
Thread.State.WAITING 状态与传统的 waiting 状态基本类似：

Timed_waiting

javadoc中的注释：

A thread that is waiting for another thread to perform an action for up to a specified waiting time is in this state.
一个正在限时等待另一个线程执行一个动作的线程处于这一状态。

继续看详细的注释：

Thread state for a waiting thread with a specified waiting time. A thread is in the timed waiting state due to calling one of the following methods with a specified positive waiting time:

• Thread.sleep
• Object.wait with timeout
• Thread.join with timeout
• LockSupport.parkNanos
• LockSupport.parkUntil

带指定的等待时间的等待线程所处的状态。一个线程处于这一状态是因为用一个指定的正的等待时间（为参数）调用了以下方法中的其一：

• Thread.sleep
• 带时限（timeout）的 Object.wait
• 带时限（timeout）的 Thread.join
• LockSupport.parkNanos
• LockSupport.parkUntil

不难看出，TIMED_WAITING 与 WAITING 间的联系还是很紧密的，主要差异在于：

• 时限（timeout）参数
• Thread.sleep()

注意：上面Waiting我们说的没有参数的wait()，等同于wait(0)，wait(0) 它不是等0毫秒，恰恰相反，它的意思是永久的等下去，到天荒地老，除非收到通知。

场景

还是我们上面的例子，现在设想一种情况：

乘务员线程增加了厕纸，正当它准备执行 notify 时，乘务员线程因某种原因被杀死了（持有的锁也随之释放）。这种情况下，条件已经满足了，但等待的线程却没有收到通知，还在傻乎乎地等待。

简而言之，就是存在通知失效的情况。

如果有个乘务员线程，她考虑得比较周全，她不是调用 wait()，而是调用 wait(1000）。

wait(1000）相当于自带倒计时 1000 毫秒的闹钟，换言之，她在同时等待两个通知，并取决于哪个先到：

• 如果在1000毫秒内，她就收到了乘务员线程的通知从而唤醒，闹钟也随之失效；
• 反之，超过1000毫秒，还没收到通知，则闹钟响起，此时她则被闹钟唤醒。

这样，在通知失效的情况下，她还是有机会自我唤醒的，进而完成尿尿动作。

虚假唤醒(spurious wakeup)

我们举个例子来说明：

女乘客线程A和女乘客线程B，来竞争 厕所这个公共资源，而乘务员线程来负责给厕所添加厕纸。

女乘客线程的判断逻辑如下：

synchronization(厕所){
    if(厕所没纸){
        wait();
    }
    doing();
}

接下来，
1、女乘客线程A先获取到锁，然后发现厕所没纸，所以进入到等待队列，处于waiting状态；
2、而女乘客线程B执行的时候，发现乘务员线程已经获取到锁了，所以进入了阻塞线程，处于blocked状态；
3、乘务员线程执行完毕之后，释放锁并且调用notify()唤醒女乘客线程A。
4、我们知道，女乘客线程A虽然被唤醒了，但是她只是退出了waiting状态，还是需要竞争锁，才能进入runnable状态，否则进入blocked状态。
5、假设，女乘客线程A竞争失败，没有获取锁，进入blocked状态。
6、女乘客线程B获取到了锁，而且这个时候，条件也满足，已经有纸了，所以女乘客线程B顺利执行，并且用完了厕纸(爱干净，没办法)，这个时候厕所又没有纸了。
7、女乘客线程A终于获取了锁，可以继续往下执行了，然而，这个时候其实已经没有厕纸了，所以就出现问题了，这就是虚假唤醒(spurious wakeup)。

解决方法很简单，上面的代码修改一下：

synchronization(厕所){
    while(厕所没纸){
        wait();
    }
    doing();
}

把if改成while，这样，每次被唤醒的时候，都需要判断一下条件是否满足，满足就继续执行，不满足就继续等待，避免虚假唤醒(spurious wakeup)的发生。

虚假唤醒(spurious wakeup)的根本原因，在于被唤醒的线程，不会立马进入runnable状态，而是需要去竞争锁，失败了，则会进入blocked状态

Thread.sleep()

sleep()与锁无关。

sleep(time)的时候，线程处于Timed_waiting，在这个time时间内，此线程不处于调度队列中，不会被调度，直到time时间到了，重新进入调度队列中，不过这个时候，线程是否运行，还是得等到被再次调度。

如果sleep()是在同步块里面调用了，和wait()不一样，它并不会释放锁。也就是说，如果线程调用 sleep 时是带了锁，sleep 期间则锁还是这个线程所拥有。

另外，sleep(0) 跟 wait(0) 是不一样的，sleep 不存在无限等待的情况，sleep(0) 相当于几乎不等待。

join(timeout) 的情景与 wait(timeout) 原理类似，这里不再展开叙述。

总结
在说完了 BLOCKED，WAITING 和 TIMED_WAITING 后，我们可以综合来看看它们。
显然，BLOCKED 同样可以视作是一种特殊的，隐式的 wait/nofity 机制。等待的条件就是有锁还是没锁。
当锁可用时，其中的一个线程会被系统隐式通知，并被赋予锁，从而获得在同步块中的执行权。等待锁的线程与系统同步机制形成了一个协作关系。
WAITING 状态属于主动地显式地申请的阻塞，BLOCKED 则属于被动的阻塞。

Terminated

线程 run()执行完毕或者异常退出，则该线程的生命周期终结，不能再次使用。

停止线程

Java多线程初探——正确停止线程

stop()

在1.0版本的jdk中，提供了一个stop方法来停止线程，但是这个方法现在已经被废弃了，因为使用这个方法停止线程，将会使线程戛然而止，我们甚至不知道程序执行到了哪里，资源是否已经释放，会出现一些不可预料的结果。

public class YieldRunnable implements Runnable{ 
    public volatile boolean isRunning = true;       
    @Override   
    public void run() {     
        String name = Thread.currentThread().getName(); 
        System.out.println(name + "开始执行！"); 
        while(isRunning) {          
            for(int i = 1; i < 6; i++) {                
                System.out.println(name + "执行了[" + i + "]次");
                //注意，yield是静态方法             
                Thread.yield();         
            }       
        }               
        System.out.println(name + "执行结束！");
    }
}
public static void main(String[] args) {
    System.out.println("主线程开始执行！");
    YieldRunnable runnable = new YieldRunnable();
    Thread thread = new Thread(runnable, "线程1");
    thread.start();
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    thread.stop();
    System.out.println("主线程执行结束！");
}

执行结果：

线程1执行了[1]次
线程1执行了[2]次
线程1执行了[3]次
线程1执行了[4]次
线程1执行了[5]次
线程1执行了[1]次
主线程执行结束！

在调用了stop方法之后，线程中的循环语句还没有执行结束线程就戛然而止了，甚至连最后执行结束的输出都没有打印出来，我们甚至不知道程序执行到哪里了，所以stop()方法是不推荐使用的。

标记位

还是上一个例子，修改main方法：

public static void main(String[] args) {
    System.out.println("主线程开始执行！");
    YieldRunnable runnable = new YieldRunnable();
    Thread thread = new Thread(runnable, "线程1");
    thread.start();
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    runnable.isRunning = false;
    System.out.println("主线程执行结束！");
}

执行结果：

线程1执行了[4]次
线程1执行了[5]次
线程1执行了[1]次
线程1执行了[2]次
线程1执行了[3]次
线程1执行了[4]次
线程1执行了[5]次
主线程执行结束！
线程1执行结束！

注意：isRunning时volatile的

interrupt()

在Java中还提供了一个方法，interrupt()方法，在jdk文档中这样描述：中断线程，这个方法真的能将线程停止吗？现在用一个实例尝试一下。

public class YieldRunnable implements Runnable{
    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + "开始执行！");
        while(true) {
            for(int i = 1; i < 6; i++) {
                System.out.println(name + "执行了[" + i + "]次");
                //注意，yield是静态方法
                Thread.yield();
            }
            long time = System.currentTimeMillis();
            while(System.currentTimeMillis() - time < 1000) {
                /*
                 * 使用while循环模拟 sleep 方法，这里不要使用sleep，具体原因下面再说
                 */
            }
        }       
    }
}
public static void main(String[] args) {
    System.out.println("主线程开始执行！");
    YieldRunnable runnable = new YieldRunnable();
    Thread thread = new Thread(runnable, "线程1");
    thread.start();
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    thread.interrupt();
    System.out.println("主线程执行结束！");
}

运行之后会发现，虽然执行了interrupt()方法，但是子线程并没有停下来，反而是一直执行下去，由此可以得知，

interrupt()方法单独使用不能停止线程。

我们发现线程有一个状态叫做中断状态，在调用interrupt()之后，线程的中断状态为true，Java提供两种方法获取线程的中断状态：

public static boolean interrupted();
public boolean isInterrupted()

这两个方法的区别：

• interrupted()方法是静态的，同时调用了该方法之后线程的中断状态会清除
• isInterrupted是成员方法，并且不会清空中端状态

public class YieldRunnable implements Runnable{
    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + "开始执行！");
        while(!Thread.currentThread().isInterrupted()) {
            for(int i = 1; i < 6; i++) {
                System.out.println(name + "执行了[" + i + "]次");
                //注意，yield是静态方法
                Thread.yield();
            }
            long time = System.currentTimeMillis();
            while(System.currentTimeMillis() - time < 1000) {
                /*
                * 使用while循环模拟 sleep 方法，这里不要使用sleep，具体原因下面再说
                */
            }
        }
        System.out.println(name + "执行结束！");
    }
}

这样就可以正确停止线程了，要想使线程停止，其实还是判断的线程的中断状态，那么它与标志位的方法有什么区别呢？
在上面的代码中，我们注意到：

while(System.currentTimeMillis() - time < 1000) {
}

这是用来模拟Thread的sleep(long l)方法的，为什么不直接使用sleep方法呢？

当线程调用了interrupt()方法后，如果线程在调用 Object 类的 wait()、wait(long) 或 wait(long, int) 方法，或者该类的 join()、join(long)、join(long,
int)、sleep(long) 或 sleep(long, int) 方法过程中受阻，则其中断状态将被清除，它还将收到一个 InterruptedException。
也就是说线程不仅不会被中断，系统还会抛出一个异常。

我们来试一下：

 public class YieldRunnable implements Runnable{
    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + "开始执行！");
        while(!Thread.currentThread().isInterrupted()) {
            for(int i = 1; i < 6; i++) {
                System.out.println(name + "执行了[" + i + "]次");
                //注意，yield是静态方法
                Thread.yield();
            }
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println(name + "执行结束！");
    }
}

执行结果：

主线程开始执行！
线程1开始执行！
线程1执行了[1]次
线程1执行了[2]次
线程1执行了[3]次
线程1执行了[4]次
线程1执行了[5]次
线程1执行了[1]次java.lang.InterruptedException: sleep interrupted
主线程执行结束！
线程1执行了[2]次
线程1执行了[3]次
……

不仅线程没有结束，在执行sleep()方法的时候还抛出了一个异常。那么对于这种情形下该如何处理才能使线程正确停止呢？
比较通用的终止线程的形式如下：

@Override
public void run() {
    try {
        // 1. isInterrupted()保证，只要中断标记为true就终止线程。
        while (!isInterrupted()) {
            // 执行任务...
        }
    } catch (InterruptedException ie) {  
        // 2. InterruptedException异常保证，当InterruptedException异常产生时，线程被终止。
    }
}

线程池

尽量使用Exector而不是直接用Thread类进行并发编程。

为什么使用线程池？

• 重用存在的线程，减少对象创建、消亡的开销，性能佳。
• 可有效控制最大并发线程数，提高系统资源的使用率，同时避免过多资源竞争，避免堵塞。
• 提供定时执行、定期执行、单线程、并发数控制等功能。

线程池ThreadPoolExecutor

Java里面线程池的顶级接口是 Executor，不过真正的线程池接口是 ExecutorService， ExecutorService 的默认实现是 ThreadPoolExecutor；类 Executors 里面调用的就是 ThreadPoolExecutor。

public interface Executor {
    void execute(Runnable command);
}
public interface ExecutorService extends Executor {
    void shutdown();
    List<Runnable> shutdownNow();
    boolean isShutdown();
    boolean isTerminated();
    <T> Future<T> submit(Callable<T> task);
    <T> Future<T> submit(Runnable task, T result);
    Future<?> submit(Runnable task);
    ...
}

线程池通过ThreadPoolExector类构造，这个构造函数参数比较多：

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

• corePoolSize: 核心线程数目，即使线程池没有任务，核心线程也不会终止，可以理解为常驻线程。ThreadPoolExecutor.allowCoreThreadTimeOut(boolean value) 设置为 true 时，闲置的核心线程会存在超时机制，如果在指定时间没有新任务来时，核心线程也会被终止，而这个时间间隔由keepAliveTime 指定。
• maximumPoolSize: 线程池中允许的最大线程数目，当活动的线程数达到这个值后，后续的新任务将会被阻塞。
• keepAliveTime: 控制线程闲置时的超时时长，超过则终止该线程。一般情况下用于非核心线程，只有在 ThreadPoolExecutor.allowCoreThreadTimeOut(boolean value) 设置为 true时，也作用于核心线程。
• unit: keepAliveTime的时间单位。常用的有：TimeUnit.HOURS(小时)、TimeUnit.MINUTES(分钟)、TimeUnit.SECONDS(秒) 和 TimeUnit.MILLISECONDS(毫秒)等。
• workQueue: 任务执行前保存任务的队列；这个队列仅保存由execute提交的Runnable任务；分有界队列和无界队列。
• threadFactory: 用来构造线程池的工厂；一般都是使用默认的；
• handler: 当线程池由于线程数目和队列限制而导致后续任务阻塞的时候，线程池的处理方式，也就是饱和策略

那么，现在，当一个新任务来到的时候，线程池是如何调度的呢？

• 如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务；
• 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入workQueue队列。
• 如果正在运行的线程数量大于或等于 corePoolSize，并且工作队列workQueue满了，但是总线程数量 小于 maximumPoolSize，那么直接创建一个线程处理被添加的任务。
• 如果工作队列workQueue满了，并且正在运行的线程数量大于或等于 maximumPoolSize，那么就会用最后一个构造参数handler处理；默认的处理方式是直接丢掉任务，然后抛出一个异常。

举例

假设workQueue大小为 4，corePoolSize为2，maximumPoolSize为6，那么当加入15个任务时，线程的调度是什么呢？

我们来分析一下：

• 首先执行任务 1、2，启动核心线程，直接执行。这时，corePoolSize已经满了。
• 执行任务3~6，corePoolSize已经满了，所以放入队列，这时，workQueue也已经满了。
• 执行任务7、8、9、10 ，因为corePoolSize和workQueue都已经满了，所以它们会被马上执行，然后，达到了maximumPoolSize。
• 执行任务 11~15 则会执行默认饱和策略，抛出异常。

最终顺序是：1、2、7、8、9、10、3、4、5、6。

当然这个过程是针对指定大小的ArrayBlockingQueue<Runnable>来说，如果是LinkedBlockingQueue<Runnable>，因为该队列无大小限制，所以不存在上述问题。

总结

当有新的任务要处理时，先看线程池中的线程数量是否大于 corePoolSize，再看缓冲队列 workQueue 是否满，最后看线程池中的线程数量是否大于 maximumPoolSize。另外，当线程池中的线程数量大于 corePoolSize 时，如果里面有线程的空闲时间超过了 keepAliveTime，就将其移除线程池，这样，可以动态地调整线程池中线程的数量。

等待队列

并发编程4：Java 阻塞队列源码分析（上）

咱们上面说的workQueue，对应的就是BlockingQueue接口，JDK为BlockingQueue提供了几种实现方式，常用的有：

• ArrayBlockingQueue
  一个由数组结构组成的有界阻塞队列。此队列按照先进先出（FIFO）的原则对元素进行排序。
• LinkedBlockingQueue
  一个由链表结构组成的有界阻塞队列。此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。可以理解为无界队列。
• PriorityBlockingQueue
  一个支持优先级排序的无界阻塞队列。默认情况下元素采取自然顺序排列，也可以通过比较器comparator来指定元素的排序规则。元素按照升序排列。
• SynchronousQueue
  https://blog.csdn.net/yanyan19880509/article/details/52562039
  一个不存储元素的阻塞队列。每一个put操作必须等待一个take操作，否则不能继续添加元素。
  一个生产线程，当它生产产品（即put的时候），如果当前没有人想要消费产品(即当前没有线程执行take)，此生产线程必须阻塞，等待一个消费线程调用take操作，take操作将会唤醒该生产线程，同时消费线程会获取生产线程的产品（即数据传递），这样的一个过程称为一次配对过程(当然也可以先take后put,原理是一样的)。
• DelayedWorkQueue
  支持延时获取元素的无界阻塞队列。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。只有在延迟期满时才能从队列中提取元素。

饱和策略

我们在上面提过：

handler: 当线程池由于线程数目和队列限制而导致后续任务阻塞的时候，线程池的处理方式，也就是饱和策略

什么时候执行饱和策略？我们在上面也说过：

如果工作队列workQueue满了，并且正在运行的线程数量大于或等于 maximumPoolSize，那么就会用最后一个构造参数handler处理；默认的处理方式是直接丢掉任务，然后抛出一个异常。

而这个handler对应的就是RejectedExecutionHandler接口。JDK为RejectedExecutionHandler提供了几种实现方式，常用的有：

• AbortPolicy
  默认的实现，直接抛出一个RejectedExecutionException异常，让调用者自己处理。
• DiscardPolicy
  直接是空方法，什么也不干。如果队列满了，后续的任务都抛弃掉。
• DiscardOldestPolicy
  将等待队列里最旧的任务踢走，让新任务得以执行。
• CallerRunsPolicy
  既不抛弃新任务，也不抛弃旧任务，而是直接在当前线程运行这个任务。但是，当前线程一般就是主线程，所以尽量少用。

Executors

Executors是系统提供的工具，提供了四种线程池：

1、newFixedThreadPool

创建固定大小的线程池。它只有核心线程，线程池创建后，线程数量将会固定不变，适合需要线程很稳定的场合。

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

• corePoolSize： 传入的线程个数nThreads
• maximumPoolSize：等于corePoolSize，也就是说所有线程都为核心线程。所以就不存在超时，因为最大线程恒等于核心线程。
• keepAliveTime：无用
• workQueue：LinkedBlockingQueue，无界队列，所以不会执行拒绝策略。
• handler：无用

2、newSingleThreadExecutor
创建一个单线程化的线程池，它只会用唯一的核心线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

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

• corePoolSize： 1
• maximumPoolSize：1
• keepAliveTime：无用
• workQueue：LinkedBlockingQueue
• handler：无用

3、newCachedThreadPool
创建一个可缓存线程池。它只有非核心线程。线程池用起来的效果是：如果有空闲线程，会复用线程；如果没有空闲线程，会新建线程；如果线程空闲超过1分钟，将会被回收。主要用在吞吐量不固定的情况下，可以自动调节吞吐量。

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

• corePoolSize： 0
• maximumPoolSize：Integer.MAX_VALUE 相当于无限大
• keepAliveTime：60秒
• workQueue：SynchronousQueue，移交机制，put一个，take一个
• handler：无用

CachedThreadPool为何使用的是SynchronousQueue?
https://github.com/huanzhiyazi/articles/blob/master/%E6%8A%80%E6%9C%AF/Java/Executors.newCachedThreadPool%E5%A6%82%E4%BD%95%E5%81%9A%E5%88%B0%E7%BA%BF%E7%A8%8B%E7%BC%93%E5%AD%98%E7%9A%84/Executors.newCachedThreadPool%E5%A6%82%E4%BD%95%E5%81%9A%E5%88%B0%E7%BA%BF%E7%A8%8B%E7%BC%93%E5%AD%98%E7%9A%84.md
https://blog.csdn.net/qq_41634872/article/details/109393730

不能使用size大于0的arrayblockingqueue的原因在于，只来了一个任务，根据线程池运行原理，那个任务会被放入工作队列，如果后续一直没有任务，那么他就会一
直躺尸。
那size==0呢，这时候每个任务过来，阻塞队列为0已经满了，都会新创建一个线程，线程池失去了节省线程创建与销毁的次数的意义。
而SynchronousQueue不同：
1. 任务1来了，调用SynchronousQueue#offer（往queue里放一个element后立即返回，如果碰巧这个element被另一个thread取走了，offer方法返回true，认为offer成功；否则返回false），这个时候没有线程来poll，所以任务1 put失败，直接新起一个线程1来执行任务1
2. 任务2来了，跟任务1情况一样，继续新起一个线程2执行
3. 这时，任务1执行完毕了，就会去队列里面看是否有需要执行的任务，就执行了SynchronousQueue#poll(keepAliveTime)，此时keepAliveTime为60s，所以会等待60s
4. 任务3来了，如果是在60s之内，那么就会唤醒线程1，并把任务3交给它来执行；如果是在60s之后，那么任务3就继续新起一个线程3执行，而线程1就会被释放掉。

4、newScheduledThreadPool
创建一个定长线程池，支持定时及周期性任务执行。

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
    return new ScheduledThreadPoolExecutor(corePoolSize);
}
public ScheduledThreadPoolExecutor(int corePoolSize) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
          new DelayedWorkQueue());
}

• corePoolSize： corePoolSize
• maximumPoolSize：Integer.MAX_VALUE
• keepAliveTime：无用
• workQueue：DelayedWorkQueue，延时获取元素的无界阻塞队列
• handler：无用

线程池大小

https://www.hellojava.com/a/87734.html

• CPU 密集型
  CPU 密集型是指那种包含大量运算、在持有的 CPU 分配的时间片上一直在执行任务、几乎不需要依赖或等待其他任何东西。 这样的任务，一直占有 CPU 进行执行，才是最好的方式。 设置线程数时，针对单台机器，最好就是有几个 CPU ，就创建几个线程，然后每个线程都在执行这种任务，永不停歇。
• IO 密集型
  我们所接触到的 IO ，大致可以分成两种：磁盘 IO和网络 IO。
  磁盘 IO ，大多都是一些针对磁盘的读写操作，最常见的就是文件的读写，假如你的数据库、 Redis 也是在本地的话，那么这个也属于磁盘 IO。
  网络 IO ，这个应该是大家更加熟悉的，我们会遇到各种网络请求，比如 http 请求、远程数据库读写、远程 Redis 读写等等。
  IO 操作的特点就是需要等待，我们请求一些数据，由对方将数据写入缓冲区，在这段时间中，需要读取数据的线程根本无事可做，因此可以把 CPU 时间片让出去，直到缓冲区写满。

一般来说：

假设机器有N个CPU:
对于计算密集型的任务，应该设置线程数为N+1；
对于IO密集型的任务，应该设置线程数为2N；
对于同时有计算工作和IO工作的任务，应该考虑使用两个线程池，一个处理计算任务，一个处理IO任务，分别对两个线程池按照计算密集型和IO密集型来设置线程数。

N+1和2N是怎么来的？

是个经验值。

经验值吗？那为什么不是N+2或者N+3，而非得是N+1呢？

无语凝噎

那假如在一个请求中，计算操作需要5ms，DB操作需要100ms，对于一台8个CPU的服务器，怎么设置线程数呢？

这是一个计算和IO混合型的任务，可以将其分解为两个线程池来处理。一个线程池处理计算操作，设置N+1=9个线程，一个线程处理IO操作，设置2N=16个线程。

如果一个任务同时包含了一个计算操作和DB操作呢，不能拆分怎么设置？你能讲一下具体的计算过程吗？

首先这个任务整体上是一个IO密集型的任务。在处理一个请求的过程中，总共耗时100+5=105ms，而其中只有5ms是用于计算操作的，CPU利用率为5/(100+5)。使用线程池是为了尽量提高CPU的利用率，减少对CPU资源的浪费，假设以100%的CPU利用率来说，要达到100%的CPU利用率，对于一个CPU就要设置其利用率的倒数个数的线程数，也即1/(5/(100+5))，8个CPU的话就乘以8。那么算下来的话，就是……168，对，这个线程池要设置168个线程数。

如果实际的任务差异较大，不同任务实际的CPU操作耗时和IO操作耗时有所不同，那么怎么设置线程数呢？

那对所有任务的CPU操作耗时和IO操作耗时求个平均值就好了。

那如果现在这个IO操作是DB操作，而DB的QPS上限是1000，这个线程池又该设置为多大呢？

按比例来减少就可以了，按照之前的计算过程，可以计算出来当线程数设置为168的时候，DB操作的QPS为，168*(1000/(100+5))=1600，如果现在DB的QPS最大为1000，那么对应的，最大只能设置168*(1000/1600)=105个线程。

那设置线程池的时候除了考虑这些，还需要考虑哪些内容呢？

除了考虑任务CPU操作耗时、IO操作耗时之外，还需要服务器的内存资源、硬盘资源、网络带宽等等的。

线程清理

工作池中任意一个 worker（工作线程）完成其任务后，会马上向任务队列请求新的任务。在任务队列返回新任务之前，worker 中的闲置线程有一个存活时间——keepAliveTime：

• 只要在 keepAliveTime 时间内返回一个新的任务，则继续在当前线程中执行；
• 否则，可能因为任务队列已空或者其它原因导致返回失败，工作池意识到所有任务可能已经执行结束了，会进行一个尝试清理过程

工作池尝试清理过程如下：

• 首先，如果工作池中的 worker 数超过了 corePoolSize，说明工作池规模需要收缩，并一直缩小到 corePoolSize 为止；
• 接下来，需要决定是否将 剩下的 corePoolSize 个 worker 也进行清理，这取决于另一个参数——allowCoreThreadTimeout：
  
  • 若该参数为 true，表示核心线程也受到 keepAliveTime 的限制，只要超时未取到任务，工作池中可以不用缓存线程，这时候将清除工作池中所有的闲置线程；
  • 否则若该参数为 false，说明没有任务执行的情况下，核心线程是可以无限制等待的。
• 默认情况下为 false，也就是说，ThreadPoolExecutor 在设计的时候，就假定线程池是一个持续运行实体，可以缓存一定数量的核心线程，只要任务到来就可以马上执行，而不用重新生成新的线程，除非手动关闭线程池。

关闭线程池

https://segmentfault.com/a/1190000021302247
https://www.cnblogs.com/liuyishi/p/10508596.html

ExecutorService 接口提供了三个方法用于手动关闭线程池，分别是shutdown(),shutdownNow()和awaitTermination()。我们最经常使用的 ThreadPoolExecutor 正是 ExecutorService 的实现类，自然也实现了这些方法。

线程池的状态

ThreadPoolExecutor 使用 runState (运行状态)这个变量对线程池的生命周期进行控制，线程池关闭过程会有频繁的运行状态转化，所以我们首先需要了解线程池的各种运行状态及其之间的转化关系，runState 一共有以下5种取值:

• RUNNING：接收新的任务并对任务队列里的任务进行处理；
• SHUTDOWN：不再接收新的任务，但是会对任务队列中的任务进行处理；
• STOP：不接收新任务，也不再对任务队列中的任务进行处理，并中断正在处理的任务；
• TIDYING：所有任务都已终止，线程数为0，在转向TIDYING状态的过程中，线程会执行terminated()钩子方法，钩子方法是指在本类中是空方法，而在子类中进行具体实现的方法；
• TERMINATED：terminated()方法执行结束后会进入这一状态，表示线程池已关闭。

void shutdown()

先来看一下源码的注释：

Initiates an orderly shutdown in which previously submitted tasks are executed, but no new tasks will be accepted. Invocation has no additional effect if already shut down. This method does not wait for previously submitted tasks to complete execution. Use {@link #awaitTermination awaitTermination} to do that.
开始有序关闭线程池，与此同时，已提交的任务将继续执行，但不再接收新的任务，如果线程池已关闭，此方法调用不会产生额外影响。此方法不会等待已提交的任务执行完毕，要等待已提交任务执行完毕可以使用 awaitTermination() 方法。

刚开始看这段注释的时候真是百思不得其解，前面说已提交的任务会继续执行，后面又说此方法不会等待已提交的任务执行完毕，这不是自相矛盾吗？
原来后半句说此方法不会等任务执行完毕的意思是这个方法不会阻塞，也就是说任务队列的任务会继续执行，但是其他的线程(例如主线程)可能会抢在这些任务之前执行，而awaitTermination()方法可以实现阻塞并等待任务执行完毕，具体使用方法参考链接中的例子。

• 将线程池运行状态设置为SHUTDOWN
• 中断所有空闲线程
  如果线程还未中断且处于空闲状态，将其中断。那么如何判断处于空闲呢？
  
  • 调用了tryAcquire(int)方法 (继承自AQS)，也就是尝试以独占的方式获取资源，成功则返回true，表示 线程处于空闲状态；失败会返回false，表示线程处于工作状态。
• 尝试将线程池置为TERMINATED状态
  
  • 满足下列条件之一时，尝试将线程池运行状态设置为 TERMINATED：
    
    1. 线程池处于 SHUTDOWN 状态，线程数为0且任务队列为空；
    2. 线程池处于 STOP 状态且线程数为0。
  • 线程池所有条件都已经满足关闭的要求，将线程池状态置为TIDYING
  • 调用terminated()，空方法，子类有具体实现，用于进行关闭线程池的前置操作，
  • 将线程池置为TERMINATED状态

List shutdownNow()

Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution. These tasks are drained (removed) from the task queue upon return from this method. This method does not wait for actively executing tasks to terminate. Use {@link #awaitTermination awaitTermination} to do that. There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. This implementation cancels tasks via {@link Thread#interrupt}, so any task that fails to respond to interrupts may never terminate.
尝试终止所有正在执行的任务，并停止处理等待队列中的的任务，最后将所有未执行的任务列表的形式返回，此方法会将任务队列中的任务移除并以列表形式返回。此方法不会等待正在执行的任务执行完毕，要等待任务执行完毕可以使用awaitTermination()方法。此方法会尽最大努力终止正在执行的任务，除此之外不做其他保证，因为此方法底层实现是通过 Thread 类的interrupt()方法终止任务的，所以interrupt()未能终止的任务可能无法结束。

• 将线程池运行状态置为STOP
• 中断所有线程，包括正在运行的线程
  中断所有的线程，不管线程是否正在运行
• 将未执行的任务移入列表中，并返回
• 尝试将线程池置为TERMINATED状态

它试图终止线程的方法是通过调用Thread.interrupt()方法来实现的，但是大家知道，这种方法的作用有限，如果线程中没有sleep 、wait、Condition、定时锁等应用, interrupt()方法是无法中断当前的线程的。所以，ShutdownNow()并不代表线程池就一定立即就能退出，它也可能必须要等待所有正在执行的任务都执行完成了才能退出。但是大多数时候是能立即退出的。

boolean awaitTermination(long timeOut, TimeUnit unit)

会阻塞当前线程，接收timeout和TimeUnit两个参数，用于设定超时时间及单位。
s

这个方法并不是用来关闭线程池的，而是调用后等待timeout时间后，反馈线程池的状态，有三种情况：

• 等待期间（包括进入等待状态之前）线程池已关闭并且所有已提交的任务（包括正在执行的和队列中等待的）都执行完毕，相当于线程池已经“终结”了，方法便会返回 true；
• 等待超时时间到后，第一种线程池“终结”的情况始终未发生，方法返回 false；
• 等待期间线程被中断，方法会抛出 InterruptedException 异常。

awaitTermination会等待一段时间并查看线程池是否已经关闭了，若关闭则返回true，否则返回false。一般情况下会和shutdown方法组合使用。

优雅的关闭线程池

service.shutdown();
try {     
    // 注意会阻塞当前线程，所以最好关闭线程池在子线程里面调用
    if(!service.awaitTermination(2, TimeUnit.SECONDS)) {
        service.shutdownNow();
    }
} catch (InterruptedException e) {
    service.shutdownNow();
}

或者，增加对等待队列中任务处理

//第一步，调用shutdown等待在执行的任务和提交等待的任务执行，同时不允许提交任务
service.shutdown();
try {
   if(!service.awaitTermination(2, TimeUnit.SECONDS)){
       //如果等待一段时间后还有任务在执行中被中断或者有任务提交了未执行
       //1.正在执行被中断的任务需要编写任务代码的时候响应中断
       List<Runnable> waitToExecuteTaskList = service.shutdownNow();
       //2.处理提交了未执行的任务，一般情况不会出现
       for(Runnable runnable:waitToExecuteTaskList){
           //todo
       }
   }
}catch (InterruptedException e){//如果被中断了
   //1.正在执行被中断的任务需要编写任务代码的时候响应中断
   List<Runnable> waitToExecuteTaskList = service.shutdownNow();
   //2.处理提交了未执行的任务，一般情况不会出现
   for(Runnable runnable:waitToExecuteTaskList){
       //todo
   }
}

小结

shutdown() 和 shutdownNow()的区别：

• shutdown正在运行的任务和队列中等待的任务，都会直行完；shutdownNow()尝试停止正在运行的任务，忽略队列中等待的任务

自己实现线程池

Android程序员会遇到的算法(part 4 消息队列的应用)
如何实现一个线程池

public class ThreadPool{
    //用一个Set或者其他数据结构把创建的线程保存起来，为的是方便以后获取线程的handle，做其他操作。
    Set<WorkerThread> set = null;
    private Queue<Runnable> queue;
    //初始化线程池，创建内部类WorkerThread并且启动它
    public ThreadPool(int size){
        for( int i = 0 ;i < size ;i++ ){
            WorkerThread t = new WorkerThread();
            t.start();
            set.add( t );
        }
        queue = new LinkedList<Runnable>();
    }
    //submit一个runnable进线程池
    public void submit(Runnable runnable){
        synchronized (queue){
            queue.add(runnable);
        }
    }
    //WorkerThread用一个死循环不停的去向Runnable队列拿Runnable执行。
    public class  WorkerThread extends Thread{
        @Override
        public void run() {
            super.run();
            while(true){
                synchronized (queue){
                        if( !queue.isEmpty() ){
                    Runnable current = queue.poll();
                    current.run();
                      }
                }
            }
        }
    }
}
ThreadPool pool = new ThreadPool(5);
pool.submit(new Runnable(...))

ThreadLocal

ThreadLocal-面试必问深度解析

从上面的结构图，我们已经窥见ThreadLocal的核心机制：

• 每个Thread线程内部都有一个Map。
• Map里面，key是ThreadLocal对象，value是ThreadLocal的value，这个value每一个线程都不一样

使用例子

public class Test {
    ThreadLocal<String> stringLocal = new ThreadLocal<String>();
    public void set(String str) {
        stringLocal.set(str);
    }
    public String getString() {
        return stringLocal.get();
    }
    public static void main(String[] args) throws InterruptedException {
        final Test test = new Test();
        test.set("11111");
        System.out.println("父线程 main ：");
        System.out.println(test.getString());
        Thread thread1 = new Thread() {
            public void run() {
                test.set("22222");
                System.out.println("\n子线程 Thread-0 ：");
                System.out.println(test.getString());
            };
        };
        thread1.start();
    }
}
/* Output: 
        父线程 main ：
                    11111
        子线程 Thread-0 ：
                    22222
 *///:~

同一个ThreadLocal对象，但是在两个线程里面存储的值是不一样的。

源码

get()

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null)
            return (T)e.value;
    }
    return setInitialValue();
}
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}
private T setInitialValue() {
    T value = initialValue();
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
    return value;
}
protected T initialValue() {
    return null;
}

• 获取当前线程的ThreadLocalMap对象
• 以当前ThreadLocal对象为key，从map中获取Entry对象。
• 从Entry节点获取存储的Value副本值返回。

set()

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

• 获取当前线程的ThreadLocalMap对象
• 把ThreadLocal对象和Value值存储到ThreadLocalMap中去

remove()

public void remove() {
 ThreadLocalMap m = getMap(Thread.currentThread());
 if (m != null)
     m.remove(this);
}
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

ThreadLocalMap

ThreadLocalMap是ThreadLocal的内部类，没有实现Map接口，用独立的方式实现了Map的功能，其内部的Entry也独立实现。

在ThreadLocalMap中，也是用Entry来保存K-V结构数据的。但是Entry中key只能是ThreadLocal对象

static class Entry extends WeakReference<ThreadLocal> {
    /** The value associated with this ThreadLocal. */
    Object value;
    Entry(ThreadLocal k, Object v) {
        super(k);
        value = v;
    }
}

Entry继承自WeakReference（弱引用，生命周期只能存活到下次GC前），但只有Key是弱引用类型的，Value并非弱引用。

Hash冲突怎么解决

ThreadLocalMap解决Hash冲突的方式就是简单的步长加1或减1，寻找下一个相邻的位置。

private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

显然ThreadLocalMap采用线性探测的方式解决Hash冲突的效率很低，如果有大量不同的ThreadLocal对象放入map中时发送冲突，或者发生二次冲突，则效率很低。

ThreadLocal内存泄露

ThreadLocal内存泄漏真因探究

ThreadLocal的原理：每个Thread内部维护着一个ThreadLocalMap，它是一个Map。这个映射表的Key是一个弱引用，其实就是ThreadLocal本身，Value是真正存的线程变量Object。注意上图的虚线，它代表一个弱引用类型，而弱引用的生命周期只能存活到下次GC前。

内存泄露是怎么发生的呢？

ThreadLocal在ThreadLocalMap中是以一个弱引用身份被Entry中的Key引用的，因此如果ThreadLocal没有外部强引用来引用它，那么ThreadLocal会在下次JVM垃圾收集时被回收。
这个时候就会出现Entry中Key已经被回收，出现一个null Key的情况，外部读取ThreadLocalMap中的元素是无法通过null Key来找到Value的。
因此如果当前线程的生命周期很长，一直存在，那么其内部的ThreadLocalMap对象也一直生存下来，这些null key就存在一条强引用链的关系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，这条强引用链会导致Entry不会回收，Value也不会回收，但Entry中的Key却已经被回收的情况，造成内存泄漏。

JVM团队已经考虑到这样的情况，并做了一些措施来保证ThreadLocal尽量不会内存泄漏：

在ThreadLocal的get()、set()、remove()方法调用的时候会清除掉线程ThreadLocalMap中所有Entry中Key为null的Value，并将整个Entry设置为null，利于下次内存回收。

我们以get()方法为例来说明：

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null)
            return (T)e.value;
    }
    return setInitialValue();
}

在调用map.getEntry(this)时，内部会判断key是否为null

private Entry getEntry(ThreadLocal key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    if (e != null && e.get() == key)
        return e;
    else
        return getEntryAfterMiss(key, i, e);
}

private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) {
    Entry[] tab = table;
    int len = tab.length;
    while (e != null) {
        ThreadLocal k = e.get();
        if (k == key)
            return e;
        if (k == null)
            expungeStaleEntry(i);
        else
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

注意k == null这里，继续调用了expungeStaleEntry(i)方法，expunge的意思是擦除，删除的意思，见名知意，在来看expungeStaleEntry方法的内部实现：

private int expungeStaleEntry(int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;
    // expunge entry at staleSlot（意思是，删除value，设置为null便于下次回收）
    tab[staleSlot].value = null;
    tab[staleSlot] = null;
    size--;
    // Rehash until we encounter null
    Entry e;
    int i;
    for (i = nextIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = nextIndex(i, len)) {
        ThreadLocal k = e.get();
        if (k == null) {
            e.value = null;
            tab[i] = null;
            size--;
        } else {
            int h = k.threadLocalHashCode & (len - 1);
            if (h != i) {
                tab[i] = null;
                // Unlike Knuth 6.4 Algorithm R, we must scan until
                // null because multiple entries could have been stale.
                while (tab[h] != null)
                    h = nextIndex(h, len);
                tab[h] = e;
            }
        }
    }
    return i;
}

将当前Entry删除后，会继续循环往下检查是否有key为null的节点，如果有则一并删除，防止内存泄漏。

但这样也并不能保证ThreadLocal不会发生内存泄漏:

分配使用了ThreadLocal，又不再调用get()、set()、remove()方法，那么就会导致内存泄漏。

从表面上看，发生内存泄漏，是因为Key使用了弱引用类型。我们来对比一下使用和不使用弱引用的情况：

• key 使用强引用：引用的ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。
• key 使用弱引用：引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。

比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏。
但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。

因此，ThreadLocal内存泄漏的根源是：

ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key的value就会导致内存泄漏，而不是因为弱引用。
所以，每次使用完ThreadLocal，都调用它的remove()方法，清除数据。

AsyncTask

AsyncTask不过是封装了线程池和Handler，用线程池来处理后台任务，用Handler来处理与UI的交互。

AsyncTask中的线程池

AsyncTask里面有两个线程池；一个THREAD_POOL_EXECUTOR，一个SERIAL_EXECUTOR。而SERIAL_EXECUTOR也使用THREAD_POOL_EXECUTOR实现的，只不过加了一个队列弄成了串行而已，那么这个THREAD_POOL_EXECUTOR是如何构造的呢？

private static final int CORE_POOL_SIZE = CPU_COUNT + 1;
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1;
private static final int KEEP_ALIVE = 1;
private static final BlockingQueue<Runnable> sPoolWorkQueue =
            new LinkedBlockingQueue<Runnable>(128);
public static final Executor THREAD_POOL_EXECUTOR
            = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
                    TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

可以看到，AsyncTask里面线程池是：

• 核心线程数为CPU + 1
• 最大线程数为CPU * 2 + 1
• 超时时间为1秒，核心线程没有设置超时机制
• 等待队列是长度为128的有界队列
• 没有传递handler参数，那么使用的就是默认的饱和策略，抛出异常，拒绝执行。

那么，就会有以下问题：

• 如果任务过多，那么超过了工作队列以及线程数目的限制导致这个线程池发生阻塞，那么悲剧发生，默认的处理方式会直接抛出一个异常导致进程挂掉。假设你自己写一个异步图片加载的框架，然后用AsyncTask实现的话，当你快速滑动ListView的时候很容易发生这种异常；这也是为什么各大ImageLoader都是自己写线程池和Handlder的原因。
• 在不同的AsyncTask的doInBackgroud里面访问了共享资源，那么就会发生各种并发编程问题。
• 在AsyncTask全部执行完毕之后，进程中还是会常驻corePoolSize个线程；在Android 4.4 （API 19）以下，这个corePoolSize是hardcode的，数值是5，而API 19改成了cpu + 1；也就是说，在Android 4.4以前；如果你执行了超过5个AsyncTask；然后啥也不干了，进程中还是会有5个AsyncTask线程。

AsyncTask中的Handler

private static InternalHandler sHandler;
private static Handler getHandler() {
    synchronized (AsyncTask.class) {
        if (sHandler == null) {
            sHandler = new InternalHandler();
        }
        return sHandler;
    }
}
private static class InternalHandler extends Handler {
    public InternalHandler() {
        super(Looper.getMainLooper());
    }
}

可以看出来，AsyncTask中的Handler用法很简单。
这里面也是有问题的：

• API 22以上，直接用的主线程的Looper，但是，API 22以下的代码，会发现它没有这个构造函数，而是使用默认的。默认情况下，Handler会使用当前线程的Looper，如果你的AsyncTask是在子线程创建的，那么很不幸，你的onPreExecute和onPostExecute并非在UI线程执行，而是被Handler post到创建它的那个线程执行；如果你在这个子线程更新了UI，那么直接导致崩溃。这也是大家口口相传的AsyncTask必须在主线程创建的原因。
• 事实上，在Android 4.1(API 16)以后，在APP主线程ActivityThread的main函数里面，直接调用了AscynTask.init函数确保这个类是在主线程初始化的；另外，init这个函数里面获取了InternalHandler的Looper，由于是在主线程执行的，因此，AsyncTask的Handler用的也是主线程的Looper。这个问题从而得到彻底的解决。

AsyncTask并行还是串行

在Android 1.6之前，AsyncTask是串行执行任务；Android 1.6的时候AsyncTask开始采用线程池来处理并发任务；但是，Android 3.0开始，为了避免AsyncTask所带来的并发错误，AsyncTask有采用了一个线程串行执行任务。当然，我们可以通过AsyncTask的executeOnExecutor()来并发执行任务。

所以，Android 3.0以上，AsyncTask默认并不是并行执行的；

为什么不并行？

由于一个进程内所有的AsyncTask都是使用的同一个线程池执行任务；如果同时有几个AsyncTask一起并行执行的话，恰好AysncTask的使用者在doInbackgroud里面访问了相同的资源，但是自己没有处理同步问题；那么就有可能导致灾难性的后果！

当然，我们可以通过AsyncTask的executeOnExecutor()来并发执行任务。但是，这个方法是Android 3.0之后才有的。

总结

• 默认的AsyncTask如果处理的任务过多，会导致程序直接崩溃；
• AsyncTask类必须在主线程初始化，必须在主线程创建，不然在API 16以下很大概率崩溃。
• 如果你曾经使用过AsyncTask，以后不用了；在Android 4.4以下，进程内也默认有5个AsyncTask线程；在Android 4.4以上，默认有CPU + 1个线程。
• Android 3.0以上的AsyncTask默认是串行执行任务的；如果要并行执行需要调用低版本没有的API，处理麻烦。

HandlerThread

HandlerThread封装了Looper，和UI线程类似，是一个具有消息循环的线程。

HandlerThread继承了Thread，它是一种可以使用Handler的Thread。它的实现也很简单，就是在run()的时候，通过Looper.prepare()来创建消息队列，然后通过Looper.loop()来开启消息循环，代码如下所示：

@Override
public void run() {
    mTid = Process.myTid();
    Looper.prepare();
    synchronized (this) {
        mLooper = Looper.myLooper();
        notifyAll();
    }
    Process.setThreadPriority(mPriority);
    onLooperPrepared();
    Looper.loop();
    mTid = -1;
}

基本用法

private Handler mHandlerMain = new Handler();
private Handler mHandler;
private HandlerThread mThread;
mThread = new HandlerThread();
mThread.start();
mHandler = new Handler(mThread.getLooper());
mHandler.post(new Runnable(){
    doSomething();//耗时操作
    mHandlerMain.sendMessage();
});

总结

• HandlerThread可以实现，多个任务串行的需求。比如说，我有两个任务，A和B，A依赖于B，A需要在B执行完之后执行，而且A和B都是耗时操作，这个时候就可以使用HandlerThread。
• HandlerThread的run()是死循环，所以不再需要它的时候，应该调用quit()或quitSafely()来终止线程的执行。

IntentService

IntentService是一个Service，内部采用了HandlerThread来执行任务，当任务执行完毕的时候，IntentService会自动退出。它的作用很像一个后台线程，但是它是一个Service，所以不容易被系统杀死，从而可以尽量保证任务的执行。

基本用法

IntentService是一个抽象类，需要实现它的抽象方法onHandleIntent():

public class MyIntentService extends IntentService{
    public MyIntentService(){
        super("MyIntentService")
    }
    protected void onHandleIntent(Intent intent){
        int tTypeAction = intent.getIntExtra("action_type");
        switch(tTypeAction){
            case 1:
                //doTask1();
                Log.d(TAG, "action1");
                break;
            case 2:
                //doTask2();
                Log.d(TAG, "action2");
                break;   
            case 3:
                //doTask3();
                Log.d(TAG, "action3");
                break;
            default:
                Log.d(TAG, "action default");
                break;    
        }
    }
    public void onDestory(){
        Log.d(TAG, "onDestory");
        super.onDestory();
    }
}

处理任务的IntentService简单实现了，接下来，我们需要发起任务：

Intent tIntent = new Intent(this, MyIntentService.class);
tIntent.putExtra("action_type", 2);
startService(tIntent);
tIntent = new Intent(this, MyIntentService.class);
tIntent.putExtra("action_type", 1);
startService(tIntent);
tIntent = new Intent(this, MyIntentService.class);
tIntent.putExtra("action_type", 3);
startService(tIntent);

运行程序，打印日志如下：

action2
action1
action3
onDestory

由此可见，这三个任务是串行的，action3执行完毕之后，IntentService就停止了。

源码分析

IntentService是一个Service，所以在调用startService()的时候，会首先执行onCreate()，如下所示：

@Override
public void onCreate() {
    super.onCreate();
    HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
    thread.start();
    mServiceLooper = thread.getLooper();
    mServiceHandler = new ServiceHandler(mServiceLooper);
}

可以看出来，基本上面HandlerThread 基本用法说的一样。
创建了一个HandlerThread，然后用他的looper生成一个Handler，这样通过mServiceHandler发送的消息，就会在HandlerThread里面执行了。

然后，和Service一样，onCreate()仅仅执行一次，接下来执行onStartCommand()，可以被调用很多次。每一次调用，都会通过mServiceHandler发送一个消息：

Override
public int onStartCommand(Intent intent, int flags, int startId) {
    onStart(intent, startId);
    return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
}
@Override
public void onStart(Intent intent, int startId) {
    Message msg = mServiceHandler.obtainMessage();
    msg.arg1 = startId;
    msg.obj = intent;
    mServiceHandler.sendMessage(msg);
}    

那么，我们来看一下ServiceHandler是如何处理这些任务的？

private final class ServiceHandler extends Handler {
    public ServiceHandler(Looper looper) {
        super(looper);
    }
    @Override
    public void handleMessage(Message msg) {
        onHandleIntent((Intent)msg.obj);
        stopSelf(msg.arg1);
    }
}

直接调用了抽象方法onHandleIntent()，这个是需要我们自己实现的，毕竟如何处理任务，只有我们自己知道。
onHandleIntent()执行完毕后，IntentService都会调用stopSelf(int startId)，来尝试终止服务。startId类似于一个唯一标识，每发送一次，都会生成一个，因为任务都是串行的，所以只有getLastStartId == startId，才认为任务全部执行完成了，才会去终止这个服务。
而stopSelf()会立马终止服务，不管有没有未完成的任务。

总结

• IntentService内部是用HandlerThread来实现的，所以当执行多个任务时，是串行的。
• IntentService本身就是Service，所以优先级比单纯的线程要高，不容易被系统杀死，适合执行一些优先级高的后台任务。
• IntentService任务执行完之后，会自己终止服务。
• 不需要自己去new Thread，并且不需要考虑什么时候关闭Service

内存模型

java的多线程并发问题最终都会反映在java的内存模型上，所谓线程安全无非是要控制多个线程对某个资源的有序访问或修改。

什么是Java内存模型？

Java内存模型(JMM)，Java虚拟机的规范，用来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各个平台下都能达到一致的并发效果。

Java内存模型的目标？

JMM定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出这样的底层细节。此处的变量包括实例字段、静态字段和构成数组对象的元素，但是不包括局部变量和方法参数，因为这些是线程私有的，不会被共享，所以不存在竞争问题。

主内存与工作内存

注意：线程的工作内存是cpu寄存器和高速缓存的抽象描述，并不是java内存模型里面的虚拟机栈

• 所有的变量都存储在主内存中(虚拟机内存的一部分)。
• 每条线程都由自己的工作内存，线程的工作内存中保存了该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。
• 线程之间无法直接访问对方的工作内存中的变量，线程间变量的传递均需要通过主内存来完成。

JMM规定了jvm有主内存(Main Memory)和工作内存(Working Memory) ，主内存存放程序中所有的类实例、静态数据等变量，是多个线程共享的，而工作内存存放的是该线程从主内存中拷贝过来的变量以及访问方法所取得的局部变量，是每个线程私有的其他线程不能访问，每个线程对变量的操作都是以先从主内存将其拷贝到工作内存再对其进行操作的方式进行，多个线程之间不能直接互相传递数据通信，只能通过共享变量来进行。。

内存间的交互操作

一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存，JMM定义了8种操作：

这8中操作都是原子的/不可再分的，JMM还规定了执行上述 8 种基本操作时必须满足如下规则：：
1. 不允许read和load、store和write操作之一单独出现。
2. 不允许一个线程丢弃最近的assign操作，变量在工作内存中改变了之后必须把该变化同步回主内存中。
3. 不允许一个线程没有发生过任何assign操作把数据从线程的工作内存同步回主内存中。
4. 一个新的变量只能在主内存中诞生。
5. 一个变量在同一时刻只允许一条线程对其进行lock操作，但可以被同一条线程重复执行多次。
6. 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行read、load操作。
7. 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作。
8. 对一个变量执行unlock操作前，必须先把该变量同步回主内存中。

线程要引用某变量，如果线程工作内存中没有该个变量，通过read-load从主内存中拷贝一个副本到工作内存中，完成后线程会引用该副本，当同一个线程再次引用该变量时，有可能重新从主存中获取变量副本(read-load-use)，也有可能直接引用原来的副本(use)，也就是说read、load、use顺序可以由jvm实现系统决定。
线程要写入某变量，它会将值指定给工作内存中的变量副本(assign)，完成后这个变量副本会同步到主存(store-write)，至于何时同步过去，即assign,store,write顺序由jvm实现系统决定。

并发编程

现在的计算机，cpu在计算的时候，并不总是从内存读取数据，它的数据读取顺序优先级 是：寄存器－高速缓存－内存。线程耗费的是CPU，线程计算的时候，原始的数据来自内存，在计算过程中，有些数据可能被频繁读取，这些数据被存储在寄存器 和高速缓存中，当线程计算完后，这些缓存的数据在适当的时候应该写回内存。当个多个线程同时读写某个内存数据时，就会产生多线程并发问题

在并发编程中，我们通常会遇到以下三个问题：原子性问题，可见性问题，有序性问题。我们先看具体看一下这三个概念：

原子性

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

一个很经典的例子就是银行账户转账问题：
比如从账户A向账户B转1000元，那么必然包括2个操作：从账户A减去1000元，往账户B加上1000元。
必须要保证这两个步骤是原子操作的。

在Java中，对基本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。

x = 10;         //语句1
y = x;         //语句2
x++;           //语句3
x = x + 1;     //语句4

上面四条语句哪些是原子操作，哪些不是呢？
这四条语句只有语句1的操作具备原子性。

1、语句1是直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中。
2、语句2实际上包含2个操作，它先要去读取x的值，再将x的值写入工作内存，虽然读取x的值以及 将x的值写入工作内存 这2个操作都是原子性操作，但是合起来就不是原子性操作了。
3、x++和 x = x+1包括3个操作：读取x的值，进行加1操作，写入新的值。

也就是说：

只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。
Java内存模型只保证了基本读取和赋值是原子性操作，如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

可见性

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

举个简单的例子，看下面这段代码：

//共享变量
int i = 0;
//线程1执行的代码
i = 10;
//线程2执行的代码
j = i;

效果一：

• 线程1从主存中读取i的副本到工作内存，此时工作内存中副本i1 = 0
• 线程2从主存中读取i的副本到工作内存，此时工作内存中副本i2 = 0
• 线程1将工作内存中i1赋值为10，这时工作内存中i1=10
• 线程1将i1提交到主存，这时主存中i=10
• 线程2执行 j = i，其实，就是j = i2，所以j=0

或者，效果二：

• 线程1从主存中读取i的副本到工作内存，此时工作内存中副本i1 = 0
• 线程1将工作内存中i1赋值为10，这时工作内存中i1=10
• 线程2从主存中读取i的副本到工作内存，此时工作内存中副本i2 = 0
• 线程2执行 j = i，其实，就是j = i2，所以j=0
• 线程1将i1提交到主存，这时主存中i=10

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取之前从主内存刷新变量值来实现可见性的。但是，无法保证什么时候来同步。

普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。
而volatile的特殊规则保证了新值能够立即同步到主内存，每次使用前立即从主内存刷新。

synchronized和final也能实现可见性。final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把this的引用传递出去，那么其他线程中就能看见final字段的值。

有序性

程序执行的顺序按照代码的先后顺序执行

int i = 0;              
boolean flag = false;
i = 1;                //语句1  
flag = true;          //语句2

语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）。

一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

比如上面的代码中，语句1和语句2谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句2先执行而语句1后执行。

但是要注意，虽然处理器会对指令进行重排序，但是它会保证程序最终结果会和代码顺序执行结果相同，在来看一个例子：

int a = 10;    //语句1
int r = 2;    //语句2
a = a + 3;    //语句3
r = a*a;     //语句4

可能的顺序是：2-1-3-4

那么，有没有可能是2-1-4-3呢？
不可能，因为处理器在进行重排序时是会考虑指令之间的数据依赖性，如果一个指令Instruction 2必须用到Instruction 1的结果，那么处理器会保证Instruction 1会在Instruction 2之前执行。

虽然重排序不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：

//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
//线程2:
while(!inited ){
  sleep()
}
doSomething(context);

上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomething(context)方法，而此时context并没有被初始化，就会导致程序出错。

从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。

Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则(先行发生原则)。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。

• 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
• 锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作
• volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
• 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
• 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作
• 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生。
• 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
• 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

程序次序规则

是一段程序代码的执行在单个线程中看起来是有序的。注意，虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”，这个应该是程序看起来执行的顺序是按照代码顺序执行的，因为虚拟机可能会对程序代码进行指令重排序。虽然进行重排序，但是最终执行的结果是与程序顺序执行的结果一致的，它只会对不存在数据依赖性的指令进行重排序。因此，在单个线程中，程序执行看起来是有序执行的，这一点要注意理解。事实上，这个规则是用来保证程序在单线程中执行结果的正确性，但无法保证程序在多线程中执行的正确性。

锁定规则

无论在单线程中还是多线程中，同一个锁如果出于被锁定的状态，那么必须先对锁进行了释放操作，后面才能继续进行lock操作。

volatile变量规则

如果一个线程先去写一个变量，然后一个线程去进行读取，那么写入操作肯定会先行发生于读操作。

private volatile boolean flag;
public void setFlag(boolean flag) {
  this.flag = flag;
}
public void getFlag() {
  return flag;
}

假设线程A来调用setFlag(true)，线程B同时来调用getFlag，对于一般的变量，是无法保证B能读到A设置的值的，因为它们执行的顺序是未知的。但是像上面，加上volatile修饰以后，虚拟机会保证，线程A的写操作在线程B的读操作之前完成，换句话，B能读到最新的值。当然了，用锁机制也能达到同样的效果，比如在方法前面都加上synchronized关键字，但是性能会远不如使用volatile。

synchronized

一个线程执行临界区代码过程如下：

1 获得同步锁
2 清空工作内存
3 从主存拷贝变量副本到工作内存
4 对这些变量计算
5 将变量从工作内存写回到主存
6 释放锁

synchronized是一个独占锁、非公平锁、可重入锁、悲观锁。

• 独占锁是指，该锁只能被一个线程获得（持有），其他线程想要获得本锁，必须要等锁的持有者释放该锁后。
• 可重入锁，当一个线程请求得到一个对象锁后，再次请求此对象锁,可以再次得到该对象锁。
• 独占锁既是悲观锁，假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
• 不可中断锁，可中断锁就是可以响应中断的锁。

重点说下非公平锁

公平锁和非公平锁

参考：公平锁和非公平锁

• 公平锁表示线程获取锁的顺序是按照线程加锁的顺序来分配的，即FIFO的顺序。
• 非公平锁则是一种获取锁的抢占机制，是随机获得锁的，先来的不一定先得到锁，这个方式可能造成某些线程一直得不到锁。

• 公平锁就是在获取锁之前会先判断等待队列是否为空或者自己是否位于队列头部，该条件通过才能继续获取锁。
• 若在释放锁的时候总是没有新的兔子来打扰，则非公平锁等于公平锁；
• 若释放锁的时候，正好一个兔子来喝水，而此时位于队列头的兔子还没有被唤醒（因为线程上下文切换是需要不少开销的），此时后来的兔子则优先获得锁，成功打破公平，成为非公平锁；
• 对于非公平锁，只要线程进入了等待队列，队列里面依然是FIFO的原则，跟公平锁的顺序是一样的

综上所述：

队列中的永远都是FIFO的顺序，公平不公平，并不是指的队列中，而是指新来的线程是否可以直接尝试获取锁，如果是公平锁，那么新线程会先进入队列尾部，然后从队列头的线程会尝试获取锁；而非公平锁，新线程会直接尝试获取锁，如果获取到就直接执行，打破公平。

非公平锁性能高于公平锁性能。

• 首先，在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。
• 而且，非公平锁能更充分的利用cpu的时间片，尽量的减少cpu空闲的状态时间。

上面这个是基于ReentryLock来说的，对于synchronized来说，这个队列其实就是锁对象的entry set，后面会详细说明。

使用

synchronized是Java提供的一个并发控制的关键字。主要有两种用法，分别是同步方法和同步代码块。也就是说，synchronized既可以修饰方法也可以修饰代码块。

public class SynchronizedDemo { 
    //同步方法 
    public synchronized void doSth(){ 
        System.out.println("Hello World"); 
    } 
    //同步代码块 
    public void doSth1(){ 
        synchronized (SynchronizedDemo.class){ 
            System.out.println("Hello World"); 
        } 
    } 
}

被synchronized修饰的代码块及方法，在同一时间，只能被单个线程访问。

• 同步方法，锁对象是当前类的实例对象
• 静态同步方法，所对象时当前类的类对象
• 同步代码块，锁对象，是我们synchronized后面跟的对象，这里是SynchronizedDemo的class对象

synchronzed的执行过程

一个线程执行临界区代码过程如下：

• 获得同步锁
• 清空工作内- 存
  从主存拷贝变量副本到工作内存
• 对这些变量计算
• 将变量从工作内存写回到主存
• 释放锁

可以保证原子性、可见性和有序性。

原理

再有人问你synchronized是什么，就把这篇文章发给他。
我们对使用里面的代码进行Javap反编译，可以得到如下代码：

public synchronized void doSth();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #3                  // String Hello World
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
  public void doSth1();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #5                  // class com/hollis/SynchronizedTest
         2: dup
         3: astore_1
         4: monitorenter
         5: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         8: ldc           #3                  // String Hello World
        10: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        13: aload_1
        14: monitorexit
        15: goto          23
        18: astore_2
        19: aload_1
        20: monitorexit
        21: aload_2
        22: athrow
        23: return

我们发现，JVM对于同步方法和同步代码块的处理方式不同：

• 对于同步方法，JVM采用ACC_SYNCHRONIZED标记符来实现同步。
• 对于同步代码块。JVM采用monitorenter、monitorexit两个指令来实现同步。

同步方法

方法级的同步是隐式的。
同步方法的常量池中会有一个ACC_SYNCHRONIZED标志。
当某个线程要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁；如果获取不到，会因为无法获得监视器锁而被阻断住。
值得注意的是，如果在方法执行过程中，发生了异常，并且方法内部并没有处理该异常，那么在异常被抛到方法外面之前监视器锁会被自动释放。

同步代码块

同步代码块使用monitorenter和monitorexit两个指令实现。
执行monitorenter指令理解为加锁，执行monitorexit理解为释放锁。
每个对象维护着一个记录着被锁次数的计数器。未被锁定的对象的该计数器为0，当一个线程获得锁（执行monitorenter）后，该计数器自增变为 1 ，当同一个线程再次获得该对象的锁的时候，计数器再次自增。
当同一个线程释放锁（执行monitorexit指令）的时候，计数器再自减。
当计数器为0的时候，锁将被释放，其他线程便可以获得锁。

Monitor

Monitor是一种同步机制，这个机制保证了在同一时刻只有一个线程能访问共享资源。

Monitor是基于C++实现的，由ObjectMonitor实现的，其主要数据结构如下：

ObjectMonitor() { 
    _header = NULL; 
    _count = 0; 
    _waiters = 0, 
    _recursions = 0; 
    _object = NULL; 
    _owner = NULL; 
    _WaitSet = NULL; 
    _WaitSetLock = 0 ;
    _Responsible = NULL ; 
    _succ = NULL ; 
    _cxq = NULL ; 
    FreeNext = NULL ; 
    _EntryList = NULL ; 
    _SpinFreq = 0 ; 
    _SpinClock = 0 ; 
    OwnerIsThread = 0 ; 
}

ObjectMonitor中有几个关键属性：

_owner：指向持有ObjectMonitor对象的线程
_WaitSet：存放处于wait状态的线程队列
_EntryList：存放处于等待锁block状态的线程队列
_recursions：锁的重入次数
_count：用来记录该线程获取锁的次数

当多个线程同时访问一段同步代码时，首先会进入_EntryList队列中，当某个线程获取到对象的monitor后进入_Owner区域并把monitor中的_owner变量设置为当前线程，同时monitor中的计数器_count加1。即获得对象锁。
若持有monitor的线程调用wait()方法，将释放当前持有的monitor，_owner变量恢复为null，_count自减1，同时该线程进入_WaitSet集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。

锁优化

聊聊并发（二）——Java SE1.6中的Synchronized
深入理解多线程（五）—— Java虚拟机的锁优化技术

• 在JDK1.6之前，synchronized的实现才会直接调用ObjectMonitor的enter和exit，这种锁被称之为重量级锁。为什么说这种方式操作锁很重呢？
  

  Java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统的帮忙，这就要从用户态转换到核心态，因此状态转换需要花费很多的处理器时间，对于代码简单的同步块（如被synchronized修饰的get 或set方法）状态转换消耗的时间有可能比用户代码执行的时间还要长，所以说synchronized是java语言中一个重量级的操纵。

• 在JDK1.6中出现对锁进行了很多的优化，进而出现轻量级锁，偏向锁，锁消除，适应性自旋锁，锁粗化，这些操作都是为了在线程之间更高效的共享数据 ，解决竞争问题。

这个例子中，每个顾客是一个线程。 柜台前面的那把椅子，就是锁。 柜台后面的柜员，就是共享资源。 你发现无法直接办理业务，要取号等待的过程叫做阻塞。 当你听到叫你的号码的时候，你起身去办业务，这就是唤醒。 当你坐在椅子上开始办理业务的时候，你就获得锁。 当你办完业务离开的时候，你就释放锁。

自旋锁

如果要阻塞或唤醒一个线程就需要操作系统的帮忙，这就要从用户态转换到内核态，因此状态转换需要花费很多的处理器时间。

自旋锁和阻塞锁最大的区别就是，到底要不要放弃处理器的执行时间。对于阻塞锁和自旋锁来说，都是要等待获得共享资源。但是阻塞锁是放弃了CPU时间，进入了等待区，等待被唤醒。而自旋锁是一直“自旋”在那里，时刻的检查共享资源是否可以被访问。

自旋锁只是将当前线程不停地执行循环体，不进行线程状态的改变，所以响应速度更快。但当线程数不停增加时，性能下降明显，因为每个线程都需要执行，占用CPU时间。
如果线程竞争不激烈，并且保持锁的时间段。适合使用自旋锁。

锁消除

public void f() {
    Object hollis = new Object();
    synchronized(hollis) {
        System.out.println(hollis);
    }
}

public void f() {
    Object hollis = new Object();
    System.out.println(hollis);
}

我们经常在代码中使用StringBuffer作为局部变量，而StringBuffer中的append是线程安全的，有synchronized修饰的，这种情况开发者可能会忽略。这时候，JIT就可以帮忙优化，进行锁消除。

锁粗化

for(int i=0;i<100000;i++){  
    synchronized(this){  
        do();  
}  

synchronized(this){  
    for(int i=0;i<100000;i++){  
        do();  
} 

Java SE1.6为了减少获得锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”，所以在Java SE1.6里锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率

偏向锁

研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。

它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下，就会给线程加一个偏向锁。
如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，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”）的状态。

轻量级锁

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

优缺点

• 轻量级锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗
• 如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用轻量级锁了，因为轻量级锁在获取锁前一直都是占用cpu做无用功，线程自旋的消耗大于线程阻塞挂起操作的消耗，其它需要cup的线程又不能获取到cpu，造成cpu的浪费。

volatile

volatile关键字的两层语义

一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

1. 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
2. 禁止进行指令重排序。

那么经过volatile修饰之后：

线程写volatile变量过程：

• 改变线程工作内存中volatile变量副本的值；
• 将改变后的副本的值从工作内存刷新到主内存。

线程读volatile变量过程：

• 从主内存中读取volatile变量的最新值到工作内存中；
• 从工作内存中读取volatile变量副本。

//共享变量
boolean stop = false;
//线程1
while(!stop){
    doSomething();
}
//线程2
stop = true;