关于多线程:多线程高并发

@[toc]

章节名称	文章地址
秋春招总结之 MySQL	MySQL
秋春招总结之 Redis	Redis
秋春招总结之并发多线程	并发多线程

每周二完定时更新

对于 Java 多线程方面的常识波及宽泛，从最根底的输出一个指令，期待运行实现到批处理操作系统，再到起初过程和线程的提出与纯熟使用到咱们的日常生活中，无疑也是咱们计算机的稳步发展的映照，这篇博客将尽可能的总结目前呈现的一些面试题目曾经本人遇到过的一些题目，心愿在本人总结几个月来遇到的问题的同时也可能进行进一步的深入与升华，每一次的记录也都让我更加记忆深切。

注：这个题目是学习计算机操作系统必备的题目，也是初步进行了解与把握前面问题的关键所在

粗略答复：过程是操作系统进行资源分配与调度的根本单位，线程是任务调度与执行的根本单位，即 CPU 调配工夫单位。他们的本质区别是是否独自占有内存地址空间以及其余系统资源。

同一个过程中能够包含多个线程，并且线程共享整个过程的资源 (寄存器，堆栈，上下文) 一个过程至多包含一个线程
线程是轻量级的过程，同一类线程共享代码和数据空间，每个线程都有本人独立的运行栈和程序计数器，线程之间切换的开销比拟小。

只有一个线程的过程能够看做是单线程的，如果一个过程内有多个线程，在执行的过程是多条 (线程) 共同完成的；线程是过程的一部分所以也被称之为轻量级过程。

三要素：

原子性：就是咱们的程序是一个不可分割的整体，所有的操作要么全副都执行，要么都不执行或者都是失败，不可能说对于一段程序，一部分胜利执行并提交，另外一部分执行失败。
有序性：程序的执行在原则上会依照咱们写的程序程序执行上来（然而在有些状况下，为了可能进步解决效率，在满足肯定的条件下，是运行进行指令的重排序）
可见性：利用到 JMM（Java 内存模型）来实现对共享变量的共享可见（一个线程进行了批改，另一个线程就能够得悉）

可能会呈现的问题：

线程切换带来的原子性问题
缓存导致的可见性问题
编译优化带来的有序性问题

解决方案：

JDK Atomic 结尾的原子类、synchronized、LOCK，能够解决原子性问题
synchronized、volatile、LOCK，能够解决可见性问题
Happens-Before 规定能够解决有序性问题

注：面试中切实遇到过

并行：单位工夫内，多个处理器或多核处理器同时解决多个工作，是真正意义上的“同时进行”。

并发：多个工作在同一个 CPU 核上，按细分的工夫片轮流(交替) 执行，从逻辑上来看那些工作是同时执行(其实只是调配工夫片进行执行)。

串行：有 n 个工作，由一个线程按程序执行。因为工作、办法都在一个线程执行所以不存在线程不平安状况，也就不存在临界区的问题。

对于这个题目来说可能会问道：你来说一说创立线程有几种的形式? 并说一说具体的区别

这里就须要本人来进行比拟充沛的筹备，首先明确创立的几种形式，而后本人实现进行了解与把握。

定义一个类，继承 Thread，并复写 run()办法，对于 run 办法来说就是实现咱们本人的业务代码。
实例化本人创立的类的对象，调用 start()办法（这里必须调用 start 办法才算是真正的启动线程）

public class Demo {

    public static  class MyThread extends  Thread{public void run(){System.out.println("Myhread");
        }
    }

    public static void main(String[] args) {MyThread myThread = new MyThread();
        myThread.start();
        System.out.println("MyThread Is Run");
    }
}

这个执行后果大家能够去运行尝试一下，有以下 r 留神点：

