Redis 是一个用 C 语言开发的数据，并且 Redis 的数据是存储在内存中的，读写速度非常快，几乎不受 CPU 和磁盘 I/O 的影响。 Redis 被广泛应用在缓存方面，它支持多种数据类型如字符串、列表、集合、有序集合、哈希等；还支持事务，且操作遵循原子性；并且拥有其他强大的功能如持久化、主从复制、集群等。

Redis 常见知识点及面试题近万字总结

本文主要对数据库常见底层知识点进行总结，整理了包括范式、索引、事务、引擎、日志等常见数据库模块的内容。

数据库常见知识点以及面试题总结

OSI七层模型 #

OSI七层模型一般指开放系统互连参考模型 (Open System Interconnect 简称OSI)是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的开放系统互连参考模型，为开放式互连信息系统提供了一种功能结构的框架。

具体如下：

- 应用层：各种应用程序协议，比如 HTTP、HTTPS、FTP、SOCKS 安全套接字协议、DNS 域名系统、GDP 网关发现协议等。

- 表示层：加密解密、转换翻译、压缩解压缩，比如 LPP 轻量级表示协议。

- 会话层：不同机器上的用户建立和管理会话，比如 SSL 安全套接字层协议、TLS 传输层安全协议、RPC 远程过程调用协议等。

- 传输层：接收上一层的数据，在必要的时候对数据进行分割，并将这些数据交给网络层，保证这些数据段有效到达对端。比如TCP传输控制协议、UDP用户数据协议。

- 网络层：控制子网的运行：逻辑编址、分组传输、路由选择，比如 IP、IPV6、SLIP 等等。路由器工作在网络层。

- 数据链路层：物理寻址，同时将原始比特流转变为逻辑传输路线，比如 XTP 压缩传输协议、PPTP 点对点隧道协议等等。交换机工作在数据链路层。

- 物理层：机械、电子、定时接口通信信道上的原始比特流传输，比如 IEEE802.2 等等，会尽可能屏蔽传输媒介和通信手段的差异。

下面这张图详细将OSI七层模型详细地进行了总结（图片来源于网络），供同学们参考。

!OSI

传输控制协议 TCP #

传输控制协议-TCP：TCP是面向连接的、可靠的、基于字节流的传输层通信协议，它将应用层的数据流分割成报文段并发送给目标节点的TCP层。数据包都有序号，对方收到则发送ACK确认，未收到则重传。TCP使用奇偶校验和来检验数据在传输过程中是否有误，在发送和接收时都要计算校验和。

 TCP/IP四层网络模型 

TCP/IP协议被组织成四个概念层，其中有三层对应于OSI参考模型中的相应层。TCP/IP协议族并不包含物理层和数据链路层，因此它不能独立完成整个计算机网络系统的功能，必须与许多其他的协议协同工作。 TCP/IP分层模型的四个协议层分别完成以下的功能：

- 网络接口层：网络接口层包括用于协作IP数据在已有网络介质上传输的协议，如ARP，RARP。
- 网际层：网际层对应OSI七层参考模型的网络层。负责数据的包装、寻址和路由。同时还包含网际控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息(常见的Ping命令)。
- 传输层对应OSI七层参考模型的传输层，它提供两种端到端的通信服务。其中TCP协议(Transmission Control Protocol)提供可靠的数据流运输服务，UDP协议(User Datagram Protocol)提供不可靠的用户数据报服务。
- 应用层对应OSI七层参考模型的应用层和表示层。

 TCP协议的三次握手🤝(重点) 

第一次握手：客户端发送SYN包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态； 

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去。

三次握手流程图如下：

!三次握手流程图

 为什么是三次握手？（不能是两次握手吗？） 

答：第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。客户端发送的连接请求可能会在网络中滞留，可能导致很长一段时间后才能收到服务器发回的ACK信息。若超过客户端的超时重传时间后，客户端就会重新请求连接。之前发送的滞留的连接请求最后还是会到达服务器，如果没有第三次握手，服务器就会打开两个连接。如果有第三次握手，客户端就会忽略服务器之后发送的对滞留连接请求的连接确认，服务器也就不会再次打开连接。

 首次握手存在什么安全隐患？ 

