面试总结个人版

素颜马尾好姑娘i 2024-03-16 16:22 79阅读 0赞

## 一、面试题 ##

> java 集合 ， spring springmvc springboot springcloud 数据库相关的， redis 相关 ，mq 相关 ，结合业务的场景题

### 1、part one ###

## 集合 ##

![4033590c075e186d68e55c0dbedc5db3.png][]

### HashMap底层原理 ###

HashMap是基于哈希表的Map接口的非同步实现。元素以键值对的形式存放，并且**允许null键和null值**，因为key值唯一（不能重复），因此，null键只有一个。另外，hashmap不保证元素存储的顺序，是一种无序的，和放入的顺序并不相同（此类不保证映射的顺序，特别是它不保证该顺序恒久不变）。**HashMap是线程不安全的**。

### HashMap的扩容原理 ###

> hashmap底层是利用**resize方法**来完成扩容的
> 
> HashMap的扩展原理是HashMap**用一个新的数组替换原来的数组**。重新计算原数组的所有数据并插入一个新数组，然后指向新数组。如果阵列在容量扩展前已达到最大值，阈值将直接设置为最大整数返回。
> 
> **HashMap**的默认**初始容量为16**
> 
> 负载因子，默认是**0.75**，原因为根据hash冲突和空间利用率综合考量计算的
> 
> 当HashMap中元素数超过容量\*负载因子时，HashMap会进行**扩容为原来的两倍。** **（2倍）**

### HashMap的底层结构1.7和1.8 ###

> 在JDK**1.7 中，由“数组+链表**”组成，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的。
> 
> 在JDK**1.8 中，由“数组+链表+红黑树**”组成。当链表过长，则会严重影响 HashMap 的性能，红黑树搜索时间复杂度是 O(logn)，而链表是 O(n)。因此，JDK1.8 对数据结构做了进一步的优化，引入了红黑树，链表和红黑树在达到一定条件会进行转换：
> 
>  *  当**链表超过 8** 且**数据总量超过 64** 才会**转红黑树**。
> 
>  *  将链表转换成红黑树前会判断，如果当前**数组的长度小于 64**，那么会选择**先进行数组扩容**，而不是转换为红黑树，以减少搜索时间。
> 
> **HashMap的线程不安全主要体现在两个方面：**
> 
>  *  1.在JDK1.7中，当**并发执行扩容**操作时会造成**环形链和数据丢失**的情况。
>  *  2.在JDK1.8中，在**并发执行put**操作时会发生**数据覆盖**的情况。

### HashMap为什么到8才会变为红黑树 ###

> 因为hashmap的底层默认为链表长度为8时会转换为红黑树，至于这样设计是为了防止链表过长导致查询效率变低。而长度为8就转换的原因是**根据链表和红黑树的时间复杂度综合比较得出的最佳性能点**。
> 
> 通常情况下，如果hash算法正常的话，链表并不会很长，转为红黑树更多的是一种**保底策略**，保证极端情况下的查询的效率。

### HashMap怎么解决hash冲突 ###

> 解决Hash冲突方法有:**开放定址法、再哈希法（再散列法）、链地址法（拉链法）、建立公共溢出区**。
> 
> **HashMap中采用的是 链地址法 。**
> 
>  *  开放定址法，也称为线性探测法，就是从发生冲突的那个位置开始，按照一定的次序从hash表中找到一个空闲的位置，然后把发生冲突的元素存入到这个空闲位置中。ThreadLocal就用到了线性探测法来解决hash冲突的。
>     
>     **包括：线性探测法、平方探测法、伪随机数法**
>  *  再哈希法(双重散列，多重散列)，**提供多个不同的hash函数**，当`R1=H1(key1)`发生冲突时，再计算`R2=H2(key1)`，直到没有冲突为止。 这样做虽然不易产生堆集，但增加了计算的时间。
>  *  链地址法(拉链法)，将 哈希值相同 的元素构成一个同义词的单链表,并将单链表的头指针存放在哈希表的第i个单元中，查找、插入和删除主要在同义词链表中进行。链表法适用于经常进行插入和删除的情况。
>  *  建立公共溢出区，将哈希表分为公共表和溢出表，当溢出发生时，将所有溢出数据统一放到溢出区。

### HashMap为什么把头插法改为尾插法 ###

> 1.7 采用 头插法（**链表死循环**）
> 
> **hashmap1.7中的死循环是有多个线程并发扩容形成了环状链表，随后再进行扩容的线程会循环取这个环状链表的节点，造成死循环；其次，环状链表是几个节点相互指向，并不是某个节点自己指向自己。**
> 
> 1.8 改为 尾插法

### Iterator 和 ListIterator 有什么区别？ ###

>  *  遍历。使用Iterator，可以遍历所有集合，如Map，List，Set；但只能在向前方向上遍历集合中的元素。
> 
> 使用ListIterator，只能遍历List实现的对象，但可以**向前和向后遍历集合中的元素**。
> 
>  *  添加元素。Iterator无法向集合中添加元素；而，ListIteror可以**向集合添加元素**。
>  *  修改元素。Iterator无法修改集合中的元素；而，ListIterator可以**使用set()修改集合中的元素**。
>  *  索引。Iterator无法获取集合中元素的索引；而，使用ListIterator，可以**获取集合中元素的索引**。

### ConcurrentHashMap的底层结构 ###

> JDK1.7
> 
> JDK1.7中的ConcurrentHashMap 是由 `Segment` 数组结构和 `HashEntry` 数组结构组成，即ConcurrentHashMap 把哈希桶切分成小数组（Segment ），每个小数组有 n 个 HashEntry 组成。
> 
> 其中，Segment 继承了 ReentrantLock，所以 Segment 是一种可重入锁，扮演锁的角色；HashEntry 用于存储键值对数据。
> 
> 首先**将数据分为一段一段的存储**，然后给**每一段数据配一把锁（分段锁），**当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问，能够实现真正的并发访问。
> 
> JDK1.8
> 
> 在数据结构上， JDK1.8 中的ConcurrentHashMap 选择了与 HashMap 相同的**数组+链表+红黑树**结构；在锁的实现上，**抛弃了原有的 Segment 分段锁**， **采用`CAS + synchronized`**实现更加低粒度的锁。
> 
> 将锁的级别控制在了更细粒度的哈希桶元素级别，也就是说只需要锁住这个**链表头结点**（红黑树的根节点），就不会影响其他的哈希桶元素的读写，大大提高了并发度。

### ConcurrentHashMap 和Hashtable的效率哪个更高？为什么？ ###

ConcurrentHashMap 的效率要 高于 Hashtable，因为 **Hashtable给整个哈希表加了一把大锁** 从而实现线程安全。而ConcurrentHashMap 的 锁粒度更低 ，在JDK1.7中采用 **分段锁** 实现线程安全，在JDK1.8 中采用 **`CAS+Synchronized`** 实现线程安全。

### HashMap和Hashtable的区别 ###

> **HashMap 的优势就是查找和操作的时间复杂度都是O(1)**。

1.  HashMap是**非线程安全**的，Hashtable是**线程安全的**
    
    HashMap：当我们进入put方法查看源码时可以发现**put方法返回的方法只有个finla修饰**，没有任何关于线程的存在
    
    Hashtable：当我们点击进入之后，就能马上看到一个**synchronized关键字**，表示这个方法在调用的时候不能被其他的线程对象访问。