咱们在程序外面调用了 start(办法后, 虚构机会先为咱们创立一个线程, 而后等到这个线程第一次失去工夫片时再调用 run()办法。

留神不可屡次调用 start(办法。在第一次调用 start()办法后, 再次调用 start()办法会抛出异样。

定义一个本人的类，实现接口 Runnable，并复写 run()办法。
创立 MyRunnable 实例 myRunnable，以 myRunnable 作为 target 创立 Thead 对象，该 Thread 对象才是真正的线程对象
调用线程对象的 start()办法

public class MyRunnable implements Runnable {

    @Override
    public void run() {System.out.println("MyRunnable);
    }
MyRunnable myRunnable = new MyRunnable();
        Thread thread = new Thread(myRunnable);
        thread.start();
        System.out.println("MyRunnable Is Run");
}

创立实现 Callable 接口的类 myCallable
以 myCallable 为参数创立 FutureTask 对象
将 FutureTask 作为参数创立 Thread 对象
调用线程对象的 start()办法

public class Demo {
    public static  class MyCallable implements Callable<Integer> {
        @Override
        public Integer call() throws Exception {System.out.println("MyCallable");
            return 0;
        }
    }

    public static void main(String[] args) {FutureTask<Integer> futureTask = new FutureTask<Integer>(new MyCallable());
        Thread thread = new Thread(futureTask);
        thread.start();

        try {Thread.sleep(1000);
            System.out.println("返回后果" + futureTask.get());
        } catch (InterruptedException e) {e.printStackTrace();
        } catch (ExecutionException e) {e.printStackTrace();
        }
        System.out.println(Thread.currentThread().getName() + "main()办法执行实现");

    }
}

Executors 提供了一系列工厂办法用于创先线程池，返回的线程池都实现了 ExecutorService 接口。

次要有newFixedThreadPool，newCachedThreadPool，newSingleThreadExecutor，newScheduledThreadPool。

具体的内容能够参看线程池的了解与使用，外面有具体具体的解说与可能会呈现的面试问题。

实现一个自定义的线程类, 能够有继承 Thread类或者实现 Runnable接口这两种形式, 它们之间有什么优劣呢？

因为 Java” 单继承, 多实现 ” 的个性, Runnable 接口应用起来比 Thread 更灵便。
Runnable 接口呈现更合乎面向对象, 将线程独自进行对象的封装。
Runnable 接口呈现, 升高了线程对象和线程工作的耦合性
如果应用线程时不须要应用 Thread 类的诸多办法, 显然应用 Runnable 接口更为轻量。

所以, 咱们通常优先应用“实现 Runnable 接口”这种形式来自定义线程类。

通常来说, 咱们应用 Runnable 和 Thread 来创立一个新的线程。然而它们有一个弊病, 就是 run 办法是没有返回值的。而有时候咱们心愿开启一个线程去执行一个工作, 并且这个工作执行实现后有一个返回值。

与 Runnable 接口相似，同样是只有一个形象办法的函数式接口，不同的是对于 Callable 来说提供的办法是有返回值的，并且反对泛型：

public interface Callable<V>{V call() throws Exception;
}

对于 Callable 的应用来说个别都是配合到线程池工具：ExecutorService来应用：

class Taskclass Task implements Callable<Integer>{

    @Override
    public Integer call() throws Exception {Thread.sleep(1000);
        return  2;
    }

    public static void main(String[] args) {ExecutorService executorService = Executors.newCachedThreadPool();
        Task task =new Task();
        Future<Integer> result = executorService.submit(task);
        // 留神调用 get 办法会阻塞以后线程 直到失去后果。// 所以理论编码中 倡议应用 能够设置超时工夫的重载 get 办法。System.out.println(result.get());
    }
}

首先来看一张图

而后以这张图来进行开展：
对于线程的状态：

新生(通过 new 关键字创立一个线程)
就绪（通过 start 要害之让线程进入就绪的状态）
运行（通过 CPU 的调用进入到运行状态）
阻塞（线程在运行的过程中遇到了 sleep（睡眠）yield（退让）wait（期待）会进入到阻塞的状态）有三种。

期待阻塞（o.wait-> 期待对列）：

运行 (running) 的线程执行 o.wait()办法，JVM 会把该线程放入期待队列 (waitting queue)
中。

同步阻塞(lock-> 锁池)

运行 (running) 的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则 JVM 会把该线
程放入锁池 (lock pool) 中。

其余阻塞(sleep/join)

运行 (running) 的线程执行 Thread.sleep(long ms)或 t.join()办法，或者收回了 I/O 申请时，
JVM 会把该线程置为阻塞状态。当 sleep()状态超时、join()期待线程终止或者超时、或者 I/O
处理完毕时，线程从新转入可运行 (runnable) 状态。

死亡（也有三种的状况）
失常完结
- run()或 call()办法执行实现，线程失常完结。

异样完结

线程抛出一个未捕捉的 Exception 或 Error。

调用 stop

间接调用该线程的 stop()办法来完结该线程—该办法通常容易导致死锁，不举荐应用。

（1）wait()：使一个线程处于期待（阻塞）状态，并且开释所持有的对象的锁；

（2）sleep()：使一个正在运行的线程处于睡眠状态，是一个静态方法，调用此办法要解决 InterruptedException 异样；

（3）notify()：唤醒一个处于期待状态的线程，当然在调用此办法的时候，并不能确切的唤醒某一个期待状态的线程，而是由 JVM 确定唤醒哪个线程，而且与优先级无关；

（4）notityAll()：唤醒所有处于期待状态的线程，该办法并不是将对象的锁给所有线程，而是让它们竞争，只有取得锁的线程能力进入就绪状态；

咱们都晓得的是对于 sleep 和 wait 都是会让线程呈现暂停执行的状态，上面从几个方面进行分析个体区别

对于 sleep()办法，咱们首先要晓得该办法是属于 Thread 类中的。而 wait()办法，则是属于

Object 类中的。

sleep()办法导致了程序暂停执行指定的工夫，让出 cpu 该其余线程，然而他的监控状态仍然

保持者，当指定的工夫到了又会主动复原运行状态。

在调用 sleep()办法的过程中，线程不会开释对象锁。
而当调用 wait()办法的时候，线程会放弃对象锁，进入期待此对象的期待锁定池，只有针对此

对象调用 notify()办法后本线程才进入对象锁定池筹备获取对象锁进入运行状态。

应用的地位不同：对于 wait 来说应用之前要获取到锁的存在，所以必须放在同步代码，或者同步块中进行执行然而 sleep 来说能够放在任何的中央执行。
sleep 须要捕捉异样。wait notify 等不须要这些。

（1）sleep()办法给其余线程运行机会时不思考线程的优先级，因而会给低优先级的线程以运行的机会；yield()办法只会给雷同优先级或更高优先级的线程以运行的机会；

（2）线程执行 sleep()办法后转入阻塞（blocked）状态，而执行 yield()办法后转入就绪（ready）状态；

（3）sleep()办法申明抛出 InterruptedException，而 yield()办法没有申明任何异样；

（4）sleep()办法比 yield()办法（跟操作系统 CPU 调度相干）具备更好的可移植性，通常不倡议应用 yield()办法来管制并发线程的执行。

start（）办法来启动线程，真正实现了多线程运行。这时无需期待 run 办法体代码执行结束，

能够间接继续执行上面的代码。

通过调用 Thread 类的 start()办法来启动一个线程，这时此线程是处于就绪状态，并没有运

行。对于多线程来说只有真正意义上调用了 start 办法才算是对于线程的一个启动。

办法 run()称为线程体，它蕴含了要执行的这个线程的内容，线程就进入了运行状态，开始运

行 run 函数当中的代码。Run 办法运行完结，此线程终止。而后 CPU 再调度其它线程。

join()办法使调用该办法的线程在此之前执行结束，也就是期待该办法的线程执行结束后再往下继续执行。留神该办法也须要捕获异样。
就是说让该线程在执行完 RUN()办法当前再执行 join 办法前面的代码，就是说能够让两个线程合并起来，用于实现同步性能

该办法与 sleep() 相似只不过不可能由用户指定暂停多长的工夫，并且 yield（）办法只能让同优先级的线程有执行的机会。后面提到了 sleep 不会开释锁标识 yield 也不会开释锁标识。
实际上，yield()办法对应了如下操作；先检测以后是否有雷同优先级的线程处于同可运行状态，如有，则把 CPU 的占有权交给次线程，否则持续运行原来的线程，所以 yield()办法称为“让步 ”，它把运行机会让给了同等级的其余线程。
sleep 办法 容许较低优先级的线程取得运行机会 ，但 yield（）办法执行时，以后线程仍处在可运行状态，所以不可能让出较低优先级的线程此时获取 CPU 占有权。在一个运行零碎中，如果较高优先级的线程没有调用 sleep 办法，也没有受到 I / O 阻塞，那么较低优先级线程只能期待所有较高优先级的线程运行完结，方可有机会运行。yield() 只是使以后线程从新回到可执行状态，所有执行 yield()的线程有可能在进入到可执行状态后马上又被执行 ，所以 yield() 办法只能使同优先级的线程有执行的机会。

这三个办法用于协调多个线程对共享数据的存取，所以必须在 synchronized 语句块内应用。synchronized 关键字用于爱护共享数据，阻止其余线程对共享数据的存取，然而这样程序的流程就很不灵便了，如何能力在以后线程还没退出 synchronized 数据块时让其余线程也有机会访问共享数据呢？此时就用这三个办法来灵便管制。wait() 办法使以后线程暂停执行并开释对象锁标示，让其余线程能够进入 synchronized 数据块，以后线程被放入对象期待池中。当调用 notify()办法后，将从对象的期待池中移走一个任意的线程并放到锁标记期待池中 ，只有锁标记期待池中线程可能获取锁标记；如果锁标记期待池中没有线程，则 notify() 不起作用。notifyAll() 从对象期待池中移走所有期待那个对象的线程并放到锁标记期待池中。

常见的 void wait 办法有

wait（long timeout）
wait()。

对于无参的办法来说：在其余线程调用此对象的 notify 办法或者 nofifyall 办法前导致以后的线程处于期待的状态。
对于有参的函数来说以上的两条成立的状况下还会在工夫超时之前也是处于期待的状态。
对于在执行完 wait 办法当前。线程会开释掉所占用的锁标识 从而使线程所在的对象中的其余 synchronized 数据可被别的线程应用。因为在执行 wait 和 notify() 时候须要对锁标记过程解决和操作 一个是开释锁一个是加锁所以就是来说须要要在 synchronized 函数中或者函数块中进行调用 ，如果不在函数中或是函数块中进行调用尽管说能够编译通过。然而会呈现 IllegalMonitorStateException 异样。

一个很显著的起因是 Java 提供的锁是对象级的而不是线程级的，每个对象都有锁，通过线程来取得因为 wait notify 和 notifyAll 都是锁级别的的操作，所以把他们定义在 Object 类中因为锁属于对象。

首先，wait()、notify() 办法是针对对象的，调用任意对象的 wait()办法都将导致线程阻塞，阻塞的同时也将开释该对象的锁，相应地，调用任意对象的 notify()办法则将随机解除该对象阻塞的线程，但它须要从新获取该对象的锁，直到获取胜利能力往下执行；

其次，wait、notify 办法必须在 synchronized 块或办法中被调用，并且要保障同步块或办法的锁对象与调用 wait、notify 办法的对象是同一个，如此一来在调用 wait 之前以后线程就曾经胜利获取某对象的锁，执行 wait 阻塞后以后线程就将之前获取的对象锁开释。

基本概念：

在 Java 中, 锁的概念都是基于对象的, 所以咱们又常常称它为 对象锁。线程和锁的关系, 咱们能够用婚姻关系来了解。一个锁同一时间只能被一个线程持有。也就是如果和一个线程“结婚”(持有), 那其余线程如果须要失去这个锁, 就得等这个线程和这个锁“离婚”(开释)

在咱们的线程之间, 有ー个同步的概念。什么是同步呢, 如果咱们当初有 2 位正在抄暑假作业答案的同学: 线程 A 和线程 B。当他们正在抄的时候, 老师忽然来批改了一些答案, 可能 A 和 B 最初写出的暑假作业就不ー样。咱们为了 AB 能写出 2 本雷同的暑假作业, 咱们就须要让老师先批改答案, 而后 A,B 同学再抄。或者 A,B 同学先抄完, 老师再批改答案。这就是线程 A, 线程 B 的线程同步。

了解为 线程之前的同步是依照肯定的程序执行的。为了可能达到线程的同步，咱们须要用锁进行实现。

    static  class  ThreadA implements  Runnable{

        @Override
        public void run() {for(int i=0;i<100;i++){System.out.println("ThreadA"+ i);
            }
        }

    }
    static  class ThreadB implements  Runnable{

        @Override
        public void run() {for(int i=0;i<100;i++){System.out.println("ThreadB"+ i);
            }
        }
    }

    public static void main(String[] args) {new Thread(new ThreadA()).start();
        new Thread(new ThreadB()).start();}

运行后果：能够发现的是对于 A 与 B 来说都是各自独立工作，也就谈不上咱们所说的两者之间进行通信的解决。

ThreadA8
ThreadA9
ThreadA10
ThreadA11
ThreadB0
ThreadA12

当初咱们要求 A 执行实现之后 B 才可能继续执行上来须要应用到 对象锁。

    private  static Object lock = new Object();
    static  class  ThreadA implements  Runnable{

        @Override
        public void run() {synchronized (lock)
            {for(int i=0;i<100;i++){System.out.println("ThreadA"+ i);
                }
            }

        }

    }
    static  class ThreadB implements  Runnable{

        @Override
        public void run() {synchronized (lock) {for (int i = 0; i < 100; i++) {System.out.println("ThreadB" + i);
                }
            }
        }
    }

    public static void main(String[] args) throws  InterruptedException{new Thread(new ThreadA()).start();
        Thread.sleep(100);
        new Thread(new ThreadB()).start();}

这里申明了一个名字为 lock 的对象锁。咱们在 ThreadA 和 Thread B 内须要同步的代码块里, 都是用 synchronized 关键字加上了同一个对象锁lock。

咱们说到了, 依据线程和锁的关系, 同一时间只有一个线程持有一个锁, 那么线程 B 就会等线程 A 执行实现后开释lock, 线程 B 能力取得锁lock

这里在主线程里应用 sleep 办法睡眠了 10 毫秒, 是为了避免线程 B 先失去锁因为如果同时 start, 线程 A 和线程 B 都是出于就绪状态, 操作系统可能会先让 B 运行。这样就会先输入 B 的内容, 而后 B 执行实现之后主动开释锁, 线程 A 再执行。

第一种办法是利用到锁的机制，然而在有的时候获取锁可能会耗费很多的工夫，而基于 Object 类的 wait 办法和notify 办法，notifyAll 办法多线程的告诉 / 期待机制正是解决锁问题的最好方法。

咱们晓得的是在同一时间外面，一个锁同一时刻是能是被一个线程所持有，当初假如 A 领有了这个锁，这个时候对于线程 B 来说是不可能获取到这个锁，然而线程 A 能够利用 lock.wait 办法来让本人处于期待的状态，这个时候，lock 就是相当于被开释。

这个时候线程 B 获取到锁并开始执行，能够在某一时刻外面应用到 lock.notify() 告诉之前持有锁然而进入到期待状态的 A，示意 A 能够不必期待了，能够持续向下执行

须要留神的是, 这个时候线程 B 并没有开释锁 lock, 除非线程 B 这个时候应用 Lock.wait()开释锁, 或者线程 B 执行完结自行开释锁, 线程 A 能力失去 lock 锁。

代码模仿实现：

  private  static Object lock = new Object();
    static  class  ThreadA implements  Runnable{

        @Override
        public void run() {synchronized (lock)
            {for(int i=0;i<10;i++){
                    try{System.out.println("ThreadA"+ i);
                        lock.notify();
                        lock.wait();} catch (InterruptedException e) {e.printStackTrace();
                    }
                }
                lock.notify();}

        }
    }
    static  class ThreadB implements  Runnable{

        @Override
        public void run() {synchronized (lock)
            {for(int i=0;i<10;i++){
                    try{System.out.println("ThreadB"+ i);
                        lock.notify();
                        lock.wait();} catch (InterruptedException e) {e.printStackTrace();
                    }
                }
                lock.notify();}

        }
    }
    public static void main(String[] args) throws  InterruptedException{new Thread(new ThreadA()).start();
        Thread.sleep(100);
        new Thread(new ThreadB()).start();}

输入后果：

在下面的栗子中线程 A 和线程 B 先打印出本人须要的货色，而后应用 notify() 办法叫醒另一个正在期待的线程，而后利用到wait() 办法让本人陷入期待，并开释锁。

来利用到关键字 volatile 来实现信号之间的通信。这里先来介绍以下次要的性能：

volatile关键字可能保障内存的可见性, 如果用 volatile关键字申明了一个在一个线程外面扭转了这个变量的值, 那其它线程是立马可见更改后的值的。

上面举一个小栗子来模仿对于信号量时候的线程之间的通信：

让线程 A 先输入 0，而后线程 B 输入 1，再让线程 A 输入 2 以此类推。

代码：

    static  volatile  int single = 0;
    static  class  ThreadA implements  Runnable{

        @Override
        public void run() {while(single<5){if(single % 2 ==0){System.out.println("ThreadA"+ single);
                    synchronized (this){single++;}
                }
            }
        }
    }
    static  class ThreadB implements  Runnable{

        @Override
        public void run() {while(single<5){if(single % 2 ==1){System.out.println("ThreadB"+ single);
                    synchronized (this){single++;}
                }
            }
        }
    }
    public static void main(String[] args) throws  InterruptedException{new Thread(new ThreadA()).start();
        Thread.sleep(100);
        new Thread(new ThreadB()).start();}

实现后果：

ThreadA0
ThreadB1
ThreadA2
ThreadB3
ThreadA4

join()办法是 Thread类的一个 实例办法 。它的作用是让以后线程陷入 期待状态, 等 join 的这个线程执行实现后, 再继续执行以后线程。

有时候, 主线程创立并启动了子线程, 如果子线程中须要进行大量的耗时运算, 主线程往往将早于子线程完结之前完结。

如果主线程想期待子线程执行结束后, 取得子线程中的解决完的某个数据, 就要用到 join 办法。

示例代码

    static  class  ThreadA implements  Runnable{

        @Override
        public void run() {
           try{System.out.println("我是子线程，我先睡一秒");
               Thread.sleep(1000);
               System.out.println("我是子线程，我实现了睡眠");
           }catch (InterruptedException e){e.printStackTrace();
           }
        }
    }

    public static void main(String[] args) throws  InterruptedException{Thread thread =new Thread(new ThreadA());
     thread.start();
    thread.join();
        System.out.println("标记");
        // 在为是应用到 jion 时候，现打印进去 标记，而后再打印线程信息。// 再应用到 join 之后 后行打印 线程信息 再打印 标记
    }

sleep 办法是 Thread类的一个静态方法。它的作用是让以后线程睡眠一段时间。它有这样两个办法·

Thread. sleep(long)
Thread.sleep(long, int)

同样, 查看源码 (JDK1.8) 发现, 第二个办法貌似只对第二个参数做了简略的解决, 没有准确到纳秒。实际上还是调用的第一个办法

这里须要强调一下 s leep 办法是不会开释以后的锁的, 而 wait 办法会。这也是最常见的一个多线程面试题, 在文章的下面有进行具体的剖析。

对于 Java 内存模型也叫做JMM，波及到关键字volatile, 这个关键字在前面会进行解说，这里能够参看如下文章,，其中有对内存模型进行具体介绍：Java 内存模型 volatile

在计算机执行程序时候，为了可能进步性能，编译器和处理器经常会对指令做从新排序解决，就是指令的重排序。

指令重排的条件

在单线程环境下不能改变程序的运行后果；
存在数据依赖关系的不容许重排序；
无奈通过 Happens-before 准则推到进去的，能力进行指令的重排序

编译器优化重排：编译器再不扭转单线程程序语义的前体下，能够重新安排语句的执行程序。
指令并行重排：才用到指令级并行基数来讲多条指令重叠执行，在不存在数据依赖（即后一个执行的语句无需依赖后面执行的语句的后果），处理器能够扭转语句对应的机器指令的执行程序。
内存零碎重排：因为处理器应用缓存和读写缓存冲区, 这使得加载 (load) 和存储 (store) 操作看上去可能是在乱序执行, 因为三级缓存的存在, 导致内存与缓存的数据同步存在时间差

指令重排能够保障串行语义统一, 然而没有任务保障多线程间的语义也统一。所以在多线程下, 指令重排序可能会导致一些问题。

一方面，咱们须要 JMM 给咱们提供一个弱小的内存模型来编写代码，同时另外一方面对于编译器和处理器来说心愿 JMM 对他们的束缚越少越好，这样就能够进行跟多的优化解决，也就是心愿是一个弱的内存模型。

于是对于 JMM 来说思考了这两种的需要：对于编译器和处理器来说：只有不改变程序的运行后果（单线程程序和正确同步了的多线程程序），编译器和处理器进行如何的优化都是可行的。

于是 JMM 提供了一个Happens-before（JSR-133 标准），来满足咱们在简略易懂的前提下，并且提供了足够强的内存可见性保障。

就是说对于这个规定来说，咱们只有是遵循了就可能保障其在 JMM 中具备强的内存可见性。

如果一个操作 happens-before 另一个操作, 那么第一个操作的执行后果将对第操作可见, 而且第一个操作的执行程序排在第二个操作之前
两个操作之间存在 happens-before 关系, 并不意味着 Java 平台的具体实现必须要依照 happens-before 关系指定的程序来执行。如果重排序之后的执行后果, 与按 happens- before 关系来执行的后果统一, 那么 JMM 也容许这样的重排序

在 Java 中, 有以下人造的 happens-before 关系：

程序程序规定: 一个线程中的每一个操作, happens-before 于该线程中的任意后续操作。·
监视器锁规定: 对一个锁的解锁, happens- before 于随后对这个锁的加锁。
volatile 变量规定: 对一个 volatile 域的写, happens- before 于任意后续对这个 volatile 域的读。
传递性: 如果 A happens- before b, 且 B happens-before C, 那么 A happensbefore c。
start 规定: 如果线程 A 执行操作 Thread. start0 启动线程 B, 那么 A 线程的 Thread B.stat0)操作 happens-before 于线程 B 中的任意操作
join 规定: 如果线程 A 执行操作 Thread join()并胜利返回, 那么线程 B 中的任意操作 happens-before 于线程 A 从 Thread join0 操作胜利返回。

as-if-serial 语义保障单线程内程序的执行后果不被扭转，happens-before 关系保障正确同步的多线程程序的执行后果不被扭转。
as-if-serial 语义给编写单线程程序的程序员发明了一个幻境：单线程程序是按程序的程序来执行的。happens-before 关系给编写正确同步的多线程程序的程序员发明了一个幻境：正确同步的多线程程序是按 happens-before 指定的程序来执行的。
as-if-serial 语义和 happens-before 这么做的目标，都是为了在不扭转程序执行后果的前提下，尽可能地进步程序执行的并行度。

在 Java 内存模型那一章咱们介绍了 JMM 有一个主内存, 每个线程有本人公有的工作内存, 工作内存中保留了一些变量在主內存的拷贝。

内存可见性, 指的是线程之间的可见性, 当一个线程批改了共享变量时, 另一个线程能够读取到这个批改后的值

为了优化程序性能，对原来有的指令执行程序进行优化从新排序。重排序可能产生在很多的阶段，比方编译重排序，CPU 从新排序

是一个给程序员应用的规定, 只有程序员在写代码的时候遵循 happens- before 规 JMM 就能保障指令在多线程之间的程序性合乎程序员的预期。

对于可见性，Java 提供了 volatile 关键字来保障 可见性 和禁止指令重排。volatile 提供 happens-before 的保障，确保一个线程的批改能对其余线程是可见的。当一个共享变量被 volatile 润饰时，它会保障批改的值会立刻被更新到主存，当有其余线程须要读取时，它会去内存中读取新值。

从实际角度而言，volatile 的一个重要作用就是和 CAS 联合，保障了原子性，具体的能够参见 java.util.concurrent.atomic 包下的类，比方 AtomicInteger。

Java 提供了 volatile 关键字来保障 可见性 和禁止指令重排。

volatile 提供 happens-before 的保障，确保一个线程的批改能对其余线程是可见的。当一个共享变量被 volatile 润饰时，它会保障批改的值会立刻被更新到主存，当有其余线程须要读取时，它会去内存中读取新值。
禁止指令的重排序功能。

1. 如果第一个操作是 volatile 读, 那无论第二个操作是什么, 都不能重排序

2. 如果第二个操作是 volatile 写, 那无论第一个操作是什么, 都不能重排序

3. 如果第一个操作是 volatile 写, 第二个操作是 volatile 读, 那不能重排序。

在 Java 中，synchronized 关键字是用来控制线程同步的，就是在多线程的环境下，管制 synchronized 代码段不被多个线程同时执行。synchronized 能够润饰类、办法、变量。

另外，在 Java 晚期版本中，synchronized 属于 重量级 锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。

如果要挂起或者唤醒一个线程，都须要操作系统帮忙实现，而操作系统实现线程之间的切换时须要从 用户态转换到内核态，这个状态之间的转换须要绝对比拟长的工夫，工夫老本绝对较高，这也是为什么晚期的 synchronized 效率低的起因。

庆幸的是在 Java 6 之后 Java 官网对从 JVM 层面对 synchronized 较大优化，所以当初的 synchronized 锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化，如 自旋锁 、 适应性自旋锁 、锁打消、 锁粗化 、 偏差锁 、 轻量级锁 等技术来缩小锁操作的开销。

synchronized 关键字最次要的三种应用形式：

润饰实例办法: 作用于以后对象实例加锁，进入同步代码前要取得以后对象实例的锁
润饰静态方法: 也就是给以后类加锁，会作用于类的所有对象实例，因为动态成员不属于任何一个实例对象，是类成员（static 表明这是该类的一个动态资源，不论 new 了多少个对象，只有一份）。所以如果一个线程 A 调用一个实例对象的非动态 synchronized 办法，而线程 B 须要调用这个实例对象所属类的动态 synchronized 办法，是容许的，不会产生互斥景象，因为拜访动态 synchronized 办法占用的锁是以后类的锁，而拜访非动态 synchronized 办法占用的锁是以后实例对象锁。
润饰代码块: 指定加锁对象，对给定对象加锁，进入同步代码库前要取得给定对象的锁。

总结：

synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。
synchronized 关键字加到实例办法上是给对象实例上锁。尽量不要应用 synchronized(String a) 因为 JVM 中，字符串常量池具备缓存性能！

public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {}

    public static Singleton getUniqueInstance() {
       // 先判断对象是否曾经实例过，没有实例化过才进入加锁代码
        if (uniqueInstance == null) {
            // 类对象加锁
            synchronized (Singleton.class) {if (uniqueInstance == null) {uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

另外，须要留神 uniqueInstance 采纳 volatile 关键字润饰也是很有必要。

uniqueInstance 采纳 volatile 关键字润饰也是很有必要的，uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：

为 uniqueInstance 分配内存空间
初始化 uniqueInstance
将 uniqueInstance 指向调配的内存地址

然而因为 JVM 具备指令重排的个性，执行程序有可能变成 1->3->2。指令重排在单线程环境下不会呈现问题，然而在多线程环境下会导致一个线程取得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因而返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。

应用 volatile 能够禁止 JVM 的指令重排，保障在多线程环境下也能失常运行。

同步块是更好的抉择，因为它不会锁住整个对象（当然你也能够让它锁住整个对象）。同步办法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们进行执行并须要期待取得这个对象上的锁。

同步块更要合乎凋谢调用的准则，只在须要锁住的代码块锁住相应的对象，这样从侧面来说也能够防止死锁。

请晓得一条准则：同步的范畴越小越好。

既然说到底层的实现原理，就未免要进行对代码的反编译解决，查看相应的字节码文件：

首先来看一个简略的实现：

public class sysDemo {public void method() {synchronized (this) {System.out.println("synchronized");
        }
    }
}

而后现进行编译成为 .class 文件：javac sysDemo.java。

再进行反编译：javap -v sysDemo

能够看到的是在执行同步代码块前后都有一个 monitor 字样，其中后面的是monitorenter，前面的是monitorexit.

于是咱们推断出：一个线程要执行同步代码块，首先要获取锁，而获取锁的过程就是 monitorenter 示意进入，在执行完代码块之后，要开释锁，开释锁就是执行monitorexit 指令。

为什么会有两个 monitorexit 呢？

这个次要是避免在同步代码块中线程因异样退出，而锁没有失去开释，这必然会造成死锁（期待的线程永远获取不到锁）。因而最初一个 monitorexit 是保障在异常情况下，锁也能够失去开释，防止死锁。
仅有 ACC_SYNCHRONIZED 这么一个标记，该标记表明线程进入该办法时，须要 monitorenter，退出该办法时须要 monitorexit。

重入锁是指一个线程获取到该锁之后，该线程能够持续取得该锁。底层原理保护一个计数器，当线程获取该锁时，计数器加一，再次取得该锁时持续加一，开释锁时，计数器减一，当计数器值为 0 时，表明该锁未被任何线程所持有，其它线程能够竞争获取锁。

Java8 为了減少取得锁和开释锁带来的性能耗费, 引入了“偏冋锁”和“轻量级锁“在 Java6 以前, 所有的锁都是”重量级“锁。所以在 Java6 及其当前对象其实有四种锁状态, 它们级别由低到高顺次是

1. 无锁状态

2. 偏差锁状态

3. 轻量级锁状态

4. 重量级锁状态

因为对于 java 中，其锁都是基于对象的，首先咱们来看一看一个对象的锁的信息都寄存在什么地位：

每个 Java 对象都有对象头。如果是非数组类型, 则用 2 个字宽来存储对象头, 如果是数组, 则会用 3 个字宽来存储对象头。在 32 位处理器中, 一个字宽是 32 位; 在 64 位虚拟机中, 一个字宽是 64 位。对象头的内容如下图：

次要来看对于 mark Word 中寄存的都是什么内容：

咱们发现在大多数的状况下，锁不仅存在多线程竞争，而且总是由同一个线程屡次获取到，于是就引入了偏差锁：

偏差锁会偏差于第一个拜访锁的线程, 如果在接下来的运行过程中, 该锁没有被其余的线程拜访, 则持有偏差锁的线程将永远不须要触发同步。也就是说, 偏差锁在资源无竞争状况下打消了同步语句, 连 CAS 操作都不做了, 进步了程序的运行性能

翻译过去就是说，咱们会对锁设置一个变量，若是发现是 true，代表资源没有竞争，就是说没有其余的线程想要来获取这个锁，就也不须要在增加各种的加锁 / 解锁的流程。然而若是 false 时候，代表存在其余线程来竞争资源，就才会进行前面的操作。

实现原理：

一个线程在第一次进入同步块时, 会在对象头和栈帧中的锁记录里存储锁的偏差的线程 |D。当下次该线程进入这个同步块时, 会去查看锁的 Mark Word 外面是不是放的本人的线程 ID。

如果是, 表明该线程曾经取得了锁, 当前该线程在进入和退出同步块时不须要破费 CAS 操作来加锁和解锁; 如果不是, 就代表有另一个线程来竟争这个偏差锁。这个时候会尝试应用 CAS 来替换 Mark Word!外面的线程 ID 为新线程的 ID, 这个时候要分两种状况:

胜利, 示意之前的线程不存在了, Mark Word 外面的线程 D 为新线程的 D, 锁不会降级, 依然为偏差锁.
失败, 示意之前的线程依然存在, 那么暂停之前的线程, 设置偏差锁标识为 0, 并设置锁标记位为 00, 降级为轻量级锁, 会依照轻量级锁的形式进行竞争锁

CAS: Compare and Swap

比拟并设置。用于在硬件层面上提供原子性操作。在 lnte 处理器中, 比拟并替换通过指令 cmpxchg实现。比拟是否和给定的数值统一, 如果统一则批改, 不统一则不批改。

多个线程在不同时间段获取到同一个把锁，即不存在锁竞争的状况，也就没有后续的线程阻塞。针对这种状况，JVM 采纳轻量级锁来防止线程的阻塞与唤醒。

轻量级加锁：

JVM 会为每个线程在以后线程的栈帧中创立用于存储锁记录的空间, 咱们称为Displaced Mark Word。如果一个线程取得锁的时候发现是轻量级锁, 会把锁的 Mark Word 复制到本人的 Displaced Mark Word 外面。

而后线程尝试用 CAS 将锁的 Mark Word 替换为指向锁记录的指针。如果胜利, 以后线程取得锁, 如果失败, 示意 Mark Word 曾经被替换成了其余线程的锁记录, 阐明在与其它线程竟争锁, 以后线程就尝试应用自旋来获取锁

自旋: 一直尝试去获取锁, 个别用循环来实现。

自旋是须要耗费 CPU 的, 如果始终获取不到锁的话, 那该线程就始终处在自旋状态, 白白浪费 CPU 资源。解决这个问题最简略的方法就是指定自旋的次数, 例如让其循环 10 次, 如果还没获取到锁就进入阻塞状态。

然而 JDK 采纳了更聪慧的形式——适应性自旋, 简略来说就是线程如果自旋胜利了, 则下次自旋的次数会更多, 如果自旋失败了, 则自旋的次数就会缩小。

自旋也不是始终进行上来的, 如果自旋到肯定水平(和 JVM、操作系统相干), 仍然没有获取到锁, 称为自旋失败, 那么这个线程会阻塞。同时这个锁就会升级成重量级锁。

轻量级开释

在开释锁时, 以后线程会应用 CAS 操作将 Displaced Mark Word 的内容复制回锁的 Mark Word 外面。如果没有产生竞争, 那么这个复制的操作会胜利。如果有其余线程因为自旋屡次导致轻量级锁升级成了重量级锁, 那么 CAS 操作会失败, 此时会开释锁并唤醒被阻塞的线程。

重量级锁依赖于操作系统的互斥量 (muteκ) 实现的, 而操作系统中线程间状态的转专换须要绝对比拟长的工夫, 所以重量级锁效率很低, 但被阻塞的线程不会耗费 CPU。

每一个线程在筹备获取共享资源时: 第一步, 查看 Mark Word外面是不是放的本人的 Threadld, 如果是, 示意以后线程是处于“偏差锁 ”。

第二步, 如果 Markward 不是本人的 Threadld, 锁降级, 这时候, 用 CAS 来执行切换, 新的线程依据 Mark Word 外面现有的 Threaded, 告诉之前线程暂停, 之前线程将 Markward 的内容置为空。

第三步, 两个线程都把锁对象的 Hashcode复制到本人新建的用于存储锁的记录空间, 接着开始通过 CAS 操作, 把锁对象的 Markward 的內容批改为本人新建的记录空间的地址的形式竞争 Markward。

第四步, 第三步中胜利执行 CAS 的取得资源, 失败的则进入自旋

第五步, 自旋的线程在自旋过程中, 胜利取得资源(即之前获的资源的线程执行实现并开释了共享资源), 则整个状态仍然处于轻量级锁的状态, 如果自旋失败

第六步, 进入重量级锁的状态, 这个时候, 自旋的线程进行阻塞, 期待之前线程执行实现并唤醒本人。

锁	长处	毛病	实用场景
偏差	加锁和解锁不须要额定的耗费, 和执行非同步办法比仅存在纳秒级的差距。	如果线程之间存在竞争，会带来额定的锁撤销的耗费	实用于只有一个线程拜访同步块场景
轻量级	竞争的线程恩不会阻塞，进步了程序的响应速度	如果始终得不到锁竞争的线程应用自旋会耗费 CPU	谋求相应工夫，同步块执行速度十分快
重量级	线程竞争不实用自旋，不会耗费 CPU	线程阻塞，相应工夫迟缓	谋求吞吐量，同步块执行速度较长

乐观锁又称为“无锁, 顾名思义, 它是 乐观派。

乐观锁总是假如对共享资源的拜访没有抵触, 线程能够不停地执行, 无需加锁也无需期待。而一旦多个线程发生冲突, 乐观锁通常是应用一种称为 CAS 的技术来保障线程执行的安全性于无锁操作中没有锁的存在, 因而不可能岀现死锁的状况, 也就是说 乐观锁天生免疫死锁

乐观锁就是咱们常说的锁。对于乐观锁来说, 它总是认为每次访问共享资源时会发生冲突, 所以必须对毎次数据操作加上锁, 以保障临界区的程序同一时间只能有一个线程在执行。

CAS 全称是比拟并替换“Compare And Swap”在 CAS 中，有三个值：

V: 要更新的值
E：预期的值
N：新值

比拟并替换的过程如下判断 V 是否等于 E, 如果等于, 将 V 的值设置为 N; 如果不等, 阐明曾经有其它线程更新了 V, 则以后线程放弃更新, 什么都不做。所以这里的预期值 E 实质上指的是“旧值”

当多个线程同时应用 cAS 操作一个变量时, 只有一个会胜出, 并胜利更新, 其余均会失败, 但失败的线程并不会被挂起, 仅是被告知失败, 并且容许再次尝试, 当然也容许失败的线程放弃操作

ABA 问题：

比如说一个线程 one 从内存地位 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且 two 进行了一些操作变成了 B，而后 two 又地位的数据变成 A，这时候线程 one 进行 CAS 操作发现内存中依然是 A，而后 one 操作胜利。只管线程 one 的 CAS 操作胜利，但可能存在潜藏的问题。

Java 并发包为了解决这个问题，提供了一个带有标记的原子援用类“AtomicStampedReference”，它能够通过管制变量值的版本来保障 CAS 的正确性。因而，在应用 CAS 前要思考分明“ABA”问题是否会影响程序并发的正确性，如果须要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。

循环工夫长，开销大

对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较大，从而浪费更多的 CPU 资源，效率低于 synchronized。

在一次操作过程中只能保障一个共享变量的准则操作

当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁来保障原子性。

即形象队列同步器：从字面上了解的意思是：

形象：抽象类，只实现了一些次要的逻辑，有些办法由子类来实现。
队列：应用先进先出（FIFO）队列来存储数据结构。
同步：实现了同步的性能

AQS 是一个用来构建锁和同步器的框架，应用 AQS 能简略且高效地结构出利用宽泛的大量的同步器，比方咱们提到的 ReentrantLock，Semaphore，其余的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask 等等皆是基于 AQS 的。当然，咱们本人也能利用 AQS 十分轻松容易地结构出合乎咱们本人需要的同步器。

AQS 核心思想是，如果被申请的共享资源闲暇，则将以后申请资源的线程设置为无效的工作线程，并且将共享资源设置为锁定状态。如果被申请的共享资源被占用，那么就须要一套线程阻塞期待以及被唤醒时锁调配的机制，这个机制 AQS 是用 CLH 队列锁实现的，行将临时获取不到锁的线程退出到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚构的双向队列（虚构的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条申请共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的调配。

AQS 的原理图：

AQS 应用一个 int 成员变量来示意同步状态，通过内置的 FIFO 队列来实现获取资源线程的排队工作。AQS 应用 CAS 对该同步状态进行原子操作实现对其值的批改。

private volatile int state;// 共享变量，应用 volatile 润饰保障线程可见性
1

状态信息通过 protected 类型的 getState，setState，compareAndSetState 进行操作

// 返回同步状态的以后值
protected final int getState() {return state;}
 // 设置同步状态的值
protected final void setState(int newState) {state = newState;}
// 原子地（CAS 操作）将同步状态值设置为给定值 update 如果以后同步状态的值等于 expect（期望值）protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
123456789101112

AQS 对资源的共享形式

AQS 定义两种资源共享形式

Exclusive（独占）：只有一个线程能执行，如 ReentrantLock。又可分为偏心锁和非偏心锁：
- 偏心锁：依照线程在队列中的排队程序，先到者先拿到锁
- 非偏心锁：当线程要获取锁时，忽视队列程序间接去抢锁，谁抢到就是谁的
Share（共享）：多个线程可同时执行，如 Semaphore/CountDownLatch。Semaphore、CountDownLatch、CyclicBarrier、ReadWriteLock。

ReentrantReadWriteLock 能够看成是组合式，因为 ReentrantReadWriteLock 也就是读写锁容许多个线程同时对某一资源进行读。

不同的自定义同步器争用共享资源的形式也不同。自定义同步器在实现时只须要实现共享资源 state 的获取与开释形式即可，至于具体线程期待队列的保护（如获取资源失败入队 / 唤醒出队等），AQS 曾经在顶层实现好了。

AQS 底层应用了模板办法模式

同步器的设计是基于模板办法模式的，如果须要自定义同步器个别的形式是这样（模板办法模式很经典的一个利用）：

使用者继承 AbstractQueuedSynchronizer 并重写指定的办法。（这些重写办法很简略，无非是对于共享资源 state 的获取和开释）
将 AQS 组合在自定义同步组件的实现中，并调用其模板办法，而这些模板办法会调用使用者重写的办法。

这和咱们以往通过实现接口的形式有很大区别，这是模板办法模式很经典的一个使用。

AQS 应用了模板办法模式，自定义同步器时须要重写上面几个 AQS 提供的模板办法：

isHeldExclusively()// 该线程是否正在独占资源。只有用到 condition 才须要去实现它。tryAcquire(int)// 独占形式。尝试获取资源，胜利则返回 true，失败则返回 false。tryRelease(int)// 独占形式。尝试开释资源，胜利则返回 true，失败则返回 false。tryAcquireShared(int)// 共享形式。尝试获取资源。正数示意失败；0 示意胜利，但没有残余可用资源；负数示意胜利，且有残余资源。tryReleaseShared(int)// 共享形式。尝试开释资源，胜利则返回 true，失败则返回 false。123456

默认状况下，每个办法都抛出 UnsupportedOperationException。这些办法的实现必须是外部线程平安的，并且通常应该简短而不是阻塞。AQS 类中的其余办法都是 final，所以无奈被其余类应用，只有这几个办法能够被其余类应用。

以 ReentrantLock 为例，state 初始化为 0，示意未锁定状态。A 线程 lock()时，会调用 tryAcquire()独占该锁并将 state+1。尔后，其余线程再 tryAcquire()时就会失败，直到 A 线程 unlock()到 state=0（即开释锁）为止，其它线程才有机会获取该锁。当然，开释锁之前，A 线程本人是能够反复获取此锁的（state 会累加），这就是可重入的概念。但要留神，获取多少次就要开释如许次，这样能力保障 state 是能回到零态的。

再以 CountDownLatch 以例，工作分为 N 个子线程去执行，state 也初始化为 N（留神 N 要与线程个数统一）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown()一次，state 会 CAS(Compare and Swap)减 1。等到所有子线程都执行完后 (即 state=0)，会 unpark() 主调用线程，而后主调用线程就会从 await()函数返回，持续后余动作。

一般来说，自定义同步器要么是独占办法，要么是共享形式，他们也只需实现 tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 AQS 也反对自定义同步器同时实现独占和共享两种形式，如ReentrantReadWriteLock。

首先

第一步应用到 acquire（int arg） 办法拿到这个线程的共享资源的状态这个状态是应用到 volatile 来润饰只有当获取到的 state 大于 0 的时候才示意获取锁是胜利的（重入一次就会加一开释一次状态就会减一）如果失败就会把以后线程包装成一个 node 节点放入到队列中（FIFO）

第二步：在当不可能获取到状态值大于 1 的时候示意没有胜利获取到锁这个时候就会放入到队列中应用到的是 addWaite办法将该线程包装成一个节点退出到队列中，若是退出到队列的尾部失败会看这个队列是否曾经初始化胜利若是胜利保障只有一个头结点是初始化胜利的没有胜利就应用 CAS 保障只用一个线程节点创立胜利最初应用 enq 办法有限自旋晓得 cas 胜利返回一个节点

第三步：在实现以上当前此时这个线程就会胜利退出到期待队列中而后进行挂起期待被唤醒。而后调用 boolean acquireQueued 先把锁标记为默认的 false 而后去判断以后节点的前置节点是不是头结点是头结点将应用到 sethead 设置成为头结点只用头结点才是 CPU 正在执行的线程节点

第四步：如果前置的节点不是头结点时候

 boolean shouldParkAfterFailedAcquire(Node pred, Node node)

获取到前驱节点的状态前置节点的 waitStatus 是Node.SIGNAL则返回 true，而后会执行 parkAndCheckInterrupt() 办法进行挂起此时若不是时候就会始终向后走直到走到一个最近的失常期待的状态而后排在她的前面

第五步：找到当前应用 park 进入劳动的状态有两种办法被唤醒一种是 unpark 一种是 interrupt

第六步：被唤醒当前看本人是否有资格可能拿到号示意可能进入运行的状态就是 head 指向以后节点。如果没有拿到就持续之前的操作

后面学习到的是 java 原生的锁——基于对象的锁。个别是配合关键字 synchronized 来应用。上面来学习于介绍位于 java.util.concurrent.locks 包下的几个其余的锁的类和接口

如果临界区是只读操作, 其实能够多线程一起执行, 但应用 synchronized 的话, 同一时间只能有一个线程执行·
synchronized 无奈晓得线程有没有胜利获取到锁
应用 synchronized, 如果临界区因为 IO 或者 sleep 办法等起因阻塞了, 而以后线程又没有开释锁, 就会导致所有线程期待。而这些都是 locks 包下的锁能够解决的。

可重入：就是说是一个反对从新进入的锁，也就是说这个锁反对一个线程对资源进行反复的加锁。

synchronized关键字就是应用的重入锁。比如说, 你在一个 synchronized实例办法外面调用另一个本实例的 synchronized实例办法, 它能够从新进入这个锁, 不会呈现任何异样。

不可反复：就是不反对反复进入的锁。不反对一个线程对资源进行反复的加锁。

ReentrantLock 就是可重入锁的代表

这里的“偏心”, 其实艰深意义来说就是“先来后到 ”, 也就是 FIFO。如果对一个锁来说, 先对锁获取申请的线程肯定会先被满足, 后对锁获取申请的线程后被满足, 那这个锁就是偏心的。

反之, 那就是不偏心的。个别状况下,非偏心锁能晋升肯定的效率。然而非偏心锁可能会产生线程饥饿 (有些线程长时间得不到锁) 的状况。所以要依据理论的需要来抉择非偏心锁和偏心锁

ReentrantLock 反对非偏心锁于偏心锁两种

具体详解（图片起源网络）：

如上能够看出偏心锁与非偏心锁的区别所在。
为什么效率有差异性：对于偏心锁来说，起初的线程要加上锁，即便锁处于闲暇的状态，也要检测是否还有其余的线程在期待中，如果有其余的线程还在期待，就挂起本人，而后加到队列的前面，而后唤醒的也是位于队列最后面的锁。在这样的状况下，例如一个新来的线程，在还有线程在期待时候，遇到即便锁处于闲暇的状态，然而本人却不可能进行执行，先要挂起而后唤醒，然而对于一个非偏心锁来说，少了这么一次的挂起与唤醒就会间接开始执行。

对于 synchronized用的锁和 Reentrantlock, 其实都是“排它锁 ”。也就是说, 这些锁在同一时刻只容许一个线程进行拜访而读写锁能够再同一时刻容许多个读线程拜访。

Java 提供了 Reentrantreadwritelock 类作为读写锁的默认实现, 外部保护了两个锁读锁, 一个写锁。通过拆散读锁和写锁, 使得在“读多写少 ” 的环境下, 大大地进步了

性能留神, 即应用读写锁, 在写线程拜访时, 所有的读线程和其它写线程均被阻塞

ReentrantLock 重入锁，是实现 Lock 接口的一个类，也是在理论编程中应用频率很高的一个锁，反对重入性，示意可能对共享资源可能反复加锁，即以后线程获取该锁再次获取不会被阻塞。

在 java 关键字 synchronized 隐式反对重入性，synchronized 通过获取自增，开释自减的形式实现重入。与此同时，ReentrantLock 还反对偏心锁和非偏心锁两种形式。那么，要想完完全全的弄懂 ReentrantLock 的话，次要也就是 ReentrantLock 同步语义的学习：1. 重入性的实现原理；2. 偏心锁和非偏心锁。

重入性的实现原理

要想反对重入性，就要解决两个问题：

1. 在线程获取锁的时候，如果曾经获取锁的线程是以后线程的话则间接再次获取胜利；

2. 因为锁会被获取 n 次，那么只有锁在被开释同样的 n 次之后，该锁才算是齐全开释胜利。

ReentrantLock 反对两种锁：偏心锁 和非偏心锁 。 何谓公平性，是针对获取锁而言的，如果一个锁是偏心的，那么锁的获取程序就应该合乎申请上的相对工夫程序，满足 FIFO。

是 ReadWriteLock 接口的 JDK 默认实现，与 ReentrantLock 的性能相似，同样是可重入的，反对偏心锁与非偏心锁，不同的是还能够反对“读写锁”

synchronized 示意只有一个线程能够获取作用对象的锁，执行代码，阻塞其余线程。

volatile 示意变量在 CPU 的寄存器中是不确定的，必须从主存中读取。保障多线程环境下变量的可见性；禁止指令重排序。

区别

volatile 是变量修饰符；synchronized 能够润饰类、办法、变量。
volatile 仅能实现变量的批改可见性，不能保障原子性；而 synchronized 则能够保障变量的批改可见性和原子性。
volatile 不会造成线程的阻塞；synchronized 可能会造成线程的阻塞。
volatile 标记的变量不会被编译器优化；synchronized 标记的变量能够被编译器优化。
volatile 关键字 是线程同步的 轻量级实现 ，所以volatile 性能必定比 synchronized 关键字要好。然而volatile 关键字只能用于变量而 synchronized 关键字能够润饰办法以及代码块。synchronized 关键字在 JavaSE1.6 之后进行了次要包含为了缩小取得锁和开释锁带来的性能耗费而引入的偏差锁和轻量级锁以及其它各种优化之后执行效率有了显著晋升， 理论开发中应用 synchronized 关键字的场景还是更多一些。

类别	synchronized	lock
存在的档次来说	java 的关键字存在于 jvm 层面下面	是一个类
锁的开释	对于 synchronized 来说其是能够自行进行开释的而且在线程产生异样的时候也是会呈现锁的开释	对于 lock 不会对锁进行被动的开释须要咱们在 try catch 语句中进行捕获在 finally 外面进行开释
锁的获取	若是 a 占用了所锁并呈现了阻塞的状况的时候线程 b 就会始终处于期待的状态	对于 lick 来说有多重获取锁的办法并不必始终处于期待的状态
锁状态的判断	无奈判断锁的状态	能够对锁的状态进行判断
性能	大量同步	大量同步

（1）synchronized 是乐观锁，属于抢占式，会引起其余线程阻塞。

（2）volatile 提供多线程共享变量可见性和禁止指令重排序优化。

（3）CAS 是基于冲突检测的乐观锁（非阻塞）

synchronized 是和 if、else、for、while 一样的关键字，ReentrantLock 是类，这是二者的本质区别。既然 ReentrantLock 是类，那么它就提供了比 synchronized 更多更灵便的个性，能够被继承、能够有办法、能够有各种各样的类变量

synchronized 晚期的实现比拟低效，比照 ReentrantLock，大多数场景性能都相差较大，然而在 Java 6 中对 synchronized 进行了十分多的改良。

相同点：两者都是可重入锁

两者都是可重入锁。“可重入锁”概念是：本人能够再次获取本人的外部锁。比方一个线程取得了某个对象的锁，此时这个对象锁还没有开释，当其再次想要获取这个对象的锁的时候还是能够获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增 1，所以要等到锁的计数器降落为 0 时能力开释锁。

次要区别如下：

ReentrantLock 应用起来比拟灵便，然而必须有开释锁的配合动作；
ReentrantLock 必须手动获取与开释锁，而 synchronized 不须要手动开释和开启锁；
ReentrantLock 只实用于代码块锁，而 synchronized 能够润饰类、办法、变量等。
二者的锁机制其实也是不一样的。ReentrantLock 底层调用的是 Unsafe 的 park 办法加锁，synchronized 操作的应该是对象头中 mark word

Java 中每一个对象都能够作为锁，这是 synchronized 实现同步的根底：

一般同步办法，锁是以后实例对象
动态同步办法，锁是以后类的 class 对象
同步办法块，锁是括号外面的对象

阻塞队列（BlockingQueue）是一个反对两个附加操作的队列。这两个附加的操作反对阻塞的插入和移除办法。

反对组塞的插入方法：意思是当队列满的时候，队列会组塞插入元素的线程，直到队列不满。
反对阻塞的移除办法：意思是在队列为空时，获取元素的线程会期待队列变为非空。

组塞队列罕用于生产者和消费者的场景，生产者是向队列外面增加元素的线程，消费者是从队列中取元素的线程
#### 不可用时候的解决
❑ 抛出异样：当队列满时，如果再往队列里插入元素，会抛出 IllegalStateException（”Queuefull”）异样。当队列空时，从队列里获取元素会抛出 NoSuchElementException 异样。
❑ 返回非凡值：当往队列插入元素时，会返回元素是否插入胜利，胜利返回 true。如果是移除办法，则是从队列里取出一个元素，如果没有则返回 null。
❑ 始终阻塞：当阻塞队列满时，如果生产者线程往队列里 put 元素，队列会始终阻塞生产者线程，直到队列可用或者响应中断退出。当队列空时，如果消费者线程从队列里 take 元素，队列会阻塞住消费者线程，直到队列不为空。
❑ 超时退出：当阻塞队列满时，如果生产者线程往队列里插入元素，队列会阻塞生产者线程一段时间，如果超过了指定的工夫，生产者线程就会退出。

留神：如果是无界组塞队列，队列不可能会呈现满的状况，所以应用 put 和 offer 办法永远不会被阻塞，而且应用 offer 办法的时候，该办法永远返回的都是 true
### 阻塞队列的类型
提供了七个组塞队列：
❑ ArrayBlockingQueue：一个由数组构造组成的有界阻塞队列。

是一个用数组实现的有界阻塞队列。此队列依照先进先出（FIFO）的准则对元素进行排序，默认状况下不保障线程偏心拜访队列
❑ LinkedBlockingQueue：一个由链表构造组成的有界阻塞队列。
是一个用链表实现的有界阻塞队列。此队列的默认和最大长度为 Integer.MAX_VALUE。此队列依照先进先出的准则对元素进行排序。
❑ PriorityBlockingQueue：一个反对优先级排序的无界阻塞队列。
是一个反对优先级的无界阻塞队列。默认状况下元素采取天然程序升序排列。也能够自定义类实现 compareTo()办法来指定元素排序规定，或者初始化 PriorityBlockingQueue 时，指定结构参数 Comparator 来对元素进行排序。须要留神的是不能保障同优先级元素的程序。
❑ DelayQueue：一个应用优先级队列实现的无界阻塞队列。
DelayQueue 是一个反对延时获取元素的无界阻塞队列。队列应用 PriorityQueue 来实现。队列中的元素必须实现 Delayed 接口，在创立元素时能够指定多久能力从队列中获取以后元素。只有在提早期满时能力从队列中提取元素

DelayQueue 十分有用，能够将 DelayQueue 使用在以下利用场景。
❑ 缓存零碎的设计：能够用 DelayQueue 保留缓存元素的有效期，应用一个线程循环查问 DelayQueue，一旦能从 DelayQueue 中获取元素时，示意缓存有效期到了。
❑ 定时任务调度：应用 DelayQueue 保留当天将会执行的工作和执行工夫，一旦从 DelayQueue 中获取到工作就开始执行，比方 TimerQueue 就是应用 DelayQueue 实现的。

❑ SynchronousQueue：一个不存储元素的阻塞队列。
SynchronousQueue 是一个不存储元素的阻塞队列。每一个 put 操作必须期待一个 take 操作，否则不能持续增加元素。它反对偏心拜访队列。默认状况下线程采纳非公平性策略拜访队列
❑ LinkedTransferQueue：一个由链表构造组成的无界阻塞队列。
是一个由链表构造组成的无界阻塞 TransferQueue 队列。绝对于其余阻塞队列，LinkedTransferQueue 多了 tryTransfer 和 transfer 办法。

transfer 办法

如果以后有消费者正在期待接管元素（消费者应用 take()办法或带工夫限度的 poll()办法时），transfer 办法能够把生产者传入的元素立即 transfer（传输）给消费者。如果没有消费者在期待接管元素，transfer 办法会将元素寄存在队列的 tail 节点，并等到该元素被消费者生产了才返回。transfer 办法的要害代码如下。

Node pred =tryAppend(s,haveData);
return awaitMatch(s,pred,e,(how==TIMED),nanos);

第一行代码是试图把寄存以后元素的 s 节点作为 tail 节点。第二行代码是让 CPU 自旋期待消费者生产元素。因为自旋会耗费 CPU，所以自旋肯定的次数后应用 Thread.yield()办法来暂停以后正在执行的线程，并执行其余线程。

tryTransfer 办法

tryTransfer 办法是用来试探生产者传入的元素是否能间接传给消费者。如果没有消费者期待接管元素，则返回 false。和 transfer 办法的区别是 tryTransfer 办法无论消费者是否接管，办法立刻返回，而 transfer 办法是必须等到消费者生产了才返回。
#### LinkedBlockingDeque：一个由链表构造组成的双向阻塞队列。
LinkedBlockingDeque 是一个由链表构造组成的双向阻塞队列。所谓双向队列指的是能够从队列的两端插入和移出元素。双向队列因为多了一个操作队列的入口，在多线程同时入队时，也就缩小了一半的竞争。相比其余的阻塞队列，LinkedBlockingDeque 多了 addFirst、addLast、offerFirst、offerLast、peekFirst 和 peekLast 等办法，以 First 单词结尾的办法，示意插入、获取（peek）或移除双端队列的第一个元素。以 Last 单词结尾的办法，示意插入、获取或移除双端队列的最初一个元素。另外，插入方法 add 等同于 addLast，移除办法 remove 等效于 removeFirst。然而 take 办法却等同于 takeFirst，不晓得是不是 JDK 的 bug，应用时还是用带有 First 和 Last 后缀的办法更分明。

办法名称	形容
void await throw InterruptedException	以后线程进入到期待状态直到应用以后线程来调用 signal 或中断以后线程就能够来进入到运行的状态并且从 await 中返回返回还有可能是应用到 interrupt（）办法中断以后线程。如果以后线程可能从 await 中返回示意曾经获取到 condition 对象锁对应的锁
signal	唤醒一个期待在 Condition 上的线程该线程从期待办法返回前必须取得与 Condition 相关联的锁。

上面了解到了具体的实现局部咱们来实现一个阻塞队列。


import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class block {private List<Integer> container =new ArrayList<>();
    private  volatile  int size;
    private  volatile  int capacity;
    private Lock lock=new ReentrantLock();

    private final Condition isnull =lock.newCondition();
    private final Condition isfull =lock.newCondition();
    zuse(int cap){this.capacity=cap;}
    public void add(int data){
        try{lock.lock();
            try{while(size>=capacity){System.out.println("阻塞队列满了");
                 isfull.await();// 此时若是队列满的时候 增加的 add 就会被阻塞起来 为满就期待}
            }
            catch (InterruptedException e){isfull.signal();
                // 示意呈现了异样 就会将其唤醒
                e.printStackTrace();}
            ++size;
            container.add(data);
            // 示意的是 对于 减少数据到外面时候 告诉 isnull 唤醒其其中的对象 能够进行数据的取用。isnull.signal();}finally {lock.unlock();
        }
    }
    public  int take(){
        try{lock.lock();
            try{while(size==0){System.out.println("阻塞队列处于空的状态");
                    isnull.await();}
            }
            catch (InterruptedException e){isnull.signal();
                e.printStackTrace();}
            --size;
            int res=container.get(0);
            container.remove(0);
            isfull.signal();// 示意又将数据取了进来 对于 退出又能够进行工作 而后 唤醒
            return  res;
        }
        finally {lock.unlock();
        }
    }
    public static void main(String[] args) {zuse queue=new zuse(5);
        Thread t1=new Thread(()->{for(int i=0;i<100;i++){queue.add(i);
               System.out.println("退出"+i);
               try{Thread.sleep(500);
               }catch (InterruptedException e){e.printStackTrace();
               }
           }
        });
        Thread t2=new Thread(()->{for(;;){System.out.println("生产"+ queue.take());
                try{Thread.sleep(500);
                }catch (InterruptedException e){e.printStackTrace();
                }
            }
        });
t1.start();
t2.start();}
}

线程本地变量，也叫作 线程的本地存储而言 ：作用是对于那些私有的变量，有时候会被很多的线程拜访，这个时候就是会呈现线程平安的问题，并且因为应用到 synchronized 关键字进行润饰时候并发水平会很低，不可能满足于日常的应用。于是应用threadlocal 来保护变量为每一个变量在应用该变量的线程外面提供一个独立的变量正本。
### 特点
1. 对于每一个线程而言都有一个属于本人的ThreadLocalMap，能够将线程本人的对象保留到其中，各管各的，这样就能够正确拜访到本人的对象。

将一个专用的 ThradLocal 动态实例作为 key，将不同对象的援用保留到不同线程的 TheadlocalMap 中，而后在线程执行的各处通过这个动态的 ThreadLocal 实例的 get()办法获取得道本人线程保留的那个对象，防止了将这个对象最为参数传递的麻烦，也就防止对这个值进行间接更改的麻烦。
其实这个 ThreadLocalMap 就是线程外面的一个对象，也是 ThreadLocal 外面的一个外部类。在Thrad 类中进行定义

ThreadLocal.ThreadLocalMop threadLocals =null;

每一个 ThreadLocal 对象都有一个惟一的 ID
在咱们拜访 ThreadLocal 中的变量的时候，利用这个惟一的值去本地线程 ThreadLocalMap 中查找对应的值

### 具体应用（源码解析）

/**
    * Sets the current thread's copy of this thread-local variable
    * to the specified value.  Most subclasses will have no need to
    * override this method, relying solely on the {@link #initialValue}
    * method to set the values of thread-locals.
    *
    * @param value the value to be stored in the current thread's copy of
    *        this thread-local.
    */
   public void set(T value) {
       /// 能够看到在 ThreadLocal 创立的时候，是获取到了以后线程 t，而后获取线程 t 的本地存储 ThreadLcoalMap, 而后对 map 进行操作, 看 map 是否存在。Thread t = Thread.currentThread();
       ThreadLocalMap map = getMap(t);
       if (map != null)
       // map 存在时候 将 key 为此以后线程 value 为想要放入的值
           map.set(this, value);
       else
       /// 当然如果以后线程还没有创立过 ThreadLocalMap，则创立 Map
           createMap(t, value); /// 创立 Map 的过程 看下边 ThreadLocalMap 中办法。}

#### get 办法

/**
    * Returns the value in the current thread's copy of this
    * thread-local variable.  If the variable has no value for the
    * current thread, it is first initialized to the value returned
    * by an invocation of the {@link #initialValue} method.
    *
    * @return the current thread's value of this thread-local
    */
   public T get() {Thread t = Thread.currentThread();
       ThreadLocalMap map = getMap(t);
       /// 同样是获取到了线程外部的援用 map 对象，通过 map 外部 getEntry 办法 获取到该 ThreadLocal 对应的对象 Entry 
       if (map != null) {ThreadLocalMap.Entry e = map.getEntry(this);
           if (e != null) {@SuppressWarnings("unchecked")
               T result = (T)e.value;
               return result;
           }
       }
       // 如果没有，默认为 null，所以在没有 set 而且没有重写 initialValue 办法的话，获取到的值就是 null。return setInitialValue();}

   /**
    * Variant of set() to establish initialValue. Used instead
    * of set() in case user has overridden the set() method.
    *
    * @return the initial value
    */
   private T setInitialValue() {T value = initialValue();
       Thread t = Thread.currentThread();
       ThreadLocalMap map = getMap(t);
       if (map != null)
           map.set(this, value);
       else
           /// 如果还没有该 map，则应用以后初始值来创立。默认为 null 和初始的创立是雷同的。createMap(t, value);
       return value;
   }

    /**
    * 返回为以后线程创立的初始化值应用，个别在 get 办法中调用和 remove 办法后 get 调用，* 如果应用能够通过外部类继承而后重写该办法即可。*
    * @return the initial value for this thread-local
    */
   protected T initialValue() {return null;}

   /**
    * Get the map associated with a ThreadLocal. Overridden in
    * InheritableThreadLocal.
    * 获取到 Thread 的外部的 ThreadLocalMap 类的援用对象 threadLcoals 
    * @param  t the current thread
    * @return the map
    */
   ThreadLocalMap getMap(Thread t) {return t.threadLocals;}

#### remove 办法

/**
    * Removes the current thread's value for this thread-local
    * variable.  If this thread-local variable is subsequently
    * {@linkplain #get read} by the current thread, its value will be
    * reinitialized by invoking its {@link #initialValue} method,
    * unless its value is {@linkplain #set set} by the current thread
    * in the interim.  This may result in multiple invocations of the
    * {@code initialValue} method in the current thread.
    *
    * @since 1.5
    */
    public void remove() {ThreadLocalMap m = getMap(Thread.currentThread());
        if (m != null)
            m.remove(this);
    }
    
      /**
        * Remove the entry for key.
        这里的 entry 类型的数组对象会在前面讲到 是如何建设的，这里也就是简略的移除 也就不必大费周章去解说了
        */
       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;
               }
           }
       }

说起 ThreadLocal 与 Thread 的关系，借用 Java 编程思维中对线程本地存储的定义，避免工作在共享资源上产生抵触的第二种形式是铲除对变量的共享。线程本地存储是一种自动化机制，能够为应用雷同变量的每个不同的线程都创立不同的存储。简略了解一下就是 Thread 上的 LocalVariables 了，既然如此就进入 Thread 源码看一下。很显著就找到了相干援用。

/* Thread 中援用了 ThreadLocal.ThreadLocalMap  很显著一线程中能够搁置很多变量 , 这个 Map 能够在 ThreadLocal 中保护  */
   ThreadLocal.ThreadLocalMap threadLocals = null;

   /*
    * InheritableThreadLocal 可继承的 ThreadLcoal
    这个 Map 能够在 ThreadLocal 中保护
    */
   ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;

后面讲到了在 set 与 get 过程中都有用到 ThreadLocalMap 上面也从具体的办法中进行了解：
### 根底的构造
继承自弱利用 WeakReference，应用了泛型 ThreadLocal

 /**
    * 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;
       }
   }

在 ThreadLocal 的 set办法中，若是对应的 map 不存在，示意此线程时第一次执行 set 办法，就须要咱们保护一个 Entry 类型的 table

  /**
     * Create the map associated with a ThreadLocal. Overridden in
     * InheritableThreadLocal.
     *
     * @param t the current thread
     * @param firstValue value for the initial entry of the map
     */
    void createMap(Thread t, T firstValue) {t.threadLocals = new ThreadLocalMap(this, firstValue);
    }

    /**
     * Construct a new map initially containing (firstKey, firstValue).
     * ThreadLocalMaps are constructed lazily, so we only create
     * one when we have at least one entry to put in it.
     */
    ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
        /// 创立一个线性 table，Entry 为 item，初始化 INITIAL_CAPACITY 默认为 16 个
        table = new Entry[INITIAL_CAPACITY];
        /// 计算出第一个 key 的索引 i
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        /// 初始化 并设置 size 值
        table[i] = new Entry(firstKey, firstValue);
        size = 1;
        /// 同时 设置容器大小的临界值，并传入初始化大小。setThreshold(INITIAL_CAPACITY);
    }

/**
    * Get the entry associated with key.  This method
    * itself handles only the fast path: a direct hit of existing
    * key. It otherwise relays to getEntryAfterMiss.  This is
    * designed to maximize performance for direct hits, in part
    * by making this method readily inlinable.
    * /// 通过 Key 的 hash 值来创立其对应的索引值，找到 entry 
    *
    * @param  key the thread local object
    * @return the entry associated with key, or null if no such
    */
   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
           /// 如果没有在间接的 table 线性表中找到的话。return getEntryAfterMiss(key, i, e);
   }

能够看进去的是也是会思考到哈希碰撞的问题，因为在 set 值的过程中可能会呈现在对于一个线程来说，一个节点下面会对应两个值，个别会取（key 的 hashcode 的值 & table.length-1）获取一个数组的地位，将其放入到该节点的地位。这里相当于是一个逆运算，间接取到该节点上的值。
上面来具体解说一个对于 hash 碰撞是如何应用 getEntryAfterMiss 办法来解决：

/**
         * Version of getEntry method for use when key is not found in
         * its direct hash slot.
         *
         * @param  key the thread local object
         * @param  i the table index for key's hash code
         * @param  e the entry at table[i]
         * @return the entry associated with key, or null if no such
         */
        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;
                    // 如果 k 为空的间接从链表中擦除 不便 GC 进行回收
                if (k == null)
                    expungeStaleEntry(i);
                else
                // 循环找到下一个 index
                    i = nextIndex(i, len);
                e = tab[i];
            }
            return null;
        }

    /**
     * Set the value associated with key.
     *
     * @param key the thread local object
     * @param value the value to be set
     */
    private void set(ThreadLocal<?> key, Object value) {// We don't use a fast path as with get() because it is at
        // least as common to use set() to create new entries as
        // it is to replace existing ones, in which case, a fast
        // path would fail more often than not.

        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)]) {ThreadLocal<?> k = e.get();

            // 如果键和传入的键雷同 则笼罩
            if (k == key) {
                e.value = value;
                return;
            }

            if (k == null) {replaceStaleEntry(key, value, i);
                return;
            }
        }

        tab[i] = new Entry(key, value);
        int sz = ++size;
          // 如果数组中没有冗余的 null 值并且如果 size 大于临界值
        if (!cleanSomeSlots(i, sz) && sz >= threshold)
            /// 进行扩容，这里就不再进行解释如何扩容了。rehash();}

    /**
     * Remove the entry for key.
     */
    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();
                // 置空，以便 GC 回收
                expungeStaleEntry(i);
                return;
            }
        }
    }