答：SYN超时机制可能导致SYN Flood攻击。因为服务器收到客户端的SYN，回复SYN-ACK时没有收到ACK确认，服务器会不断进行重试直至超时，Linux默认等待63秒才断开连接，攻击者可能利用此机制发动SYN洪水，不断建立连接后断开，造成SYN队列满，让正常连接无法得到处理。

SYN Flood防护措施：SYN队列满后，通过tcp_syncookies参数回发SYN Cookie，若是正常连接则客户端会发回SYN Cookie，直接建立连接，而非法连接则不会。

 建立连接后客户端出现故障怎么办？ 

答：TCP设有保活机制。在keep alive time即保活时间内，开启保活功能的一端将向对方发送保活探测报文，如果未收到响应则继续发送。当尝试次数达到保活探测数时若仍未收到响应则中断连接。

 TCP协议的四次挥手👋🏻(重点) 

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。

第一次挥手：客户端发送释放连接的报文FIN，用来关闭客户端到服务器的数据传送。

第二次挥手：服务器收到客户端发送的FIN，发回客户端确认报文ACK，此时ACK=1，确认序号为收到的序号+1。此时，TCP连接处于半关闭状态。即服务器进入CLOSE_WAIT状态。

第三次挥手：服务器不再需要连接时，发送释放连接报文FIN给客户端，此时FIN=1，ACK=1。关闭与客户端的数据传送，服务器进入LAST_ACK状态。

第四次挥手：客户端收到后发出确认，ACK=1，确认序号为收到序号+1，并进入TIME-WAIT状态，等待2MSL（最大报文存活时间）后释放连接。服务器端收到客户端的确认信息后立即释放连接。

 为什么是四次挥手？ 

答：因为全双工通信发送方和接收方都需要FIN报文和ACK报文。客户端发送了FIN释放连接报文后，服务器收到了这个报文，进入CLOSE-WAIT状态。这个状态是为了让服务器发送还未发送完成的数据，发送完毕后，服务器会发送FIN释放了连接报文。

 为什么还要等待2MSL后才释放连接？ 

答：

1. 确保有足够的时间让对方收到ACK包。如果服务器没收到客户端发送来的确认报文，就会重新发送释放连接报文，客户端等待2MSL就是为了处理这种情况的发生。

2. 可以避免新旧链接混淆。等待2MSL可以让该连接时间段内产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

 服务器出现大量CLOSE_WAIT的原因是什么？怎么办？ 

答：可能是对方关闭Socket连接，我方忙于读或写，没有及时关闭连接。解决方法：检查代码，特别是释放资源的代码；检查配置，特别是处理请求的线程配置。

 TCP如何保证可靠传输？ 

- 发送方给每个包进行编号，接收方对数据包进行排序，再把有序数据交付给应用层。 

- TCP会保持首部和数据的校验和，目的是检测数据在传输过程中的变化，如果检验和有差错，TCP将丢弃这个报文段且不确认收到此报文段。

- 发送方每发完一个报文段就停止发送，等待接收方确认。收到接收方的确认后再发下一个报文段；如果不能及时收到确认，将发送方重发这个报文段。

- 流量控制：当接收方来不及处理发送方的数据，就会提示发送方降低发送速率。TCP利用滑动窗口实现流量控制。

- 拥塞控制：当网络拥塞时，会减少数据的发送。

 TCP的滑动窗口 

TCP使用滑动窗口做流量控制与乱序重排。发送方和接收方各有一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接受窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。接收窗口只会对窗口内最后一个按序到达的字节进行确认。发送方得到一个字节的确认后，就知道这个字节之前的所有字节都已经被接收。

 TCP的拥塞控制 

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，导致网络拥塞程度更高。因此，当出现拥塞时，应当控制发送方的速率。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。TCP主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

 慢开始和拥塞避免 

慢开始让拥塞窗口大小为1，收到确认后，会将窗口大小翻倍（2,4,8...）慢开始有一个限制ssthresh，当拥塞窗口大小 >= ssthresh的一半时，会进入拥塞避免。

