并发编程的一切

1、基础概念

什么是进程和线程

进程:程序运行资源分配的最小单位

资源:CPU、内存空间、磁盘 IO 等，同一进程中的多条线程共享该进程中的全部系统资源。

进程和进程之间是相互独立的，可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就是处于运行 状态下的操作系统本身,用户进程就是所有由你启动的进程。

线程是 CPU 调度的最小单位必须依赖于进程而存在

线程是进程的一个实体,是 CPU 调度和分派的基本单位,它是比进程更小的、能独立运行的基本单位。线程自己基本上不拥有系统资源，只拥有一点在运行中必不可少的资源(如程序计数器，一组寄存器和栈)，但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。

线程无处不在

任何一个程序都必须要创建线程,特别是 Java 不管任何程序都必须启动一个main 函数的主线程; Java Web 开发里面的定时任务、定时器、JSP 和 Servlet、异步消息处理机制，远程访问接口RM等,任何一个监听事件, onclick的触发事件等都离不开线程和并发的知识。

CPU核心数和线程数的关系

核心数、线程数:目前主流 CPU 都是多核的。增加核心数目就是为了增加线程数,因为操作系统是通过线程来执行任务的,一般情况下它们是 1:1 对应关系,也就是说四核 CPU 一般拥有四个线程。但 Intel 引入超线程技术后,使核心数与线程数形成 1:2 的关系

CPU时间片轮转机制

时间片轮转调度是一种最古老、最简单、最公平且使用最广的算法,又称RR调度。每个进程被分配一个时间段,称作它的时间片,即该进程允许运行的时间

如果在时间片结束时进程还在运行,则 CPU 将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束,则 CPU 当即进行切换。

上下文切换

从一个进程切换到另一个进程是需要一定时间的，包括保存和装入寄存器值及内存映像,更新各种表格和队列等。时间片设得太短会导致过多的进程切换,降低了CPU 效率: 而设得太长又可能引起对短的交互请求的响应变差。将时间片设为100ms通常是一个比较合理的折衷。

并行和并发

并发:指应用能够交替执行不同的任务,比如单CPU 核心下执行多线程并非是同时执行多个任务,如果你开两个线程执行,就是在你几乎不可能察觉到的速度不断去切换这两个任务,已达到"同时执行效果",其实并不是的,只是计算机的速度太快,我们无法察觉到而已.

并行:指应用能够同时执行不同的任务,例:吃饭的时候可以边吃饭边打电话, 这两件事情可以同时执行

两者区别:一个是交替执行,一个是同时执行.

高并发编程的意义、好处和注意事项

为什么要使用多线程

1. 充分利用CPU资源
2. 加快响应用户的时间
3. 模块化、异步化、简单化

注意事项

1. 线程之间的安全性
   eg.多个线程同时写一个变量
2. 线程之间的死锁
3. 线程太多会将服务器资源耗尽形成死机宕机
   线程数太多有可能造成系统创建大量线程（栈空间+指针）而导致消耗完系统内存以及CPU的“过渡切换”

2、认识 Java里的线程

Java天生就是多线程的

一个 Java程序从main()方法开始执行，然后按照既定的代码逻辑执行，看似没有其他线程参与，但实际上执行main()方法的是一个名称为 main 的线程，当然还有其他很多守护线程

[6] Monitor Ctrl-Break //监控 Ctrl-Break 中断信号的

[5] Attach Listener //内存 dump，线程 dump，类信息统计，获取系统属性等

[4] Signal Dispatcher // 分发处理发送给 JVM 信号的线程

[3] Finalizer // 调用对象 finalize 方法的线程，尽量不要在finalize的原因

[2] Reference Handler//清除 Reference 的线程

[1] main //main 线程，用户程序入口

线程的启动与中止

启动

启动线程的方式有两个：

1. 继承Thread
2. 实现Runnable

两种方式的区别