2.  HashMap允许null作为键或值，Hashtable不允许,运行时会报NullPointerException
3.  HsahMap在数组+链表的结构中引入了红黑树，Hashtable没有

jdk 1.8版本之后HashMap增加了一个新的结构叫做红黑树。

1.  **HashMap初始容量为16，Hashtable初始容量为11**
    
    ![0d6c8592b48347249426654d1ecf2bc0.png][]

![86e4c26f864a0cecccbec8fb263a4a8f.png][]

1.  HsahMap扩容是当前**容量翻倍**，Hashtable是当前**容量翻倍+1**
2.  HsahMap**只支持Iterator**遍历，Hashtable支持**Iterator**和**Enumeration**

### ArrayList的容量和底层扩容 ###

> 在jdk1.7中
> 
> ArrayList的**默认容量为10**，底层为数组结构，当元素存满时，会自动**扩容1.5倍**
> 
> 在jdk1.8中，
> 
> ArrayList通过无参构造器创建的集合**初始容量为0**，再**添加第一个元素时**会**扩容到默认容量的10**
> 
> arraylist的**特征**为增删慢，查询快，因为ArrayList增删可能会涉及到数组的扩容。
> 
> **底层扩容**：arraylist的底层扩容机制所涉及的一个最重要的方法为**grow方法**，在这个方法中会先得到现有的数组长度，然后根据现有数组长度利用右移运算符去得到新的数组长度，然后会去使用arrays工具类的copeof方法去生成一个新长度的数组，再把旧的数组中的元素全部复制到新数组中，最后返回数组，即到此扩容完成。

## jdk1.8的新特性 ##

> 1.  接口的默认方法与静态方法，也就是**接口中可以有实现方法**
> 2.  Lambda 表达式
> 3.  函数式接口与静态导入
> 4.  访问局部变量，等等其他新特性。
> 5.  方法引用：可以直接引用已有Java类或对象的方法或构造器。
> 6.  Date Time API：加强对日期与时间的处理
> 7.  Stream API：可以把函数式编程风格引入到Java中

### 四大函数式接口 ###

> Consumer<T>：消费型接口（void accept(T t)） 以上为消费型接口，有参数，无返回值类型的接口。 Supplier<T>：供给型接口（T get（）） 只有返回值，没有参数 Function<T, R>：函数型接口（R apply（T t）） 输入一个类型得参数，输出一个类型得参数， Predicate<T>：断言型接口（boolean test（T t）） 输入一个参数，输出一个boolean类型得返回值。

### 2、part two ###

![302e46f3c6e678b989c953766c4c0666.png][]

## 死锁的四个必要条件 ##

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象.

1、**互斥**条件：一个资源每次只能被一个进程使用；

2、**请求与保持**条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放；

3、**不剥夺**条件:进程已获得的资源，在末使用完之前，不能强行剥夺；

4、**循环等待**条件:若干进程之间形成一种头尾相接的循环等待资源关系；

### 预防死锁 ###

破坏死锁的四个条件

### 死锁的解除 ###

一旦检测出死锁，就应该立即采取措施来接触死锁。死锁解除的主要方法有：

*  **资源剥夺法。** 挂起某些死锁进程，抢占它的资源，分配给其他死锁进程。
 *  **撤销进程法。** 强制撤销部分进程并剥夺这些进程的资源，让其他进程顺利执行。
 *  **进程回退法。**让一个或多个死锁进程回退到足以避免死锁的地步。

### 3、part three ###

## Spring: ##

### \#\{ \} 和 $\{ \} 的区别: ###

**\#\{ \}** 的 sql 语句带 引号

![01b507156036a3376f77df968114bfb1.png][]

可以防止sql预处理 使用 **PreparementStatement**

**$\{ \}** 的 sql 不带引号

![e0eb92ec62f34bc7d8c1359fd6e0f41f.png][]

> 在给bean属性赋值时有两种方式
> 
> **@Autowired：先根据类型注入 再根据名字注入**，如果找到类型有多个则根据名字找
> 
> **@Resource：先根据名字注入 再根据类型注入**

### 注解 ###

> 四个创建bean的注解： @Controller @Service @Repository @Component
> 
> 注入依赖bean的注解： （@Autowired 搭配 @Qualifier 指定名字） @Resource
> 
> 注入普通属性的注解：@Value
> 
> 标识配置类的注解：@Configuration
> 
> 指定扫描包的注解 : @ComponentScan(basePackages = \{"com.glls.java2301"\})
> 
> 指定优先级的注解：@Primary
> 
> 指定初始化方法的注解：@PostConstruct
> 
> 指定销毁bean 的时候调用的方法：@PreDestroy

### 动态代理设计模式 ###

> 动态创建代理类的对象，为原始类的对象添加辅助功能。

**JDK动态代理**实现（基于**接口**） 代理对象和真实对象的关系 像是**兄弟** 代理对象 对真实对象进行增强

**CGlib动态代理**实现（基于**继承**） 代理对象和真实对象的关系 就像是 **父子**

切点： 真正要被增强的方法

通知：增强的业务代码 （实际增强的逻辑部分 ）

切面：切点 + 通知

### AOP ###

（Aspect Oriented Programming），即面向切面编程

是spring的两大特性之一

在**beanpostprocessor bean后置增强中 动态代理对象替换了原来的对象**

利用一种称为"横切"的技术，剖开封装的对象内部，并将那些**影响了多个类的公共行为封装到一个可重用模块**，并将其命名为"Aspect"，即切面。所谓"切面"，简单说就是**那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来**，便于减少系统的重复代码，降低模块之间的耦合度，并有利于未来的可操作性和可维护性。

### IOC ###

IOC 思想基于 IOC 容器完成，IOC 容器 底层 就是 **对象工厂**

### Spring 提供 IOC 容器实现两种方式：（两个接口） ###

*  BeanFactory：IOC 容器基本实现，是 Spring 内部的使用接口，不提供开发人员进行使用
    
     *  加载配置文件时候不会创建对象，在**获取对象（使用）才去创建对象**
 *  ApplicationContext：BeanFactory 接口的子接口，提供更多更强大的功能，一般由开发人 员进行使用
    
     *  **加载配置文件时候就会把在配置文件对象进行创建**

### IoC（Inversion of Control ）控制反转【`重点`】 ###

--------------------

> **Inverse Of Controll：控制反转**
> 
> **反转了依赖关系的满足方式，由之前的自己创建依赖对象，变为由工厂推送。(变主动为被动，即反转)**
> 
> **解决了具有依赖关系的组件之间的强耦合，使得项目形态更加稳健**
> 
> 补充： 什么是IOC
> 
> 1.控制反转，把对象创建和对象之间的调用过程，交给 Spring 进行管理
> 
> Bean管理（两个操作）：
> 
> （1）Spring创建对象
> 
> （2）Spring属性注入
> 
> 2.使用 IOC **目的：为了耦合度降低**
> 
> 3.入门案例就是 IOC 实现
> 
> IOC 底层原理：
> 
> **xml 解析、工厂模式、反射**

### DI（Dependency Injection）依赖注入【`重点`】 ###

--------------------

概念

> 在Spring创建对象的同时，为其属性赋值，称之为依赖注入。

## Bean ##

### bean生命周期 ###