在拥塞避免中，ssthresh每次收到确认后不再是翻倍，而是+1。如果出现了超时，则ssthresh将设置为当前拥塞窗口的一半，然后重新执行慢开始。

 快重传和快恢复 

接收方会对最后一个收到的有序报文段进行确认。例如已经接收到M 1和M 2，此时收到M 4，应当发送对M 2的确认。发送端如果收到了三个重复的确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到3个M 2，则M 3丢失，立即重传M 3。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复：拥塞窗口大小设置为原来的一半，然后不再执行慢开始，直接进入拥塞避免。

用户数据报协议-UDP #

UDP即用户数据报协议，是一个无连接的简单的面向数据报的传输层协议。UDP面向非连接，不维护连接状态，支持同时向多个客户端传输相同的信息。由于其数据报头只有8个字节所以额外开销较小。吞吐量只受限于数据生成速率、传输速率以及机器性能。UDP会尽最大努力交付，但不保证可靠交付，无需维持复杂的链接状态表。它是面向报文的，不对应用程序提交的报文信息进行拆分或合并。

TCP和UDP的区别 #

它们的区别如下：

- TCP提供面向连接、可靠的数据传输服务；UDP提供无连接、最大努力的数据传输服务。
- TCP 主要提供完整性服务，UDP 主要提供及时性服务。
- UDP支持一对一，一对多，多对一，多对多；TCP只支持一对一。
- UDP不具备有序性，TCP可保证有序性。

超文本传输协议-HTTP #

HTTP（HyperText Transfer Protocol），即超文本传输协议。是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。它基于 TCP/IP 通信协议来传递数据（HTML 文件、图片文件、查询结果等）。

 输入URL后会发生什么(重点) 

1. DNS解析：浏览器会根据URL逐层查询DNS缓存，解析URL的域名所对应的IP地址。

   > 注：DNS缓存由近到远依次是：浏览器缓存->系统缓存->路由器缓存->IPS服务器缓存->根域名服务器缓存->顶级域名服务器缓存。

2. 建立TCP连接：找到IP地址后，会根据IP地址和对应的端口（默认80），和服务器通过三次握手建立TCP连接。

3. 发送HTTP请求：浏览器会给服务器发送读取文件的HTTP请求。

4. 服务器响应：服务器对浏览器请求作出响应，并把带有HTML文本的HTTP响应报文发送给浏览器。

5. 浏览器解析渲染页面：浏览器收到HTML并在视窗内进行渲染。

6. 连接结束：浏览器和服务器通过四次挥手释放TCP连接。

> 第5步和第6步没有先后顺序。

 常见的HTTP状态码 

- 1xx: 提示信息，表示请求已被接收，继续处理。
- 2xx: 成功，表示请求已被成功接收，理解，接受。
- 3xx: 重定向，要完成请求必须进行进一步操作。
- 4xx: 客户端错误，请求有格式错误或请求无法实现。
- 5xx: 服务端错误，服务器未能响应合法请求。

| 状态码                    | 解释                                                         |
| ------------------------- | ------------------------------------------------------------ |
| 200 OK                    | 正常返回                                                     |
| 400 Bad Request           | 客户端请求有格式错误，不能被服务器所理解                     |
| 401 Unauthorized          | 请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用 |
| 403 Forbidden             | 服务器收到请求，但拒绝提供服务                               |
| 404 Not Found             | 请求资源不存在（输入错误的URL）                              |
| 500 Internal Server Error | 服务器内部错误                                               |
| 503 Server Unavailable    | 服务器当前不能处理客户端请求，一段时间后可能恢复正常         |

 GET请求和POST请求的区别(基础但很重要) 

- HTTP报文层面：GET将请求信息放在URL，浏览器会对URL长度进行限制；POST将信息放在报文体中，大小无限制。
- 数据库层面：GET作为查询请求，每次执行得到的结果都相同，且不会修改数据，因此符合幂等性和安全性；POST会往数据库中提交数据，不符合幂等性和安全性。
- 其他层面：GET请求可以被浏览器记录，可以被缓存和存储，POST请求不行。

 Cookie和Session 

 Cookie 