Thread 才是 Java 里对线程的唯一抽象
Runnable是对任务（业务逻辑）的抽象。Thread 可以接受任意一个 Runnable 的实例并执行。

终止

1.自然终止

要么是 run 执行完成了，要么是抛出了一个未处理的异常导致线程提前结束。

2.Stop

暂停、恢复和停止操作对应在线程 Thread 的 API 就是 suspend()、resume()和stop()。但是这些 API 是过期的，也就是不建议使用的。不建议使用的原因主要有：以 suspend()方法为例，在调用后，线程不会释放已经占有的资源（比如锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方法在终结一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资源释放工作的机会，因此会导致程序可能工作在不确定状态下。正因为suspend()、resume()和 stop()方法带来的副作用，这些方法才被标注为不建议使用的过期方法。

3.中断

interrupt()：对线程进行中断，只是修改中断标志位，好比其他线程对A线程打了个招呼，“A，你要中断了”，不代表线程 A 会立即停止自己的工作，A线程完全可以不理会这种中断请求。因为 java 里的线程是协作式的，不是抢占式的。

isInterrupted()：判断当前线程是否被中断

Thread.interrupted() ：判断当前线程是否被中断，并将标志位设置为false

线程通过检查自身的中断标志位是否被置为 true 来进行响应，线程通过方法 isInterrupted() 来进行判断是否被中断，也可以调用静态方法Thread.interrupted()来进行判断当前线程是否被中断，不过Thread.interrupted()会同时将中断标识位改写为 false。

如果一个线程处于了阻塞状态（如线程调用了 thread.sleep、thread.join、thread.wait 等），若在线程在检查中断标示时如果发现中断标示为 true，则会在这些阻塞方法调用处抛出 InterruptedException 异常，并且在抛出异常后会立即将线程的中断标示位清除，即重新设置为 false。

不建议自定义一个取消标志位来中止线程的运行。因为 run 方法里有阻塞调用时会无法很快检测到取消标志，线程必须从阻塞调用返回后，才会检查这个取消标志。这种情况下，使用中断会更好，因为，

1. 一般的阻塞方法，如 sleep 等本身就支持中断的检查
2. 检查中断位的状态和检查取消标志位没什么区别，用中断位的状态还可以避免声明取消标志位，减少资源的消耗。

注意：处于死锁状态的线程无法被中断

3、线程的状态

Java中线程的状态分为6种：

1. 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法；
2. 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为运行；
3. 阻塞(BLOCKED)：表示线程阻塞于锁。
4. 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）；
5. 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。
6. 终止(TERMINATED)：表示该线程已经执行完毕。

4、线程相关方法

深入理解run()和start()

Thread类是Java里对线程概念的抽象，start()方法让一个线程进入就绪队列等待分配 cpu，分到 cpu 后才调用实现的 run()方法，start()方法不能重复调用，如果重复调用会抛出异常。

而 run 方法是业务逻辑实现的地方，本质上和任意一个类的任意一个成员方法并没有任何区别，可以重复执行，也可以被单独调用。

yield()方法

使当前线程让出 CPU 占有权，但让出的时间是不可设定的，也不会释放锁资源。

join()方法

把指定的线程加入到当前线程，可以将两个交替执行的线程合并为顺序执行。

其他方法

• notify()：通知一个在对象上等待的线程,使其从 wait 方法返回,而返回的前提是该线程获取到了对象的锁，没有获得锁的线程重新进入 WAITING 状态。
• notifyAll()：通知所有等待在该对象上的线程
• wait()：调用该方法的线程进入 WAITING 状态,只有等待另外线程的通知或被中断才会返回.需要注意,调用 wait()方法后,会释放对象的锁
• wait(long)超时等待一段时间,这里的参数时间是毫秒,也就是等待长达 n 毫秒,如果没有 通知就超时返回
• wait (long,int) 对于超时时间更细粒度的控制,可以达到纳秒

线程的优先级