1.  bean 的实例化 通过构造方法创建bean 的实例 默认是无参构造
2.  给bean 的属性赋值
3.  把 bean 的 实例 传递给 bean的后置处理器的方法 postProcessBeforeInitialization
4.  执行初始化的方法
5.  把 bean 的 实例 传递给 bean的后置处理器的方法 postProcessAfterInitialization （这一步完成动态代理，狸猫换太子）
6.  得到完整的bean 对象 ，这时的bean 对象才能够使用 （真正调用的是干活的代理对象， 动态代理对象替换了原来的对象）
7.  销毁bean 当容器关闭的时候 调用销毁的方法

### 什么是bean？ ###

1.bean是对象，一个或者多个不限定 2.**bean由Spring中一个叫IoC的东西管理** 3.我们的应用程序由一个个bean构成

### Spring 中的 bean 的作用域有哪些? ###

*  singleton : 唯一 bean 实例，Spring 中的 bean 默认都是单例的。
 *  prototype : 每次请求都会创建一个新的 bean 实例。
 *  request : 每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效。
 *  session : ：在一个HTTP Session中，一个Bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。
 *  global-session： 全局session作用域，仅仅在基于portlet的web应用中才有意义，Spring5已经没有了。Portlet是能够生成语义代码(例如：HTML)片段的小型Java Web插件。它们基于portlet容器，可以像servlet一样处理HTTP请求。但是，与 servlet 不同，每个 portlet 都有不同的会话

## JSON: ##

**js 对象 转为 json 串 方法： JSON.stringify(user);**

**json串转为 js 对象的方法 ： JSON.parse(jsonstr);**

### Jackson常用注解 ###

> 日期格式化 @JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
> 
> 属性名修改 @JsonProperty("new\_name")
> 
> 属性忽略 @JsonIgnore
> 
> null和empty属性排除 Jackson 默认会输出null值的属性，如果不需要，可以排除。
> 
> @JsonInclude(JsonInclude.Include.NON\_NULL) //null值 属性不输出 @JsonInclude(value= JsonInclude.Include.NON\_EMPTY) // empty属性不输出( 空串，长度为0的集合，null值)
> 
> 自定义序列化 @JsonSerialize(using = MySerializer.class) // 使用MySerializer输出某属性

### FastJson ###

<dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>fastjson</artifactId>
        <version>1.2.54</version>
    </dependency>

