[toc]

## 理解Java编译流程

低级语言是计算机认识的语言、高级语言是程序员认识的语言。如何从高级语言转换成低级语言呢？这个过程其实就是编译。

不同的语言都有自己的编译器，Java语言中负责编译的编译器是一个命令：`javac`

通过`javac`命令将Java程序的源代码编译成Java字节码，即我们常说的.class文件。这也是我们所理解的编译.

但是.class并不是计算机能够识别的语言.要想让机器能够执行,需要把字节码再翻译成机器指令,这个过程是JVM来完成的.这个过程也叫编译.只是层次更深..

因此我们了解到,编译器可划分为`前端（Front End）`与`后端（Back End）`。

![QQ20180414-203816](http://www.hollischuang.com/wp-content/uploads/2018/04/QQ20180414-203816.png)

**我们可以把将`.java`文件编译成`.class`的编译过程称之为前端编译。把将`.class`文件翻译成机器指令的编译过程称之为后端编译。**

### 前端编译（Front End）

> 前端编译主要指与源语言有关但与目标机无关的部分，包括词法分析、语法分析、语义分析与中间代码生成。

例如我们使用很多的IDE，如eclipse，idea等，都内置了前端编译器。主要功能就是把`.java`代码转换成`.class字节码

### 后端编译（Back End）

> 后端编译主要指与目标机有关的部分，包括代码优化和目标代码生成等。

在后端编译中,通常都经过前端编译的处理,已经加工成.class字节码文件了 JVM通过`解释字节码`将其逐条读入并翻译为对应机器指令,读一条翻译一条,势必是分产生效率问题因此引入了JIT(just in time)

## 什么是JIT (Just in time)

> 当JVM发现某个方法或代码块运行特别频繁的时候，就会认为这是“热点代码”（Hot Spot Code)。JIT会把部分“热点代码”翻译成本地机器相关的机器码，并进行**优化**，然后`缓存`起来，以备下次使用

在HotSpot虚拟机中内置了两个`JIT编译器`分别是:

	- Client complier  [客户端]
	- Server complier  [服务端]

目前JVM中默认都是采用:    解释器+一个JIT编译器    配合的方式进行工作 即`混合模式`

下图是我机器上安装的JDK ,可以看出,使用的JIT是Server Complier, 解释器和JIT的工作方式是mixed mode

![image-20210312145623034](/Users/tengyu/Library/Application Support/typora-user-images/image-20210312145623034.png)

> 面试题:为何HotSpot虚拟机要实现两个不同的即时编译器？

HotSpot虚拟机中内置了两个即时编译器：Client Complier和Server Complier，简称为C1、C2编译器，分别用在客户端和服务端。目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。程序使用哪个编译器，取决于虚拟机运行的模式。HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。

用Client Complier获取更高的*编译速度*，用Server Complier 来获取更好的*编译质量*。和为什么提供多个垃圾收集器类似，都是为了适应不同的应用场景。







### 编译器和解释器的优缺点以及实用场景

> 在JVM执行代码时,它并不是马上开始编译代码,当一段经常被执行的代码被编译后,下次运行就不用重复编译,此时使用JIT是划算的,但是它也不是万能的,比如说一些极少执行的代码在编译时花费的时间比解释器还久,这时就是得不偿失了

所以,解释器和JIT各有千秋:

解释器与编译器两者各有优势：当程序需要*迅速启动和执行*的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取*更高的执行效率*。

1. 当极少执行或者执行次数较少的JAVA代码使用解释器最优.
2. 当重复执行或者执行次数较多的JAVA代码使用JIT更划算.



### 热点检测算法

要想触发JIT，首先需要识别出热点代码。目前主要的热点代码识别方式是热点探测（Hot Spot Detection），有以下两种：

### 1）基于采样的热点探测
采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某些方法经常出现在栈顶，那这个方法就是“热点方法”。这种探测方法的好处是实现简单高效，还可以很容易地获取方法调用关系（将调用堆栈展开即可），缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。

### 2)  基于计数器的热点探测

采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阀值，就认为它是“热点方法”。这种统计方法实现复杂一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对更加精确严谨。

> 那么在HotSpot虚拟机中使用的是哪个热点检测方式呢？

在HotSpot虚拟机中使用的是第二种,基于计数器的热点探测方法，因此它为每个方法准备了`两个计数器`：

#### >1 *方法调用计数器*

> 顾名思义，就是记录一个方法被调用次数的计数器。

#### >2 *回边计数器*

> 是记录方法中的for或者while的运行次数的计数器。

在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

## 对象栈上分配的优化

### 逃逸分析

> 逃逸分析是一种有效减少JAVA程序中 ` 同步负载` 和 `堆内存分配压力` 的分析算法.Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到`栈`上.

 

```java
public static StringBuffer method(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append("关注");
    sb.append("java宝典");
    return sb;
  	//此时sb对象从method方法逃出..
}
```

```java
public static String method(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append("关注");
    sb.append("java宝典");
    return sb.toString();
  	//此时sb对象 没有离开 作用域
}
```



```java
    public void globalVariableEscape(){
        globalVariableObject = new Object(); //静态变量,外部线程可见,发生逃逸
    }

    public void instanceObjectEscape(){
        instanceObject = new Object(); //赋值给堆中实例字段,外部线程可见,发生逃逸
    }
```

**在确定对象不会逃逸后,JIT将可以进行以下优化:  标量替换  同步消除 栈上分配**



第一段代码中的`sb`就逃逸了，而第二段代码中的`sb`就没有逃逸。



在Java代码运行时，通过JVM参数可指定是否开启逃逸分析，

`-XX:+DoEscapeAnalysis` ： 表示开启逃逸分析

`-XX:-DoEscapeAnalysis` ： 表示关闭逃逸分析 

`-XX:+PrintEscapeAnalysis`  开启打印逃逸分析筛选结果

`从jdk 1.7开始已经默认开始逃逸分析`



### 标量替换

允许将对象打散分配在栈上，比如若一个对象拥有两个字段，会将这两个字段视作局部变量进行分配。

逸分析只是栈上内存分配的前提，还需要进行**标量替换**才能真正实现。例:

```java
public static void main(String[] args) throws Exception {
    long start = System.currentTimeMillis();
    for (int i = 0; i < 10000; i++) {
        allocate();
    }
    System.out.println((System.currentTimeMillis() - start) + " ms");
    Thread.sleep(10000);
}
public static void allocate() {
    MyObject myObject = new MyObject(2019, 2019.0);
}
public static class MyObject {
    int a;
    double b;
    MyObject(int a, double b) {
        this.a = a;
        this.b = b;
    }
}
```

**标量，就是指JVM中无法再细分的数据，比如int、long、reference等。相对地，能够再细分的数据叫做聚合量**

Java虚拟机中的原始数据类型（int，long等数值类型以及reference类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它称为聚合量，Java中最典型的聚合量是对象

如果逃逸分析证明一个对象不会被外部访问，并且这个对象是可分解的，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。拆散后的变量便可以被单独分析与优化，可以各自分别在栈帧或寄存器上分配空间，原本的对象就无需整体分配空间了

仍然考虑上面的例子，MyObject就是一个聚合量，因为它由两个标量a、b组成。通过逃逸分析，JVM会发现myObject没有逃逸出allocate()方法的作用域，标量替换过程就会将myObject直接拆解成a和b，也就是变成了：

```java
static void allocate() {
    int a = 2019;
    double b = 2019.0;
}
```



可见，对象的分配完全被消灭了，而int、double都是基本数据类型，直接在栈上分配就可以了。所以，在对象不逃逸出作用域并且能够分解为纯标量表示时，对象就可以在栈上分配

- 开启标量替换 (-XX:+EliminateAllocations)

标量替换的作用是允许将对象根据属性打散后分配在栈上，默认该配置为开启



### 同步消除(锁消除)

> 如果同步块所使用的锁对象通过逃逸分析被证实只能够被一个线程访问，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这个取消同步的过程就叫同步省略，也叫锁消除

例子:

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

在经过逃逸分析后,JIT编译阶段会被优化成:

```java
public void f() {
    Object java_bible = new Object();
    System.out.println(java_bible);  //锁被去掉了.
}
```

如果JIT经过逃逸分析之后发现并无线程安全问题的话，就会做锁消除。





## 栈上分配

 通过逃逸分析,我们发现,许多对象的**生命周期会随着方法的调用开始而开始，方法的调用结束而结束**,很多的对象的作用域都不会逃逸出方法外,对于此种对象,我们可以考虑使用栈上分配,而不是在堆中分配.

因为一旦分配在堆空间中，当方法调用结束，没有了引用指向该对象，该对象就需要被gc回收，而如果存在大量的这种情况，对gc来说反而是一种负担。

JVM提供了一种叫做栈上分配的概念，针对那些**作用域不会逃逸出方法的对象**，在分配内存时不在将对象分配在堆内存中，而是将对象属性**打散后分配在栈（线程私有的，属于栈内存,标量替换）上**，这样，随着方法的调用结束，栈空间的回收就会随着将栈上分配的打散后的对象回收掉，不再给gc增加额外的无用负担，从而提升应用程序整体的性能

那么问题来了,如果栈上分配失败了怎么办?

## 对象的内存分配

创建个对象有多种方法: 比如 使用new  , reflect , clone 不管使用哪种 ,我们都要先分配内存

我们拿new 来举个例子:

```java
T t = new T()
  
class T{
	int m = 8;
}

//javap
  
0 new #2<T>		//new作用在内存申请开辟一块空间 new完之后m的值为 0
3 dup 
4 invokespecial #3 <T.<init>>  
7 astore_1	
8 return
```

那么它是怎么分配的呢?

当我们使用new创建对象后代码开始运行后，虚拟机执行到这条new指令的时候，会先检查要new的对象对应的类是否已被加载，如果没有被加载则先进行类加载,检查通过之后，就需要给对象进行内存分配，分配的内存主要用来存放对象的实例变量

为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来

根据内存连续和不连续的情况,JVM使用不同的分配方式.

- 连续: 指针碰撞
- 不连续:空闲列表

`指针碰撞`(Serial、ParNew等带Compact过程的收集器)
假设Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump the Pointer）。

`空闲列表`(CMS这种基于Mark-Sweep算法的收集器)
如果Java堆中的内存并不是规整的，已使用的内存和空闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”（Free List）。



无论那种方式，最终都需要确定出一块内存区域，用于给新建对象分配内存。对象的内存分配过程中，主要是对象的引用指向这个内存区域，然后进行初始化操作,那么在并发场景之中,如果多线程并发去堆中获取内存区域,怎么保证`内存分配`的`线程安全性`.



## 解决堆内存分配的并发问题

保证分配过程中的线程安全有两种方式:

- CAS  
- TLAB



### CAS 

`CAS`:采用CAS机制，配合失败重试的方式保证线程安全性

CAS对于内存的控制是使用重试机制,因此效率比较低,目前JVM使用的是`TLAB方式`,我们着重介绍TLAB.

### TLAB

`TLAB`:每个线程在`Java堆`中预先分配一小块内存，然后再给对象分配内存的时候，直接在自己这块"私有"内存中分配，当这部分区域用完之后，再分配新的"私有"内存,注意这个`私有`对于创建对象时是私有的,但是对于读取是共享的.



TLAB (Thread local allcation buffer ) 在“分配”这个动作上是线程独占的，至于在读取、垃圾回收等动作上都是线程共享的。在对象的创建时,首先尝试进行栈上分配,如果分配失败,会使用TLAB尝试分配,如果失败查看是否是大对象,如果是大对象直接进入老年代,否则进入新生代(Eden).这里我总结了一张流程图,如下:





![image-20210312094505064](/Users/tengyu/Library/Application Support/typora-user-images/image-20210312094505064.png)





我们可以总结出: 创建大对象和创建多个小对象相比,多个小对象的效率更高

不知道大家有没有注意到,TLAB分配空间,每个线程在`Java堆`中预先分配一小块内存,他们在堆中去抢地盘的时候,也会出现并发问题,但是对于TLAB的同步控制和我们直接在堆中分配相比效率高了不少(不至于因为要分配一个对象而锁住整个堆了).

## 总结

为了保证Java对象的内存分配的安全性，同时提升效率，每个线程在Java堆中可以预先分配一小块内存，这部分内存称之为TLAB（Thread Local Allocation Buffer）,这块内存的分配时线程独占的，读取、使用、回收是线程共享的。

虚拟机是否使用TLAB  可以通过  `-XX:+/-UseTLAB `     参数指定



JVM分配对象空间创建实例的流程

Redis是目前最为主流的缓存技术之一，Redis基于内存操作从而拥有强大的性能，可以达到每秒10万次的请求，可以说是一款非常强大的缓存技术了。

本文分为三部分：

- 基础知识介绍
- 常用技术讲解与缓存机制
- 使用场景、缓存问题

# 基础知识介绍

**NoSQL概述**

什么是NoSQL？

NoSQL = Not Only SQL （不仅仅是SQL）

关系型数据库：表格 ，行 ，列

非关系型数据库：没有固定的查询语言，键值对存储，列存储，文档存储

随着web2.0互联网的诞生！传统的关系型数据库很难对付web2.0时代！尤其是超大规模的高并发的社区。



NoSQL 特点

1、方便扩展

2、大数据量高性能（Redis 一秒写8万次，读取11万）

3、数据类型是多样性的



NoSQL四大分类

KV键值对：如Redis主要是用于内容缓存，主要是为了处理大量数据高访问负载

文档型数据库：如MongoDBMongoDB 是一个基于分布式文件存储的数据库

列存储数据库：如HBase分布式文件系统，以列簇式存储，将同一列数据存储在一起

图关系数据库：如Neo4j他不是存图形，放的是关系，比如：朋友圈社交网络，广告推荐！



**Redis简介**

Redis 是什么？

Redis（Remote Dictionary Server )，即远程字典服务，它是一个开源的由ANSI C语言编写，性能优秀、支持网络、可持久化的Key-Value内存的NoSQL数据库!



Redis 能干嘛？

1、内存存储、持久化。

2、效率高，可以用于高速缓存

3、发布订阅系统

4、计时器、浏览量！

 5、........



**Redis好处**

主要从“高性能”和“高并发”这两点来介绍。

![Redis缓存机制与应用](https://p6-tt.byteimg.com/origin/pgc-image/7ede911b397f470f93ec818318fce4f6?from=pc)

把数据库数据存入缓存，请求直接从内存中读取不用经过数据库，减轻数据库压力并且提升性能。

# 常用技术讲解与缓存机制

Redis主要有5种数据类型，包括String，List，Set，Zset，Hash，满足大部分的使用要求

**String**

- String：session、对象、小文件（存文件流字节数组，比磁盘IO快）？
- int：秒杀、限流、计数
- bitmap：

场景1.setbit和bitcount结合可以统计一年365天哪天有用户操作过，getbit可以获取某一天是否用户操作过

场景2.权限控制，比如每个权限对应一个bit,哪个用户有该权限，该位为1，没权限为0

**list**

替换java jvm中的集合，可以作为数据共享，java的话多进程间不能共享或不好共享

**hash**

可以使redis key变少，类似对象。

场景1.商品详情页、商品对应的收藏数、库存啊，放在redis中因为是原子性的，多地方访问都是实时性的

场景2.聚合场景：一个对象在数据库中可能各个属性在不同表，可以聚合到redis同个对象中

**set**

set性能慢，可以单独redis实例

场景1.SRANDMEMBER或者spop命令可以用来抽奖

场景2.随机事件

场景3.共同好友（交集）

场景4.推荐好友（差集）

**sorted_set**

有序集合，数量少时底层是zipList压缩表，数据多了变skiplist

场景1.排行榜

场景2.有序事件

场景3.评论分页

![Redis缓存机制与应用](https://p3-tt.byteimg.com/origin/pgc-image/6ddde37802934a2b8e4a1717f732387e?from=pc)

Redis 中除开最常用的 5 种数据类型之外，还有 3 种特殊的数据类型

![Redis缓存机制与应用](https://p6-tt.byteimg.com/origin/pgc-image/b8e2cd5aec574ebab34e50602b9869a4?from=pc)

可以通过help命令查询相关类型命令说明，比如：

```
help @string help @list1
```

 

**事务**

Redis 事务本质：一组命令的集合！ 一个事务中的所有命令都会被序列化，在事务执行过程的中，会按照顺序执行！

Redis单条命令式保存原子性的，但是事务不保证原子性！

```
# 开启事务 
multi  

#命令入队 
set k1 v1 
set k2 v2   
get k2    


# 执行事务
exec   1
```

![Redis缓存机制与应用](https://p6-tt.byteimg.com/origin/pgc-image/44064f827927434aa3f4d7789a9249a6?from=pc)



**Redis持久化**

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

redis提供两种持久化机制 RDB（默认） 和 AOF 机制。

1、RDB

RDB是Redis DataBase缩写快照 ，默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb

![Redis缓存机制与应用](https://p1-tt.byteimg.com/origin/pgc-image/deb121beff13408ab6532b014b07a7af?from=pc)

触发机制

（1）save的规则满足的情况下

（2）执行 flushall 命令

（3）退出redis，也会产生 rdb 文件



2、AOF：

持久化，AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

![Redis缓存机制与应用](https://p3-tt.byteimg.com/origin/pgc-image/cb60ccda14e644a2872d5d25fcadd34b?from=pc)

AOF的三种策略（1）always （2）everysec(默认值) （3）no always



![Redis缓存机制与应用](https://p1-tt.byteimg.com/origin/pgc-image/6767598bca44402b89881933b24b16ff?from=pc)

在应用时，要根据自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。



**redis主从复制**

概念主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。

优点：（1）读写分离 （2）备份

缺点：主服务器宕机，需要人工启动

![Redis缓存机制与应用](https://p1-tt.byteimg.com/origin/pgc-image/9297dd62499a485fb25f1c602f18f956?from=pc)


**哨兵模式**

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

![Redis缓存机制与应用](https://p3-tt.byteimg.com/origin/pgc-image/7b7765c3fc0c4523ae2193355945a56d?from=pc)



# 使用场景、缓存问题

1、热点数据的缓存

公司项目用户量达到一定数量的时候，这时合理的利用缓存不仅能够提升项目访问速度，还能大大降低数据库的压力。

2、业务上的统计，排行榜

为了保证数据实时效，比如项目的访问量，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力

3、限时业务的运用

每日签到、限制登录功能等业务场景

4、消息队列

提供基本的发布订阅功能，但不像消息队列那种专业级别



**缓存雪崩**

原因：大量redis key在同一时间失效，导致大量请求访问数据库，数据库服务器宕机，线上服务大面积报错。

解决办法：

（1）redis高可用

（2）加锁排队，限流降级

（3）缓存失效时间均匀分布

![Redis缓存机制与应用](https://p1-tt.byteimg.com/origin/pgc-image/e387882067f24a498f52a740534e50e4?from=pc)



**缓存穿透**

原因：指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决办法： （1）接口层增加校验 （2）采用布隆过滤器

![Redis缓存机制与应用](https://p6-tt.byteimg.com/origin/pgc-image/9dce9ecc50fd4eb992babd6076787155?from=pc)

**缓存击穿**

原因：指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。比如微博热搜。

解决办法：

（1）设置热点数据缓存没有过期时间

（2）加互斥锁

![Redis缓存机制与应用](https://p6-tt.byteimg.com/origin/pgc-image/a5c4853f4b6249649895a970bb433d62?from=pc)



好了就介绍到这了，可以自己动手尝试吧。

Redis缓存机制与应用

**AQS**是`AbstractQueuedSynchronizer`的简称，即`抽象队列同步器`，从字面意思上理解:

- 抽象：抽象类，只实现一些主要逻辑，有些方法由子类实现；
- 队列：使用先进先出（FIFO）队列存储数据；
- 同步：实现了同步的功能。

那AQS有什么用呢？AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的同步器，比如我们提到的ReentrantLock，Semaphore，ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。

当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器，只要之类实现它的几个`protected`方法就可以了，在下文会有详细的介绍。

# ** AQS的数据结构**

AQS内部使用了一个volatile的变量state来作为资源的标识。同时定义了几个获取和改版state的protected方法，子类可以覆盖这些方法来实现自己的逻辑：



```
getState()
setState()
compareAndSetState()
```

这三种叫做均是原子操作，其中compareAndSetState的实现依赖于Unsafe的compareAndSwapInt()方法。

而AQS类本身实现的是一些排队和阻塞的机制，比如具体线程等待队列的维护（如获取资源失败入队/唤醒出队等）。它内部使用了一个先进先出（FIFO）的双端队列，并使用了两个指针head和tail用于标识队列的头部和尾部。其数据结构如图：

![img](https://gblobscdn.gitbook.com/assets%2F-L_5HvtIhTFW9TQlOF8e%2F-L_5TIKcBFHWPtY3OwUo%2F-L_5TJQjOPACL_iNG1yE%2FAQS%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84.png?alt=media)

 

但它并不是直接储存线程，而是储存拥有线程的Node节点。

# **11.3 资源共享模式**

资源有两种共享模式，或者说两种同步方式：

- 独占模式（Exclusive）：资源是独占的，一次只能一个线程获取。如ReentrantLock。
- 共享模式（Share）：同时可以被多个线程获取，具体的资源个数可以通过参数指定。如Semaphore/CountDownLatch。

一般情况下，子类只需要根据需求实现其中一种模式，当然也有同时实现两种模式的同步类，如`ReadWriteLock`。

AQS中关于这两种资源共享模式的定义源码（均在内部类Node中）。我们来看看Node的结构：



```
static final class Node {
    // 标记一个结点（对应的线程）在共享模式下等待
    static final Node SHARED = new Node();
    // 标记一个结点（对应的线程）在独占模式下等待
    static final Node EXCLUSIVE = null; 

    // waitStatus的值，表示该结点（对应的线程）已被取消
    static final int CANCELLED = 1; 
    // waitStatus的值，表示后继结点（对应的线程）需要被唤醒
    static final int SIGNAL = -1;
    // waitStatus的值，表示该结点（对应的线程）在等待某一条件
    static final int CONDITION = -2;
    /*waitStatus的值，表示有资源可用，新head结点需要继续唤醒后继结点（共享模式下，多线程并发释放资源，而head唤醒其后继结点后，需要把多出来的资源留给后面的结点；设置新的head结点时，会继续唤醒其后继结点）*/
    static final int PROPAGATE = -3;

    // 等待状态，取值范围，-3，-2，-1，0，1
    volatile int waitStatus;
    volatile Node prev; // 前驱结点
    volatile Node next; // 后继结点
    volatile Thread thread; // 结点对应的线程
    Node nextWaiter; // 等待队列里下一个等待条件的结点


    // 判断共享模式的方法
    final boolean isShared() {
        return nextWaiter == SHARED;
    }

    Node(Thread thread, Node mode) {     // Used by addWaiter
        this.nextWaiter = mode;
        this.thread = thread;
    }

    // 其它方法忽略，可以参考具体的源码
}

// AQS里面的addWaiter私有方法
private Node addWaiter(Node mode) {
    // 使用了Node的这个构造函数
    Node node = new Node(Thread.currentThread(), mode);
    // 其它代码省略
}
```

> 注意：通过Node我们可以实现两个队列，一是通过prev和next实现CLH队列(线程同步队列,双向队列)，二是nextWaiter实现Condition条件上的等待线程队列(单向队列)，这个Condition主要用在ReentrantLock类中。

# **11.4 AQS的主要方法源码解析**

AQS的设计是基于**模板方法模式**的，它有一些方法必须要子类去实现的，它们主要有：

- isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
- tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
- tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
- tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

这些方法虽然都是`protected`方法，但是它们并没有在AQS具体实现，而是直接抛出异常（虽然不知道这里为什么不使用抽象方法的实现方式）：



```
protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}
```

而AQS实现了一系列主要的逻辑。下面我们从源码来分析一下获取和释放资源的主要逻辑：

## **11.4.1 获取资源**

获取资源的入口是acquire(int arg)方法。arg是要获取的资源的个数，在独占模式下始终为1。我们先来看看这个方法的逻辑：



```
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
```

首先调用tryAcquire(arg)尝试去获取资源。前面提到了这个方法是在子类具体实现的。

如果获取资源失败，就通过addWaiter(Node.EXCLUSIVE)方法把这个线程插入到等待队列中。其中传入的参数代表要插入的Node是独占式的。这个方法的具体实现：



```
private Node addWaiter(Node mode) {
    // 生成该线程对应的Node节点
    Node node = new Node(Thread.currentThread(), mode);
    // 将Node插入队列中
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        // 使用CAS尝试，如果成功就返回
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    // 如果等待队列为空或者上述CAS失败，再自旋CAS插入
    enq(node);
    return node;
}