在 Java 线程中，通过一个整型成员变量 priority 来控制优先级，优先级的范围从 1~10，在线程构建的时候可以通过 setPriority(int)方法来修改优先级，默认优先级是 5，优先级高的线程分配时间片的数量要多于优先级低的线程。

• 频繁阻塞（休眠或者 I/O 操作）的线程需要设置较高优先级;
• 偏重计算（需要较多 CPU 时间）的线程则设置较低的优先级，确保处理器不会被独占。

在不同的 JVM 以及操作系统上，线程规划会存在差异，有些操作系统甚至会忽略对线程优先级的设定。

守护线程

Daemon（守护）线程是一种支持型线程，因为它主要被用作程序中后台调度以及支持性工作。这意味着，当一个 Java 虚拟机中不存在非 Daemon 线程的时候，Java 虚拟机将会退出。可以通过调用 Thread.setDaemon(true)将线程设置为 Daemon 线程。我们一般用不上，比如垃圾回收线程就是 Daemon 线程。

Daemon 线程被用作完成支持性工作，但是在 Java 虚拟机退出时 Daemon 线程中的 finally 块并不一定会执行。在构建 Daemon 线程时，不能依靠 finally 块中的内容来确保执行关闭或清理资源的逻辑。

5、CAS

原理

Compare-And-Swap

CAS的基本思：如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。循环CAS就是在一个循环里不断的做cas操作，直到成功为止。

自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。

ABA问题

描述：因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。

ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。

只能保证一个共享变量的原子操作

循环CAS的方式来保证原子操作对多个共享变量操作时，无法保证操作的原子性。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

6、线程间的共享

synchronized内置锁

关键字synchronized 可以修饰方法或者以同步块的形式来进行使用，它主要确保多个线程在同一个时刻，只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性和排他性，又称为内置锁机制。

对象锁和类锁

其实类锁只是一个概念上的东西，并不是真实存在的，类锁其实锁的是每个类的对应的 class 对象。类锁和对象锁之间也是互不干扰的。

错误的加锁和原因分析

public class Main1 extends Thread {
    private Integer i = 0;

    public Main1(Integer i) {
        this.i = i;
    }

    @Override
    public void run() {
        synchronized (i) {
            i++;
            System.out.println(i);
        }
    }
}

原因：虽然我们对 i 进行了加锁，但是当我们可以看到. class 文件

public class Main1 extends Thread {
    private Integer i = 0;

    public Main1(Integer i) {
        this.i = i;
    }

    public void run() {
        synchronized(this.i) {
            Integer var2 = this.i;
            Integer var3 = this.i = this.i + 1;
            System.out.println(this.i);
        }
    }
}

本质上是返回了一个新的 Integer 对象。也就是每个线程实际加锁的是不同的 Integer 对象。

Volatile，最轻量的同步机制

保证了不同线程对这个变量进行操作时的可见性。即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。但是 volatile 不能保证数据在多个线程下同时写时的线程安全。

最适用的场景：一个线程写，多个线程读。

死锁

死锁的发生必须具备以下四个必要条件

1. 互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2. 请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3. 不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4. 环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

防死锁的发生

只要打破四个必要条件之一就能有效预防死锁的发生。

1. 打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。
2. 打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无法满足，则退出原占有的资源。
3. 打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不然就等待，这样就不会占有且申请。
4. 打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。

• 避免死锁常见的算法有有序资源分配法、银行家算法。

死锁的危害与解决方案

危害

1. 线程不工作了，但是整个程序还是活着的
2. 没有任何的异常信息可以供我们检查
3. 一旦程序发生了发生了死锁，是没有任何的办法恢复的，只能重启程序

解决

1. 内部通过顺序比较，确定拿锁的顺序；
2. 采用尝试拿锁的机制

ThreadLocal解析

与Synchronized不同，ThreadLocal是通过并行的方式解决并发的问题，为每个线程都提供了变量的副本，使得每个线程在某一时间訪问到的并非同一个对象，隔离多个线程对数据的数据共享。

ThreadLocal的使用