>  *  日期格式化：@JSONField(format="yyyy/MM/dd")
>  *  属性名修改：@JSONField(name="birth"）
>  *  忽略属性：@JSONField(serialize = false)
>  *  包含null值：
>  *  @JSONField(serialzeFeatures = SerializerFeature.WriteMapNullValue) 默认会忽略所有null值,有此注解会输出null
>  *  @JSONField(serialzeFeatures = SerializerFeature.WriteNullStringAsEmpty) null的String输出为""
>  *  自定义序列化：@JSONField(serializeUsing = MySerializer2.class)

### 4、part four ###

## ElasticSearch ##

### terms查询 ###

> terms和term的查询机制是一样，都**不会将指定的查询关键字进行`分词`**，直接去分词库中匹配，找到相应文档内容。
> 
> terms是在针对一个字段包含多个值的时候使用。
> 
> term：where province = 北京；
> 
> terms：where province = 北京 or province = ？or province = ？ 一个字段可以等于多个值 有点类似 in

### match查询【`重点`】 ###

> match查询属于高层查询，他会根据你查询的字段类型不一样，采用不同的查询方式。
> 
>  *  查询的是日期或者是数值的话，他会将你基于的字符串查询内容转换为日期或者数值对待。
>  *  如果查询的内容是一个不能被分词的内容（keyword），match查询不会对你指定的查询关键字进行分词。
>  *  如果查询的内容时一个可以被分词的内容（text），match会将你指定的查询内容根据一定的方式去分词，去分词库中匹配指定的内容。
> 
> match查询，**实际底层就是多个term查询**，将多个term查询的结果给你封装到了一起。

## JVM ##

### jvm的内存组成 ###

五大内存区域，分1.7和1.8

![2097254930e9cac375553884602e4579.png][]

1.堆内存：引用类型的数据，内部组成：1.新生代（伊甸区和幸存者区）2.老年代。该区域经常发生垃圾回收的操作

2.虚拟机栈：方法在运行时，需要存储一些内容，存储到栈

3.本地方法栈：本地方法（被native修饰的方法），方法运行时，保存的一些信息

4.程序计数器：针对线程的，记录每个线程当前的执行的行数

5.元空间（1.7叫做方法区）：存放已被加载的类信息、常量、静态变量等信息

### JVM的堆内存 ###

堆内存：分为两块：1.新生代 2.老年代

新生代：内部又分为伊甸区和幸存者区1、2

创建新对象，默认进入到伊甸区，GC在运行时，会将存活的对象放在幸存者区，如果对象存活超过15次，存储到老年代

老年代：存活时间长的对象或者大对象

### GC如何判定对象是否回收 ###

引用计数法

使用可达性分析算法来判定：GC Roots

### GC常用算法 ###

> **标记清除算法**：
> 
> 第一步：利用可达性去遍历内存，把存活对象、需要回收的对象标记出来；第二步：在遍历一遍，把标记过的对象回收掉。**缺点**：效率不高，无法清除垃圾碎片
> 
> **标记整理算法**：
> 
> 首先，把存活对象和垃圾对象进行标记，然后将所有的存活对象向一端进行移动，然后直接清除端以外的内存。**特点**：适用于存活对象多，垃圾少的情况；需要整理的过程，无空间碎片产生；
> 
> **标记复制算法**：
> 
> 按照容量复制两个大小相等的内存空间，当有一个用完以后，就把还存活着对象复制到另一个区域中，在清除掉用完的区域，**缺点**：内存使用率低，只有原来的一半空间
> 
> **分代收集算法**：
> 
> 根据内存对象的存活周期不同，将内存划分成几块，一般为新生代、老年代。
> 
> 新生代一般采用复制算法，老年代一般采用标记整理算法。

### jvm内存模型 ###

> **Java 内存模型**（下文简称 **JMM**）就是在底层处理器内存模型的基础上，定义自己的多线程语义。它明确指定了一组排序规则，来保证线程间的可见性。
> 
> 这一组规则被称为 **Happens-Before**, JMM 规定，要想保证 B 操作能够看到 A 操作的结果（无论它们是否在同一个线程），那么 A 和 B 之间必须满足 **Happens-Before 关系**。
> 
>  *  **单线程规则**：一个线程中的每个动作都 happens-before 该线程中后续的每个动作
>  *  **监视器锁定规则**：监听器的**解锁**动作 happens-before 后续对这个监听器的**锁定**动作
>  *  **volatile 变量规则**：对 volatile 字段的写入动作 happens-before 后续对这个字段的每个读取动作
>  *  **线程 start 规则**：线程 **start()** 方法的执行 happens-before 一个启动线程内的任意动作
>  *  **线程 join 规则**：一个线程内的所有动作 happens-before 任意其他线程在该线程 **join()** 成功返回之前
>  *  **传递性**：如果 A happens-before B, 且 B happens-before C, 那么 A happens-before C
> 
> Java 提供了几种语言结构，包括 *volatile*, *final* 和 *synchronized*, 它们旨在帮助程序员向**编译器**描述程序的并发要求，其中：
> 
>  *  **volatile** \- 保证**可见性**和**有序性**
>  *  **synchronized** \- 保证**可见性**和**有序性**; 通过**管程（Monitor）**保证一组动作的**原子性**
>  *  **final** \- 通过禁止**在构造函数初始化**和**给 final 字段赋值**这两个动作的重排序，保证**可见性**（如果 **this 引用逃逸**就不好说可见性了）
> 
> 编译器在遇到这些关键字时，会插入相应的内存屏障，保证语义的正确性。
> 
> 有一点需要**注意**的是，**synchronized** **不保证**同步块内的代码禁止重排序，因为它通过锁保证同一时刻只有**一个线程**访问同步块（或临界区），也就是说同步块的代码只需满足 **as-if-serial** 语义 - 只要单线程的执行结果不改变，可以进行重排序。
> 
> 所以说**，Java 内存模型描述的是多线程对共享内存修改后彼此之间的可见性**，另外，还确保正确同步的 Java 代码可以在不同体系结构的处理器上正确运行。

## 锁 ##

### 乐观锁 ###

### AQS：（AbstractQueueSynchronizer） ###

AQS通过一个 FIFO 队列维护线程同步状态，实现类只需要继承该类，并重写指定方法即可实现一套线程同步机制。

在 `AQS` 中的锁类型有两种：分别是**「Exclusive(独占锁)**「和」**Share(共享锁)」**

**「独占锁」就是「每次都只有一个线程运行」**，例如 ReentrantLock。

**「共享锁」就是「同时可以多个线程运行」**，如 Semaphore、CountDownLatch、ReentrantReadWriteLock。

### CAS： ###

JAVA中CAS是通过自旋操作完成赋值，若值不相等再更新预期值、重新计算新值，接着进行CAS操作，直到成功为止。底层是JVM调用操作系统原语指令`unsafe`，并由CPU完成原子操作，你要知道并发/多线程环境下如果CPU没有原子操作我们是无法完成

#### CAS优点 ####

*  **没有引用锁的概念，并发量不高情况下提高效率**
 *  **减少线程上下文切换**

#### CAS缺点 ####

*  **cpu开销大，在高并发下，许多线程，更新一变量，多次更新不成功，循环反复，给cpu带来大量压力。**
    
    循环时间过长：由于 CAS 经常需要重试，当重试次数过多时，会导致线程等待时间太长，影响程序的性能
    
    解决方法：**设置自旋次数**，避开这个耗时问题
 *  **只是一个变量的原子性操作，不能保证代码块的原子性。**
    
    只能保证一个变量的原子操作：CAS 保证的是对一个变量执行操作的原子性，如果对多个变量操作时，CAS 目前无法直接保证操作的原子性的
    
    解决方法：使用**互斥锁**来保证原子性 将多个变量封装成对象
 *  **ABA问题** （马蓉问题）
    
    ABA 问题：CAS 无法解决 ABA 问题，即在多线程环境下，一个变量的值被改变后，又被恢复到原来的值，导致 CAS 无法感知到这种变化。
    
    解决方法：设置一个**带有标记的原子引用类**，通过**控制变量值的版本**来保证CAS的正确性

### 什么是Unsafe类 ###

是**CAS的核心类**，由于JAVA方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe相当于一个后门，基于该类可以直接操作特定的内存数据。Unsafe存在于sun.misc包中，其内部方法可以像C的指针一样直接操作内存，因为Java中CAS操作的执行依赖于Unsafe类的方法

### 小结： ###

1、CAS比较并交换方法只能保证数据的稳定性 ，并不能保证原子性，原子性的实质底层是通过JAVA提供的Unsafe类调用C语言外部的接口，底层是调用汇编的一个原子指令给数据总线加锁所以线程是安全的。

2、 CAS缺点通过 期望值和实际值是否相等 并不能保证中间有空档期 所以需要通过版本号来控制 JUC提供的AtomicStampedReference 时间戳原子类 保证了没改变一次主内存数据 版本号+1 在修改主内存数据时 除了通过**值判断相等**外还加上**版本号预计值和实际值是否相等** 双重控制 **解决了ABA问题**。

### synchronized 和 lock 的区别 ###

1.Lock是显示锁，需要手动开启和关闭。synchronized是隐士锁，可以自动释放锁。 2.Lock是一个接口，是JDK实现的。synchronized是一个关键字，要依赖JVM实现。 3.Lock是可中断锁，synchronized是不可中断锁，需要线程执行完才能释放锁。 4.发生异常时，Lock不会主动释放占有的锁，必须通过unlock进行手动释放，如果执行过程中发生异常未正 常释放锁的话，可能引发死锁。synchronized在发生异常的情况下会自动释放占有的锁，不会出现死锁的情 况。 5.Lock可以判断锁的状态，synchronized不可以判断锁的状态。 6.Lock实现锁的类型是可重入锁、公平锁。synchronized实现锁的类型是可重入锁、非公平锁。 7.Lock适用于大量同步代码块的场景，synchronized适用于少量同步代码块的场景。

### synochronizd和volatile关键字区别： ###

1.volatile关键字解决的是变量在多个线程之间的可见性；而sychronized关键字解决的是多个线程之间访问共享资源的同步性。 2.volatile只能用于修饰变量，而synchronized可以修饰方法，以及代码块。（volatile是线程同步的轻量级实现，所以volatile性能比synchronized要好，并且随着JDK新版本的发布，sychronized关键字在执行上得到很大的提升，在开发中使用synchronized关键字的比率还是比较大） 3.多线程访问volatile不会发生阻塞，而sychronized会出现阻塞。 4.volatile能保证变量在多个线程之间的可见性，但不能保证原子性；而sychronized可以保证原子性，也可以间接保证可见性，因为它会将私有内存和公有内存中的数据做同步。 线程安全包含原子性和可见性两个方面。 对于用volatile修饰的变量，JVM虚拟机只是保证从主内存加载到线程工作内存的值是最新的。 一句话说明volatile的作用：实现变量在多个线程之间的可见性。

## volatile： ##

#### volatile的三大特性 : ####

> **1、保证可见性：**
> 
> 在多线程的场景下，当一个线程修改一个被Volatitle修饰的变量，另外一个线程也能读到该变量修改后的值，该变量即为共享变量，被所有线程共享。

> **2、禁止指令重排：**
> 
> 禁止CPU执行时进行指令重排操作（内存屏障）从而能**保证有序执性**，但是它并不能保证原子性。
> 
> **观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令。**
> 
> > lock前缀指令相当于一个**内存屏障（也称为内存栅栏）**，内存屏障会提供3个功能：
> > 
> > （1）它确保指令重排序时，不会把后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；也即是，在执行到内存屏障这个指令时，在他前面的操作已经完成。
> > 
> > （2）它会强制将缓存的修改操作立即写入主存。
> > 
> > （3）如果是写操作，他会导致其他CPU中对应的缓存无效。

> **3、不保证原子性：**
> 
> 对volatile变量的单次读/写操作可以保证原子性的，如long和double类型变量，但是并不能保证i++这种操作的原子性，因为本质上i++是读、写两次操作。
> 
> 可以通过AtomicInteger或者Synchronized来保证+1操作的原子性。

## 强、弱、软引用： ##

### 强引用（StrongReference） ###

**强引用是默认支持**，当内存不足的时候，JVM开始垃圾回收。

强引用是最常见的普通对象引用，只要还有强引用指向对象，对象就存活，垃圾回收器不会处理存活对象。比如：

StringBuilder sb = new StringBuilder();

#### 强引用有如下特点： ####

*  强引用可以直接访问目标对象
 *  强引用(存在)指向的对象任何时候都不会被回收。
 *  强引用可能会导致**内存泄漏**

#### 软引用（SoftReference） ####

软引用是用来描述一些非必需但仍有用的对象。**在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常**。这种特性常常被用来**实现缓存技术**，比如网页缓存，图片缓存等。

### 弱引用（WeakReference） ###

弱引用中的对象具有很短的声明周期，因为在系统GC时，**只要发现弱引用，不管堆空间是否足够，都会将对象进行回收**。由于垃圾回收器是一个**优先级很低的线程**，因此**不一定**会**很快**发现那些只具有**弱引用**的对象。

软引用 和 弱引用 都非常  适合保存那些  可有可无  的  缓存数据，当内存不足时，缓存数据被回收，当内存充足时，也可以存在较长时间，起到加速的作用。

## 内存泄漏、溢出： ##

1.内存溢出(out of memory) 是指 程序在**申请内存时**，**没有足够的内存空间供其使用**，出现 out of memory

2.内存泄漏(memory leak) 是指 程序**申请内存后**，**无法释放已申请的内存**空间，这样的泄漏积少成多,造成泄漏。

3.为了尽量避免浪费内存的情况，我们有时可以在变量sb不再使用后通过将变量sb**置为null**（sb = null）**中断强引用与对象之前的联系**，来加速对象的回收··

## 过滤器和拦截器的区别： ##

**①拦截器是基于java的反射机制的，而过滤器是基于函数回调。 　　②拦截器不依赖与servlet容器，过滤器依赖与servlet容器。 　　③拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用。 　　④拦截器可以访问action上下文、值栈里的对象，而过滤器不能访问。 　　⑤在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次。**

**⑥拦截器可以获取IOC容器中的各个bean，而过滤器就不行，这点很重要，在拦截器里注入一个service，可以调用业务逻辑。**

***拦截器可以获取ioc中的service bean实现业务逻辑，拦截器可以获取ioc中的service bean实现业务逻辑，拦截器可以获取ioc中的service bean实现业务逻辑，***

触发时机

有个专业词语叫触发时机

1.过滤器和拦截器触发时机、触发时间和地点不一样:

过滤器是在请求进入容器后，但请求进入servlet之前进行预处理的。请求结束返回也是，是在servlet处理完后，返回给前端之前。

总结：过滤器包裹住servlet，servlet包裹住拦截器。

![2b7aed5cf68816afd63b3532850f1280.png][]

2.过滤器的触发时机是容器后，servlet之前，所以过滤器的doFilter(

ServletRequest request, ServletResponse response, FilterChain chain

)的入参是ServletRequest ，而不是httpservletrequest。因为过滤器是在httpservlet之前。

![ad5100546476b422ed6ebae89d1ce9ef.png][]

### 过滤器和拦截器的区别和应用场景 ###

1）过滤器（Filter）：当你有一堆东西的时候，你只希望选择符合你要求的某一些东西。定义这些要求的工具，就是过滤器。（理解：就是一堆字母中取一个B）

（2）拦截器（Interceptor）：在一个流程正在进行的时候，你希望干预它的进展，甚至终止它进行，这是拦截器做的事情。（理解：就是一堆字母中，干预他，通过验证的少点，顺便干点别的东西）。

## JVM ##

### 什么是STW ###

STW: Stop-The-World: 是在`垃圾回收算法`执⾏过程当中，将JVM内存冻结、应用程序停顿的⼀种状态。

*  在STW 状态下，JAVA的`所有线程都是停⽌执⾏的 -> GC线程除外`
 *  一旦Stop-the-world发生，**除了GC所需的线程外，其他线程都将停止工作**，中断了的线程直到GC任务结束才继续它们的任务
 *  STW是不可避免的,`垃圾回收算法执⾏`一定会出现STW,我们**要做的只是减少停顿的时间**
 *  GC各种算法优化的重点，就是 `减少STW(暂停)` ，同时这也是JVM调优的重点

## 垃圾回收的相关算法： ##

## 双亲委派： ##

![40fddc12c531bd84a940f678127a7664.png][]

## Redis ##

Redis（Remote Dictionary Server）即远程字典服务，是由C语言去编写的，基于 Key-Value的NoSQL、**基于内存存储数据**，Redis提供了多种持久化机制

（NoSQL只是一种概念，泛指非关系型数据库，和关系型数据库做一个区分。）

### Redis存储数据的结构 ###

> 常用的5种数据结构：
> 
>  *  key-**string**：一个key对应一个值。 （可以用来存储**用户验证码**）
>  *  key-**list**：一个key对应一个列表。 **有序的 可以重复**的
>  *  key-**set**：一个key对应一个集合。 **无序的 不可以重复**的
>  *  key-**zset**：一个key对应一个有序的集合。 **有序的 不可以重复**的
>  *  key-**hash**：一个key对应**一个Map**。
> 
> 另外三种数据结构：
> 
>  *  HyperLogLog：**计算近似值**的。
>  *  GEO：**地理位置**。
>  *  BIT：一般存储的也是一个字符串，**存储的是一个byte\[\]**。

### 为什么redis的核心功能是单线程，性能还是那么高 ###

Redis使用单个线程处理请求，**避免了多个线程之间线程切换和锁资源争用的开销**。注意：单线程是指的是在核心网络模型中，网络请求模块使用一个线程来处理，即一个线程处理所有网络请求。

除此之外redis还有其他的特点使其性能高：

*  **内存存储**：Redis是使用内存(in-memeroy)存储，**没有磁盘IO上的开销**。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)。
 *  **非阻塞IO**：Redis使用**多路复用IO技术**，将epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。
 *  **优化的数据结构**：Redis有诸多可以直接应用的优化数据结构的实现，应用层可以**直接使用原生的数据结构提升性能**。
 *  **使用底层模型不同**：**Redis直接自己构建了 VM (虚拟内存)机制** ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
 *  有自己的一套通信协议