通过下面理解到了 ThreadLocalMap 的援用以及 get 和 set 的问题，此时就呈现了一个问题如何保障每个线程中援用 ThreadLocalMap 中创立的 ThreadLocal 是惟一的，并且进行高效的存取就成了一个至关重要的问题。
咱们会发现对于下面所讲到的 set 和 get 办法都有用到threadLocalHashCode 其实这里的散列的办法和 HashMap1 的相似。然而这个的 Hash key 生成器不是 ThreadLocal 对象的 Hash 值，而是从 0 开始的 AtomicInteger 通过 getAndAdd HASH_INCREMENT 来生成的

   /**
     * The next hash code to be given out. Updated atomically. Starts at
     * zero.
     */
    private static AtomicInteger nextHashCode =
        new AtomicInteger();

    /**
     * The difference between successively generated hash codes - turns
     * implicit sequential thread-local IDs into near-optimally spread
     * multiplicative hash values for power-of-two-sized tables.
     */
    private static final int HASH_INCREMENT = 0x61c88647;

    /**
     * Returns the next hash code.
     */
    private static int nextHashCode() {return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

这样就保障了每一个 ThreadLocal 的对象都有一个惟一的 ID 信息

对于为什么要应用

0x61c88647 这里具体解说的大略是黄金分割比例与斐波那契数列的相干内容，为了可能让生成的 hashcode 尽可能的散布在大小为 2 的 N 次方的数组外面具体解说

首先对于咱们来说，ThreadLocal 并不是用来解决共享变量的多线程的拜访，而是说通过 ThreadLocal.set()到线程中的对象是该线程本人应用的对象，其余线程时不可能拜访到的，各个线程拜访到的是不同的对象。另外说，ThreadLocal 使得各个线程可能放弃各自独立的对象，并不是通过 set() 办法来实现的，而是通过每个线程中的 new 对象的操作来创立的对象，每个线程创立一个，不是什么对象的拷贝或正本。通过 Thr.srt()将这个新创建的对象的援用保留到各线程的本人的 map 中，每个线程都有这样属于本人的 mao，执行 get() 办法的时候，各线程从本人的 map 中取出放进去的对象。因而取出的是各自本人线中的对象。ThreadLocal 实例是最为 map 的 key 来应用

如何应用 ThreadLocal 为每一个线程创立变量的正本：

首先在每个线程 Thread 外部有一个 ThreadLocal。ThreadLocalMap 类型的成员变量 threadLocals，这个 threadLocals 就是用来存储理论变量的正本的，键值为以后 ThreadLocal 变量，value 为变量的正本（即 T 类型的变量）
初始时，在 Thread 外面，threadLocals 为空，当通过 ThreadLocal 变量调用 get()办法或者 set()办法，就会对 Thread 类中的 threadLocals 进行初始化，并且以以后 ThreadLocal 变量为键值，以 ThreadLocal 要保留的正本变量为 value，存到 threadLocals。
为什么 ThreadLocals 的类型 ThreadLocalMap1 的键值为 ThreadLocal 对象，是因为每个线程中可有多个 threadLocal 变量，就是说能够应用 ThreadLocal 创立多个实例变量。
咱们在应用到 get 之前必须先试用到 set，否则会呈现空指针异样：

能够应用到数据库的连贯和 Session 治理等。


private static ThreadLocal<Connection> connectionHolder
= new ThreadLocal<Connection>() {public Connection initialValue() {return DriverManager.getConnection(DB_URL);
}
};
public static Connection getConnection() {return connectionHolder.get();
}

Session 治理


private static final ThreadLocal threadSession = new ThreadLocal();
 
public static Session getSession() throws InfrastructureException {Session s = (Session) threadSession.get();
    try {if (s == null) {s = getSessionFactory().openSession();
            threadSession.set(s);
        }
    } catch (HibernateException ex) {throw new InfrastructureException(ex);
    }
    return s;
}

总的来说对于 ThreadLocal 的理解还不算是很粗浅，次要是对于多线程本人应用到的太少太少了多线程要多加实际

非线程平安：多个线程同时对对象中的同一个实例变量进行操作时会呈现值被更改，值不同步的状况，进而影响程序的执行流程。

线程平安：是多线程在拜访时候，采纳加锁机制，当一个线程拜访某个类的数据的时候对其进行爱护，其余线程不能拜访该线程直到该线程读取实现当前其余的线程能力对其进行拜访不会呈现数据的不一致性或则数据净化。

区别：非线程平安是指多线程操作同一个对象可能会呈现问题，而线程平安则是多线程在操作同一个对象的时候不会呈现问题。对于线程的平安是通过线程同步控制来实现的也就是 synchronized 非线程平安是通过异步实现

死锁：是指两个或两个以上的进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。

四个必要的条件：

1、互斥条件 ：所谓互斥就是进程在某一时间内独占资源。
2、 请求与保持条件 ：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
3、 不剥夺条件 : 进程已获得资源，在末使用完之前，不能强行剥夺。
4、 循环等待 条件 : 若干进程之间形成一种头尾相接的循环等待资源关系。
活锁：任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试，
失败，尝试，失败。

区别：处于活锁的实体是在不断的改变状态，所谓的“活”，而处于死锁的实体表现为等待；活锁有可能自行解开，死锁则不能。

一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行的状态。
Java 中导致饥饿的原因：
1、高优先级线程吞噬所有的低优先级线程的 CPU 时间。
2、线程被永久堵塞在一个等待进入同步块的状态，因为其他线程总是能在它之前
持续地对该同步块进行访问。
3、线程在等待一个本身也处于永久等待完成的对象 (比如调用这个对象的 wait 方
法 )，因为其他线程总是被持续地获得唤醒。
5、Java 中用到的线程调度算法是什么？
采用时间片轮转的方式。可以设置线程的优先级，会映射到下层的系统上面的优
先级上，如非特别需要，尽量不要用，防止线程饥饿

首先明确什么是上下文；
对于每个工作运行前，CPU 都须要晓得工作是从哪里加载的，又是从哪里开始运行的，就波及到 CPU 寄存器和 程序计数器。

cpu 的寄存器是 cpu 中内置容量小，然而速度较快的内存。
程序计数器是会存储 cpu 正在执行令的地位或是行将执行的指令的地位。

将以后 cpu 的上下文（就是说 cpu 寄存器和程序计数器外面的内容）保存起来。
而后加载新工作的上下文 cpu 寄存器和程序计数器。
最初跳到程序计数所指向的地位运行新工作。
被保存起来的上下文会存储到零碎的内核中期待工作从新调度指向时候再次加载进来。、

上下文切换分为线程过程和中断上下文。

线程是调度的根本单位，而过程则是资源进行调配和领有的根本单位。
内核中的工作的调度其实是在调度线程，过程只是给线程提供虚构的内存全局变量等资源。线程在进行上下文的切换的时候共享雷同的虚拟内存和全局变量等资源不须要进行批改然而对于线程本人公有的数据如栈和寄存器要进行批改，
线程上下文切换的时候分为两种的状况，就是对于两个线程属于不同的过程两个线程属于雷同的过程。

过程是有内核治理和调度的所以说对于过程的上下文切换只会产生在内核态因而来说过程的上下文切换岂但会包含虚拟内存栈全局变量等用户资源还包含扩内核堆栈寄存器等内核空间的状态。
所以来说对于过程的上下文切换会比零碎调用多一个步骤：
保留以后过程的内核状态和 CPU 寄存器之前先把该过程的虚拟内存栈保存起来加载下一个过程的内核当前还要刷新过程的虚构内核和用户栈。
保留上下文和复原上下文须要内核在 PUC 上运行才可能实现

为了疾速响应硬件的事件中断解决会打断过程的失常调度和执行而后调用中断来处理程序响应申请工夫在打断其余过程的运行的时候也须要将之前过程的运行的状况保留下来而后等到中断完结当前过程依然能够复原到原来的状态

对同一个 cpu 来说中断解决比过程领有更高的优先级所以中断上下文切换不会与过程上下文切换同时产生

关于多线程:多线程高并发

前言

1. 根底

过程与线程的区别

区别

蕴含关系

什么是并发编程的三要素？在 Java 中如何来保障多线程的平安运行。

什么是并行，什么是并发，说一说两者之间的区别：

2. 实现 Java 的多线程

创立的四种形式：

继承 Thread 类；

实现 Runnable 接口

实现 Callable 接口

应用线程池

Thread 类与 Runnable 接口的比拟：

Callable

Callable 接口

3. 线程的各个状态

4. 各种状态下的问题

对于线程同步以及线程调度的相干办法

sleep 和 wait 的区别

sleep 和 yield 的区别

start 和 run 的区别

join()

yield()

wait()和 notify()、notifyAll()

wait,notify 阻塞唤醒确切过程？在哪阻塞，在哪唤醒？为什么要呈现在同步代码块中，为什么要处于 while 循环中？

wait，notify 和 notifyAll 这些办法为什么不在 thread 类外面

如何唤醒一个阻塞的线程

5. 线程之间的通行

通过加锁

无锁状况

有锁状况

利用期待 / 告诉机制

信号量

其余

join 办法

sleep 办法

6. Java 内存模型相干

7. 重排序与 Happens-before

什么是指令的重排序

指令重排的三种状况：

Happens-before

什么是 Happens-before

定义

人造的 happens-before 有哪些

as-if-serial 规定和 happens-before 规定的区别(重点)

8. Volatile 关键字

相干的重要概念

内存可见性

重排序

happens-before 规定

volatile 有什么具体性能

volatile 与一般变量排序的规定

9. synchronized 与锁

有什么作用

平时是怎么应用这个关键字的，在我的项目中如何利用

双重校验实现对象单例

同步办法和同步块，哪个是更好的抉择？

说一下 synchronized 底层实现

synchronized 可重入的原理

说一下对于在 Java6 之后进行的锁的降级

对象头

偏差锁

实现原理：

轻量级锁

轻量级加锁：

轻量级开释

重量级锁

总结降级流程（常问重点）

比照

10. 乐观于乐观锁

什么是乐观锁

什么是乐观锁

CAS

CAS 的三大问题以及解决方案

ABA 问 题：

循环工夫长，开销大

在一次操作过程中只能保障一个共享变量的准则操作

AQS(AbstractQueuedSynchronizer)

ABA 问题：

Just My Socks（注册教程内含优惠码）