类接口很简单，只有 4 个方法

//设置当前线程的线程局部变量的值。
void set(Object value) 

//该方法返回当前线程所对应的线程局部变量。
public Object get() 

//将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动 被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但它 可以加快内存回收的速度。
public void remove()

//返回该线程局部变量的初始值，该方法是一个 protected 的方法，显然是为 了让子类覆盖而设计的。这个方法是一个延迟调用方法，在线程第 1 次调用 get() 或 set(Object)时才执行，并且仅执行 1 次。ThreadLocal 中的缺省实现直接返回一 个 null。
protected Object initialValue()

public final static ThreadLocal<String> RESOURCE = new ThreadLocal<String>();
//此时不论什么一个线程能够并发访问这个变量，对它进行写入、读取操作，都是线程安全的。

源码解析

get方法开始

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

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
}

Thread.ThreadLocalMap threadLocals;

先取到当前线程，然后调用 getMap 方法获取对应的 ThreadLocalMap

static class ThreadLocalMap {

        /**
         * The entries in this hash map extend WeakReference, using
         * its main ref field as the key (which is always a
         * ThreadLocal object).  Note that null keys (i.e. entry.get()
         * == null) mean that the key is no longer referenced, so the
         * entry can be expunged from table.  Such entries are referred to
         * as "stale entries" in the code that follows.
         */
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
        
				/**
         * The table, resized as necessary.
         * table.length MUST always be a power of two.
         */
        private Entry[] table;
     
}

Entry是个内部静态类，继承了WeakReference

Entry是类似于Map的k,v结构

• k：ThreadLocal
• v：需要线程隔离的变量

用数组保存了Entry，因为可能有多个变量需要线程隔离

扩容算法

private final int threadLocalHashCode = nextHashCode();

private static int nextHashCode() {
    return nextHashCode.getAndAdd(HASH_INCREMENT);
}

private Entry getEntry(ThreadLocal<?> key) {
    ...
    int i = key.threadLocalHashCode &(table.length - 1);
    Entry e = table [i];
    ...
}

private void set(ThreadLocal<?> key, Object value){
    Entry[] tab = table;
    int len = tab.length;
    int i = key.threadLocalHashCode & (len-1);
    ...
}

private void resize() {
    Entry[] oldTab = table;
    int oldLen = oldTab . length;
    int newLen = oldLen * 2;
    ...
}

1. threadLocalHashCode是倍增的，增加HASH_INCREMENT
2. 无论存取都会都会命中key.threadLocalHashCode & (len-1)这个位置
3. Entry初始大小是16，由于resize扩容时会变成数组容量的2倍
4. (len-1)在2进制上的表示全部为1，所以能固定尾数达到均匀分布的目的，减少冲突的概率

内存泄漏

根据我们前面对 ThreadLocal 的分析，我们可以知道每个 Thread 维护一个 ThreadLocalMap，这个映射表的 key 是 ThreadLocal 实例本身，value 是真正需 要存储的 Object，也就是说 ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从ThreadLocalMap 获取 value。仔细观察 ThreadLocalMap，这个 map 是使用ThreadLocal的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收

图中的虚线表示弱引用。

这样，当把 threadlocal 变量置为 null 以后，没有任何强引用指向 threadlocal 实例，所以 threadlocal 将会被 gc 回收。这样一来，ThreadLocalMap 中就会出现 key 为 null 的 Entry，就没有办法访问这些 key 为 null 的 Entry 的 value，如果当前 线程再迟迟不结束的话，这些 key 为 null 的 Entry 的 value 就会一直存在一条强 引用链:Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而这块 value 永 远不会被访问到了，所以存在着内存泄露。

只有当前 thread 结束以后，current thread 就不会存在栈中，强引用断开， Current Thread、Map value 将全部被 GC 回收。最好的做法是不在需要使用 ThreadLocal 变量后，都调用它的 remove()方法，清除数据。

看一下remove方法