### 击穿、穿透、雪崩是什么 ###

#### 击穿 ####

缓存击穿跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是**某个**热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿。

从两个方面解决，第一是否可以考虑热点key不设置过期时间，第二是否可以考虑降低打在数据库上的请求数量。

解决方案：

*  在**缓存失效后，通过 互斥锁 或者 队列 来控制读数据写缓存的线程数量**，比如**某个key只允许一个线程查询数据和写缓存**，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
 *  **热点数据缓存永远不过期**。永不过期实际包含两层意思：
    
     *  物理不过期，针对热点key不设置过期时间
     *  逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建

穿透

缓存穿透是指用户请求的数据在**缓存中不存在即没有命中，同时在数据库中也不存在**，导致用户每次请求该数据都要去数据库中查询一遍。如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。

> 缓存穿透的关键在于在Redis中查不到key值，它和缓存击穿的根本区别在于传进来的key在Redis中是不存在的。假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，**一些非法的参数，不可能存在的key就直接返回错误提示。**

解决方法：

*  **将无效的key存放进Redis中：**

当出现Redis查不到数据，数据库也查不到数据的情况，我们就把这个key保存到Redis中，设置value="null"，并设置其过期时间极短，后面再出现查询这个key的请求的时候，直接返回null，就不需要再查询数据库了。但这种处理方式是有问题的，假如传进来的这个不存在的Key值每次都是随机的，那存进Redis也没有意义。

*  使用**布隆过滤器：**