Cookie是由服务器发送给客户端的特殊信息，以文本的形式存放在客户端。客户端再次请求时，会把Cookie回发。服务器接收到后，会解析Cookie生成与客户端相对应的内容。

 Session 

Session是服务端的机制，在服务端保存的信息。解析客户端请求并操作session id，并按需保存状态信息。

 Cookie和Session的区别 

- 数据存放位置不同：Cookie数据存放在客户的浏览器上，Session数据放在服务器上。
- 安全程度不同：Cookie并不安全，攻击者可以分析存放在本地的Cookie，可能会带来安全问题。Session是相对安全的。
- 性能差别：Session会在其生命周期内保存在服务器上。当访问量增加，会占用服务器的性能，可使用Cookie减轻服务器性能开销。
- 数据存储大小不同：单个Cookie保存的数据不能超过4KB，许多浏览器都限制一个站点最多保存20个Cookie。而Session则存储于服务端，不受浏览器限制。

HTTPS #

HTTPS（全称：Hyper Text Transfer Protocol over SecureSocket Layer），它是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础上加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

 什么是SSL？ 

SSL（Security Sockets Layer），即安全套阶层，它是为网络通信提供安全及数据完整性的一种安全协议，SSL3.0后改名为TLS，采用身份验证和数据加密来保证网络通信的安全和数据的完整性。

 SSL 加密方式 

- 对称加密：加密和解密都使用同一个密钥。
- 非对称加密：加密使用的密钥和解密使用的密钥是不相同的。（公钥和私钥）
- 哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆。
- 数字签名：证明某个消息或者文件是某人发出/认同的。

 HTTPS数据传输流程 

1. 浏览器将支持的加密算法信息发送给服务器。
2. 服务器选择一种浏览器支持的算法，以证书的形式回发给浏览器。
3. 浏览器检查证书的合法性，并用证书中的公钥对随机生成的消息进行加密。
4. 服务器用自己的私钥解密消息，确定密码，验证哈希，并加密响应消息回发给浏览器。
5. 浏览器解密响应消息，如果跟之前发过去的哈希值一致，那么之后都使用之前生成的随机密码加密。

 HTTPS的加密过程 

1. 服务器拥有CA证书的公钥和私钥；
2. 浏览器向服务器发送请求，服务器将证书公钥传输给浏览器；
3. 浏览器验证证书有效后，随机生成一个密钥，再用公钥加密后传给服务器；
4. 服务器收到后用私钥解密可以得到这个密钥；
5. 这样浏览器和服务器双方都有密钥，之后双方所有的数据都通过密钥加密解密就行。

有了CA证书，可以避免中间人攻击，浏览器可以确保收到的公钥一定是请求网站发过来的。

HTTP和HTTPS的区别 #

- HTTP需要到CA申请证书，HTTP不需要。
- HTTPS密文传输，HTTP明文传输。
- 连接方式不同，HTTPS默认使用443端口，HTTP使用80端口。
- HTTPS = HTTP + 加密 + 认证 + 完整性保护，较HTTP安全。

Socket 套接字 #

Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口，它封装了一系列网络操作的API。

Socket的通信流程如下图所示：

!socket

Socket面试中问得较少，但也可能被问到，建议同学们亲自动手编写一个demo来实现服务器和客户端的socket通信。

本文主要讲解计算机网络知识点及面试题。

计算机网络知识点及面试题详解

Spring概述 #

 什么是Spring？ 

>  Spring 是一款开源的轻量级 Java 开发框架，旨在提高开发人员的开发效率以及系统的可维护性。

 你们项目为什么使用Spring框架？ 

这个问题我们直接回答其优点即可。

