进程和线程的区别和联系
从资源占用,切换效率,通信方式等方面解答
线程具有许多传统进程所具有的特征，故又称为轻型进程(Light—Weight Process)或进程元；而把传统的进程称为重型进程(Heavy—Weight Process)，它相当于只有一个线程的任务。在引入了线程的操作系统中，通常一个进程都有若干个线程，至少需要一个线程。下面，我们从调度、并发性、 系统开销、拥有资源等方面，来比较线程与进程。
1．调度
在传统的操作系统中，拥有资源的基本单位和独立调度、分派的基本单位都是进程。而在引入线程的操作系统中，则把线程作为调度和分派的基本单位。而把进程作 为资源拥有的基本单位，使传统进程的两个属性分开，线程便能轻装运行，从而可显著地提高系统的并发程度。在同一进程中，线程的切换不会引起进程的切换，在 由一个进程中的线程切换到另一个进程中的线程时，将会引起进程的切换。
2．并发性
在引入线程的操作系统中，不仅进程之间可以并发执行，而且在一个进程中的多个线程之间，亦可并发执行，因而使操作系统具有更好的并发性，从而能更有效地使 用系统资源和提高系统吞吐量。例如，在一个未引入线程的单CPU操作系统中，若仅设置一个文件服务进程，当它由于某种原因而被阻塞时，便没有其它的文件服 务进程来提供服务。在引入了线程的操作系统中，可以在一个文件服务进程中，设置多个服务线程，当第一个线程等待时，文件服务进程中的第二个线程可以继续运 行；当第二个线程阻塞时，第三个线程可以继续执行，从而显著地提高了文件服务的质量以及系统吞吐量。
3．拥有资源
不论是传统的操作系统，还是设有线程的操作系统，进程都是拥有资源的一个独立单位，它可以拥有自己的资源。一般地说，线程自己不拥有系统资源(也有一点必 不可少的资源)，但它可以访问其隶属进程的资源。亦即，一个进程的代码段、数据段以及系统资源，如已打开的文件、I/O设备等，可供问一进程的其它所有线 程共享。
4．系统开销
由于在创建或撤消进程时，系统都要为之分配或回收资源，如内存空间、I／o设备等。因此，操作系统所付出的开销将显著地大于在创建或撤消线程时的开销。类 似地，在进行进程切换时，涉及到整个当前进程CPU环境的保存以及新被调度运行的进程的CPU环境的设置。而线程切换只须保存和设置少量寄存器的内容，并 不涉及存储器管理方面的操作。可见，进程切换的开销也远大于线程切换的开销。此外，由于同一进程中的多个线程具有相同的地址空间，致使它们之间的同步和通信的实现，也变得比较容易。在有的系统中，线程的切换、同步和通信都无须
简单介绍一下进程的切换过程
线程上下文的切换代价,要回答,切换会保存寄存器,栈等线程相关的现场,需要由用户态切换到内核态,可以用vmstat命令查看线程上下文的切换状况
1.线程的状态转换
六个状态对应ThreadState的枚举
CAS与ABA问题
Java中的线程的生命周期大体可分为5种状态。
1. 新建(NEW)：新创建了一个线程对象。
2. 可运行(RUNNABLE)：线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权 。
3. 运行(RUNNING)：可运行状态(runnable)的线程获得了cpu 时间片（timeslice） ，执行程序代码。
4. 阻塞(BLOCKED)：阻塞状态是指线程因为某种原因放弃了cpu 使用权，也即让出了cpu timeslice，暂时停止运行。直到线程进入可运行(runnable)状态，才有机会再次获得cpu timeslice 转到运行(running)状态。阻塞的情况分三种：
(一). 等待阻塞：运行(running)的线程执行o.wait()方法，JVM会把该线程放入等待队列(waitting queue)中。
(二). 同步阻塞：运行(running)的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入锁池(lock pool)中。
(三). 其他阻塞：运行(running)的线程执行Thread.sleep(long ms)或t.join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入可运行(runnable)状态。
5. 死亡(DEAD)：线程run()、main() 方法执行结束，或者因异常退出了run()方法，则该线程结束生命周期。死亡的线程不可再次复生。
CAS原理
在计算机科学中，比较和交换（Compare And Swap）是用于实现多线程同步的原子指令。 它将内存位置的内容与给定值进行比较，只有在相同的情况下，将该内存位置的内容修改为新的给定值。 这是作为单个原子操作完成的。 原子性保证新值基于最新信息计算; 如果该值在同一时间被另一个线程更新，则写入将失败。 操作结果必须说明是否进行替换; 这可以通过一个简单的布尔响应（这个变体通常称为比较和设置），或通过返回从内存位置读取的值来完成（摘自维基本科）
ABA问题
产生ABA问题的原因
CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。这就是CAS的ABA问题。
如何规避ABA问题
常用的办法是在更新数据的时候加入版本号，以版本号来控制更新。
【1】CAS方法：CompareAndSwap
1、乐观锁的使用的机制就是CAS。
在CAS方法中，CAS有三个操作数，内存值V，旧的预期值E，要修改的新值U。当且仅当预期值E和内存值V相等时，将内存值V修改为U，否则什么都不做。
2、非阻塞算法（nonblocking algorithms）：一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。
（1）非阻塞算法简介：https://www.ibm.com/developerworks/cn/java/j-jtp04186/
（2）非阻塞算法通常叫作乐观算法，因为它们继续操作的假设是不会有干扰。如果发现干扰，就会回退并重试。
3、CAS方法
（1）CompareAndSwap()就使用了非阻塞算法来代替锁定。
（2）举例：AtomicInteger来研究在没有锁的情况下是如何做到数据正确性的。
在没有锁机制的情况下，要保证线程间的数据是可见的，就会常常用到volatile原语了。
private volatile int value;
可使用如下方法读取内存变量值value：
public final int getValue(){
return value;
}
递增计数器是如何实现的：
public final int incrementAndGet(){
for(;;){
int current = getValue();
int next = value + 1;
if(compareAndSet(current,next)){
return next;
}
}
}
该方法采用了CAS操作，每次从内存中读取数据然后将此数据和+1后的结果进行CAS操作，如果成功就返回结果，否则重试直到成功为止。
而compareAndSet操作利用了Java本地接口（JNI，Java Native Interface）完成CPU指令的操作：
public final boolean compareAndSet(int expect, int update){
return unsafe.compareAndSwapInt(this,valueOffset,expect,unsafe);
}
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset(*.class.getDeclaredField("value"));
} catch (Exception ex) {
throw new Error(ex); }
}
“ABA”问题
1、可以发现，CAS实现的过程是先取出内存中某时刻的数据，在下一时刻比较并替换，那么在这个时间差会导致数据的变化，此时就会导致出现“ABA”问题。
2、什么是”ABA”问题？
比如说一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。
尽管线程one的CAS操作成功，但是不代表这个过程就是没有问题的。
【3】用AtomicStampedReference/AtomicMarkableReference解决ABA问题
例子：用AtomicStampedReference解决ABA问题：
package concur.lock;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicStampedReference;
public class ABA {
private static AtomicInteger atomicInt = new AtomicInteger(100);
private static AtomicStampedReference<Integer> atomicStampedRef =
new AtomicStampedReference<Integer>(100, 0);
public static void main(String[] args) throws InterruptedException {
Thread intT1 = new Thread(new Runnable() {
@Override
public void run() {
atomicInt.compareAndSet(100, 101);
atomicInt.compareAndSet(101, 100);
}
});
Thread intT2 = new Thread(new Runnable() {
@Override
public void run() {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
boolean c3 = atomicInt.compareAndSet(100, 101);
System.out.println(c3); //true
}
});
intT1.start();
intT2.start();
intT1.join();
intT2.join();
Thread refT1 = new Thread(new Runnable() {
@Override
public void run() {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
atomicStampedRef.compareAndSet(100, 101,
atomicStampedRef.getStamp(), atomicStampedRef.getStamp()+1);
atomicStampedRef.compareAndSet(101, 100,
atomicStampedRef.getStamp(), atomicStampedRef.getStamp()+1);
}
});
Thread refT2 = new Thread(new Runnable() {
@Override
public void run() {
int stamp = atomicStampedRef.getStamp();
System.out.println("before sleep : stamp = " + stamp); // stamp = 0
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("after sleep : stamp = " + atomicStampedRef.getStamp());//stamp = 1
boolean c3 = atomicStampedRef.compareAndSet(100, 101, stamp, stamp+1);
System.out.println(c3); //false
}
});
refT1.start();
refT2.start();
}
}
2.同步与互斥
Synchronized实现原理
Synchronized是Java中解决并发问题的一种最常用的方法，也是最简单的一种方法。Synchronized的作用主要有三个：
确保线程互斥的访问同步代码
保证共享变量的修改能够及时可见
有效解决重排序问题。
从语法上讲，Synchronized总共有三种用法：
修饰普通方法
修饰静态方法
修饰代码块
Java中每一个对象都可以作为锁，这是synchronized实现同步的基础：
1、普通同步方法，锁是当前实例对象
2、静态同步方法，锁是当前类的class对象
3、同步方法块，锁是括号里面的对象
synchronize底层原理：
Java 虚拟机中的同步(Synchronization)基于进入和退出Monitor对象实现， 无论是显式同步(有明确的 monitorenter 和 monitorexit 指令,即同步代码块)还是隐式同步都是如此。在 Java 语言中，同步用的最多的地方可能是被 synchronized 修饰的同步方法。同步方法 并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法表结构的 ACC_SYNCHRONIZED 标志来隐式实现的，关于这点，稍后详细分析。
同步代码块：monitorenter指令插入到同步代码块的开始位置，monitorexit指令插入到同步代码块的结束位置，JVM需要保证每一个monitorenter都有一个monitorexit与之相对应。任何对象都有一个monitor与之相关联，当且一个monitor被持有之后，他将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor所有权，即尝试获取对象的锁；
在JVM中，对象在内存中的布局分为三块区域：对象头、实例变量和填充数据。如下：
实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解即可。
对象头：Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。其中Klass Point是是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键。
Mark Word：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。Java对象头一般占有两个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit），但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
Monior：我们可以把它理解为一个同步工具，也可以描述为一种同步机制，它通常被描述为一个对象。与一切皆对象一样，所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。Monitor 是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联（对象头的MarkWord中的LockWord指向monitor的起始地址），同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。其结构如下：
Owner：初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL；
EntryQ:关联一个系统互斥锁（semaphore），阻塞所有试图锁住monitor record失败的线程。
RcThis:表示blocked或waiting在该monitor record上的所有线程的个数。
Nest:用来实现重入锁的计数。
HashCode:保存从对象头拷贝过来的HashCode值（可能还包含GC age）。
Candidate:用来避免不必要的阻塞或等待线程唤醒，因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降。Candidate只有两种可能的值0表示没有需要唤醒的线程1表示要唤醒一个继任线程来竞争锁。
Java虚拟机对synchronize的优化：
锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级，关于重量级锁，前面我们已详细分析过，下面我们将介绍偏向锁和轻量级锁以及JVM的其他优化手段。
偏向锁
偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。
轻量级锁
倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。
自旋锁
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。
锁消除
消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间，如下StringBuffer的append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。
/**
* Created by zejian on 2017/6/4.
* Blog : http://blog.****.net/javazejian
* 消除StringBuffer同步锁
*/
public class StringBufferRemoveSync {
public void add(String str1, String str2) {
//StringBuffer是线程安全,由于sb只会在append方法中使用,不可能被其他线程引用
//因此sb属于不可能共享的资源,JVM会自动消除内部的锁
StringBuffer sb = new StringBuffer();
sb.append(str1).append(str2);
}
public static void main(String[] args) {
StringBufferRemoveSync rmsync = new StringBufferRemoveSync();
for (int i = 0; i < 10000000; i++) {
rmsync.add("abc", "123");
}
}
}
synchronize的可重入性：
从互斥锁的设计上来说，当一个线程试图操作一个由其他线程持有的对象锁的临界资源时，将会处于阻塞状态，但当一个线程再次请求自己持有对象锁的临界资源时，这种情况属于重入锁，请求将会成功，在java中synchronized是基于原子性的内部锁机制，是可重入的，因此在一个线程调用synchronized方法的同时在其方法体内部调用该对象另一个synchronized方法，也就是说一个线程得到一个对象锁后再次请求该对象锁，是允许的，这就是synchronized的可重入性。如下：
public class AccountingSync implements Runnable{
static AccountingSync instance=new AccountingSync();
static int i=0;
static int j=0;
@Override
public void run() {
for(int j=0;j<1000000;j++){
//this,当前实例对象锁
synchronized(this){
i++;
increase();//synchronized的可重入性
}
}
}
public synchronized void increase(){
j++;
}
public static void main(String[] args) throws InterruptedException {
Thread t1=new Thread(instance);
Thread t2=new Thread(instance);
t1.start();t2.start();
t1.join();t2.join();
System.out.println(i);
}
}
正如代码所演示的，在获取当前实例对象锁后进入synchronized代码块执行同步代码，并在代码块中调用了当前实例对象的另外一个synchronized方法，再次请求当前实例锁时，将被允许，进而执行方法体代码，这就是重入锁最直接的体现，需要特别注意另外一种情况，当子类继承父类时，子类也是可以通过可重入锁调用父类的同步方法。注意由于synchronized是基于monitor实现的，因此每次重入，monitor中的计数器仍会加1。
线程中断：正如中断二字所表达的意义，在线程运行(run方法)中间打断它，在Java中，提供了以下3个有关线程中断的方法
//中断线程（实例方法）
public void Thread.interrupt();
//判断线程是否被中断（实例方法）
public boolean Thread.isInterrupted();
//判断是否被中断并清除当前中断状态（静态方法）
public static boolean Thread.interrupted();
等待唤醒机制与synchronize：所谓等待唤醒机制本篇主要指的是notify/notifyAll和wait方法，在使用这3个方法时，必须处于synchronized代码块或者synchronized方法中，否则就会抛出IllegalMonitorStateException异常，这是因为调用这几个方法前必须拿到当前对象的监视器monitor对象，也就是说notify/notifyAll和wait方法依赖于monitor对象，在前面的分析中，我们知道monitor 存在于对象头的Mark Word 中(存储monitor引用指针)，而synchronized关键字可以获取 monitor ，这也就是为什么notify/notifyAll和wait方法必须在synchronized代码块或者synchronized方法调用的原因。
这段话的大概意思为：
每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：
1、如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
2、如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1.
3.如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。
执行monitorexit的线程必须是objectref所对应的monitor的所有者。
指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。
通过这两段描述，我们应该能很清楚的看出Synchronized的实现原理，Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。
从反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。
运行结果解释
有了对Synchronized原理的认识，再来看上面的程序就可以迎刃而解了。
代码段2结果： 虽然method1和method2是不同的方法，但是这两个方法都进行了同步，并且是通过同一个对象去调用的，所以调用之前都需要先去竞争同一个对象上的锁（monitor），也就只能互斥的获取到锁，因此，method1和method2只能顺序的执行。
代码段3结果： 虽然test和test2属于不同对象，但是test和test2属于同一个类的不同实例，由于method1和method2都属于静态同步方法，所以调用的时候需要获取同一个类上monitor（每个类只对应一个class对象），所以也只能顺序的执行。
代码段4结果： 对于代码块的同步实质上需要获取Synchronized关键字后面括号中对象的monitor，由于这段代码中括号的内容都是this，而method1和method2又是通过同一的对象去调用的，所以进入同步块之前需要去竞争同一个对象上的锁，因此只能顺序执行同步块。
总结
Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到内核态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。
因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“偏向锁”和“轻量级锁”。无锁 --> 偏向锁 --> 轻量级 --> 重量级
锁优化会将锁由轻量级升级为重量级
AQS与Lock
什么是Lock锁？
在Java中锁是出现是为了防止多个线程访问同一资源，锁有内建锁（synchronized）,synchronized关键字实现锁是隐式加解锁，在JDK5后，java.util.concurrent包中增加了lock接口，它提供了和synchronized一样可以防止多个线程访问同一资源，但是lock锁需要手动加锁解锁，也提供了synchronized没有的同步特性（后文会叙述）。
Reentrantlock(可重入锁）如何实现一个锁？
Reentrantlock(可重入锁）中所有方法实际上都是调用了其静态内部类Sync中的方法，而Sync继承了AbstractQueuedSynchronizer(AQS --简称同步器)
什么是AQS？
同步器是用来构建锁以及其他同步组件的基础框架，它的实现主要是依赖一个int状态变量以及通过一个FIFO队列共同构成同步对列。
子类必须重写AQS的用proteted 修饰的用来改变同步状态的方法，其他方法主要实现了排队与阻塞机制。int状态的更新使用getState( )/setSate以及compareAndSetState( )/
子类推荐使用静态内部类来继承AQS实现自己的同步语义，同步器既支持独占锁，也支持共享锁。
Lock锁与AQS的关系：
Lock面向使用者，定义了使用者与锁交互的接口；
AQS—面向锁的实现者，简化了锁的实现， 屏蔽了同步状态的管理、线程排队、线程等待与唤醒等底层操作。
了解到AQS和Lock锁的基本知识后我们可以自己写一个类Mutex锁来实现Lock接口，在Mutex中有静态内部类继承AQS类：
深入理解AQS
在同步组件的实现中，AQS是核心部分，AQS面向锁的实现，同步组件的实现者通过使用AQS提供的模板方法实现同步组件语义，AQS则实现了对同步状态的管理，以及对阻塞线程进行排队，等待通知等一些底层的实现处理。AQS的核心包括了：同步队列，独占式锁的获取和释放，共享锁的获取和释放，超时等待锁以及可中断锁的获取，这一系列功能的实现。这些实现依靠的是AQS提供的模板方法：
独占式锁：
共享式锁：
AQS的模板方法基于同步队列，那么什么是同步队列呢？
同步队列
当多个线程竞争共享资源时，一个线程竞争到共享资源后，其他请求资源的线程会被阻塞，进入同步队列，也就是说同步队列中存放的被阻塞的线程，这些线程等待cpu调度再次竞争共享资源。
同步队列是一种队列，队列的实现可以通过数组也可通过链表，在AQS中同步队列的数据结构是链表。那是什么链表呢：是有头结点吗？是单向还是双向呢？
通过源码可以发现同步队列是带头尾结点的双向链表。(注意：不带头结点和带头结点区别：头插时，不带头结点需要频繁改变头指针）并且在添加元素是通过尾插。
在AQS中有一个静态内部类Node
3.线程池
Executors.NewFixedThreadPool固定线程数,*队列.适用于任务数量不均匀的场景,对内存压力不敏感,但系统负载敏感的场景.
Executors..newCachedThreadPool无限线程数,适用于要求低延迟的短期任务场景.
Executors.newSingleThreadPool单个线程的固定线程池,适用于保证异步执行顺序的场景.
Executors.newScheduledThreadPool适用于定期执行任务场景,支持固定频率和固定延迟.
Executors.newWorkStealingPool使用ForkJoinPool,多任务队列的固定并行度,适合任务执行时长不均匀的场景.
线程池参数介绍
一、ThreadPoolExecutor的重要参数
1、corePoolSize：核心线程数
* 核心线程会一直存活，及时没有任务需要执行
* 当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理
* 设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭
2、queueCapacity：任务队列容量（阻塞队列）
* 当核心线程数达到最大时，新任务会放在队列中排队等待执行
3、maxPoolSize：最大线程数
* 当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务
* 当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常
4、 keepAliveTime：线程空闲时间
* 当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize
* 如果allowCoreThreadTimeout=true，则会直到线程数量=0
5、allowCoreThreadTimeout：允许核心线程超时
6、rejectedExecutionHandler：任务拒绝处理器
* 两种情况会拒绝处理任务：
- 当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务
- 当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务
* 线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常
* ThreadPoolExecutor类有几个内部实现类来处理这类情况：
- AbortPolicy 丢弃任务，抛运行时异常
- CallerRunsPolicy 执行任务
- DiscardPolicy 忽视，什么都不会发生
- DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务
* 实现RejectedExecutionHandler接口，可自定义处理器
二、ThreadPoolExecutor执行顺序
线程池按以下行为执行任务
1. 当线程数小于核心线程数时，创建线程。
2. 当线程数大于等于核心线程数，且任务队列未满时，将任务放入任务队列。
3. 当线程数大于等于核心线程数，且任务队列已满
- 若线程数小于最大线程数，创建线程
- 若线程数等于最大线程数，抛出异常，拒绝任务
4.JUC常用工具
1. JUC 简介
在 Java 5.0 提供了 java.util.concurrent(简称JUC)包,在此包中增加了在并发编程中很常用的工具类,
用于定义类似于线程的自定义子系统,包括线程池,异步 IO 和轻量级任务框架;还提供了设计用于多线程上下文中
的 Collection 实现等;
2. volatile 关键字
volatile 关键字: 当多个线程进行操作共享数据时,可以保证内存中的数据是可见的;相较于 synchronized 是一种
较为轻量级的同步策略;
volatile 不具备"互斥性";
volatile 不能保证变量的"原子性";
考察点
1.理解线程的同步与互斥原理
临界资源与临界区的概念
重量级锁,轻量级锁,自旋锁,偏向锁,读写锁,重入锁的概念
2.掌握线程安全相关机制
CAS,synchronized,lock同步方式的实现原理
ThreadLocal是线程独享的局部变量,使用弱引用的ThreadLocalMap保存ThreadLocal变量
3.了解JUC工具的使用场景与实现原理
ReentrantLock,ConcurrentHash,LongAdder的实现方式
4.熟悉线程池的原理,使用场景,常用配置
慎用*队列,可能会有OOM的风险
5.理解线程的同步与异步,阻塞与非阻塞
同步异步:任务是否在同一个线程中执行
阻塞非阻塞:异步执行任务时,线程是否会阻塞等待结果
加分项
1.结合实际项目经验或实际案例介绍原理
2.解决多线程问题的排查思路与经验
多线程并发执行可能会导致一些问题：
安全性问题：在单线程系统上正常运行的代码，在多线程环境中可能会出现意料之外的结果。
活跃性问题：不正确的加锁、解锁方式可能会导致死锁or活锁问题。
性能问题：多线程并发即多个线程切换运行，线程切换会有一定的消耗并且不正确的加锁。
3.熟悉常用的线程分析工具与方法
如Jstack
排查过程如下：
1、top #查看java进程占用cpu、内存情况
2、ps (ps -mp java进程ID -o THREAD,tid,time) #查看java线程占用cpu、优先级、时间等
第二步找出该进程内最耗费CPU的线程，可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid
3、将可疑线程的tid转成16进制（通过windows自动程序员计算器转换）
4、jstack -l java进程ID > aa.log #导出java进程堆栈信息
5、在里面查找16进制的线程id，看对应堆栈代码日志。可以知道这个线程在做什么事情
4.了解Java8对JUC的增强
用LongAdder替换AtomicLong,更适合并发度高的场景
5.了解Reactive异步编程思想
真题汇总
1.如何实现生产者消费者模型?
可利用锁,信号量,线程通信,阻塞队列等方法实现
用synchronized对存储加锁，然后用object原生的wait() 和 notify()做同步。
用concurrent.locks.Lock，然后用condition的await() 和signal()做同步。
直接使用concurrent.BlockingQueue。
使用PipedInputStream/PipedOutputStream。
使用信号量semaphore。
我的理解，生产者消费者模式，其实只要保证在存储端同一时刻只有一个线程读或写就不会有问题，然后再去考虑线程同步。方法1 2 5都比较类似，都是加锁来限制同一时刻只能有一个读或写。而方法3 4其实是在存储内部去保证读和写的唯一的，最低层肯定还是通过锁机制来实现的，java底层代码都封装好了而已。
我自己尝试写了下前三种，代码如下：
synchronized版本
import java.util.LinkedList;
import java.util.Queue;
public class ProducerAndConsumer {
private final int MAX_LEN = 10;
private Queue<Integer> queue = new LinkedList<Integer>();
class Producer extends Thread {
@Override
public void run() {
producer();
}
private void producer() {
while(true) {
synchronized (queue) {
while (queue.size() == MAX_LEN) {
queue.notify();
System.out.println("当前队列满");
try {
queue.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
queue.add(1);
queue.notify();
System.out.println("生产者生产一条任务，当前队列长度为" + queue.size());
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
class Consumer extends Thread {
@Override
public void run() {
consumer();
}
private void consumer() {
while (true) {
synchronized (queue) {
while (queue.size() == 0) {
queue.notify();
System.out.println("当前队列为空");
try {
queue.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
queue.poll();
queue.notify();
System.out.println("消费者消费一条任务，当前队列长度为" + queue.size());
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
public static void main(String[] args) {
ProducerAndConsumer pc = new ProducerAndConsumer();
Producer producer = pc.new Producer();
Consumer consumer = pc.new Consumer();
producer.start();
consumer.start();
}
}
lock版实现，使用了condition做线程之间的同步。
import java.util.LinkedList;
import java.util.Queue;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
/**
* version 1 doesn't use synchronized to improve performance
*/
public class ProducerAndConsumer1 {
private final int MAX_LEN = 10;
private Queue<Integer> queue = new LinkedList<Integer>();
private final Lock lock = new ReentrantLock();
private final Condition condition = lock.newCondition();
class Producer extends Thread {
@Override
public void run() {
producer();
}
private void producer() {
while(true) {
lock.lock();
try {
while (queue.size() == MAX_LEN) {
System.out.println("当前队列满");
try {
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
queue.add(1);
condition.signal();
System.out.println("生产者生产一条任务，当前队列长度为" + queue.size());
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
lock.unlock();
}
}
}
}
class Consumer extends Thread {
@Override
public void run() {
consumer();
}
private void consumer() {
while (true) {
lock.lock();
try {
while (queue.size() == 0) {
System.out.println("当前队列为空");
try {
condition.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
queue.poll();
condition.signal();
System.out.println("消费者消费一条任务，当前队列长度为" + queue.size());
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
lock.unlock();
}
}
}
}
public static void main(String[] args) {
ProducerAndConsumer pc = new ProducerAndConsumer();
Producer producer = pc.new Producer();
Consumer consumer = pc.new Consumer();
producer.start();
consumer.start();
}
}
BlockingQueue版实现
import java.util.Random;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
public class ProducerAndConsumer {
private BlockingQueue<Integer> queue = new LinkedBlockingQueue<Integer>(10);
class Producer extends Thread {
@Override
public void run() {
producer();
}
private void producer() {
while(true) {
try {
queue.put(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("生产者生产一条任务，当前队列长度为" + queue.size());
try {
Thread.sleep(new Random().nextInt(1000)+500);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
class Consumer extends Thread {
@Override
public void run() {
consumer();
}
private void consumer() {
while (true) {
try {
queue.take();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("消费者消费一条任务，当前队列长度为" + queue.size());
try {
Thread.sleep(new Random().nextInt(1000)+500);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
public static void main(String[] args) {
ProducerAndConsumer pc = new ProducerAndConsumer();
Producer producer = pc.new Producer();
Consumer consumer = pc.new Consumer();
producer.start();
consumer.start();
}
}
2.如何理解线程的同步与异步,阻塞与非阻塞?
1、进程和线程的概念
进程：运行中的应用程序称为进程，拥有系统资源（cpu、内存）
线程：进程中的一段代码，一个进程中可以有多段代码。本身不拥有资源（共享所在进程的资源）；
在java中，程序入口被自动创建为主线程，在主线程中可以创建多个子线程。
多进程: 在操作系统中能同时运行多个任务(程序)
多线程: 在同一应用程序中有多个功能流同时执行
已经有了进程，为什么还会需要线程呢？主要原因如下：
许多应用程序中，同时发生着多个活动。将这些应用程序分解成多个准并行的线程，程序设计的模型会变成更加简单。
由于线程比进程进行更加轻量，创建和取消更加容易。
如果程序是IO密集型，那么多线程执行能够加快程序的执行速度。（如果是CPU密集型，则没有这个优势）
在多CPU系统中，多线程是可以真正并行执行的。
2、线程的主要特点
①、不能以一个文件名的方式独立存在在磁盘中；
②、不能单独执行，只有在进程启动后才可启动；
③、线程可以共享进程相同的内存（代码与数据）。
3、多线程原理
同一时间，CPU只能处理1条线程，只有1条线程在工作（执行）
多线程并发（同时）执行，其实是CPU快速地在多条线程之间调度（切换）
如果CPU调度线程的时间足够快，就造成了多线程并发执行的假象
思考：如果线程非常非常多，会发生什么情况？
CPU会在N多线程之间调度，CPU会累死，消耗大量的CPU资源
每条线程被调度执行的频次会降低（线程的执行效率降低）
4、线程的主要用途
①、利用它可以完成重复性的工作（如实现动画、声音等的播放）。
②、从事一次性较费时的初始化工作（如网络连接、声音数据文件的加载）。
③、并发执行的运行效果（一个进程多个线程）以实现更复杂的功能
5、多线程（多个线程同时运行）程序的优缺点
优点：
①、可以减轻系统性能方面的瓶颈，因为可以并行操作；
②、提高CPU的处理器的效率，在多线程中，通过优先级管理，可以使重要的程序优先操作，提高了任务管理的灵活性；
另一方面，在多CPU系统中，可以把不同的线程在不同的CPU中执行，真正做到同时处理多任务。
缺点：
1、开启线程需要占用一定的内存空间（默认情况下，主线程占用1M，子线程占用512KB），如果开启大量的线程，会占用大量的内存空间，降低程序的性能
2、线程越多，CPU在调度线程上的开销就越大
3、程序设计更加复杂：比如线程之间的通信、多线程的数据共享
6、多线程的生命周期
线程状态：
与人有生老病死一样，线程也同样要经历新建、就绪、运行(活动)、阻塞和死亡五种不同的状态。这五种状态都可以通过Thread类中的方法进行控制。
创建并运行线程：
① 新建状态(New Thread)：在Java语言中使用new 操作符创建一个线程后，该线程仅仅是一个空对象，它具备类线程的一些特征，但此时系统没有为其分配资源，这时的线程处于创建状态。
线程处于创建状态时，可通过Thread类的方法来设置各种属性，如线程的优先级(setPriority)、线程名(setName)和线程的类型(setDaemon)等。
② 就绪状态(Runnable)：使用start()方法启动一个线程后，系统为该线程分配了除CPU外的所需资源，使该线程处于就绪状态。此外，如果某个线程执行了yield()方法，那么该线程会被暂时剥夺CPU资源，重新进入就绪状态。
③ 运行状态(Running)：Java运行系统通过调度选中一个处于就绪状态的线程，使其占有CPU并转为运行状态。此时，系统真正执行线程的run()方法。
a) 可以通过Thread类的isAlive方法来判断线程是否处于就绪/运行状态：当线程处于就绪/运行状态时，isAlive返回true，当isAlive返回false时，可能线程处于阻塞状态，也可能处于停止状态。
④ 阻塞和唤醒线程
阻塞状态(Blocked)：一个正在运行的线程因某些原因不能继续运行时，就进入阻塞 状态。这些原因包括：
等待阻塞：当线程执行了某个对象的wait()方法时，线程会被置入该对象的等待集中，直到执行了该对象的notify()方法wait()/notify()方法的执行要求线程首先获得该对象的锁。
同步阻塞：当多个线程试图进入某个同步区域（同步锁）时，没能进入该同步区域（同步锁）的线程会被置入锁定集（锁池）中，直到获得该同步区域的锁，进入就绪状态。
其他阻塞：运行的线程执行sleep()或join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。
⑤ 死亡状态(Dead)：线程在run()方法执行结束后进入死亡状态。此外，如果线程执行了interrupt()或stop()方法，那么它也会以异常退出的方式进入死亡状态。
7、终止线程的三种方法
① 使用退出标志，使线程正常退出，也就是当run方法完成后线程终止，推荐使用。
② 使用stop方法强制终止线程(这个方法不推荐使用，因为stop和suppend、resume一样，也可能发生不可预料的结果)。
③ 使用interrupt方法中断线程。
8、概念解释
8.1 同步/异步, 它们是消息的通知机制
同步：
所谓同步，当前程序执行完才能执行后面的程序，程序执行时按照顺序执行，需要等待。平时写的代码基本都是同步的；
异步：
异步的概念和同步相对。
程序没有等到上一步程序执行完才执行下一步，而是直接往下执行，前提是下面的程序没有用到异步操作的值，异步的实现方式基本上都是多线程（定时任务也可实现，但是情况少）。
8.2 阻塞/非阻塞, 它们是程序在等待消息(无所谓同步或者异步)时的状态.
阻塞：
阻塞调用是指调用结果返回之前，当前线程会被挂起。函数只有在得到结果之后才会返回。
有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。
对于同步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回而已。
非阻塞：
非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回。
简单示例：老张烧水
老张爱喝茶，废话不说，煮开水。
出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
1 老张把水壶放到火上，立等水开。（同步阻塞）
老张觉得自己有点傻
2 老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）
老张还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出嘀~~~~的噪音。
3 老张把响水壶放到火上，立等水开。（异步阻塞）（本可以坐着等通知的却非要立即等着，实际不大会出现这种情况，异步异步阻塞没有实际意义）
老张觉得这样傻等意义不大
4 老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）
所谓同步异步，只是对于水壶而言。
普通水壶，同步；响水壶，异步。
虽然都能干活，但响水壶可以在自己完工之后，提示老张水开了。这是普通水壶所不能及的。
同步只能让调用者去轮询自己（情况2中），造成老张效率的低下。
所谓阻塞非阻塞，仅仅对于老张而言。
立等的老张，阻塞；看电视的老张，非阻塞。
情况1和情况3中老张就是阻塞的，媳妇喊他都不知道。虽然3中响水壶是异步的，可对于立等的老张没有太大的意义。所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。
同步阻塞关系：
线程阻塞（祥见多线程介绍）除了程序主动调用休眠外常见的就是程序遇到同步代码块，同一时间不能并行执行，当有多个请求了出现线程等待的情况即为阻塞。
同步原因：
阻塞源于同步代码块，首先需要弄清楚何时需要同步，需要同步的地方是因为多个线程操作了同一个变量，导致在并行执行时变量值的混乱，故需要加同步锁来实现同一时间只能有同一个线程执行同步代码块中的程序，如果不涉及多线程操作同一个变量的情况是不需要使用同步的，在多线程编程时尽量避免操作公共变量来避免阻塞。
9、Java同步机制有4种实现方式
ThreadLocal
synchronized( )
wait() 与 notify()
volatile
目的：都是为了解决多线程中的对同一变量的访问冲突
9.1 ThreadLocal
ThreadLocal 保证不同线程拥有不同实例，相同线程一定拥有相同的实例，即为每一个使用该变量的线程提供一个该变量值的副本，每一个线程都可以独立改变自己的副本，而不是与其它线程的副本冲突。
优势：提供了线程安全的共享对象与其它同步机制的区别：同步机制是为了同步多个线程对相同资源的并发访问，是为了多个线程之间进行通信；而ThreadLocal 是隔离多个线程的数据共享，从根本上就不在多个线程之间共享资源,这样当然不需要多个线程进行同步了。
9.2 volatile
volatile 修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且当成员变量发生变化时，强迫线程将变化值回写到共享内存。
优势：这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。
缘由：Java 语言规范中指出，为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。这样当多个线程同时与某个对象交互时，就必须要注意到要让线程及时的得到共享成员变量的变化。而 volatile 关键字就是提示 VM ：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。
使用技巧：在两个或者更多的线程访问的成员变量上使用 volatile 。当要访问的变量已在synchronized 代码块中，或者为常量时，不必使用。
线程为了提高效率，将某成员变量(如A)拷贝了一份（如B），线程中对A的访问其实访问的是B。只在某些动作时才进行A和B的同步，因此存在A和B不一致的情况。volatile就是用来避免这种情况的。 volatile告诉jvm，它所修饰的变量不保留拷贝，直接访问主内存中的（读操作多时使用较好；线程间需要通信，本条做不到）
Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。
只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：
对变量的写操作不依赖于当前值；
该变量没有包含在具有其他变量的不变式中。
9.3 sleep() vs wait()
sleep是线程类（Thread）的方法，导致此线程暂停执行指定时间，把执行机会给其他线程，但是监控状态依然保持，到时后会自动恢复。调用sleep不会释放对象锁。
wait() 是Object类的方法，对此对象调用wait方法导致本线程放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象发出notify方法（或notifyAll）后本线程才进入对象锁定池准备获得对象锁进入运行状态。
（如果变量被声明为volatile，在每次访问时都会和主存一致；如果变量在同步方法或者同步块中被访问，当在方法或者块的入口处获得锁以及方法或者块退出时释放锁时变量被同步。）
3.线程池处理任务的流程?
流程解释为:
当线程池新加入一个线程时，首先判断当前线程数，是否小于coreSize，如果小于，则执行步骤2，否则执行3
创建新线程添加到线程池中，跳转结束
判断当前线程池等待队列是否已满，若已满，则跳转至步骤5
加入等待队列，等待线程池空闲，跳转结束
判断当前线程数是否已达到maximumPoolSize，若未达到，则跳转至步骤7
执行线程池拒绝策略，跳转结束
创建一个新线程，执行任务
跳转结束
4.wait与sleep有什么不同?
wait是Object方法,sleep是Thread方法
wait会释放锁,sleep不会
wait要在同步块中使用,sleep在任何地方使用
wait不需要捕获异常,sleep需要
5.Synchronized与ReentrantLock有什么不同,各适用什么场景?
相似点：
这两种同步方式有很多相似之处，它们都是加锁方式同步，而且都是阻塞式的同步，也就是说当如果一个线程获得了对象锁，进入了同步块，其他访问该同步块的线程都必须阻塞在同步块外面等待，而进行线程阻塞和唤醒的代价是比较高的（操作系统需要在用户态与内核态之间来回切换，代价很高，不过可以通过对锁优化进行改善）。
区别：
这两种方式最大区别就是对于Synchronized来说，它是java语言的关键字，是原生语法层面的互斥，需要jvm实现。而ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成。
Synchronized进过编译，会在同步块的前后分别形成monitorenter和monitorexit这个两个字节码指令。在执行monitorenter指令时，首先要尝试获取对象锁。如果这个对象没被锁定，或者当前线程已经拥有了那个对象锁，把锁的计算器加1，相应的，在执行monitorexit指令时会将锁计算器就减1，当计算器为0时，锁就被释放了。如果获取对象锁失败，那当前线程就要阻塞，直到对象锁被另一个线程释放为止。
由于ReentrantLock是java.util.concurrent包下提供的一套互斥锁，相比Synchronized，ReentrantLock类提供了一些高级功能，主要有以下3项：
1.等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。
2.公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。
3.锁绑定多个条件，一个ReentrantLock对象可以同时绑定对个对象。
6.读写锁适用与什么场景,ReentrantReadWriteLock是如何实现的?
互斥锁：mutex，用于保证在任何时刻，都只能有一个线程访问该对象。当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒
自旋锁：spinlock，在任何时刻同样只能有一个线程访问对象。但是当获取锁操作失败时，不会进入睡眠，而是会在原地自旋，直到锁被释放。这样节省了线程从睡眠状态到被唤醒期间的消耗，在加锁时间短暂的环境下会极大的提高效率。但如果加锁时间过长，则会非常浪费CPU资源
读写锁：rwlock，区分读和写，处于读操作时，可以允许多个线程同时获得读操作。但是同一时刻只能有一个线程可以获得写锁。其它获取写锁失败的线程都会进入睡眠状态，直到写锁释放时被唤醒。
注意：写锁会阻塞其它读写锁。当有一个线程获得写锁在写时，读锁也不能被其它线程获取；写优先于读，当有线程因为等待写锁而进入睡眠时，则后续读者也必须等待
适用于读取数据的频率远远大于写数据的频率的场合。
RCU：即read-copy-update，在修改数据时，首先需要读取数据，然后生成一个副本，对副本进行修改。修改完成后，再将老数据update成新的数据。使用RCU时，读者几乎不需要同步开销，既不需要获得锁，也不使用原子指令，不会导致锁竞争，因此就不用考虑死锁问题了。而对于写者的同步开销较大，它需要复制被修改的数据，还必须使用锁机制同步并行其它写者的修改操作。在有大量读操作，少量写操作的情况下效率非常高
信号量：semaphore，是用于线程间同步的，当一个线程完成操作后就通过信号量通知其它线程，然后别的线程就可以继续进行某些操作了。
信号量和互斥锁的区别：semaphore
信号量是用于线程间同步的，而互斥锁是用于线程的互斥的
互斥量的获取和释放都是在同一线程中完成的，pthread_mutex_lock(),pthread_mutex_unlock()。而信号量的获得和释放是在不同的线程的操作为sem_wait(),sempost()；
互斥量的值只能为0和1，而信号量只要value>0，其它线程就可以sem_wait成功，成功后信号量value减一。若value值不大于0，则sem_wait阻塞，直到sem_post释放后value加1。因此信号量的值可以为非负整数
读写锁顶层接口是 ReadWriteLock , 实现类是 ReentrantReadWriteLock;
其实读写锁,运用没什么好说的. 同时读,没有安全性问题, 所以不用到互斥, 而读写, 或写写则涉及到安全性问题, 就要互斥.直接上代码吧
package com.zz.amqp1.locktest;
import lombok.Data;
import java.util.Random;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
/**
* Description:读写锁
* <p>
* 1 写写, 读写, 需要互斥
* 2 读读, 不需要互斥
*
* </p>
* User: zhouzhou
* Date: 2018-12-27
* Time: 2:20 PM
*/
public class TestReadWriteLock {
public static void main(String[] args) {
ReadWriteLockDemo demo = new ReadWriteLockDemo();
for (int i = 0; i < 5; i++) {
new Thread(()->{
demo.set(new Random().nextInt(101));
},"write:" + (i+1)).start();
}
for (int i = 0; i < 100; i++) {
new Thread(()->{
demo.read();
}).start();
}
}
}
@Data
class ReadWriteLockDemo{
private int number = 0;
// 可重入读写锁
private ReadWriteLock lock = new ReentrantReadWriteLock();
public void read(){
lock.readLock().lock();
try {
System.out.println("当前的值为" + this.number);
} finally {
lock.readLock().unlock();
}
}
public void set(Integer value){
lock.writeLock().lock();
try {
System.out.println(String.format("当前线程{%s}正在进行写操作{%s}", Thread.currentThread().getName(),value));
this.setNumber(value);
} finally {
lock.writeLock().unlock();
}
}
}
7.线程之间如何通信?
wait/notify机制
共享变量的synchronize&lock同步机制
线程之间的通信方式：共享内存(隐式通信)，消息传递(显示通信)
线程之间同步：在共享内存的并发模型中，同步是显示做的；在消息传递的并发模型中，由于消息的发生必须在消息接收之前，所以同步是隐式做的
8.保证线程安全的方法有哪些?
CAS,synchronized,lock,ThreadLocal
第一种实现线程安全的方式
同步代码块
第二种 方式
同步方法
第三种 方式
Lock锁机制， 通过创建Lock对象，采用lock()加锁，unlock()解锁，来保护指定的代码块
最后总结：
由于synchronized是在JVM层面实现的，因此系统可以监控锁的释放与否；而ReentrantLock是使用代码实现的，系统无法自动释放锁，需要在代码中的finally子句中显式释放锁lock.unlock()。
另外，在并发量比较小的情况下，使用synchronized是个不错的选择；但是在并发量比较高的情况下，其性能下降会很严重，此时ReentrantLock是个不错的方案。
补充：
在使用synchronized 代码块时,可以与wait()、notify()、nitifyAll()一起使用，从而进一步实现线程的通信。
其中，wait()方法会释放占有的对象锁，当前线程进入等待池，释放cpu,而其他正在等待的线程即可抢占此锁，获得锁的线程即可运行程序；线程的sleep()方法则表示，当前线程会休眠一段时间，休眠期间，会暂时释放cpu，但并不释放对象锁，也就是说，在休眠期间，其他线程依然无法进入被同步保护的代码内部，当前线程休眠结束时，会重新获得cpu执行权,从而执行被同步保护的代码。
wait()和sleep()最大的不同在于wait()会释放对象锁，而sleep()不会释放对象锁。
notify()方法会唤醒因为调用对象的wait()而处于等待状态的线程，从而使得该线程有机会获取对象锁。调用notify()后，当前线程并不会立即释放锁，而是继续执行当前代码，直到synchronized中的代码全部执行完毕，才会释放对象锁。JVM会在等待的线程中调度一个线程去获得对象锁，执行代码。
需要注意的是，wait()和notify()必须在synchronized代码块中调用。
notifyAll()是唤醒所有等待的线程。
9.如何尽可能提高多线程并发性能?
减少临界区范围
使用ThreadLocal
减少线程切换
使用读写锁或CopyOnWrite
在Java程序中，多线程几乎已经无处不在。与单线程相比，多线程程序的设计和实现略微困难，但通过多线程，我们却可以获得多核CPU带来的性能飞跃，从这个角度说，多线程是一种值得尝试的技术。那么如何写出高效的多线程程序呢？
有关多线程的误区：线程越多，性能越好
不少初学者可能认为，线程数量越多，那么性能应该越好。因为程序给我们的直观感受总是这样。一个两个线程可能跑的很难，线程一多可能就快了。但事实并非如此。因为一个物理CPU一次只能执行一个线程，多个线程则意味着必须进行线程的上下文切换，而这个代价是很高的。因此，线程数量必须适量，最好的情况应该是N个CPU使用N个线程，并且让每个CPU的占有率都达到100%，这种情况下，系统的吞吐量才发挥到极致。但现实中，不太可能让单线程独占CPU达到100%，一个普遍的愿意是因为IO操作，无论是磁盘IO还是网络IO都是很慢的。线程在执行中会等待，因此效率就下来了。这也就是为什么在一个物理核上执行多个线程会感觉效率高了，对于程序调度来说，一个线程等待时，也正是其它线程执行的大好机会，因此，CPU资源得到了充分的利用。
尽可能不要挂起线程
多线程程序免不了要同步，最直接的方法就是使用锁。每次只允许一个线程进入临界区，让其它相关线程等待。等待有2种，一种是直接使用操作系统指令挂起线程，另外一种是自旋等待。在操作系统直接挂起，是一种简单粗暴的实现，性能较差，不太适用于高并发的场景，因为随之而来的问题就是大量的线程上下文切换。如果可以，尝试一下进行有限的自旋等待，等待不成功再去挂起线程也不迟。这样很有可能可以避免一些无谓的开销。JDK中ConcurrentHashMap的实现里就有一些自旋等待的实现。此外Java虚拟机层面，对synchronized关键字也有自旋等待的优化。
善用“无锁”
阻塞线程会带来性能开销，因此，一种提供性能的方案就是使用无锁的CAS操作。JDK中的原子类，如AtomicInteger正是使用了这种方案。在高并发环境中，冲突较多的情况下，它们的性能远远好于传统的锁操作（《实战Java高并发程序设计》 P158）。
处理好“伪共享”问题
大家知道，CPU有一个高速缓存Cache。在Cache中，读写数据的最小单位是缓存行，如果2个变量存在一个缓存行中，那么在多线程访问中，可能会相互影响彼此的性能。因此将变量存放于独立的缓存行中，也有助于变量在多线程访问是的性能提升（《实战Java高并发程序设计》 P200），大量的高并发库都会采用这种技术。
10.ThreadLocal用来解决什么问题,ThreadLocal是如何实现的?
不是用来解决多线程共享变量问题,而是用来解决线程数据隔离问题
ThreadLocal是一个解决线程并发问题的一个类，用于创建线程的本地变量，我们知道一个对象的所有线程会共享它的全局变量，所以这些变量不是线程安全的，我们可以使用同步技术。但是当我们不想使用同步的时候，我们可以选择ThreadLocal变量。
每个线程都会拥有他们自己的Thread变量，他们可以使用get/set方法去获取他们的默认值或者在线程内部改变他们的值。ThreadLocal实例通常是希望他们同线程状态关联起来是private static属性。
底层实现主要是存有一个map，以线程作为key，泛型作为value，可以理解为线程级别的缓存。每一个线程都会获得一个单独的map。
11.死锁的产生条件,如何分析线程是否有死锁?
其实，真正理清楚了死锁产生的必要的条件，写出一个死锁的例子并不困难。那么，就java的多线程而言，产生死锁有哪些必要条件呢？
1，必须有2个或以上的线程。一个线程是不会产生死锁的，它顶多产生等待。
2，必须有2个临界资源，即，必须有2个锁。这也是死锁产生的必要的条件。当只有一个临界资源，或者说只有一个锁时，当一个线程获取了锁，另一个线程虽然暂时无法获取锁，但它至多也就是需要进行等待。而不会陷入死锁。
3，两个线程，每个线程都获取了其中的一个锁，但为了完成工作，还需对方的另一个锁。这种情况下，才会产生死锁。这种情况也称为循环等待。
4，不可剥夺。
以上即为死锁产生的必要条件。
避免死锁可以概括成三种方法：
固定加锁的顺序(针对锁顺序死锁)
开放调用(针对对象之间协作造成的死锁)
使用定时锁-->tryLock()
12.在实际工作中遇到过什么样的并发问题,如何发现排查并解决的?
异步协程方式解决