如果布隆过滤器判定某个 key 不存在布隆过滤器中，那么就一定不存在，如果判定某个 key 存在，那么很大可能是存在(存在一定的误判率)。于是我们可以在缓存之前再加一个布隆过滤器，将数据库中的所有key都存储在布隆过滤器中，在查询Redis前先去布隆过滤器查询 key 是否存在，如果不存在就直接返回，不让其访问数据库，从而避免了对底层存储系统的查询压力。

#### 雪崩 ####

如果缓在某一个时刻出现大规模的key失效，那么就会导致**大量的请求打在了数据库上面**，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。

造成缓存雪崩的**关键在于同一时间的大规模的key失效**，

主要有两种可能：第一种是**Redis宕机**，第二种可能就是**采用了相同的过期时间**。

解决方案：

1、事前：

*  均匀过期：**设置不同的过期时间**，让缓存失效的时间尽量均匀，避免相同的过期时间导致缓存雪崩，造成大量数据库的访问。如把每个Key的失效时间都加个随机值，`setRedis（Key，value，time + Math.random() * 10000）；`，保证数据不会在同一时间大面积失效。
 *  分级缓存：**第一级缓存失效的基础上，访问二级缓存，`每一级缓存的失效时间都不同`**。
 *  热点数据缓存永远不过期。永不过期实际包含两层意思：
    
     *  物理不过期，针对热点key不设置过期时间
     *  逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建
 *  保证Redis缓存的高可用，防止Redis宕机导致缓存雪崩的问题。可以使用 主从+ 哨兵，Redis集群来避免 Redis 全盘崩溃的情况。

2、事中：

*  互斥锁：在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
 *  使用熔断机制，限流降级。当流量达到一定的阈值，直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上将数据库击垮，至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果。

3、事后：

**开启Redis持久化机制**，尽快恢复缓存数据，一旦重启，就能从磁盘上自动加载数据恢复内存中的数据。

## 如何保证redis跟数据库的数据一致性 ##

### 如何保证缓存与数据库双写时的数据一致性？ ###

共有四种方案：

1.  先更新数据库，后更新缓存
2.  先更新缓存，后更新数据库
3.  先删除缓存，后更新数据库
4.  先更新数据库，后删除缓存

第一种和第二种方案，没有人使用的，因为第一种方案存在问题是：并发更新数据库场景下，会将脏数据刷到缓存。

第二种方案存在的问题是：如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。

目前主要用第三和第四种方案。

### 3.先删除缓存，后更新数据库 ###

该方案也会出问题，此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）

1.  请求A进行写操作，删除缓存
2.  请求B查询发现缓存不存在
3.  请求B去数据库查询得到旧值
4.  请求B将旧值写入缓存
5.  请求A将新值写入数据库

上述情况就会导致不一致的情形出现。而且，如果**不采用给缓存设置过期时间策略，该数据永远都是脏数据**。

#### 答案一：延时双删 ####

使用伪代码如下：(删一次，睡一会儿再删一次)

public void write(String key,Object data){
            Redis.delKey(key);
            db.updateData(data);
            Thread.sleep(1000);
            Redis.delKey(key);
        }

转化为中文描述就是 （1）先淘汰缓存 （2）再写数据库（这两步和原来一样） （3）休眠1秒，再次淘汰缓存，这么做，可以将1秒内所造成的缓存脏数据，再次删除。确保读请求结束，写请求可以删除读请求造成的缓存脏数据。自行评估自己的项目的读数据业务逻辑的耗时，写数据的休眠时间则在读数据**业务逻辑的耗时基础上，加几百ms即可**。

如果使用的是 Mysql 的读写分离的架构的话，那么其实主从同步之间也会有时间差。

![9437740b27a41b5276e2fe9732459089.png][]

此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）

1.  请求 A 更新操作，删除了 Redis
2.  请求主库进行更新操作，主库与从库进行同步数据的操作
3.  请 B 查询操作，发现 Redis 中没有数据
4.  去从库中拿去数据
5.  此时同步数据还未完成，拿到的数据是旧数据

此时的解决办法就是如果是**对 Redis 进行填充数据的查询数据库操作，那么就强制将其指向主库进行查询**。

![21573417564fc9b44e9a5f0affc37aea.png][]

### 4.先更新数据库，后删除缓存 ###

这一种情况也会出现问题，比如更新数据库成功了，但是在删除缓存的阶段出错了**没有删除成功**，那么此时**再读取缓存的时候每次都是错误的数据了。**

![ac628f35083ab4831672a662e37bc457.png][]

此时解决方案就是**利用消息队列进行 删除的补偿**。具体的业务逻辑用语言描述如下：

1.  请求 A 先对数据库进行更新操作
2.  在对 Redis 进行删除操作的时候发现报错，删除失败
3.  此时将Redis 的 key 作为消息体发送到消息队列中
4.  系统接收到消息队列发送的消息后再次对 Redis 进行删除操作

但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起，所以这时会有一个优化的方案，我们知道对 Mysql 数据库更新操作后在 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。

![1a765bb1d59c6f69d448e8fd06762376.png][]

### binlog： ###

二进制日志（binnary log）以**事件形式**记录了对MySQL数据库执行更改的所有操作。

binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但可以通过查询通用日志来查看MySQL执行过的所有语句。

需要注意的一点是，即便**update操作没有造成数据变化，也是会记入binlog**。

binlog有两个常用的使用场景：

*  主从复制：mysql replication在master端开启binlog,master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
 *  数据恢复：通过mysqlbinlog工具来恢复数据。

#### 红锁：给你的所有redis都挂上锁，这样挂一个就没事了（都上成功锁才算成功，完事都解锁了才算解锁成功） ####

### Redis提高数据库容量的办法有两种： ###

*  一种是可以将数据分割到多个RedisServer上，**集群**；
 *  另一种是使用虚拟内存把那些不经常访问的数据交换到磁盘上。**需要特别注意的是Redis并没有使用OS提供的Swap，而是自己实现。**

### CAP ###

C：consistency，数据在多个副本中能保持一致的状态。

A：Availability，整个系统在任何时刻都能提供可用的服务，通常达到99.99%四个九可以称为**高可用**

P：Partition tolerance，分区容错性，在分布式中，由于网络的原因无法避免有时候出现数据不一致的情况，系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，换句话说，系统可以跨网络分区线性的伸缩和扩展。

CAP理论的核心：一个分布式系统`不可能同时`很好的满足一致性，可用性和分区容错性这三个需求，`最多只能同时较好的满足两个`。

*  CA：单点集群，满足一致性，可用性的系统，通常在可扩展上不太强大。应用：传统的Oracle数据库
 *  CP：满足一致性，分区容错性的系统，通常性能不是特别高。应用：Redis，MongoDB，银行
 *  AP：满足可用性，分区容错性，通常可能对一致性要求低一些。应用：大多数网站架构的选择

### Base ###

Base就是为了**解决关系型数据库强一致性引起的问题而引起的可用性降低**而提出的解决方案。

Base其实是下面三个术语的缩写：

*  基本可用（Basically Available）
 *  软状态（Soft state）状态可以有一段时间不同步
 *  最终一致（Eventually consistent）最终数据是一致的就可以了，而不是时时保持强一致

### AOF和RDB ###

AOF：

RDB：fork出来一份替换

主从模式：从节点分担读压力

哨兵模式：解决单点故障

集群：去中心化，解决数据存储容量不足，分担读、写压力

### Redis内存淘汰策略 ###