private void remove(ThreadLocal<?> key) {
    Entry[] tab = table;
    int len = tab.length;
    int i = key.threadLocalHashCode & (len-1);
    for (Entry e = tab[i];
    e != null;
    e = tab[i = nextIndex(i, len)]) {
        if (e.get() == key) {
            e.clear();
            expungeStaleEntry(i);
            return;
        }
    }
}

也就是说expungeStaleEntry移除了这个引用，而get()、set()在某些时候，也调用了 expungeStaleEntry 方法用来清除 Entry 中 Key 为 null 的 Value，但是 这是不及时的，也不是每次都会执行的，所以一些情况下还是会发生内存泄露。 只有 remove()方法中显式调用了 expungeStaleEntry 方法。

从表面上看内存泄漏的根源在于使用了弱引用，但是另一个问题也同样值得 思考:

为什么使用弱引用而不是强引用?

分两种情况讨论

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

比较两种情况，我们可以发现:由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果都没有手动删除对应 key，都会导致内存泄漏，但是使用弱引用可 以多一层保障。

因此，ThreadLocal 内存泄漏的根源是：由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果没有手动删除对应 key 就会导致内存泄漏，而不是因为弱引 用。

总结

• JVM 利用设置 ThreadLocalMap 的 Key 为弱引用，来避免内存泄露。
• JVM 利用调用 remove、get、set 方法的时候，回收弱引用。
• 当 ThreadLocal 存储很多 Key 为 null 的 Entry 的时候，而不再去调用 remove、 get、set 方法，那么将导致内存泄漏。
• 使用线程池**+** ThreadLocal 时要小心，因为这种情况下，线程是一直在不断的 重复运行的，从而也就造成了 value 可能造成累积的情况。

7、线程间的合作

等待/通知机制

• 等待方遵循如下原则。
  1)获取对象的锁。
  2)如果条件不满足，那么调用对象的 wait()方法，被通知后仍要检查条件。
  3)条件满足则执行对应的逻辑。

synchronized(对象){
    while (条件不满足) {
        对象.wait();
    }
    处理逻辑
}

• 通知方遵循如下原则。
  1)获得对象的锁。
  2)改变条件。
  3)通知所有等待在对象上的线程。

synchronized(对象){
    改变条件
    对象.notifyAll();
}

notify 和 notifyAll 应该用谁

尽可能用 notifyall()，谨慎使用 notify()，因为 notify()只会唤醒一个线程，我们无法确保被唤醒的这个线程一定就是我们需要唤醒的线程

8、阻塞队列

什么是阻塞队列

1. 支持阻塞的插入方法：意思是当队列满时，队列会阻塞插入元素的线程，直到队列不满。
2. 支持阻塞的移除方法：意思是在队列为空时，获取元素的线程会等待队列变为非空。

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

• 抛出异常：当队列满时，如果再往队列里插入元素，会抛出IllegalStateException（“Queuefull”）异常。当队列空时，从队列里获取元素会抛出NoSuchElementException异常。
• 返回特殊值：当往队列插入元素时，会返回元素是否插入成功，成功返回true。如果是移除方法，则是从队列里取出一个元素，如果没有则返回null。
• 一直阻塞：当阻塞队列满时，如果生产者线程往队列里put元素，队列会一直阻塞生产者线程，直到队列可用或者响应中断退出。当队列空时，如果消费者线程从队列里take元素，队列会阻塞住消费者线程，直到队列不为空。
• 超时退出：当阻塞队列满时，如果生产者线程往队列里插入元素，队列会阻塞生产者线程一段时间，如果超过了指定的时间，生产者线程就会退出。

常用阻塞队列

• ArrayBlockingQueue：
  是一个用数组实现的有界阻塞队列。默认情况下不保证线程公平的访问队列，初始化时有参数可以设置；其队列中的锁是没有分离的，即生产和消费用的是同一个锁；