- 轻量：Spring是轻量级框架，基本版本大约只有2MB。
- 控制反转（IoC）：Spring通过控制反转实现了松散耦合，使其具备高可维护性和拓展性。
- 面向切面编程（AOP）：Spring支持面向切面编程，能够很方便地进行日志记录，数据库访问等。
- 容器：Spring包含并负责管理应用中对象的生命周期和配置，无需手动干预。
- 事务管理：Spring提供一个持续的事务管理接口，可以扩展到上至本地事务下至全局事务（JTA）。
- 异常处理：Spring 提供方便的API把具体技术相关的异常（比如由JDBC，Hibernate or JDO抛出的）转化为一致的unchecked 异常。

 Spring的组成部分 

!Spring组成

重要模块如下：

- Spring Core：核心类库，提供IoC服务
- Spring Context：提供框架式的Bean访问方式，以及企业级功能（JNDI、定时任务等）；
- Spring Aspects：提供AspectJ 集成支持
- Spring AOP：提供面向切面编程实现
- Spring DAO：对JDBC的抽象，简化了数据访问异常的处理；
- Spring ORM：对现有的ORM框架的支持；
- Spring Web：提供了基本的面向Web的综合特性，如：Web基本功能，WebSockets等。
- Spring MVC：提供面向Web应用的Model-View-Controller实现。
- Spring Test：集成测试模块。（Spring团队提倡测试驱动开发，即TDD）

依赖注入(DI) #

 什么是依赖注入？ 

依赖注入，即Dependency Inversion，全称是“依赖注入到容器”，通俗地讲，容器是某个对象，如果把某个类放入这个容器中，通过“依赖注入”可以解析出这个类的实例。

 依赖注入的方式有哪些？ 

依赖注入的方式：

- 构造器注入：将被依赖对象通过构造函数的参数注入给依赖对象，并且在初始化对象的时候注入。

  - 优点： 对象初始化完成后便可获得可使用的对象。

  - 缺点： 当需要注入的对象很多时，构造器参数列表会变得很长，不够灵活。若有多种注入方式，每种方式只需注入指定几个依赖，那么就需要提供多个重载的构造函数，使得代码难以维护。

- setter方法注入：IoC Service Provider通过调用成员变量提供的setter函数将被依赖对象注入给依赖类。

  - 优点： 灵活，可以有选择性地注入需要的对象。

  - 缺点： 由于依赖对象初始化完成后尚未注入被依赖对象，故还不能使用。

- 接口注入：依赖类必须要实现指定的接口，然后实现该接口中的一个函数，该函数就是用于依赖注入，该函数的参数就是要注入的对象。

  - 优点：接口注入中，接口的名字、函数的名字都不重要，只要保证函数的参数是要注入的对象类型即可。

  - 缺点： 侵入性太强，破坏系统的封装性，不建议使用。

还有一种注入方式是注解注入，即使用@Autowired进行注入。严格地说，它不是一种新的注入方式，注解注入本质上还是Setter注入或构造函数注入。

控制反转(IoC) #

 什么是IoC 

IoC（Inversion of Control）控制反转，是Spring Core最核心的部分，它是一种设计思想，不是具体的技术实现。IoC的思想就是将原本需要手动创建的对象交由Spring框架进行管理，Spring会根据容器的配置文件去创建实例和管理实例之间的依赖关系，对象与对象之间松散耦合，有利于功能的复用。简单来说，IoC让对象创建不用去new了，可以由Spring自动生产，并配合Java的反射机制，根据 配置文件在运行的时候动态去创建对象及管理对象，并调用对象方法。

在没有IoC之前，项目中的一个类可能依赖于很多其他不同的类，如果我们需要实例化这个类，我们需要搞清楚所有依赖类的构造函数，并逐一实例化，在添加或者修改类结构时，项目几乎无法维护。有了IoC之后，只需要配置好，并在需要的地方进行引用，这大大增加了可维护性。

 依赖倒置原则、IoC、DI、IoC容器的关系 

> 依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

关系如图所示：

!关系图

Spring Bean #

 什么是Bean？ 

Spring bean是指被Spring IoC容器管理的对象。Bean是由Spring IoC容器进行实例化、组装和管理的对象。它是在程序运行时，通过反射机制生成的。

