Java多线程常见知识点

Java多线程面试常见知识点

谈你对synchronized锁的理解，锁的粒度的是什么，一个线程怎么去判断synchronized锁已经被占用，底层实现是什么？

• 修饰实例方法，作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
• 修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁 。因为访问静态 synchronized
  方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
• 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

怎么判断目前线程是否持有锁

在java.lang.Thread中有一个方法叫holdsLock()，它返回true如果当且仅当当前线程拥有某个具体对象的锁

什么是加锁粒度呢？

所谓加锁粒度就是你要锁住的范围是多大

synchronized和lock的区别

1、lock是一个接口，而synchronized是java的一个关键字。
2、synchronized在发生异常时会自动释放占有的锁，因此不会出现死锁；而lock发生异常时，不会主动释放占有的锁，必须手动来释放锁，可能引起死锁的发生。

synchronized锁方法和锁代码块的区别是什么

java里synchronized锁的一些概念：有分为对象锁和类锁两种。
对象锁（又称作实例锁），是指锁在某一个实例对象上的；类锁（又称作全局锁），是锁针对类上的，无论实例多少该类对象，都是共享该锁。

同步方法直接在方法上加synchronized实现加锁，同步代码块则在方法内部加锁，很明显，同步方法锁的范围比较大，而同步代码块范围要小点，一般同步的范围越大，性能就越差，一般需要加锁进行同步的时候，肯定是范围越小越好，这样性能更好。

可见性、原子性、有序性

原子性
原子性是指一个操作是不可中断的，要么全部执行成功要么全部执行失败，有着“同生共死”的感觉。及时在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程所干扰。

可见性
可见性是指当一个线程修改了共享变量后，其他线程能够立即得知这个修改

有序性
如果在本线程内观察，所有的操作都是有序的；如果在一个线程观察另一个线程，所有的操作都是无序的。

volatile和synchronized的区别

• volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取；synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住
• volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的
• volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性
• volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
• volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化

同步和异步

同步
我们可以将同步看成是单线的执行，即要么执行成功，要么执行失败
同步是单线程

异步
异步则是当你的任务提交了之后，不用管任务的结果是什么，可以继续执行别的任务。
异步是多线程

两者比较
1、同步的执行效率会比较低，耗费时间，但有利于我们对流程进行控制，避免很多不可掌控的意外情况；
2、异步的执行效率高，节省时间，但是会占用更多的资源，也不利于我们对进程进行控制

进程的状态

创建状态：进程在创建时需要申请一个空白PCB（进程的控制块），向其中填写控制和管理进程的信息，完成资源分配。如果创建工作无法完成，比如资源无法满足，就无法被调度运行，把此时进程所处状态称为创建状态

就绪状态：进程已经准备好，已分配到所需资源，只要分配到CPU就能够立即运行

执行状态：进程处于就绪状态被调度后，进程进入执行状态

阻塞状态：正在执行的进程由于某些事件（I/O请求，申请缓存区失败）而暂时无法运行，进程受到阻塞。在满足请求时进入就绪状态等待系统调用

终止状态：进程结束，或出现错误，或被系统终止，进入终止状态。无法再执行

进程三种状态间的转换

一个进程在运行期间，不断地从一种状态转换到另一种状态，它可以多次处于就绪状态和执行状态，也可以多次处于阻塞状态。

(1) 就绪→执行处于就绪状态的进程，当进程调度程序为之分配了处理机后，该进程便由就绪状态转变成执行状态。

(2) 执行→就绪处于执行状态的进程在其执行过程中，因分配给它的一个时间片已用完而不得不让出处理机，于是进程从执行状态转变成就绪状态。

(3) 执行→阻塞正在执行的进程因等待某种事件发生而无法继续执行时，便从执行状态变成阻塞状态。

(4) 阻塞→就绪处于阻塞状态的进程，若其等待的事件已经发生，于是进程由阻塞状态转变为就绪状态。

进程和线程的区别？

进程是资源分配的最小单位，线程是CPU调度的最小单位
进程包括线程

资源开销：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。

包含关系：如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程。

内存分配：同一进程的线程共享本进程的地址空间和资源，而进程之间的地址空间和资源是相互独立的。

影响关系：一个进程崩溃后，在保护模式下不会对其他进程产生影响，但是一个线程崩溃整个进程都死掉。所以多进程要比多线程健壮。

执行过程：每个独立的进程有程序运行的入口、顺序执行序列和程序出口。但是线程不能独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制，两者均可并发执行。

java多线程同步5种方法

1. 同步方法
2. 同步代码块
3. 使用特殊域变量(volatile)实现线程同步
4. 使用重入锁实现线程同步
5. 使用局部变量实现线程同步

多线程的创建方式有哪几种

第一种，通过继承Thread类创建线程类
通过继承Thread类来创建并启动多线程的步骤如下：
1、定义一个类继承Thread类，并重写Thread类的run()方法，run()方法的方法体就是线程要完成的任务，因此把run()称为线程的执行体；
2、创建该类的实例对象，即创建了线程对象；
3、调用线程对象的start()方法来启动线程；

//继承Thread类来创建线程
public class ThreadTest {
 
    public static void main(String[] args) {
        //设置线程名字
        Thread.currentThread().setName("main thread");
        MyThread myThread = new MyThread();
        myThread.setName("子线程:");
        //开启线程
        myThread.start();
        for(int i = 0;i<5;i++){
            System.out.println(Thread.currentThread().getName() + i);
        }
    }
}
 
class MyThread extends Thread{
    //重写run()方法
    public void run(){
        for(int i = 0;i < 10; i++){
            System.out.println(Thread.currentThread().getName() + i);
        }
    }
}

第二种，通过实现Runnable接口创建线程类
这种方式创建并启动多线程的步骤如下：
1、定义一个类实现Runnable接口，实现run方法；
2、创建该类的实例对象obj；
3、将obj作为构造器参数传入Thread类实例对象，这个对象才是真正的线程对象；
4、调用线程对象的start()方法启动该线程；