• LinkedBlockingQueue：
  一个由链表结构组成的有界阻塞队列，此队列的默认和最大长度为Integer.MAX_VALUE；队列中的锁是分离的，即生产用的是putLock，消费是takeLock

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

• DelayQueue：
  一个支持延时获取元素并使用优先级队列实现的无界阻塞队列。队列使用PriorityQueue来实现。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。只有在延迟期满时才能从队列中提取元素。
  用于缓存系统的设计：可以用DelayQueue保存缓存元素的有效期，使用一个线程循环查询DelayQueue，一旦能从DelayQueue中获取元素时，表示缓存有效期到了。

• SynchronousQueue：
  一个不存储元素的阻塞队列。每一个put操作必须等待一个take操作，否则不能继续添加元素。SynchronousQueue的吞吐量高于LinkedBlockingQueue和ArrayBlockingQueue。匿名传递

• LinkedTransferQueue：
  一个由链表结构组成的无界阻塞队列。多了tryTransfer和transfer方法：
  transfer

  如果当前有消费者正在等待接收元素（消费者使用take()方法或带时间限制的poll()方法时），transfer方法可以把生产者传入的元素立刻transfer（传输）给消费者。如果没有消费者在等待接收元素，transfer方法会将元素存放在队列的tail节点，并等到该元素被消费者消费了才返回。
  tryTransfer
  是用来试探生产者传入的元素是否能直接传给消费者。如果没有消费者等待接收元素，则返回false。和transfer方法的区别是tryTransfer方法无论消费者是否接收，方法立即返回，而transfer方法是必须等到消费者消费了才返回。

• LinkedBlockingDeque：
  一个由链表结构组成的双向阻塞队列。多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。双向阻塞队列可以运用在“工作窃取”模式中

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

工作窃取算法 work-stealing

工作窃取(work-stealing)算法是指某个线程从其他队列里窃取任务来执行。
一个大任务分割为若干个互不依赖的子任务，为了减少线程间的竞争，把这些子任务分别放到不同的队列里，并未每个队列创建一个单独的线程来执行队列里的任务，线程和队列一一对应。比如线程1负责处理1队列里的任务，2线程负责2队列的。但是有的线程会先把自己队列里的任务干完，而其他线程对应的队列里还有任务待处理。干完活的线程与其等着，不如帮其他线程干活，于是它就去其他线程的队列里窃取一个任务来执行。而在这时它们可能会访问同一个队列，所以为了减少窃取任务线程和被窃取任务线程之间的竞争，通常会使用双端队列，被窃取任务线程永远从双端队列的头部拿任务执行，而窃取任务线程永远从双端队列的尾部拿任务执行。

优点：充分利用线程进行并行计算，减少线程间的竞争。
缺点：在某些情况下还是会存在竞争，比如双端队列里只有一个任务时。并且该算法会消耗更多的系统资源， 比如创建多个线程和多个双端队列。

在Java中：

• 可以使用LinkedBlockingDeque来实现工作窃取算法
• JDK1.7引入的Fork/Join框架就是基于工作窃取算法

9、线程池

为什么要用线程池？

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： 线程空闲时的存活时间

• TimeUnit： keepAliveTime的时间单位

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

• threadFactory：
  创建线程的工厂，通过自定义的线程工厂可以给每个新建的线程设置一个具有识别度的线程名，当然还可以更加自由的对线程做更多的设置，比如设置所有的线程为守护线程。
  Executors静态工厂里默认的threadFactory，线程的命名规则是“pool-数字-thread-数字”

• RejectedExecutionHandler： 线程池的饱和策略

  当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：
  （1）AbortPolicy：直接抛出异常，默认策略；

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

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

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

线程池的工作机制

1. 如果当前运行的线程少于corePoolSize，则创建新线程来执行任务（注意，执行这一步骤需要获取全局锁）
2. 如果运行的线程等于或多于corePoolSize，则将任务加入BlockingQueue。
3. 如果无法将任务加入BlockingQueue（队列已满），则创建新的线程来处理任务。
4. 如果创建新线程将使当前运行的线程超出maximumPoolSize，任务将被拒绝，并调用RejectedExecutionHandler.rejectedExecution()方法。