在使用时，我们需要编写配置文件告诉IoC容器帮助我们管理哪些对象，可以通过XML文件、注解或Java配置类进行配置。

 BeanFactory 

BeanFactory是Spring框架最底层的接口，它提供了IoC的配置机制，包含Bean的各种定义，便于实例化Bean。在实例化时，BeanFactory可用于建立Bean之间的依赖关系。

 ApplicationContext 

ApplicationContext，即应用上下文，继承自BeanFactory接口，它是Spring的一个更高级容器，提供了更丰富的功能：

- 国际化（MessageSource）
- 访问资源，如URL和文件（ResourceLoader）
- 载入多个（有继承关系）上下文 ，使得每一个上下文都专注于一个特定的层次，比如应用的web层
- 消息发送、响应机制（ApplicationEventPublisher）
- AOP

 BeanFactory和ApplicationContext的区别 

- 加载方式不同：BeanFactory采用的是延迟加载（懒加载）的方式来注入Bean的。在启动的时候不会实例化Bean，只有在使用到某个Bean，即调用getBean()时才会对该Bean进行实例化。ApplicationContext在启动时就会将所有Bean进行实例化。不过当Bean配置了lazy-init=true时，ApplicationContext也会延迟对该Bean的加载。

- BeanFactory是Spring框架的基础设施，面向Spring，而ApplicationContext面向使用Spring框架的开发者，相比BeanFactory提供了更多面向实际应用的功能，几乎所有场合都能够直接使用ApplicationContext，而不是使用底层的BeanFactory。

 Bean的作用域 

Bean的作用域：

- singleton：唯一的bean实例，与单例模式相同，Spring中的bean默认都是单例的。
- prototype：每次请求都会创建一个新的bean实例。
- request：为每个http请求都创建一个新的bean，该bean仅在当前http request内有效
- session：每次来自新session的请求都创建一个新的bean，该bean仅在当前session内有效。
- global-session ： 全局 session 作用域，仅仅在基于 portlet 的 web 应用中才有意义，Spring5 已经没有了。

 Bean的生命周期 

Bean生命周期：

创建bean

1. 实例化Bean：对于BeanFactory容器，当客户向容器请求一个尚未初始化的bean时，或初始化bean的时候需要注入另一个尚未初始化的依赖时，容器就会调用createBean进行实例化。对于ApplicationContext容器，当容器启动结束后，通过获取BeanDefinition对象中的信息，实例化所有的bean。
2. 设置对象属性（依赖注入）：实例化后的对象被封装在BeanWrapper对象中，Spring根据BeanDefinition中的信息以及通过BeanWrapper提供的设置属性的接口完成依赖注入。
3. 处理Aware接口：在这一步，Spring会检测对象是否实现了xxxAware接口，并将相关的xxxAware实例注入给Bean：
   - 如果这个Bean已经实现了BeanNameAware接口，则调用它所实现的setBeanName(String beanId)方法，此处传递的是Spring配置文件中Bean的id值。
   - 如果这个Bean已经实现了BeanFactoryAware接口，会调用它所实现的setBeanFactory()方法，传递的是BeanFactory自身。
   - 如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传递的是ApplicationContext；
4. BeanPostProcessor：如果想对Bean进行一些自定义的处理，可以让Bean实现BeanPostProcessor接口，这样做会调用postProcessBeforeInitialization(Object obj, String s)方法。
5. InitializingBean与init-method：如果Bean在Spring配置文件中配置了init-method属性，则会自动调用其配置的初始化方法。
6. 如果这个Bean实现了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法。另外，由于这个方法是在Bean初始化结束时调用的，所以可以被应用于内存或缓存技术。

> 以上几个步骤执行完成后，Bean就已经被正确创建了，之后就可以使用这个Bean了。

销毁bean

7. DisposableBean：若Bean实现了DisposableBean这个接口，会调用其实现的destroy()方法。
8. destroy-method：若配置了destroy-method属性，则会调用其配置的销毁方法。

最后我通过一张图来总结Bean的生命周期。

!Bean的生命周期

 @Component和@Bean的区别 