>  *  volatile-lru：在内存不足时，Redis会在设置过了生存时间的key中干掉一个最近最少使用的key。
>  *  allkeys-lru：在内存不足时，Redis会再全部的key中干掉一个最近最少使用的key。
>  *  volatile-lfu：在内存不足时，Redis会再设置过了生存时间的key中干掉一个最近最少频次使用的key。
>  *  allkeys-lfu：在内存不足时，Redis会再全部的key中干掉一个最近最少频次使用的key。
>  *  volatile-random：在内存不足时，Redis会再设置过了生存时间的key中随机干掉一个。
>  *  allkeys-random：在内存不足时，Redis会再全部的key中随机干掉一个。
>  *  volatile-ttl：在内存不足时，Redis会在设置过了生存时间的key中干掉一个剩余生存时间最少的key。
>  *  noeviction：（默认）在内存不足时，直接报错。

## Java中的类加载器： ##

主要有一下四种类加载器:

1 **启动类加载器**(Bootstrap ClassLoader)用来加载java核心类库，无法被java程序直接引用。

2 **扩展类加载器**(extensions class loader):它用来加载 Java 的扩展库。Java 虚拟机的实现会提供 一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。

3 **系统类加载器**（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，**Java 应用的类都是由它来完成加载的**。可以通过ClassLoader.getSystemClassLoader()来获取它。

4 **用户自定义类加载器**，通过继承 java.lang.ClassLoader类的方式实现。

## MYSQL ##

## mysql事务的隔离级别和传播行为 ##

### 事务的特性： ###

原子性：事务的不可分割，组成事务的各个逻辑单元不可分割。

一致性：事务执行的前后，数据完整性保持一致。

隔离性：事务执行不应该受到其他事务的干扰。

持久性：事务一旦结束，数据就持久化到数据库中。

查看/设置隔离级别 查看：SELECT @@tx\_isolation 设置：set tx\_isolation='xxx'

事务的隔离级别 如果不考虑隔离性，引发一些安全问题

隔离性：一个事务的执行，不应该受到其他事务的干扰。

脏读：一个事务读到了另一个事务未提交的数据，导致查询结果不一致 不可重复读：一个事务读到了另一个事务已经提交的update的数据，导致多次查询结果不一致。 虚读/幻读：一个事务读到了另一个事务已经提交的insert的数据，导致多次查询结果不一致。

### 设置事务的隔离级别： ###

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>default</td> 
   <td>(默认值）（采用数据库的默认的设置) （建议）</td> 
  </tr> 
  <tr> 
   <td>read-uncommited</td> 
   <td>读未提交</td> 
  </tr> 
  <tr> 
   <td>read-commited</td> 
   <td>读已提交 （Oracle数据库默认的隔离级别）</td> 
  </tr> 
  <tr> 
   <td>repeatable-read</td> 
   <td>可重复读 （MySQL数据库默认的隔离级别）</td> 
  </tr> 
  <tr> 
   <td>serialized-read</td> 
   <td>序列化读</td> 
  </tr> 
 </tbody> 
</table>

read uncommitted (读取未提交内容) ：脏读，不可重复读，虚读都有可能发生 read committed (读取提交内容) ：避免脏读。但是不可重复读和虚读是有可能发生 repeatable read (可重读) ：避免脏读和不可重复读，但是虚读有可能发生。 serializable(可串行化) ：避免脏读，不可重复读，虚读。

### 传播行为 ###

1、PROPAGATION\_**REQUIRED**（required）：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

2、PROPAGATION***NESTED**（nested）：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION***REQUIRED**类似的操作

3、PROPAGATION\_**SUPPORTS**（supports）：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就**以非事务执行**。

4、PROPAGATION\_**MANDATORY**（mandatory）：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就**抛出异常**。

5、PROPAGATION\_**REQUIRES\_NEW**：支持当前事务，创建新事务，无论当前存不存在事务，都创建新事务。

6、PROPAGATION\_**NOT\_SUPPORTED**：以**非事务方式执行操作**，如果当前存在事务，就把当前事务挂起。

7、PROPAGATION\_**NEVER**：以非事务方式执行，如果当前存在事务，则**抛出异常**。

### redolog、binlog、undolog 区别与作用 ###

> mysql数据更新是先到 内存 再到 磁盘（mysql）的，因此改完后如果还没写入磁盘就出错的话就会出现 脏数据。

#### **重做日志（redo log）** ####

确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

#### 回滚日志（undo log） ####

**撤销日志** ，在 **数据库事务 开始之前**，MYSQL会去记录更新前的数据到undo log文件中。如果事务回滚或者数据库崩溃时，可以利用undo log日志中记录的日志信息进行回退。同时也可以提供多版本并发控制下的读(MVCC)。

**保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即 非锁定读**

#### MVCC是什么？ ####

MVCC，全称Multi-Version Concurrency Control，即 **多版本并发控制** 。MVCC是一种并发控制的方法，一般在数据库管理系统 中，实现对数据库的并发访问，在编程语言中实现事务内存。

它主要是用来 **处理mysql在多线程操作缓存** 数据时出现的一系列 **并发问题**。

![6d24eb93881c51850336f4b017072a3f.png][]

#### 二进制日志（binlog） ####

用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。

## 优化 ##

### SQL优化 ###

查询上优化，公司不让设置外键（不让多表查询）有时候为了查询效率，会在表中添加一些冗余字段

![50e2ea8de3c1780652d312cfae1ff6be.png][]

看看是不是存在 **exist** 或者 **in** 导致**全表扫描**了

> 1、对查询进行优化，应尽量避免全表扫描，首先应考虑在 **where 及 order by 涉及的列上建立索引**。 2、应尽量避免在 where 子句中使用!=或<>操作符，否则将导致引擎放弃使用索引而进行全表扫描。 3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描， 4、应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描 5、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描 6、任何地方都不要使用 select \* from t ，用具体的字段列表代替“\*”，不要返回用不到的任何字段。 7、索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。 一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

#### 索引 ####

**非聚集索引和聚集索引的区别在于：**

通过聚集索引可以一次查到需要查找的数据， 而通过非聚集索引第一次只能查到记录对应的**主键值** ， 再使用主键的值通过聚集索引查找到需要的数据。

聚集索引一张表只能有一个，而非聚集索引一张表可以有多个。

MySQL调优、tomcat调优

结合场景：曾经遇见过sql优化的问题，这个是因为表数据太多，执行sql时间太长，于是我加了索引

### Tomcat优化 ###

### JVM优化 ###

### 4、part four ###

## SpringCloud ##

### nacos（注册中心、配置中心） ###

![95af2b556d6b8a32ef4dc501e3584551.png][]

配置中心：配置集中化管理，立即生效

### Ribbon（负载均衡） ###

#### 工作流程： ####

@LoadBalanced      //    这个注解打开   就会依据 服务名 进行负载均衡
    //让ribbon 拦截 RestTemplate 发出的所有的请求
    //ribbon 获取 url 中的 service name
    //从 nacos注册中心 获取 实例列表
    //负责从 实例列表中 通过相应的 负载均衡算法 ，获取一个实例
    //RestTemplate 请求实例

### OpenFeign（服务远程调用） ###

可以做到使用 HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个 HTTP 请求。同时OpenFeign通过集成Ribbon实现客户端的负载均衡

> nacos-server : 注册中心，解决是服务的注册与发现

> Ribbon：客户端负载均衡器，解决的是服务集群负载均衡的问题