提交任务

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

关闭线程池

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

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

合理地配置线程池

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

• 任务的性质：
  CPU密集型任务

  应配置尽可能小的线程，如配置Ncpu+1个线程的线程池

  IO密集型任务

  由于线程并不是一直在执行任务，则应配置尽可能多的线程，如2*Ncpu

  混合型任务

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

• 任务的优先级：
  高、中和低

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

• 任务的执行时间：
  长、中和短。

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

• 任务的依赖性：是否依赖其他系统资源，如数据库连接。

10、AQS

AbstractQueuedSynchronizer，是用来构建锁或其他同步组件的基础框架，他使用一个int成员变量表示同步状态，通过内置的队列来完成资源资源获取线程的排队工作。

使用方式和设计模式

子类继承AQS并实现抽象方法来管理同步状态，在AQS里由一个int型的state来代表这个状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法：

etState()
setState(int newState)
compareAndSetState(int expect,int update)

它们能够保证状态的改变是安全的

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

模板方法模式

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

1. 锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；
2. 同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所需关注的领域。
3. 实现者需要继承同步器并重写指定的方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些模板方法将会调用使用者重写的方法。

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

AQS中的方法

模板方法

模板同步器提供的模板方法分为三类：

1. 独占式获取与释放同步状态
2. 共享式获取与释放同步状态
3. 查询队列中等待线程状态

可重写方法

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

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

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

11、CLH队列锁

名字是由三个人名组成的，Craig, Landin, and Hagersten

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

后一个自旋等待前一个的锁资源

流程：

1. 创建一个的CurNode，将其中的locked设置为true表示需要获取锁，preNode表示对其前驱结点的引用；
2. 线程A对tailNode域调用getAndSet方法，使自己成为队列的尾部，同时获取一个指向其前驱结点的引用preNode；线程B需要获得锁，同样的流程再来一遍；
3. 线程就在前驱结点的locked字段上旋转，直到前驱结点释放锁(前驱节点的锁值 locked == false)；
4. 当一个线程需要释放锁时，将当前结点的locked域设置为false，同时回收前驱结点；

优点

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

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

12、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，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。

13、JMM

原理

Java内存模型即Java Memory Model，定义了JVM在RAM中的工作方式。JVM是整个计算机虚拟模型，所以JMM是隶属于JVM的。

早期计算机中cpu和内存的速度是差不多的，但在现代计算机中，cpu的指令速度远超内存的存取速度,由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

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

Java内存模型

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


JMM的关键技术点都是围绕着多线程的原子性、可见性和有序性来*建立的，这也是Java解决多线程并行机制的环境下，定义出的一种规则，意在保证多个线程间可以有效地、正确地协同工作。

可见性

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

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

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

原子性

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

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

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

有序性

对于一个线程执行的代码而言，我们总是习惯地认为代码总是按照书写顺序从先往后依次执行，这在单线程环境下，确实如此，但是在多线程并发环境下估计就不见得了，程序的执行可能就会出现乱序，给人的感觉就是写在前面的代码可能在后面执行了。其实有序性问题的原因是因为程序在执行时，可能因为编译器优化的缘故，进行了指令重排的操作，重排后的指令与原指令的顺序未必一致。

为什么要指令重排

一条指令的执行是分多个步骤的：

1. IF取值
2. ID译码和取寄存器操组数
3. EX执行或地址计算
4. MEN访问存储器
5. WB写回

如：C=A+B

右边就是流水线的情况，其中在ADD指令上就有一个大X，这就表示一个中断，为什么这里会有中断（停顿）呢？原因很简单，R2中的数据还没有准备好，必须要等到它写回到存储器上才能继续使用，所以ADD操作在这里必须等待一次。由于ADD的延迟，导致其后面所有的指令都要慢一步。