//实现Runnable接口
public class RunnableTest {
  
    public static void main(String[] args) {
        //设置线程名字
        Thread.currentThread().setName("main thread:");
        Thread thread = new Thread(new MyRunnable());
        thread.setName("子线程:");
        //开启线程
        thread.start();
        for(int i = 0; i <5;i++){
            System.out.println(Thread.currentThread().getName() + i);
        }
    }
}
  
class MyRunnable implements Runnable {
  
    @Override
    public void run() {
        for (int i = 0; i < 10; i++) {
            System.out.println(Thread.currentThread().getName() + i);
        }
    }
}

第三种，通过Callable和Future接口创建线程
通过这两个接口创建线程，你要知道这两个接口的作用，下面我们就来了解这两个接口：通过实现Runnable接口创建多线程时，Thread类的作用就是把run()方法包装成线程的执行体，那么，是否可以直接把任意方法都包装成线程的执行体呢？从JAVA5开始，JAVA提供提供了Callable接口，该接口是Runnable接口的增强版，Callable接口提供了一个call()方法可以作为线程执行体，但call()方法比run()方法功能更强大，call()方法的功能的强大体现在：
1、call()方法可以有返回值；
2、call()方法可以声明抛出异常；
从这里可以看出，完全可以提供一个Callable对象作为Thread的target，而该线程的线程执行体就是call()方法。但问题是：Callable接口是JAVA新增的接口，而且它不是Runnable接口的子接口，所以Callable对象不能直接作为Thread的target。还有一个原因就是：call()方法有返回值，call()方法不是直接调用，而是作为线程执行体被调用的，所以这里涉及获取call()方法返回值的问题。

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
//实现Callable接口
public class CallableTest {
 
    public static void main(String[] args) {
        //执行Callable 方式，需要FutureTask 实现实现，用于接收运算结果
        FutureTask<Integer> futureTask = new FutureTask<Integer>(new MyCallable());
        new Thread(futureTask).start();
        //接收线程运算后的结果
        try {
            Integer sum = futureTask.get();
            System.out.println(sum);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
    }
}
 
class MyCallable implements Callable<Integer> {
 