- @Component作用于类，而@Bean作用于方法
- @Component会自动扫描路径来自动装配Bean到Spring IoC中，也可以通过@ComponentScan自定义扫描路径。@Bean表示方法产生一个由Spring管理的bean。
- @Bean 比 @Component 的自定义性更强，许多地方我们只能通过 @Bean 来对bean进行注册。比如当我们引用第三方库中的类需要装配到 Spring容器时，则只能通过 @Bean来实现。

Spring AOP #

 谈谈你对AOP的理解 

AOP（Aspect-Oriented Programming）面向切面编程，它能够将那些与业务无关，却为业务模块所共同调用的通用功能（例如事务处理、日志管理、权限控制等）封装起来，减少系统中的重复代码，降低模块间的耦合度，提高项目的拓展性和可维护性。

它的基本思想如下：AOP注重关注点分离，即不同的问题交给不同的部分去解决，目的是为了将业务功能的关注点和通用化功能的关注点进行分离。这些通用化功能（例如：事务处理、日志管理...）的代码实现就是所谓的切面(Aspect)。业务功能代码和切面代码分开后，架构将变得高内聚，低耦合。最后，切面需要最终被合并到业务中，确保功能的完整性，这就是织入（Weave）。

 AOP的三种织入方式 

- 编译时织入：需要特殊的Java编译器，如AspectJ。
- 类加载时织入：需要特殊的Java编译器，如AspectJ何AspectWerkz。
- 运行时织入：Spring AOP采用的方式，通过动态代理的方式，实现简单。

 AOP中的重要概念 

AOP，面向切面编程，即Aspect Oriented Programming。

- Aspect：切面，类似于Java中的类声明，是对系统中横跨多个类的关注点进行模块化封装
- Joinpoint：连接点，程序执行过程中的一个“点”，例如：方法的执行或异常的处理。在Spring AOP中，一个连接点总是代表一个方法的执行。
- Pointcut：切入点，即一组连接点的集合；
- Advice：通知，定义了将会织入到 Joinpoint 的具体逻辑，通过@Before、@After、@Around等注解来区别在JointPoint之前、之后等位置执行代码
- Weaving：织入，织入指的是将Advice连接到Pointcut指定的Joinpoint处的过程
- Interceptor：拦截器，是一种实现Advice（通知）的方式；
- Target：目标对象，即符合切入点所指定的条件被织入Advice的对象。

 Advice的种类 

- 前置通知（Before）
- 后置通知（AfterReturning）
- 异常通知（AfterThrowing）
- 最终通知（After）
- 环绕通知（Around）

 AOP的实现 

前置知识：设计模式-代理模式，可查看我的这篇文章：https://www.yeliheng.com/articles/dc912a27

在Java中，AOP有两种基于动态代理的实现方式，分别是JDK Proxy和cglib。具体使用哪种方式生成，由AopProxyFactory根据AdvisedSupport对象的配置来决定。默认策略是：如果目标类是接口，则采用JDK Proxy来实现，否则使用cglib来生成代理。

JDK Proxy的核心是InvocationHandler接口和Proxy类，通过Java内部的反射机制实现。

cglib是通过修改字节码来实现代理的，底层基于ASM框架（ASM是一种字节码操作框架）。它以继承的方式动态生成目标类的代理，因此，如果某个类被final关键字修饰，则无法使用cglib来做动态代理。

反射机制在生成类的过程中比较高效，ASM在生成类之后的执行过程中比较高效。

 Spring中的代理模式的实现 

- 真实实现类的逻辑包含在getBean()方法中。
- getBean方法返回的实际上是Proxy的实例。
- Proxy实例是Spring采用JDK Proxy或cglib动态生成的。

注：getBean()方法用于查找或实例化容器中的Bean，这样是为什么Spring AOP只能作用于Spring容器中的Bean的原因。对于不是使用IoC容器管理的对象，Spring AOP是无能为力的。

 Spring AOP的应用 

请查看我的这篇文章：Spring AOP的最佳实践：在你的系统中记录用户的操作日志

Spring 事务 #

 Spring管理事务的方式 