> OpenFeign：声明式 HTTP 客户端 、代替Resttemplate组件，实现远程调用

## Layui： ##

, {field: 'status', title: '状态',templet: function(d){
    if(d.status==0){
    return '<span style="color: #009688;">待通过</span>'
    }else if(d.status==2){
    return '<span style="color: #1E9FFF;">已驳回</span>'
    }else if(d.status==1){
    return '<span style="color: #FF5722;">已通过</span>'
    }else if(d.status==3){
    return '<span style="color: #FF5722;">已撤销</span>'
    }

![ba1470b186229848b0e0e580bdccc8fe.png][]

![8f7e61dcef2e2426b8660451441ffa91.png][]

#### ajax 刷新： ####

var index = parent.layer.getFrameIndex(window.name); //先得到当前iframe层的索引
                                parent.layer.close(index); //再执行关闭

#### 关闭 弹出层: ####

var iframeIndex = parent.layer.getFrameIndex(![img](file:///C:\Users\86158\AppData\Roaming\Tencent\QQ\Temp\%W@GJ$ACOF(TYDYECOKVDYB.png)window.name);
                parent.layer.msg("更新成功");
                parent.layer.close(iframeIndex);

#### 本地存储： ####

localStorage.setItem("token", JSON.stringify(result.data.user));

#### 格式化日期： ####

document.getElementById('time').value = (new Date()).format('yyyy-MM-dd');

## VUE： ##

### axios ###

![f285f87bb0045bab2e8484bac225fb61.png][]

![e2ade88598bcb0b516cdfed2f74d0a68.png][]

![f53acf98f132da358495be2dedda67e5.png][]

### vue 的常用指令 ###

指令： 指令 (Directives) 是带有 v- 前缀的特殊 attribute。
        指令 attribute 的值预期是单个 JavaScript 表达式 (v-for 是例外情况，稍后我们再讨论)。
        指令的职责是，当表达式的值改变时，将其产生的连带影响，响应式地作用于 DOM。
        指令：
        v-model="vuedata"     数据双向绑定
        v-bind:htmlattr="vuedata"    属性动态赋值
        v-bind的简写       :htmlattr="vuedata"
        v-on:htmlevent="vuemethods"    事件动态绑定
        v-on的简写       @htmlevent = "vuemethods"
        v-html : 可以解析 html 标签
        v-once : 一次性的插值
        v-if="vuedata"  v-if 指令将根据表达式 vuedata 的值的真假来插入/移除 x 元素。

![8dedf3ef606a15fe8aec3d5ca7222e22.png][]

**计算属性有缓存不用每次都调用，而方法每次都需要调用**

### 数据库设计三范式 ###

> 第一范式：要求数据表中的**字段（列）不可再分(原子性)**

![7cbd676e6e89aff0f0b1f61f91b56912.png][]

> 第二范式：**不存在**非关键字段对**关键字段（主键）**的**部分依赖**
> 
> ps: 主要是针对联合主键,非主键不能只依赖联合主键的一部分
> 
>  *  联合主键,即多个列组成的主键

![d6524553a82ca26c2e9e49cc14dd72dc.png][]

![10c40a29007b46d3a8732bf790b83fda.png][]

> 第三范式：**不存在非关键字段之间的传递依赖**

## 二、Linux指令 ##

# 看防火墙     systemctl start|stop|restart|enable|disable|status 服务名称	 systemctl status iptables 
    # yum下载   						   yum install -y xxx    
    # 查看端口是否运行 					   netstat -naop|grep 6379
    # 将宿主机的文件复制到容器内部的指定目录  docker cp 文件名称 容器id:容器内部路径
    # 将容器内部的文件复制到宿主机           docker cp 容器id：容器目录    宿主机目录
    # 只查看后几行   tail 文件名			  tail -f 日志 监控日志
    # 常用的参数                           docker run -d -p 宿主机端口:容器端口 --name 容器名称 镜像的标识|镜像名称[:tag]

![22d9d02363802513c4244a6d42046105.png][]

## 端口 ##

6379 redis

9200 elasticSearch

5601 kibana

##  ##

#### 分布式锁的场景： ####

#### 分布式事务的场景： ####

#### Redis使用场景： ####

用户支付时，将**支付数据**存放在redis中

[4033590c075e186d68e55c0dbedc5db3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/f9dad6d94cc94aa0b0bf94fab7e47350.png
[0d6c8592b48347249426654d1ecf2bc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/baa720f7e4604280a64c8a8a88758c26.png
[86e4c26f864a0cecccbec8fb263a4a8f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/123b71d294064ac0aa9d3f12ebe38c7b.png
[302e46f3c6e678b989c953766c4c0666.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/117035c2bc9a4c8da051472ed0c1f739.png
[01b507156036a3376f77df968114bfb1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/bec0374117b34fb08507b7ef4b7135c2.png
[e0eb92ec62f34bc7d8c1359fd6e0f41f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/090e9c1355e14134a0b72a6228572939.png
[2097254930e9cac375553884602e4579.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/9448630c2537445ba471c83d2b4887b3.png
[2b7aed5cf68816afd63b3532850f1280.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/d78555a5bb544d9a82dee558dc7b33f9.png
[ad5100546476b422ed6ebae89d1ce9ef.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/8309e7884cda44369a513b169795ee48.png
[40fddc12c531bd84a940f678127a7664.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/490759a8e2cc414c860fe546c8103d8b.png
[9437740b27a41b5276e2fe9732459089.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/094e484e5e3b4486bb019b2af796e68a.png
[21573417564fc9b44e9a5f0affc37aea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/4d8bb5c586cf42b6a7a828030d5e9ec7.png
[ac628f35083ab4831672a662e37bc457.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/21f7c7d4614e4394a484da1800ac7607.png
[1a765bb1d59c6f69d448e8fd06762376.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/48c9fb9f1e554d2abdb826fdf0c1f88d.png
[6d24eb93881c51850336f4b017072a3f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/c9a5c183054f40bcacfbcead5cd22de7.png
[50e2ea8de3c1780652d312cfae1ff6be.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/e791da5572b84ab78219790d6826ae81.png
[95af2b556d6b8a32ef4dc501e3584551.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/055532204d374d89a8edc3672c6890bd.png
[ba1470b186229848b0e0e580bdccc8fe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/b8b79862c81a48dbab4049fc950f6c27.png
[8f7e61dcef2e2426b8660451441ffa91.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/7f36a8040b304537873233527ca5eda6.png
[f285f87bb0045bab2e8484bac225fb61.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/29e94bc9c71941dd82d7a6ef2df84edd.png
[e2ade88598bcb0b516cdfed2f74d0a68.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/cf4ee258e89a4e3487f297551e2e3afb.png
[f53acf98f132da358495be2dedda67e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/e692eefeb24d407cb81641dfb3695118.png
[8dedf3ef606a15fe8aec3d5ca7222e22.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/97c887773dc34fa9af34deb33cd84864.png
[7cbd676e6e89aff0f0b1f61f91b56912.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/038b65f0eff6401c9466ae98ebcf63e6.png
[d6524553a82ca26c2e9e49cc14dd72dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/650603f403a24da1af23239600ee9dec.png
[10c40a29007b46d3a8732bf790b83fda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/f4d2386e808243dfbfe00e176a5c1d39.png
[22d9d02363802513c4244a6d42046105.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/52360ba3b64c461db2d73b2f5a82f2ff.png