    @Override
    public Integer call() throws Exception {
        int sum = 0;
        for (int i = 0; i < 100; i++) {
            sum += i;
        }
        return sum;
    }
}

线程的状态：

Java语言定义了5种线程状态，在任意一个时间点，一个线程只能有且只有其中一个状态。

新建状态(New): 线程对象被创建后，就进入了新建状态。例如，Thread thread = new Thread()。

就绪状态(Runnable): 也被称为“可执行状态”。线程对象被创建后，其它线程调用了该对象的start()方法，从而来启动该线程。例如，thread.start()。处于就绪状态的线程，随时可能被CPU调度执行。

运行状态(Running): 线程获取CPU权限进行执行。需要注意的是，线程只能从就绪状态进入到运行状态。

阻塞状态(Blocked): 阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态（阻塞状态只能先进入就绪状态，再进入运行状态），才有机会转到运行状态。阻塞的情况分三种：

• 等待阻塞 – 通过调用线程的wait()方法，让线程等待某工作的完成。
• 同步阻塞 – 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态。
• 其他阻塞 –通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

死亡状态(Dead): 线程执行完了或者因异常退出了run()方法，该线程结束生命周期。

只有就绪状态能进入运行状态，其他状态都不行

notify()：从阻塞状态进入到就绪状态，唤醒在此对象锁上等待的单个线程。
notifyAll()：从阻塞状态进入到就绪状态，唤醒在此对象锁上等待的所有线程。
wait()：让当前线程处于“等待(阻塞)状态，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法”，当前线程被唤醒(进入“就绪状态（因为wait会释放锁，所以要等其他线程来唤醒它）”)。
join()：从运行状态进入到阻塞状态，把指定的线程添加到当前线程中，可以不给参数直接thread.join（），也可以给一个时间参数，单位为毫秒thread.join（100）。事实上join方法是通过wait方法来实现的。比如线程A中加入了线程B.join方法，则线程A默认执行wait()方法，释放资源进入等待状态，此时线程B获得资源，执行结束后释放资源，线程A重新获取自CPU，继续执行，由此实现线程的顺序执行。
sleep()：从运行状态进入到阻塞状态，方法导致了程序暂停执行指定的时间，让出cpu给其他线程，但是它的监控状态依然保持者，当指定的时间到了又会自动苏醒，并返回到就绪状态，不是运行状态。sleep()中指定的时间是线程不会运行的最短时间。因此，sleep()方法不能保证该线程睡眠到期后就开始执行。在调用sleep()方法的过程中，线程不会释放对象锁。
yield()：从运行状态进入到就绪状态，线程礼让，yield意味着放手，放弃，投降。一个调用yield()方法的线程告诉虚拟机它乐意让其他线程占用自己的位置。这表明该线程没有在做一些紧急的事情。注意，这仅是一个暗示，并不能保证不会产生任何影响。
让我们列举一下关于以上定义重要的几点：
Yield是一个静态的原生(native)方法
Yield告诉当前正在执行的线程把运行机会交给线程池中拥有相同优先级的线程
Yield不能保证使得当前正在运行的线程迅速转换到可运行的状态
它仅能使一个线程从运行状态转到可运行状态，而不是等待或阻塞状态
stop():stop方法就是直接停止掉当前线程的方法
run():run()方法只是一个类的普通方法，调用后自动压栈执行，执行完后弹栈便可
start():方法作用开启一个分支线程，在JVM中开辟一块新的栈空间，代码执行完，自动结束。用start方法来启动线程，真正实现了多线程运行，这时无需等待run方法体代码执行完毕而直接继续执行下面的代码

Join方法：假如在主线程中调用了t.join，t.join()方法只会使主线程(或者说调用t.join()的线程)进入等待池并等待t线程执行完毕后才会被唤醒。并不影响同一时刻处在运行状态的其他线程。就是说在线程中调用了别的线程的join方法，那就是别的线程先执行了，然后再执行该线程

Thread类的方法

start()、run()、isAlive()、interrupt()、join()、sleep(long millis)、yield()

sleep方法和wait方法的区别

最主要是sleep方法没有释放锁，而wait方法释放了锁，使得其他线程可以使用同步控制块或者方法(锁代码块和方法锁)
wait，notify和notifyAll只能在同步控制方法或者同步控制块里面使用，而sleep可以在任何地方使用(使用范围)， sleep必须捕获异常，而wait，notify和notifyAll不需要捕获异常

三种结束线程的方法：

1.设置退出标志，使线程正常退出，正常地退出run()方法后线程结束。
2.使用interrupt()方法终止线程。
3.使用stop方法强制终止线程（不推荐使用）

线程池

当程序中需要创建大量生存期很短暂的线程时，更应该考虑使用线程池 线程池在系统启动时即创建大量空闲的线程，程序将一个Runnable对象或Callable对象传给线程池，线程池就会启动一个线程来执行它们的run（）或call（）方法 当run（）或call（）方法执行结束后，该线程并不会死亡，而是再次返回线程池中成为空闲状态，等待执行下一个Runnable对象的run（）或call（）方法 使用线程池可以有效地控制系统中并发线程的数量
使用线程池来执行线程任务的步骤如下： 调用Executors类的静态工厂方法创建一个ExecutorService对象，该对象代表一个线程池 创建Runnable实现类或Callable实现类的实例，作为线程执行任务 调用ExecutorService对象的submit（）方法来提交Runnable实例或Callable实例 当不想提交任何任务时，调用ExecutorService对象的shutdown（）方法来关闭线程池

线程池的关闭：
线程池自动关闭的两个条件：1、线程池的引用不可达；2、线程池中没有线程；
调用ExecutorService对象的shutdown（）方法来关闭线程池

线程池的三大方法、七大参数、四种拒绝策略（可以顺带谈一下阿里巴巴开发手册对于线程池使用的规范）
线程池的好处：
　　01：降低资源的消耗
　　02：提高响应的速度
　　03：方便管理
（重点）线程复用、可以控制最大并发数、管理线程

三大方法：不建议使用
Executors.newCachedThreadPool();// 请求多就创建线程多
Executors.newFixedThreadPool(5);// 给定线程的线程池
Executors.newSingleThreadExecutor();// 只有单个线程

七大参数：（自定义创建线程池）
1.核心线程数 corePoolSize
2.最大线程数 maximumPoolSize
3.等待时间 keepAliveTime
4.等待时间单位 unit
5.工作队列 workQueue
6.线程工厂 threadFactory
7.拒绝策略 handler

四大拒绝策略：线程池满了就会执行拒绝策略，就是最大承载=核心容量+阻塞队列，满了的策略
我们在使用ThreadPoolExecutor的时候是可以自己选择拒绝策略的，而拒绝策略我们所知道的有四种。
AbortPolicy 超出线程池能接受的最大大小(最大大小为 阻塞队列 + 最大线程数量) 抛出异常（队列和线程池满了之和就会抛出异常）
CallerRunsPolicy 使用调用者所在线程执行，满了之后退回到原来线程
discardOldestPolicy 超出数量 丢掉任务 不抛出异常
discardPolicy 满了之后尝试竞争第一个，失败也不抛异常

submit()和execute()的区别

一类是实现了Runnable接口的类，一类是实现了Callable接口的类。两者都可以被ExecutorService执行，它们的区别是：
execute方法大家都不陌生，即开启线程执行池中的任务。还有一个方法submit也可以做到，它的功能是提交指定的任务去执行并且返回Future对象，即执行的结果。下面简要介绍一下两者的三个区别：

1、接收的参数不一样，都可以是Runnable，submit 也可以是Callable

2、submit有返回值，而execute没有
submit(Runnable x) 返回一个future。可以用这个future来判断任务是否成功完成

3、submit方便Exception处理
如果发生异常submit()可以通过捕获Future.get抛出的异常,而execute()会终止这个线程

最大线程数如何定义？

（从CPU密集型和IO密集型考虑）
01：一个计算为主的程序（CPU密集型程序），多线程跑的时候，可以充分利用起所有的 CPU 核心数，比如说 8 个核心的CPU ,开8 个线程的时候，可以同时跑 8 个线程的运算任务，此时是最大效率。但是如果线程远远超出 CPU 核心数量，反而会使得任务效率下降，因为频繁的切换线程也是要消耗时间的。因此对于 CPU 密集型的任务来说，线程数等于 CPU 数是最好的了。
02：如果是一个磁盘或网络为主的程序（IO密集型程序），一个线程处在 IO 等待的时候，另一个线程还可以在 CPU 里面跑，有时候 CPU 闲着没事干，所有的线程都在等着 IO，这时候他们就是同时的了，而单线程的话此时还是在一个一个等待的。我们都知道 IO 的速度比起 CPU 来是很慢的。此时线程数等于CPU核心数的两倍是最佳的。

怎样根据并发和执行任务时间使用线程

（1）高并发、任务执行时间短的业务，线程池线程数可以设置为CPU核数+1，减少线程上下文的切换

（2）并发不高、任务执行时间长的业务要区分开看：
a）假如是业务时间长集中在IO操作上（IO密集型），也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来，可以加大线程池中的线程数目，让CPU处理更多的业务
b）假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，和（1）一样吧，线程池中的线程数设置得少一些，减少线程上下文的切换

（3）并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，增加服务器是第二步，至于线程池的设置，设置参考（2）。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件对任务进行拆分和解耦。

为什么用Excutors去创建线程池不好？（阿里巴巴代码开发规范有提及）

java中创建线程池的方式一般有两种：

• 通过Executors工厂方法创建
• 通过new ThreadPoolExecutor(int corePoolSize, int maximumPoolSize,
  long keepAliveTime, TimeUnit unit, BlockingQueue
  workQueue)自定义创建

线程池不允许使用 Executors 去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式能更加明确线程池的运行规则，规避资源耗尽的风险。
ThreadPoolExecutor创建线程池：

ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(10, 100, 600, TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(65536), namedThreadFactory);

threadPoolExecutor 为线程池

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

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

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

线程池的五种状态（Running、Shutdown、Stop、Tidying、Terminated）

1、RUNNING
(1) 状态说明：线程池处在RUNNING状态时，能够接收新任务，以及对已添加的任务进行处理。
(02) 状态切换：线程池的初始化状态是RUNNING。换句话说，线程池被一旦被创建，就处于RUNNING状态，并且线程池中的任务数为0！
2、 SHUTDOWN
(1) 状态说明：线程池处在SHUTDOWN状态时，不接收新任务，但能处理已添加的任务。
(2) 状态切换：调用线程池的shutdown()接口时，线程池由RUNNING -> SHUTDOWN。
3、STOP
(1) 状态说明：线程池处在STOP状态时，不接收新任务，不处理已添加的任务，并且会中断正在处理的任务。
(2) 状态切换：调用线程池的shutdownNow()接口时，线程池由(RUNNING or SHUTDOWN ) -> STOP。
4、TIDYING
(1) 状态说明：当所有的任务已终止，ctl记录的”任务数量”为0，线程池会变为TIDYING状态。当线程池变为TIDYING状态时，会执行钩子函数terminated()。terminated()在ThreadPoolExecutor类中是空的，若用户想在线程池变为TIDYING时，进行相应的处理；可以通过重载terminated()函数来实现。
(2) 状态切换：当线程池在SHUTDOWN状态下，阻塞队列为空并且线程池中执行的任务也为空时，就会由 SHUTDOWN -> TIDYING。
当线程池在STOP状态下，线程池中执行的任务为空时，就会由STOP -> TIDYING。
5、 TERMINATED
(1) 状态说明：线程池彻底终止，就变成TERMINATED状态。
(2) 状态切换：线程池处在TIDYING状态时，执行完terminated()之后，就会由 TIDYING -> TERMINATED。

线程池的任务执行流程、excute方法和 submit方法的区别？

这里用一个图来说明线程池的执行流程

任务被提交到线程池，会先判断当前线程数量是否小于corePoolSize，如果小于则创建线程来执行提交的任务，否则将任务放入workQueue队列，如果workQueue满了，则判断当前线程数量是否小于maximumPoolSize,如果小于则创建线程执行任务，否则就会调用handler，以表示线程池拒绝接收任务。

一类是实现了Runnable接口的类，一类是实现了Callable接口的类。两者都可以被ExecutorService执行，它们的区别是：
execute方法大家都不陌生，即开启线程执行池中的任务。还有一个方法submit也可以做到，它的功能是提交指定的任务去执行并且返回Future对象，即执行的结果。下面简要介绍一下两者的三个区别：

1、接收的参数不一样，都可以是Runnable，submit 也可以是Callable

2、submit有返回值，而execute没有
submit(Runnable x) 返回一个future。可以用这个future来判断任务是否成功完成

3、submit方便Exception处理
如果发生异常submit()可以通过捕获Future.get抛出的异常,而execute()会终止这个线程

Synchronized锁和Lock锁的区别

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

synchronized的好处
①粒度降低了；
②JVM 开发团队没有放弃 synchronized，而且基于 JVM 的 synchronized 优化空间更大， 更加自然。
③在大量的数据操作下，对于 JVM 的内存压力，基于 API 的 ReentrantLock 会开销更多的内存。

wait状态和block状态的区别：

Java线程虚假唤醒

（线程本应该处于wait状态却被唤醒了，解决方案是wait方法应该用while循环包裹，不用if）
虚假唤醒（spurious wakeup）是一个表象，即在多处理器的系统下发出wait的程序有可能在没有notify唤醒的情形下苏醒继续执行。以运行在linux的hotspot虚拟机上的java程序为例，wait方法在jvm执行时实质是调用了底层pthread_cond_wait/pthread_cond_timedwait函数，挂起等待条件变量来达到线程间同步通信的效果，而底层wait函数在设计之初为了不减慢条件变量操作的效率并没有去保证每次唤醒都是由notify触发，而是把这个任务交由上层应用去实现，即使用者需要定义一个循环去判断是否条件真能满足程序继续运行的需求，当然这样的实现也可以避免因为设计缺陷导致程序异常唤醒的问题。
出现虚假唤醒的原因是从阻塞态到就绪态再到运行态没有进行判断，我们只需要让其每次得到操作权时都进行判断就可以了；

所以将
if(num != 0){
    this.wait();}
改为
while(num != 0){
    this.wait();}
将
if(num == 0){
    this.wait();}
改为
while(num == 0){
    this.wait();}
即可。

原文参考：
[https://www.jianshu.com/p/90a6bf4cbe52]

JMM的三种特性（原子性、可见性、有序性）、主内存和线程工作内存的八种交互动作

原子性
所谓原子性，是指在一次操作或多次操作中，要么所有的操作全部执行，并不会受到人任何元素的干扰而中断，要么所有的操作都不执行，中间不会有任何上下文切换（context switch）。比如：A给B转账100，A账户扣除100，B账户账户收入100，这两个操作必须符合原子性，要么都成功，要么都失败。所以并发编程就需要将应该是原子操作的一系列操作封装成一个原子操作。
可见性
线程只能操作自己工作空间中的数据，对其他线程的工作空间不可见。但是并发编程中一个线程对共享变量进行了修改，另一个线程要能立刻看到被改后的最新值。
线程1对共享变量的修改如果要被线程2及时看到，需要经过2个步骤：

1. 把工作内存1中更新过的共享变量值刷新到主内存中
2. 把主内存中最新的共享变量的值更新打工作内存2中
   以上2个步骤，任意一个出现问题，都会导致共享变量无法被其他线程及时看到，无法实现可见性，导致其他线程读取的数据不准确从而产生线程不安全。
   例子：

private int i = 0;
 
private int j = 0;
 
//线程1 i = 10; 
 
//线程2 j = i；

线程1修改i的值为10时的执行步骤：
1）将10赋给线程1工作内存中的 i 变量；
2）将线程1工作内存中的 i 变量的值赋给主内存中的 i 变量;
当线程2执行j = i时，线程2的执行步骤：
1）将主内存中的 i 变量的值读取到线程2的工作内存中；
2）将主内存中的 j 变量的值读取到线程2的工作内存中；
3）将线程2工作内存中的 i 变量的值赋给线程2工作内存中的 j 变量；
4）将线程2工作内存中的 j 变量的值赋给主内存中的 j 变量;
如果线程1执行完步骤1，线程2开始执行，此时主内存中 i 变量的值仍然为 0，那么线程2获取到的 i 变量的值为 0，而不是 10。
这就是可见性问题，线程1对 i 变量做了修改之后，线程2没有立即看到线程1修改的值。
有序性
程序中的顺序不一定就是执行的顺序,因为系统会对代码进行一次重排序，重排序的作用就是提高效率。但是虽然指令重排不会影响单线程的执行结果，但是会影响多线程并发执行的结果正确性，所以并发编程就要保证重排序之后的有序性，执行结果不能因为重排序而出错。重排序有三种：
编译器优化的重排序（编译期间）：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
指令级并行的重排序（运行期间）：现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序：由于处理器使用缓存和读 / 写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
例子：

int x = 1;
 
int y = 2;
 
int z;
 
z = x + y;
 
int m = 0;
.

这一段代码int m = 0;这个操作在前面和在后面对程序的最终结果不会有影响，但是z=x+y这个操作本身很耗时，所以int m = 0要等一会才能执行到它，这在并发执行的时候显然单位时间内完成的任务比较少，也就降低了整体的效率，所以系统就会重排序将int m = 0放到上面去提前执行。一般重排序的原则就有将执行操作时间少的指令排在前面执行。其实这个就是计算机组成原理中学的CPU流水线作业，能够大大提高系统吞吐量。
举例一：

int i = 0;
int j = 0;
i = 10;   //语句1
j = 1;    //语句2

语句可能的执行顺序如下：
1）语句1 语句2
2）语句2 语句1

语句1一定在语句2前面执行吗？答案是否定的，这里可能会发生执行重排（Instruction Reorder）。一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序在单线程环境下最终执行结果和代码顺序执行的结果是一致的。
比如上面的代码中，语句1和语句2谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句2先执行而语句1后执行。
举例二：

int i = 0;    //语句1
int j = 0;    //语句2
i = i + 10;   //语句3
j = i * i;    //语句4

语句可能的执行顺序如下：
1）语句1 语句2 语句3 语句4
2）语句2 语句1 语句3 语句4
3）语句1 语句3 语句2 语句4
语句3是不可能在语句4之后执行的，因为编译器在进行指令重排时会考虑数据的依赖性问题，语句4依赖于语句3，因此语句3一定在语句4之前执行。
接下来我们说一下多线程环境。
举例三：

private boolean flag = false;   
private Context context = null;  
//线程1
context = loadContext();  //语句1
flag = true;              //语句2
 
//线程2 
while(!flag){
    Thread.sleep(1000L)
}
dowork(context);

语句可能的执行顺序如下：
1）语句1 语句2
2）语句2 语句1
由于在线程1中语句1、语句2是没有依赖性的，所以可能会出现指令重排。如果发生了指令重排，线程1先执行语句2，这时候线程2开始执行，此时flag值为true，因此线程2继续执行dowrk(context)，此时context并没有初始化，因此就会导致程序错误。
因此可以得出结论，指令重排不会影响单线程的执行结果，但是会影响多线程并发执行的结果正确性.
处理器不会对存在数据依赖的操作进行重排序。这里数据依赖的准确定义是：如果两个操作同时访问一个变量，其中一个操作是写操作，此时这两个操作就构成了数据依赖。

Java虚拟机内存模型中定义了8种关于主内存和工作内存的交互协议操作：
lock：作用于主内存的变量，把一个变量标识为一条线程独占状态。
unlock：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量可以被其他线程锁定。
read：作用于主内的变量，把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
load：作用于工作内存的变量，把read读取操作从主内存中得到的变量值放入工作内存的变量拷贝中。
use：作用于工作内存的变量，把工作内存中一个变量的值传递给java虚拟机执行引擎，每当虚拟机遇到一个需要使用到变量值的字节码指令时将会执行该操作。
assign：作用于工作内存变量，把一个从执行引擎接收到的变量的值赋值给工作变量，每当虚拟机遇到一个给变量赋值的字节码时将会执行该操作。
store：作用于工作内存的变量，把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
write：作用于主内存的变量，把store操作从工作内存中得到的变量值放入主内存的变量中。

volatile如何保证可见性（MESI缓存一致性协议）

首先我们先了解一下volatile关键字的用法 ，volatile被喻为轻量级的”synchronized”,它只是一个变量修饰符，只能用来修饰变量不能修饰方法和代码块。

volatile与可见性：
先说一下可见性，所谓的可见性就是指可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

缓存一致性协议
每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里。

MESI协议
缓存一致性协议里最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。

• Modify（修改）：当缓存行中的数据被修改时，该缓存行置为M状态
• Exclusive（独占）：当只有一个缓存行使用某个数据时，置为E状态
• Shared（共享）：当其他CPU中也读取某数据到缓存行时，所有持有该数据的缓存行置为S状态
• Invalid（无效）：当某个缓存行数据修改时，其他持有该数据的缓存行置为I状态

它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

而这其中，监听和通知又基于总线嗅探机制来完成。

总线嗅探机制
嗅探机制其实就是一个监听器，回到我们刚才的流程，如果是加入MESI缓存一致性协议和总线嗅探机制之后：

• CPU1读取数据a=1，CPU1的缓存中都有数据a的副本，该缓存行置为（E）状态
• CPU2也执行读取操作，同样CPU2也有数据a=1的副本，此时总线嗅探到CPU1也有该数据，则CPU1、CPU2两个缓存行都置为（S）状态
• CPU1修改数据a=2，CPU1的缓存以及主内存a=2，同时CPU1的缓存行置为（S）状态，总线发出通知，CPU2的缓存行置为（I）状态
• CPU2再次读取a，虽然CPU2在缓存中命中数据a=1，但是发现状态为（I），因此直接丢弃该数据，去主内存获取最新数据

当我们使用volatile关键字修饰某个变量之后，就相当于告诉CPU：我这个变量需要使用MESI和总线嗅探机制处理。从而也就保证了可见性。

volatile如何保证有序性（内存屏障——lock前缀指令）

volatile与有序性
我们都知道多线程通过抢占时间片来执行自己的代码体，所以我们会感觉到线程是同时执行完的，除了引入了时间片以外，由于处理器优化和指令重排等，CPU还可能对输入代码进行乱序执行，比如我们拿到数据要执行写库，查询，删除这三个操作，这就会可能要涉及到有序性的问题了。

volatile可以禁止指令重排，这就保证了代码的程序会严格按照代码的先后顺序执行。这就保证了有序性。被volatile修饰的变量的操作，会严格按照代码顺序执行接下来我们就说一下为了实现volatile内存语义JMM是怎样限制重排序（包括编译器重排序和处理器重排序）的。

volatile重排序规则表（针对编译器重排序）：

从这张表我们可以看出：
当第一个操作是Volatile读时，不管第二个操作是什么，都不能重排序；
当第一个操作是Volatile写时，第二个操作是Volatile读或写，不能重排序；
当第一个操作是普通读写，第二个操作是Volatile写时，不能重排序。
内存屏障（针对处理器重排序）：
编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。（首先保证了正确性，再去追求执行效率）

1. 在每个volatile写操作前插入StoreStore屏障；对于这样的语句Store1; StoreLoad;
   Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
2. 在每个volatile写操作后插入StoreLoad屏障；对于这样的语句Store1; StoreLoad;
   Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。
3. 在每个volatile读操作前插入LoadLoad屏障；对于这样的语句Load1;LoadLoad;
   Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
4. 在每个volatile读操作后插入LoadStore屏障；对于这样的语句Load1; LoadStore;
   Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

如果编译器无法确定后面是否还会有volatile读或者写的时候，为了安全，编译器通常会在这里插入一个StoreLoad屏障

synchronized和volatile的区别

（volatile是一种非锁机制，这种机制可以避免锁机制引起的线程上下文切换和调度问题。因此，volatile的执行成本比synchronized更低；volatile只能保证可见性有序性；synchronized可以保证原子性可见性有序性）

• volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取；
  synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
• volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的
• volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性
• volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
• volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化

为什么volatile不能保证原子性

原子性
因为volatile它不是锁只是一个变量修饰符，所以无法保证原子性
问题来了，既然它可以保证修改的值立即能更新到主存，其他线程也会捕捉到被修改后的值，那么为什么不能保证原子性呢？
首先需要了解的是，Java中只有对基本类型变量的赋值和读取是原子操作，如i = 1的赋值操作，但是像j = i或者i++这样的操作都不是原子操作，因为他们都进行了多次原子操作，比如先读取i的值，再将i的值赋值给j，两个原子操作加起来就不是原子操作了。
所以，如果一个变量被volatile修饰了，那么肯定可以保证每次读取这个变量值的时候得到的值是最新的，但是一旦需要对变量进行自增这样的非原子操作，就不会保证这个变量的原子性了。

举个栗子
一个变量i被volatile修饰，两个线程想对这个变量修改，都对其进行自增操作也就是i++，i++的过程可以分为三步，首先获取i的值，其次对i的值进行加1，最后将得到的新值写会到缓存中。
线程A首先得到了i的初始值100，但是还没来得及修改，就阻塞了，这时线程B开始了，它也得到了i的值，由于i的值未被修改，即使是被volatile修饰，主存的变量还没变化，那么线程B得到的值也是100，之后对其进行加1操作，得到101后，将新值写入到缓存中，再刷入主存中。根据可见性的原则，这个主存的值可以被其他线程可见。
问题来了，线程A已经读取到了i的值为100，也就是说读取的这个原子操作已经结束了，所以这个可见性来的有点晚，线程A阻塞结束后，继续将100这个值加1，得到101，再将值写到缓存，最后刷入主存，所以即便是volatile具有可见性，也不能保证对它修饰的变量具有原子性。

JUC包中的原子类如何保证原子性？（CAS机制和自旋锁）

关于上面addAndGet的实现，我们可以发现里面有个无限循环，不停地去尝试修改操作，直到修改成功，这就是自旋，是一种乐观的策略。就是我假设每次执行都没人跟我争，有人跟我争那我就再多尝试一次。而悲观的策略就是我认为一定会有人跟我争的，所以每次我要执行代码的时候我先关上门（上锁）不给别人进。
自旋操作呢有一个比较大的缺点就是，在并发程度高的情况下，可能一个线程尝试了好久都没成功，那你想咯，一个线程没有放弃CPU执行权在那里不断循环，不是很浪费CPU资源吗？
我在后续的文章还会介绍JUC中的锁（Lock），里面有一个概念叫自旋锁。Java中的锁有很多讲究，很有特点，你可以看Java锁的膨胀过程和优化 了解一下
总结操作基本类型的原子类
总结一下操作基本类型的原子类，它们的内部都维护者一个对应的基本类型的成员变量value，这个变量是被volatile关键字修饰的，这可以保证每次一个线程要使用它都会拿到最新的值。然后在进行一些原子操作的时候，需要依赖一个神秘人物Unsafe类（这家伙是一个隐藏很深的东西，我们只需要知道它是干嘛的就好了），这个类里面就有一些CAS函数，一些原子操作就是通过自旋方式，不断地使用CAS函数进行尝试直到达到自己的目的。
关于操作基本类型的原子类我就介绍到这里，可能你会觉得我介绍的不全，不过我觉得是够了，因为无论是在方法使用方面还是实现方面我都介绍了一两个典型的例子，而其它的也就是以此类推，都可以看懂的了，看不懂你找我。

CAS机制，会引发什么问题，如何解决ABA问题？

（CAS会导致ABA问题，解决ABA问题是使用版本号机制）
CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。
CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。
CAS的缺点：
1.CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。
2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。
3.ABA问题
这是CAS机制最大的问题所在。
什么是ABA问题？
CAS：对于内存中的某一个值V，提供一个旧值A和一个新值B。如果提供的旧值V和A相等就把B写入V。这个过程是原子性的。
CAS执行结果要么成功要么失败，对于失败的情形下一班采用不断重试。或者放弃。
ABA：如果另一个线程修改V值假设原来是A，先修改成B，再修改回成A。当前线程的CAS操作无法分辨当前V值是否发生过变化。
引用原书的话：如果在算法中的节点可以被循环使用，那么在使用“比较并交换”指令就可能出现这种问题，在CAS操作中将判断“V的值是否仍然为A？”，并且如果是的话就继续执行更新操作，在某些算法中，如果V的值首先由A变为B，再由B变为A，那么CAS将会操作成功。
怎么避免ABA问题？
利用版本号比较可以有效解决ABA问题
Java中提供了AtomicStampedReference和AtomicMarkableReference来解决ABA问题。

悲观锁和乐观锁的区别，应用？（java中的Synchronized关键字和lock锁使用的都是悲观锁；CAS机制是乐观锁的一种实现方式）**

悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
乐观锁应用场景：
1、版本号机制（version方式）：
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
核心SQL代码：
update table set x=x+1, version=version+1 where id=#{id} and version=#{version};
2、CAS（定义见后）操作方式：
即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

公平锁和非公平锁（公平锁按照先来先服务，不会出现饥饿；非公平锁会导致饥饿，但是效率更高，默认的锁都是非公平的）**

公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。

• 优点：所有的线程都能得到资源，不会饿死在队列中。
• 缺点：吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大

非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。

• 优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。
• 缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。

自旋锁和互斥锁，自旋锁的优缺点？（优点：减少上下文切换和用户态内核态的切换带来的开销；缺点：循环等待消耗CPU）**

自旋锁（spinlock）：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。
获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。

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

临界区：每个进程中访问临界资源的那段程序称为临界区，每次只允许一个进程进入临界区，进入后不允许其他进程进入。
自旋锁的优缺点：自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能可以大幅度提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗，这些操作会导致线程发生两次上下文切换!
自旋锁的缺点：但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用cpu做无用功，同时有大量线程在竞争一个锁，会导致获取锁的时间很长，线程自旋的消耗大于线程阻塞挂起操作的消耗，其它需要cup的线程又不能获取到cpu，造成 cpu的浪费。所以这种情况下我们要关闭自旋锁；自旋锁时间阈值(1.6 引入了适应性自旋锁)

可重入锁和不可重入锁（不可重入锁容易导致死锁发生，大多数锁都是可重入的，例如Synchronized锁和ReentrantLock）**

不可重入锁
若当前线程执行中已经获取了锁，如果再次获取该锁时，就会获取不到被阻塞。
可重入锁
可重入就意味着：一个线程可以进入任何一个该线程已经拥有的锁所同步着的代码块
在java环境下，ReentrantLock和synchronized都是可重入锁

JDK1.6 Synchronized锁升级（偏向锁—轻量级锁—重量级锁）**

JDK1.6 之后做了一些优化，为了减少获得锁和释放锁带来 的性能开销，引入了偏向锁、轻量级锁的概念。因此大家 会发现在 synchronized 中，锁存在四种状态 分别是：无锁、偏向锁、轻量级锁、重量级锁； 锁的状态 根据竞争激烈的程度从低到高不断升级。
偏向锁的基本原理
前面说过，大部分情况下，锁不仅仅不存在多线程竞争， 而是总是由同一个线程多次获得，为了让线程获取锁的代价更低就引入了偏向锁的概念。怎么理解偏向锁呢？ 当一个线程访问加了同步锁的代码块时，会在对象头中存储当前线程的 ID，后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁。如果相等，表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁 了
回顾线程的竞争机制
再来回顾一下线程的竞争机制对于锁升级这块的一些基本 流程。
加入有这样一个同步代码块，存在 Thread#1、Thread#2 等 多个线程
情况一：只有 Thread#1 会进入临界区；
情况二：Thread#1 和 Thread#2 交替进入临界区,竞争不激 烈；
情况三：Thread#1/Thread#2/Thread3… 同时进入临界区， 竞争激烈
偏向锁
此时当 Thread#1 进入临界区时，JVM 会将 lockObject 的 对象头 Mark Word 的锁标志位设为“01”，同时会用 CAS 操作把 Thread#1 的线程 ID 记录到 Mark Word 中，此时进 入偏向模式。所谓“偏向”，指的是这个锁会偏向于 Thread#1， 若接下来没有其他线程进入临界区，则 Thread#1 再出入 临界区无需再执行任何同步操作。也就是说，若只有 Thread#1 会进入临界区，实际上只有 Thread#1 初次进入 临界区时需要执行 CAS 操作，以后再出入临界区都不会有 同步操作带来的开销。
轻量级锁
偏向锁的场景太过于理想化，更多的时候是 Thread#2 也 会尝试进入临界区， 如果 Thread#2 也进入临界区但是 Thread#1 还没有执行完同步代码块时，会暂停 Thread#1 并且升级到轻量级锁。Thread#2 通过自旋再次尝试以轻量 级锁的方式来获取锁
重量级锁
如果 Thread#1 和 Thread#2 正常交替执行，那么轻量级锁 基本能够满足锁的需求。但是如果 Thread#1 和 Thread#2 同时进入临界区，那么轻量级锁就会膨胀为重量级锁，意 味着 Thread#1 线程获得了重量级锁的情况下，Thread#2 就会被阻塞

Synchronized锁的底层实现，锁的是什么，其它线程如何判断该锁已经被占用了？**

synchronized作用

• 原子性：synchronized保证语句块内操作是原子的
• 可见性：synchronized保证可见性（通过“在执行unlock之前，必须先把此变量同步回主内存”实现）
• 有序性：synchronized保证有序性（通过“一个变量在同一时刻只允许一条线程对其进行lock操作”）

synchronized的底层实现：
synchronized的底层实现是完全依赖与JVM虚拟机的。
jvm基于进入和退出Monitor对象来实现方法同步和代码块同步
每一个锁都对应一个monitor对象，在HotSpot虚拟机中它是由ObjectMonitor实现的（C++实现）。每个对象都存在着一个monitor与之关联，对象与其monitor之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个monitor被某个线程持有后，它便处于锁定状态
所以谈synchronized的底层实现，就不得不谈数据在JVM内存的存储：Java对象头，以及Monitor对象监视器。
1.Java对象头
在JVM虚拟机中，对象在内存中的存储布局，可以分为三个区域:
对象头(Header)
实例数据(Instance Data)
对齐填充(Padding)
Java对象头主要包括两部分数据：
类型指针（Klass Pointer）：是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例;
标记字段(Mark Word)：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等,它是实现轻量级锁和偏向锁的关键.
2.Java锁对象存储位置
所以，很明显synchronized使用的锁对象是存储在Java对象头里的标记字段里。

3.Monitor
synchronized的对象锁，其指针指向的是一个monitor对象（由C++实现）的起始地址。每个对象实里都会有一个 monitor。
Monitor描述为对象监视器,可以类比为一个特殊的房间，这个房间中有一些被保护的数据，Monitor保证每次只能有一个线程能进入这个房间进行访问被保护的数据，进入房间即为持有Monitor，退出房间即为释放Monitor。
使用syncrhoized加锁的同步代码块在字节码引擎中执行时，主要就是通过锁对象的monitor的取用与释放来实现的。
jvm基于进入和退出Monitor对象来实现方法同步和代码块同步。
方法级的同步是隐式，即无需通过字节码指令来控制的，它实现在方法调用和返回操作之中。JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。当方法调用时，调用指令将会 检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先持有monitor（虚拟机规范中用的是管程一词）， 然后再执行方法，最后再方法完成(无论是正常完成还是非正常完成)时释放monitor。
代码块的同步是利用monitorenter和monitorexit这两个字节码指令。它们分别位于同步代码块的开始和结束位置。当jvm执行到monitorenter指令时，当前线程试图获取monitor对象的所有权，如果未加锁或者已经被当前线程所持有，就把锁的计数器+1；当执行monitorexit指令时，锁计数器-1；当锁计数器为0时，该锁就被释放了。如果获取monitor对象失败，该线程则会进入阻塞状态，直到其他线程释放锁。
同步代码块是通过 monitorenter 和 monitorexit 指令获取线程的执行权
同步方法通过加 ACC_SYNCHRONIZED 标识实现线程的执行权的控制

synchronized的使用：

• 修饰实例方法，对当前实例对象加锁
• 修饰静态方法，多当前类的Class对象加锁
• 修饰代码块，对synchronized括号内的对象加锁

死锁产生的四个必要条件以及死锁的处理策略

死锁：
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。

互斥条件：一个资源每次只能被一个进程使用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

四个必要条件是说，死锁必定要满足这四个，而不是满足了这四个就一定死锁，也许还要加上其它条件才会死锁。

以上这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

• 预防死锁：通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或几个条件，来防止死锁的发生。
• 避免死锁：在资源的动态分配过程中，用某种方法去防止系统进入不安全状态，从而避免死锁的发生。
• 检测死锁：允许系统在运行过程中发生死锁，但可设置检测机构及时检测死锁的发生，并采取适当措施加以清除。
• 解除死锁：当检测出死锁后，便采取适当措施将进程从死锁状态中解脱出来

高并发的情况下怎么保证下单不会超卖（也就是库存为负数）

1、可以设置事务
设置事务,在保存库存后若库存<0,进行回滚，根据返回的库存数对客户进行提示是否购买成功，这是在spring中解决问题

2、可以使用乐观锁机制，
乐观锁，大多是基于数据版本 Version ）记录机制实现。
可以给商品表加一个version字段，我们在实际减库存的SQL操作中，读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据
何谓数据版本？
即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来 实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，
1 假设数据库中帐户信息表中有一个 version 字段，当前值为1 ；而当前帐户余额字段（ balance ）为 $100 。操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
2 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并 从其帐户余额中扣除 $20 （ $100-$20 ）。
3 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣 除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大 于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数 据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的 数据版本号为 2 ，数据库记录当前版
本也为 2 ，不满足 “ 提交版本必须大于记 录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。 这样，就避免了操作员 B 用基于version=1 的旧数据修改的结果覆盖操作 员 A 的操作结果的可能。 从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A
和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系 统整体性能表现。 需要注意的是，乐观锁机制往往基于系统中的数据存储
逻辑，因此也具备一定的局 限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户 余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。