- 编程式事务管理：在代码中通过编码的方式实现事务，例如通过TransactionTemplate或TransactionManager手动管理事务，这种方式不推荐在项目中使用，实现复杂，会使得代码难以维护。
- 声明式事务管理：此方式意味着你可以将事务管理和业务代码分离，只需要使用注解或在Xml配置文件中进行配置。在项目中经常基于AOP实现，使用@Transactional进行事务管理。

 事务三要素是什么？ 

数据源：表示具体的事务性资源，是事务的真正处理者，如MySQL等。

事务管理器：像一个大管家，从整体上管理事务的处理过程，如打开、提交、回滚等。

事务应用和属性配置：像一个标识符，表明哪些方法要参与事务，如何参与事务，以及一些相关属性如隔离级别、超时时间等。

 Spring 事务中有哪几种的事务传播行为？ 

>  事务传播行为是为了解决业务层方法之间互相调用的事务问题。当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。

Spring事务定义了以下7种传播行为：

1. PROPAGATION_REQUIRED：默认的Spring事务传播级别，若当前存在事务，则加入该事务，若不存在事务，则新建一个事务。

2. PAOPAGATION_REQUIRE_NEW：若当前没有事务，则新建一个事务。若当前存在事务，则新建一个事务，新老事务相互独立。外部事务抛出异常回滚不会影响内部事务的正常提交。

3. PROPAGATION_NESTED：如果当前存在事务，则嵌套在当前事务中执行。如果当前没有事务，则新建一个事务，类似于PAOPAGATION_REQUIRE_NEW。

4. PROPAGATION_SUPPORTS：支持当前事务，若当前不存在事务，以非事务的方式执行。

5. PROPAGATION_NOT_SUPPORTED：以非事务的方式执行，若当前存在事务，则把当前事务挂起。

6. PROPAGATION_MANDATORY：强制事务执行，若当前不存在事务，则抛出异常。

7. PROPAGATION_NEVER：以非事务的方式执行，如果当前存在事务，则抛出异常。

 说说Spring事务的隔离级别 

- ISOLATION_DEFAULT：使用数据库默认的隔离级别。MySQL 默认采用的 REPEATABLE_READ 隔离级别，Oracle默认采用的READ_COMMITTED隔离级别。

- ISOLATION_READ_UNCOMMITTED：这是事务最低的隔离级别，它允许读取该事务尚未提交的数据变更。此隔离级别可能会产生脏读、幻读或不可重复读。
- ISOLATION_READ_COMMITTED：保证一个事务修改的数据提交后才能够被另外一个事务读取。此隔离级别可以阻止脏读，但是幻读或不可重复读仍有可能发生。
- ISOLATION_REPEATABLE_READ：它除了保证一个事务不能读取另外一个事务未提交的数据外，还保证对同一字段多次读取结果都是一致的，除非数据是被自身事务所修改。此隔离级别可以阻止脏读和不可重复读，但幻读仍有可能发生。
- ISOLATION_SERIALIZABLE：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能，开销巨大，使用场景较少。

 事务注解的本质是什么？ 

@Transactional这个注解仅仅是一些（和事务相关的）元数据，在运行时被事务基础设施读取消费，并使用这些元数据来配置bean的事务行为。 大致来说具有两方面功能：

- 表明该方法要参与事务。
- 配置相关属性来定制事务的参与方式和运行行为。

声明式事务主要得益于Spring AOP。使用一个事务拦截器，在方法调用的前后/周围进行事务性通知（Advice），来驱动事务完成。@Transactional注解既可以标注在类上，也可以标注在方法上。当在类上时，默认应用到类里的所有方法。如果此时方法上也标注了，则方法上的优先级高，另外注意方法必须是public的。

本文整理了Spring框架原理及部分常见面试题，方便同学们复习。

Spring框架原理及面试题详解

本文整理了一些面试常考的Java基础知识点，方便同学们复习。

标签：面试

Redis 常见知识点及面试题近万字总结

数据库常见知识点以及面试题总结

计算机网络知识点及面试题详解

Spring框架原理及面试题详解

Java基础知识以及面试题总结