// 自旋CAS插入等待队列
private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) { // Must initialize
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}
```

> 上面的两个函数比较好理解，就是在队列的尾部插入新的Node节点，但是需要注意的是由于AQS中会存在多个线程同时争夺资源的情况，因此肯定会出现多个线程同时插入节点的操作，在这里是通过CAS自旋的方式保证了操作的线程安全性。

OK，现在回到最开始的aquire(int arg)方法。现在通过addWaiter方法，已经把一个Node放到等待队列尾部了。而处于等待队列的结点是从头结点一个一个去获取资源的。具体的实现我们来看看acquireQueued方法



```
final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        // 自旋
        for (;;) {
            final Node p = node.predecessor();
            // 如果node的前驱结点p是head，表示node是第二个结点，就可以尝试去获取资源了
            if (p == head && tryAcquire(arg)) {
                // 拿到资源后，将head指向该结点。
                // 所以head所指的结点，就是当前获取到资源的那个结点或null。
                setHead(node); 
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            // 如果自己可以休息了，就进入waiting状态，直到被unpark()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}
```

> 这里parkAndCheckInterrupt方法内部使用到了LockSupport.park(this)，顺便简单介绍一下park。
>
> LockSupport类是Java 6 引入的一个类，提供了基本的线程同步原语。LockSupport实际上是调用了Unsafe类里的函数，归结到Unsafe里，只有两个函数：
>
> - park(boolean isAbsolute, long time)：阻塞当前线程
> - unpark(Thread jthread)：使给定的线程停止阻塞

所以**结点进入等待队列后，是调用park使它进入阻塞状态的。只有头结点的线程是处于活跃状态的**。

当然，获取资源的方法除了acquire外，还有以下三个：

- acquireInterruptibly：申请可中断的资源（独占模式）
- acquireShared：申请共享模式的资源
- acquireSharedInterruptibly：申请可中断的资源（共享模式）

> 可中断的意思是，在线程中断时可能会抛出`InterruptedException`

总结起来的一个流程图：

![img](https://gblobscdn.gitbook.com/assets%2F-L_5HvtIhTFW9TQlOF8e%2F-L_5TIKcBFHWPtY3OwUo%2F-L_5TJQpo8U_q8r9AJ5q%2Facquire%E6%B5%81%E7%A8%8B.jpg?alt=media)

acquire流程

# **11.4.2 释放资源**

释放资源相比于获取资源来说，会简单许多。在AQS中只有一小段实现。源码：



```
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

private void unparkSuccessor(Node node) {
    // 如果状态是负数，尝试把它设置为0
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);
    // 得到头结点的后继结点head.next
    Node s = node.next;
    // 如果这个后继结点为空或者状态大于0
    // 通过前面的定义我们知道，大于0只有一种可能，就是这个结点已被取消
    if (s == null || s.waitStatus > 0) {
        s = null;
        // 等待队列中所有还有用的结点，都向前移动
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    // 如果后继结点不为空，
    if (s != null)
        LockSupport.unpark(s.thread);
}
```

 

 AQS的数据结构



## 事务的特性(ACID)

群里有小伙伴面试时,碰到面试官提了个很刁钻的问题:

`Mysql为何使用可重复读(Repeatable read)为默认隔离级别???`  

下面进入正题:

我们都知道事务的几种性质 :`原子性`、`一致性`、`隔离性`和`持久性`  (ACID) 

为了维持一致性和隔离性,一般使用加锁这种方式来处理,但是加锁相对带来的是并发处理能力的降低

而数据库是个高并发的应用,因此对于加锁的处理是事务的精髓.

下面我们来了解一下封锁协议,以及事务在数据库中做了什么

## 封锁协议（Locking Protocol）



> MySQL的锁系统：shared lock 和 exclusive lock  即共享锁和排他锁，也叫读锁(S)和写锁(X),共享锁和排他锁都属于悲观锁。排他锁又可以可以分为行锁和表锁。

`封锁协议（Locking Protocol）`: 在使用X锁或S锁对数据加锁时,约定的一些规则.例如何时申请X或S锁,持续时间,何时释放锁等.



### 一级、二级、三级封锁协议

> 对封锁方式规定不同的规则，就形成了各种不同的封锁协议,不同的封锁协议，为并发操作的正确性提供不同程度的保证



####  一级封锁协议

> 一级封锁协议定义：事务T在修改数据R之前必须先对其加X锁(排他锁)，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。

 		一级封锁协议可以防止丢失修改，并保证事务T是可恢复的。使用一级封锁协议可以解决丢失修改问题。
 在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，它不能保证可重复读和不读“脏”数据。　　

#### 二级封锁协议

> 二级封锁协议定义：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁(共享锁)，读完后释放S锁。事务的加锁和解锁严格分为两个阶段，第一阶段加锁，第二阶段解锁。

* `加锁阶段`: 在对任何数据进行读操作之前要申请并获得S锁（共享锁，其它事务可以继续加共享锁，但不能加排它锁），在进行写操作之前要申请并获得X锁（排它锁，其它事务不能再获得任何锁）。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。

* `解锁阶段`:当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。

　　 二级封锁协议除防止了丢失修改，还可以进一步防止读“脏”数据。但在二级封锁协议中，由于读完数据后释放S锁，所以它不能保证可重复读。

​		二级封锁的目的是保证并发调度的正确性。就是说，如果事务满足两段锁协议，那么事务的并发调度策略是串行性的。保证事务的并发调度是串行化（串行化很重要，尤其是在数据恢复和备份的时候）
　　

#### 三级封锁协议 

> 三级封锁协议定义：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁(共享锁)，直到事务结束才释放。在一级封锁协议（一级封锁协议：修改之前先加X锁，事务完成释放）的基础上加上S锁，事务结束后释放S锁

　　三级封锁协议除防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。
上述三级协议的主要区别在于什么操作需要申请封锁，以及何时释放。



## 事务四种隔离级别

在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。`上面提到的封锁协议 ，也是为了构建这些隔离级别存在的。`

| 隔离级别                        | 脏读（Dirty Read） | 不可重复读（NonRepeatable Read） | 幻读（Phantom Read） |
| ------------------------------- | ------------------ | -------------------------------- | -------------------- |
| 未提交读（Read uncommitted）    | 可能               | 可能                             | 可能                 |
| 已提交读（Read committed）      | 不可能             | 可能                             | 可能                 |
| **可重复读（Repeatable read）** | **不可**能         | **不可**能                       | **可能**             |
| 可串行化（Serializable ）       | 不可能             | 不可能                           | 不可能               |

对于事务并发访问会产生的问题,以及各隔离级别的详细介绍在我的上一篇文章

[一文搞懂事务](https://mp.weixin.qq.com/s/9-I6aWl_4Avjele0ykhwEQ)



## 为什么是RR

一般的DBMS系统，默认都会使用读提交（Read-Comitted，RC）作为默认隔离级别，如Oracle、SQL Server等，而MySQL却使用可重复读（Read-Repeatable，RR）。要知道，越高的隔离级别，能解决的数据一致性问题越多，理论上性能的损耗更大，且并发性越低。隔离级别依次为: `SERIALIZABLE > RR > RC > RU`



我们可以通过以下语句设置和获取数据库的隔离级别:

查看系统的隔离级别:

```mysql
mysql> select @@global.tx_isolation isolation;
+-----------------+
| isolation       |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set, 1 warning (0.00 sec)
```

查看当前会话的 隔离级别:

```mysql
mysql> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+
1 row in set, 1 warning (0.00 sec)
```



设置会话的隔离级别，隔离级别由低到高设置依次为:

```mysql
set session transacton isolation level read uncommitted;
set session transacton isolation level read committed;
set session transacton isolation level repeatable read;
set session transacton isolation level serializable;
```

 

设置当前系统的隔离级别，隔离级别由低到高设置依次为:

```mysql
set global transacton isolation level read uncommitted;
set global transacton isolation level read committed;
set global transacton isolation level repeatable read;
set global transacton isolation level serializable;
```



> 可重复读(Repeated Read)：可重复读。基于锁机制并发控制的DBMS需要对选定对象的读锁(read locks)和写锁(write locks)一直保持到事务结束，但不要求“范围锁(range-locks)”，因此可能会发生“幻影读(phantom reads)”
> 在该事务级别下，保证同一个事务从开始到结束获取到的数据一致。是Mysql的默认事务级别。 

下面我们先来思考2个问题

* **在读已提交(Read Commited)级别下，出现不可重复读问题怎么办?需要解决么？**

不用解决，这个问题是可以接受的！毕竟你数据都已经提交了，读出来本身就没有太大问题！Oracle ,SqlServer 默认隔离级别就是RC，我们也没有更改过它的默认隔离级别.

* **在Oracle，SqlServer中都是选择读已提交(Read Commited)作为默认的隔离级别**，**为什么Mysql不选择读已提交(Read Commited)作为默认隔离级别，而选择可重复读(Repeatable Read)作为默认的隔离级别呢？**

历史原因,早阶段Mysql(5.1版本之前)的Binlog类型Statement是默认格式，即依次记录系统接受的SQL请求；5.1及以后，MySQL提供了Row,Mixed,statement  3种Binlog格式, 当binlog为statement格式,使用RC隔离级别时,会出现`BUG`**因此Mysql将可重复读(Repeatable Read)作为默认的隔离级别！**



## Binlog简介

> Mysql binlog是二进制日志文件，用于记录mysql的数据更新或者潜在更新(比如DELETE语句执行删除而实际并没有符合条件的数据)，在mysql主从复制中就是依靠的binlog。可以通过语句“show binlog events in 'binlogfile'”来查看binlog的具体事件类型。binlog记录的所有操作实际上都有对应的事件类型的

MySQL binlog的三种工作模式：
`Row `（用到MySQL的特殊功能如存储过程、触发器、函数，又希望数据最大化一直则选择Row模式，我们公司选择的是row）
简介：日志中会记录每一行数据被修改的情况，然后在slave端对相同的数据进行修改。
优点：能清楚的记录每一行数据修改的细节
缺点：数据量太大

` Statement （默认）`
简介：每一条被修改数据的sql都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql再次执行。在主从同步中一般是不建议用statement模式的，因为会有些语句不支持，比如语句中包含UUID函数，以及LOAD DATA IN FILE语句等
优点：解决了 Row level下的缺点，不需要记录每一行的数据变化，减少bin-log日志量，节约磁盘IO，提高新能
缺点：容易出现主从复制不一致

 `Mixed（混合模式）`
简介：结合了Row level和Statement level的优点，同时binlog结构也更复杂。

 我们可以简单理解为binlog是一个`记录数据库更改`的`文件`,主从复制时需要此文件,具体细节先略过



## 主从不一致实操

binlog为`STATEMENT`格式，且隔离级别为**读已提交(Read Commited)**时，有什么bug呢？
测试表:

```mysql
mysql> select * from test;
+----+------+------+
| id | name | age  |
+----+------+------+
|  1 | NULL | NULL |
|  2 | NULL | NULL |
|  3 | NULL | NULL |
|  4 | NULL | NULL |
|  5 | NULL | NULL |
|  6 | NULL | NULL |
+----+------+------+
6 rows in set (0.00 sec)

```

| Session1                                                     | Session2                                                     |
| :----------------------------------------------------------- | ------------------------------------------------------------ |
| mysql> set tx_isolation = 'read-committed';
Query OK, 0 rows affected, 1 warning (0.00 sec) | mysql> set tx_isolation = 'read-committed';
Query OK, 0 rows affected, 1 warning (0.00 sec) |
| begin;<br />Query OK, 0 rows affected (0.00 sec)             | begin;<br />Query OK, 0 rows affected (0.00 sec)             |
| delete from test where 1=1;
Query OK, 6 rows affected (0.00 sec) |                                                              |
|                                                              | insert into test values (null,'name',100);
Query OK, 1 row affected (0.00 sec) |
|                                                              | commit;
Query OK, 0 rows affected (0.01 sec)                  |
| commit;
Query OK, 0 rows affected (0.01 sec)                  |                                                              |

Master此时输出

```mysql
select * from test;
+----+------+------+
| id | name | age  |
+----+------+------+
|  7 | name |  100 |
+----+------+------+
1 row in set (0.00 sec)

```

但是，你在此时在从(slave)上执行该语句，得出输出

```mysql

mysql> select * from test;
Empty set (0.00 sec)

```

在master上执行的顺序为先删后插！而此时binlog为STATEMENT格式，是基于事务记录，在事务未提交前，二进制日志先缓存，提交后再写入记录的,因此顺序为先插后删！slave同步的是binglog，因此从机执行的顺序和主机不一致！slave在插入后删除了所有数据.

解决方案有两种！
(1)隔离级别设为**可重复读(Repeatable Read)**,在该隔离级别下引入间隙锁。当`Session 1`执行delete语句时，会锁住间隙。那么，`Ssession 2`执行插入语句就会阻塞住！
(2)将binglog的格式修改为row格式，此时是基于行的复制，自然就不会出现sql执行顺序不一样的问题！奈何这个格式在mysql5.1版本开始才引入。因此由于历史原因，mysql将默认的隔离级别设为**可重复读(Repeatable Read)**，保证主从复制不出问题！

## RU和Serializable

项目中不太使用**读未提交(Read UnCommitted)**和**串行化(Serializable)**两个隔离级别，原因:

**读未提交(Read UnCommitted)**

允许脏读，也就是可能读取到其他会话中未提交事务修改的数据	一个事务读到另一个事务未提交读数据

**串行化(Serializable)**

使用的悲观锁的理论，实现简单，数据更加安全，但是并发能力非常差。如果你的业务并发的特别少或者没有并发，同时又要求数据及时可靠的话，可以使用这种模式。一般是使用mysql自带分布式事务功能时才使用该隔离级别



## RC和 RR

此时我们纠结的应该就只有一个问题了:隔离级别是用`读已提交`还是`可重复读`？

接下来对这两种级别进行对比的第一种情况:

**在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！**

### 实现一个简单的间隙锁例子

```mysql
select * from test where id <11 ;
+----+------+------+
| id | name | age  |
+----+------+------+
|  1 | NULL | NULL |
|  2 | NULL | NULL |
|  3 | NULL | NULL |
|  4 | NULL | NULL |
|  5 | NULL | NULL |
|  6 | NULL | NULL |
|  7 | name |   7  |
+----+------+------+
7 rows in set (0.00 sec)
```

| session1                                                     | session2                                                     |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| mysql> set tx_isolation = 'repeatable-read';
Query OK, 0 rows affected, 1 warning (0.00 sec) | mysql> set tx_isolation = 'repeatable-read';
Query OK, 0 rows affected, 1 warning (0.00 sec) |
| Begin;                                                       |                                                              |
| select * from test where id <11 for update;                  |                                                              |
|                                                              | insert into test values(null,'name',9);   //被阻塞!          |
| commit;
Query OK, 0 rows affected (0.00 sec)                  |                                                              |
|                                                              | Query OK, 1 row affected (12.23 sec) //锁释放后完成了操作    |

在RR隔离级别下，可以锁住（-∞，10] 这个间隙，防止其他事务插入数据！
而在RC隔离级别下，不存在间隙锁，其他事务是可以插入数据！

`ps`:在RC隔离级别下并不是不会出现死锁，只是出现几率比RR低而已

  ### 锁表和锁行

**在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行**

```mysql
select * from test;
+----+------+------+
| id | name | age  |
+----+------+------+
|  8 | name |   11 |
|  9 | name |    9 |
| 10 | name |   15 |
| 11 | name |   15 |
| 12 | name |   16 |
+----+------+------+
```

锁表的例子:

| session1                                                     | session2                                                     |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| Begin;                                                       |                                                              |
| update test set age = age+1  where age = 15;
Rows matched: 2  Changed: 2  Warnings: 0 |                                                              |
|                                                              | insert into test values(null,'test',15);
ERROR 1205 (HY000): Lock wait timeout exceeded; |
| Commit;                                                      |                                                              |

session2插入失败	查询 数据显示:

```mysql
select * from test;
+----+------+------+
| id | name | age  |
+----+------+------+
|  8 | name |   11 |
|  9 | name |    9 |
| 10 | name |   16 |
| 11 | name |   16 |
| 12 | name |   16 |
+----+------+------+
```

### 半一致性读(semi-consistent)特性

**在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性！**

在5.1.15的时候，innodb引入了一个概念叫做“semi-consistent”，减少了更新同一行记录时的冲突，减少锁等待。
所谓半一致性读就是，一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本,判断此版本是否满足where条件。若满足则重新发起一次读操作，此时会读取行的最新版本并加锁！

## 建议

在RC级别下,用的binlog为row格式，是基于行的复制,Innodb的创始人也是建议binlog使用该格式

**互联网项目请用：读已提交(Read Commited)这个隔离级别**



## 总结

由于历史原因,老版本Mysql的binlog使用statement格式,不使用RR隔离级别会导致主从不一致的情况

目前(5.1版本之后)我们使用row格式的binlog 配合RC隔离级别可以实现更好的并发性能.



Mysql为何使用可重复读(Repeatable read)为默认隔离级别

下面是Java线程相关的高频面试题(含答案)，你可以用它来好好准备面试。





### 1.并行和并发有什么区别？

- **并发**：是指多个线程任务在同一个CPU上快速地轮换执行，由于切换的速度非常快，给人的感觉就是这些线程任务是在同时进行的，但其实并发只是一种逻辑上的同时进行；
- **并行**：是指多个线程任务在不同CPU上同时进行，是真正意义上的同时执行。

### 2.进程和线程的区别与联系?

#### 区别

* 并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可并发执行。

* 拥有资源：进程是拥有资源的一个独立单位，线程不拥有系统资源，但可以访问隶属于进程的资源。

* 系统开销：多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。

线程和进程在使用上各有优缺点：线程执行开销小，但不利于资源的管理和保护；而进程正相反。同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。


#### 联系

* 一个线程只能属于一个进程，而一个进程可以有多个线程，但至少有一个线程；

* 资源分配给进程，同一进程的所有线程共享该进程的所有资源；

* 处理机分给线程，即真正在处理机上运行的是线程；

* 线程在执行过程中，需要协作同步。不同进程的线程间要利用消息通信的办法实现同步。

### 3.守护线程是什么？

* 护线程是程序运行的时候在后台提供一种通用服务的线程。所有用户线程停止，进程会停掉所有守护线程，退出程序。

* **守护线程拥有自动结束自己生命周期的特性，而非守护线程不具备这个特点**。

#### 应用场景:

 JVM 中的垃圾回收线程就是典型的守护线程， 当 JVM 要退出时，垃圾回收线程也会结束自己的生命周期.

### 4.创建线程有哪几种方式？

1.继承Thread类  	

2.实现Runnable接口  

3.实现Callable接口   

4.通过线程池创建线程(ThreadPollExecutor,ExecutorService..)

### 5.说一下 runnable 和 callable 有什么区别？

* Runnable和Callable 都是接口，分别提供run方法和call方法
* Runnable的run方法无返回值，Callable的call方法提供返回值来表示任务运行结果

* Runnable无法通过throws抛出异常，所有CheckedException必须在run方法内部处理。Callable可直接抛出Exception异常.
* Runnable可以作为Thread构造器的参数，通过开启新的线程来执行，也可以通过线程池来执行。而Callable通过提交给线程池执行

### 6.线程有哪些状态？

这里要注意审题,是`系统线程状态`还是`Java中线程的状态`?

#### Java中线程的状态

java.lang.Thread类

```java
public enum State {

    NEW,


    RUNNABLE,


    BLOCKED,

 
    WAITING,


    TIMED_WAITING,


    TERMINATED;
}
```



#### 操作系统中线程的状态

- **初始状态**（NEW)

  对应 Java中的NEW

- **可运行状态**（READY）

  对应 Java中的 **RUNNBALE** 状态

- **运行状态**（RUNNING)

  对应 Java中的 **RUNNBALE** 状态

- 等待状态（WAITING)

  该状态在 Java中被划分为了 **BLOCKED**，**WAITING**，**TIMED_WAITING** 三种状态

  当线程调用阻塞式 API时，**进程(线程)进入等待状态，这里指的是操作系统层面的**。从 JVM层面来说，**Java线程仍然处于 RUNNABLE 状态**。

  > JVM 并不关心操作系统线程的实际状态，从 JVM 看来，等待CPU使用权（操作系统状态为可运行态）与等待 I/O（操作系统处于等待状态）没有区别，都是在等待某种资源，所以都归入RUNNABLE 状态

- **终止状态** （DEAD）

  对应  TERMINATED

### 7.sleep() 和 wait() 有什么区别？

sleep()和wait()都是线程暂停执行的方法。

* sleep方法属于Thread类中的静态方法，wait属于Object的成员方法。

* **sleep()**不涉及线程通信，调用时会暂停此线程指定的时间，但监控依然保持，**不会释放对象锁**，到时间**自动恢复**

* **wait() 用于线程间的通信，调用时会**放弃对象锁**，进入**等待队列，待调用notify()/notifyAll()唤醒指定的线程或者所有线程，才进入对象锁定池准备重新获得对象锁进入运行状态。

* wait，notify和notifyAll只能在**同步控制方法**或者**同步控制块**里面使用，而sleep可以在任何地方使用（使用范围）

* sleep()方法必须捕获异常InterruptedException，而wait()\notify()以及notifyAll()不需要捕获异常。

### 8.notify()和 notifyAll()有什么区别？

* notify() 方法随机唤醒对象的`等待池`中的一个线程，进入`锁池`；

* notifyAll() 唤醒对象的等待池中的所有线程，进入`锁池`。



- 等待池：假设线程A调用了某个对象的wait()方法，线程A就会释放该对象的锁，并进入该对象的等待池，等待池中的线程不会去竞争该对象的锁。
- 锁池：只有获取了对象的锁，线程才能执行对象的 synchronized 代码，对象的锁每次只有一个线程可以获得，其他线程只能在锁池中等待

### 9.线程的 run() 和 start() 有什么区别？

- 调用 start() 方法是用来启动线程的，轮到该线程执行时，会自动调用 run()；
- 调用 run() 方法，无法达到启动多线程的目的，相当于主线程线性执行 Thread 对象的 run() 方法。

- 一个线程对线的 start() 方法只能调用一次，多次调用会抛出 java.lang.IllegalThreadStateException 异常；而run() 方法没有限制。

### 10.创建线程池有哪几种方式?

- **通过Executors工厂方法创建**   (阿里巴巴开发规约中不建议使用此种方式创建线程池)
- **通过new  ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue)**   自定义创建(推荐)

 

### 11.Java线程池中submit() 和 execute()方法的区别

两个方法都可以向线程池提交任务

* execute()方法的返回类型是void，它定义在Executor接口中。

* submit()方法可以返回持有计算结果的Future对象，它定义在ExecutorService接口中，它扩展了Executor接口，其它线程池类像ThreadPoolExecutor和ScheduledThreadPoolExecutor都有这些方法。 

### 12.在 java 程序中怎么保证多线程的运行安全？



程序中保证多线程运行安全的方式：

1.使用安全类，比如 Java. util. concurrent 下的类。

2.使用自动锁 synchronized。

3.使用手动锁 Lock  例如Reentrantlock。

4.保证一个或者多个操作在CPU执行的过程中不被中断。(原子性)

5.保证一个线程对共享变量的修改，另外一个线程能够立刻看到。(可见性)

6.保证程序执行的顺序按照代码的先后顺序执行。(有序性)



注意回答中不能缺少这3种特性



线程的安全性问题体现在：

- 原子性：一个或者多个操作在 CPU 执行的过程中不被中断的特性
- 可见性：一个线程对共享变量的修改，另外一个线程能够立刻看到
- 有序性：程序执行的顺序按照代码的先后顺序执行





### 13.多线程锁的升级原理是什么？

锁的级别从低到高：

无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

 

锁分级别原因：

没有优化以前，synchronized是重量级锁（悲观锁），使用 wait 和 notify、notifyAll 来切换线程状态非常消耗系统资源；线程的挂起和唤醒间隔很短暂，这样很浪费资源，影响性能。所以 JVM 对 synchronized 关键字进行了优化，把锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。 



在学习并发编程知识`synchronized`时，我们总是难以理解其实现原理，因为偏向锁、轻量级锁、重量级锁都涉及到对象头，所以了解`java`对象头是我们深入了解`synchronized`的前提条件.这篇文章包含了对象头的解析以及锁膨胀过程的解析:

[JAVA对象布局之对象头(Object Header)](https://mp.weixin.qq.com/s/0eSiHchlOHAZSAGAchkWmA)



### 14. 什么是死锁？什么是活锁? 什么是线程饥饿?

[JAVA并发之加锁导致的活跃性问题剖析](https://mp.weixin.qq.com/s/THRpIo9LsWyC-k6Ws36O8g)



### 15.ThreadLocal 是什么？有哪些使用场景？

1.ThreadLocal  介绍

2.ThreadLocal  应用

3.ThreadLocal  源码解析

3.1解决 Hash 冲突

4.ThreadLocal 特性

5..ThreadLocal 内存泄露问题

[java并发之无同步方案-ThreadLocal](https://mp.weixin.qq.com/s/0GMj_v63QYjW5AT9n9--1Q)



### 16.说一下synchronized底层实现原理?

前置知识,需要了解 对象头.-->[JAVA对象布局之对象头(Object Header)](https://mp.weixin.qq.com/s/0eSiHchlOHAZSAGAchkWmA)

- 同步代码块是通过 monitorenter 和 monitorexit 指令获取线程的执行权

  monitorenter，如果当前monitor的进入数为0时，线程就会进入monitor，并且把进入数+1，那么该线程就是monitor的拥有者(owner)。

  如果该线程已经是monitor的拥有者，又重新进入，就会把进入数再次+1。也就是可重入的。

  执行monitorexit的线程必须是monitor的拥有者，指令执行后，monitor的进入数减1，如果减1后进入数为0，则该线程会退出monitor。其他被阻塞的线程就可以尝试去获取monitor的所有权。

  monitorexit指令出现了两次，第1次为同步正常退出释放锁；第2次为发生异步退出释放锁；

- 同步方法通过加 ACC_SYNCHRONIZED 标识实现线程的执行权的控制

  标志位ACC_SYNCHRONIZED，作用就是一旦执行到这个方法时，就会先判断是否有标志位，如果有这个标志位，就会先尝试获取monitor，获取成功才能执行方法，方法执行完成后再释放monitor。在方法执行期间，其他线程都无法获取同一个monitor。归根结底还是对monitor对象的争夺，只是同步方法是一种隐式的方式来实现。 

总的来说，synchronized的底层原理是通过monitor对象来完成的

### 17.synchronized和volatile的区别是什么？

**作用：**

- synchronized 表示只有一个线程可以获取作用对象的锁，执行代码，阻塞其他线程。 
- volatile 表示变量在 CPU 的寄存器中是不确定的，必须从主存中读取。保证多线程环境下变量的可见性；禁止指令重排序。

**区别：**

- synchronized 可以作用于变量、方法、对象；volatile 只能作用于变量。
- synchronized 可以保证线程间的有序性、原子性和可见性；volatile 只保证了可见性和有序性，无法保证原子性。
- synchronized 线程阻塞，volatile 线程不阻塞。

### 18.synchronized和Lock的区别是什么？

在多线程情况下，锁是线程控制的重要途径。Java为此也提供了2种锁机制，synchronized和lock。

我们这里不讨论具体的实现原理和细节,只讨论它们的区别

如果有小伙伴有兴趣更深入了解它们,请关注公众号:JAVA宝典



**区别**

*  lock是一个接口，而synchronized是java的一个关键字。

* synchronized在发生异常时会自动释放占有的锁，因此不会出现死锁；而lock发生异常时，不会主动释放占有的锁，必须手动来释放锁，可能引起死锁的发生(也称隐式锁和显式锁)

* lock等待锁过程中可以用interrupt来中断等待，而synchronized只能等待锁的释放，不能响应中断；

* Lock可以通过trylock来知道有没有获取锁，而synchronized不能；
* Lock可以提高多个线程进行读操作的效率。（可以通过readwritelock实现读写分离）
* 在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要优于synchronized。在使用时要根据适当情况选择。
* synchronized 是 JVM 层面实现的；Lock 是 JDK 代码层面实现

* synchronized使用Object对象本身的wait 、notify、notifyAll调度机制，而Lock可以使用Condition进行线程之间的调度

* 继上一条,synchronized只有一个阻塞队列,而Lock使用Condition可以有多个阻塞队列

  

  **synchronized和lock的用法区别**

  * synchronized：在需要同步的对象中加入此控制，synchronized可以加在方法上，也可以加在特定代码块中，括号中表示需要锁的对象。

  * lock：一般使用ReentrantLock类做为锁。在加锁和解锁处需要通过lock()和unlock()显示指出。所以一般会在finally块中写unlock()以防死锁。

###  19.说一下 你对atomic 的理解 ?

在JDK5.0之前，想要实现无锁无等待的算法是不可能的，除非用本地库，自从有了Atomic变量类后，这成为可能。

在java.util.concurrent.atomic包下有这些类:

- 标量类：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
- 数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
- 更新器类：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater
- 复合变量类：AtomicMarkableReference，AtomicStampedReference

拿AtomicInteger来举例,其内部实现不是简单的使用synchronized，而是一个更为高效的方式CAS (compare and swap) + volatile和native方法，从而避免了synchronized的高开销，执行效率大为提升。

```java
/** 
 * Atomically increments by one the current value. 
 * 
 * @return the previous value 
 */  
public final int getAndIncrement() {  
    return unsafe.getAndAddInt(this, valueOffset, 1);  
} 
```

这里直接调用一个叫Unsafe的类去处理,这个类是用于执行低级别、不安全操作的方法集合。尽管这个类和所有的方法都是公开的（public），但是这个类的使用仍然受限，你无法在自己的java程序中直接使用该类，因为只有授信的代码才能获得该类的实例。所以我们平时的代码是无法使用这个类的，因为其设计的操作过于偏底层，如若操作不慎可能会带来很大的灾难，所以直接禁止普通代码的访问，当然JDK使用是没有问题的。

关于CAS 在我的另一篇文章:	[什么是CAS,ABA问题怎么解决?](https://mp.weixin.qq.com/s/AMFAevn3ALMcZ0lXEi5SjQ)



### 20.说一下 你对Semaphore 的理解 ?

1. Semaphore就是一个信号量，**它的作用是限制某段代码块的并发数**。
2. Semaphore有一个构造函数，可以**传入一个int型整数n，表示某段代码最多只有n个线程可以访问**，
3. **如果超出了n，那么请等待，等到某个线程执行完毕这段代码块，下一个线程再进入**。
4. 由此可以看出如果Semaphore构造函数中传入的int型整数n=1，相当于变成了一个synchronized了。

 Semaphore类位于java.util.concurrent包下，它提供了2个构造器：

```java
//参数permits表示许可数目，即同时可以允许多少线程进行访问  
public Semaphore(int permits) {  
    sync = new NonfairSync(permits);  
}  
//这个多了一个参数fair表示是否是公平的，即等待时间越久的越先获取许可  
public Semaphore(int permits, boolean fair) {  
    sync = (fair)? new FairSync(permits) : new NonfairSync(permits);  
}  
```

- Semaphore类中比较重要的几个方法，首先是acquire()、release()方法：
- acquire()用来获取一个许可，若无许可能够获得，则会一直等待，直到获得许可。
- release()用来释放许可。注意，在释放许可之前，必须先获获得许可。

```java
//尝试获取一个许可，若获取成功，则立即返回true，若获取失败，则立即返回false  
public boolean tryAcquire() { };  
//尝试获取一个许可，若在指定的时间内获取成功，则立即返回true，否则则立即返回false  
public boolean tryAcquire(long timeout, TimeUnit unit) throws InterruptedException { };   
//尝试获取permits个许可，若获取成功，则立即返回true，若获取失败，则立即返回false  
public boolean tryAcquire(int permits) { };   
//尝试获取permits个许可，若在指定的时间内获取成功，则立即返回true  
public boolean tryAcquire(int permits, long timeout, TimeUnit unit) throws InterruptedException { };  
//得到当前可用的许可数目  
public int availablePermits(); 
```