再如：

a = b + c
d = e - f

重排序优化后

####Happen-Before规则

这些原则是指令重排不可以违背的：

• 程序顺序原则：一个线程内保证语义的串行性
• volatile规则：volatile变量的写操作，先发生于读操作，这保证了volatile变量的可见性
• 锁规则：解锁（unlock）必然发生在随后的加锁（lock）前
• 传递性：A先于B，B先于C，那么A必然先于C
• 线程的start()方法先于它的每一个动作
• 线程的所有操作先于线程的终结（Thread.join()）
• 线程的中断（interrupt）先于被中断线程的代码
• 对象的构造函数执行、结束先于finalize()方法

重排后的指令绝对不能改变原有的串行语义

volatile原理

• 可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
• 原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

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

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

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

synchronized的实现原理

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

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

1. 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
2. 如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1.
3. 如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。

对同步方法，从同步方法反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来实现，相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。

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

synchronized使用的锁是存放在Java对象头里面，Java对象的对象头由 mark word 和 klass pointer 两部分组成：

1. mark word存储了同步状态、标识、hashcode、GC状态等等。

2. klass pointer存储对象的类型指针，该指针指向它的类元数据

   另外对于数组而言还会有一份记录数组长度的数据。
   
   锁信息则是存在于对象的mark word中，MarkWord里默认数据是存储对象的HashCode等信息
   
   但是会随着对象的运行改变而发生变化，不同的锁状态对应着不同的记录存储方式
   

14、 各种锁

锁状态

一共有四种状态：

• 无锁状态
• 偏向锁状态
• 轻量级锁状态
• 重量级锁状态

它会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获得锁和释放锁的效率。

偏向锁

引入背景：大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁，减少不必要的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

轻量级锁

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

加锁过程：

1. 在代码进入同步块的时候，如果同步对象锁状态为无锁状态且不允许进行偏向（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word
2. 拷贝对象头中的Mark Word复制到锁记录中
3. 拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤4，否则执行步骤5
4. 如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态
5. 如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，那么它就会自旋等待锁，一定次数后仍未获得锁对象。重量级线程指针指向竞争线程，竞争线程也会阻塞，等待轻量级线程释放锁后唤醒他。锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

自旋锁

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

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

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

自旋锁的优缺点

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

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

自旋锁的缺点

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

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

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

不同锁比较

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销的消耗	只有一个线程访问同步代码块
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度	如果始终得不到竞争的线程会消耗CPU	追求响应时间 同步块执行速度非常快
重量级锁	线程竞争不使用自选，不会消耗CPU	线程阻塞，响应时间缓慢	追求吞吐量 同步块执行速度较长

10、面试题

1. 调用 yield() 、sleep()、wait()、notify()等方法对锁有何影响?

   yield() 、sleep()被调用后，都不会释放当前线程所持有的锁。调用 wait()方法后，会释放当前线程持有的锁，而且当前被唤醒后，会重新 去竞争锁，锁竞争到后才会执行 wait 方法后面的代码。调用 notify()系列方法后，对锁无影响，线程只有在 syn 同步代码执行完后才 会自然而然的释放锁，所以 notify()系列方法一般都是 syn 同步代码的最后一行。

2. sleep 、wait、yield 的区别，wait 的线程如何唤醒它

3. sleep是可中断的么

4. sychronied修饰普通方法和静态方法的区别？什么是可见性?

5. 锁分哪几类？

6. CAS无锁编程的原理

7. AQS原理

8. Synchronized的原理以及与ReentrantLock的区别

9. Synchronized做了哪些优化

10. Synchronized static与非static锁的区别和范围

11. volatile 能否保证线程安全？在DCL上的作用是什么

12. volatile和synchronize有什么区别

13. 什么是守护线程？你是如何退出一个线程的

14. 线程生命周期

15. ThreadLocal是什么

16. 线程池基本原理

17. 有三个线程T1，T2，T3，怎么确保它们按顺序执行