# SpringBoot Web 案例

• 开发流程

  我们在进行功能开发时，都是根据如下流程进行：

  1. 查看页面原型明确需求

     • 根据页面原型和需求，进行表结构设计、编写接口文档 (已提供)

  2. 阅读接口文档

  3. 思路分析

  4. 功能接口开发

     • 就是开发后台的业务功能，一个业务功能，我们称为一个接口

  5. 功能接口测试

     • 功能开发完毕后，先通过 Postman 进行功能接口测试，测试通过后，再和前端进行联调测试

  6. 前后端联调测试

     • 和前端开发人员开发好的前端工程一起测试

# 会话跟踪技术

# Cookie

• cookie 是客户端会话跟踪技术，它是存储在客户端浏览器的，我们使用 cookie 来跟踪会话，我们就可以在浏览器第一次发起请求来请求服务器的时候，我们在服务器端来设置一个 cookie。

  比如第一次请求了登录接口，登录接口执行完成之后，我们就可以设置一个 cookie，在 cookie 当中我们就可以来存储用户相关的一些数据信息。比如我可以在 cookie 当中来存储当前登录用户的用户名，用户的 ID。

  服务器端在给客户端在响应数据的时候，会自动的将 cookie 响应给浏览器，浏览器接收到响应回来的 cookie 之后，会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求当中，都会将浏览器本地所存储的 cookie 自动地携带到服务端。

  接下来在服务端我们就可以获取到 cookie 的值。我们可以去判断一下这个 cookie 的值是否存在，如果不存在这个 cookie，就说明客户端之前是没有访问登录接口的；如果存在 cookie 的值，就说明客户端之前已经登录完成了。这样我们就可以基于 cookie 在同一次会话的不同请求之间来共享数据。

  我刚才在介绍流程的时候，用了 3 个自动：

  • 服务器会 自动 的将 cookie 响应给浏览器。

  • 浏览器接收到响应回来的数据之后，会 自动 的将 cookie 存储在浏览器本地。

  • 在后续的请求当中，浏览器会 自动 的将 cookie 携带到服务器端。

  为什么这一切都是自动化进行的？

  是因为 cookie 它是 HTP 协议当中所支持的技术，而各大浏览器厂商都支持了这一标准。在 HTTP 协议官方给我们提供了一个响应头和请求头：

  • 响应头 Set-Cookie ：设置 Cookie 数据的

  • 请求头 Cookie：携带 Cookie 数据的

  代码测试

  	@Slf4j
  	@RestController
  	public class SessionController {
  	// 设置 Cookie
  	@GetMapping("/c1")
  	public Result cookie1(HttpServletResponse response){
  	response.addCookie(new Cookie("login_username","itheima")); // 设置 Cookie / 响应 Cookie
  	return Result.success();
  	}
  	// 获取 Cookie
  	@GetMapping("/c2")
  	public Result cookie2(HttpServletRequest request){
  	Cookie[] cookies = request.getCookies();
  	for (Cookie cookie : cookies) {
  	if(cookie.getName().equals("login_username")){
  	System.out.println("login_username: "+cookie.getValue()); // 输出 name 为 login_username 的 cookie
  	}
  	}
  	return Result.success();
  	}
  	}

  A. 访问 c1 接口，设置 Cookie，http://localhost:8080/c1

  我们可以看到，设置的 cookie，通过响应头 Set-Cookie 响应给浏览器，并且浏览器会将 Cookie，存储在浏览器端。

  B. 访问 c2 接口 http://localhost:8080/c2，此时浏览器会自动的将 Cookie 携带到服务端，是通过请求头 Cookie，携带的。

  优缺点

  • 优点：HTTP 协议中支持的技术（像 Set-Cookie 响应头的解析以及 Cookie 请求头数据的携带，都是浏览器自动进行的，是无需我们手动操作的）
  • 缺点：
    • 移动端 APP (Android、IOS) 中无法使用 Cookie
    • 不安全，用户可以自己禁用 Cookie
    • Cookie 不能跨域

  跨域介绍：

  ​ <img src="../../JavaWeb/day12-SpringBootWeb 登录认证 / 讲义 /assets/image-20230112103840467.png" alt="image-20230112103840467" style="zoom:80%;" />

  • 现在的项目，大部分都是前后端分离的，前后端最终也会分开部署，前端部署在服务器 192.168.150.200 上，端口 80，后端部署在 192.168.150.100 上，端口 8080
  • 我们打开浏览器直接访问前端工程，访问 url：http://192.168.150.200/login.html
  • 然后在该页面发起请求到服务端，而服务端所在地址不再是 localhost，而是服务器的 IP 地址 192.168.150.100，假设访问接口地址为：http://192.168.150.100:8080/login
  • 那此时就存在跨域操作了，因为我们是在 http://192.168.150.200/login.html 这个页面上访问了 http://192.168.150.100:8080/login 接口
  • 此时如果服务器设置了一个 Cookie，这个 Cookie 是不能使用的，因为 Cookie 无法跨域

  区分跨域的维度：

  • 协议
  • IP / 协议
  • 端口

  只要上述的三个维度有任何一个维度不同，那就是跨域操作

  举例：

  ​ http://192.168.150.200/login.html ----------> https://192.168.150.200/login [协议不同，跨域]

  ​ http://192.168.150.200/login.html ----------> http://192.168.150.100/login [IP 不同，跨域]

  ​ http://192.168.150.200/login.html ----------> http://192.168.150.200:8080/login [端口不同，跨域]

  ​ http://192.168.150.200/login.html ----------> http://192.168.150.200/login [不跨域]

# Session

• Session，它是服务器端会话跟踪技术，所以它是存储在服务器端的。而 Session 的底层其实就是基于我们刚才所介绍的 Cookie 来实现的。

  • 获取 Session

    如果我们现在要基于 Session 来进行会话跟踪，浏览器在第一次请求服务器的时候，我们就可以直接在服务器当中来获取到会话对象 Session。如果是第一次请求 Session ，会话对象是不存在的，这个时候服务器会自动的创建一个会话对象 Session 。而每一个会话对象 Session ，它都有一个 ID（示意图中 Session 后面括号中的 1，就表示 ID），我们称之为 Session 的 ID。

  • 响应 Cookie (JSESSIONID)

    接下来，服务器端在给浏览器响应数据的时候，它会将 Session 的 ID 通过 Cookie 响应给浏览器。其实在响应头当中增加了一个 Set-Cookie 响应头。这个 Set-Cookie 响应头对应的值是不是 cookie？ cookie 的名字是固定的 JSESSIONID 代表的服务器端会话对象 Session 的 ID。浏览器会自动识别这个响应头，然后自动将 Cookie 存储在浏览器本地。

  • 查找 Session

    接下来，在后续的每一次请求当中，都会将 Cookie 的数据获取出来，并且携带到服务端。接下来服务器拿到 JSESSIONID 这个 Cookie 的值，也就是 Session 的 ID。拿到 ID 之后，就会从众多的 Session 当中来找到当前请求对应的会话对象 Session。

    这样我们是不是就可以通过 Session 会话对象在同一次会话的多次请求之间来共享数据了？好，这就是基于 Session 进行会话跟踪的流程。

  代码测试

  	@Slf4j
  	@RestController
  	public class SessionController {
  	@GetMapping("/s1")
  	public Result session1(HttpSession session){
  	log.info("HttpSession-s1: {}", session.hashCode());
  	session.setAttribute("loginUser", "tom"); // 往 session 中存储数据
  	return Result.success();
  	}
  	@GetMapping("/s2")
  	public Result session2(HttpServletRequest request){
  	HttpSession session = request.getSession();
  	log.info("HttpSession-s2: {}", session.hashCode());
  	Object loginUser = session.getAttribute("loginUser"); // 从 session 中获取数据
  	log.info("loginUser: {}", loginUser);
  	return Result.success(loginUser);
  	}
  	}

  A. 访问 s1 接口，http://localhost:8080/s1

  请求完成之后，在响应头中，就会看到有一个 Set-Cookie 的响应头，里面响应回来了一个 Cookie，就是 JSESSIONID，这个就是服务端会话对象 Session 的 ID。

  B. 访问 s2 接口，http://localhost:8080/s2

  接下来，在后续的每次请求时，都会将 Cookie 的值，携带到服务端，那服务端呢，接收到 Cookie 之后，会自动的根据 JSESSIONID 的值，找到对应的会话对象 Session。

  那经过这两步测试，大家也会看到，在控制台中输出如下日志：

  两次请求，获取到的 Session 会话对象的 hashcode 是一样的，就说明是同一个会话对象。而且，第一次请求时，往 Session 会话对象中存储的值，第二次请求时，也获取到了。 那这样，我们就可以通过 Session 会话对象，在同一个会话的多次请求之间来进行数据共享了。

  优缺点

  • 优点：Session 是存储在服务端的，安全
  • 缺点：
    • 服务器集群环境下无法直接使用 Session
    • 移动端 APP (Android、IOS) 中无法使用 Cookie
    • 用户可以自己禁用 Cookie
    • Cookie 不能跨域

  PS：Session 底层是基于 Cookie 实现的会话跟踪，如果 Cookie 不可用，则该方案，也就失效了。

  服务器集群环境为何无法使用 Session？

  ​ <img src="../../JavaWeb/day12-SpringBootWeb 登录认证 / 讲义 /assets/image-20230112112557480.png" alt="image-20230112112557480" style="zoom:67%;" />

  • 首先第一点，我们现在所开发的项目，一般都不会只部署在一台服务器上，因为一台服务器会存在一个很大的问题，就是单点故障。所谓单点故障，指的就是一旦这台服务器挂了，整个应用都没法访问了。

  ​

  • 所以在现在的企业项目开发当中，最终部署的时候都是以集群的形式来进行部署，也就是同一个项目它会部署多份。比如这个项目我们现在就部署了 3 份。

  • 而用户在访问的时候，到底访问这三台其中的哪一台？其实用户在访问的时候，他会访问一台前置的服务器，我们叫负载均衡服务器，我们在后面项目当中会详细讲解。目前大家先有一个印象负载均衡服务器，它的作用就是将前端发起的请求均匀的分发给后面的这三台服务器。

  • 此时假如我们通过 session 来进行会话跟踪，可能就会存在这样一个问题。用户打开浏览器要进行登录操作，此时会发起登录请求。登录请求到达负载均衡服务器，将这个请求转给了第一台 Tomcat 服务器。

    Tomcat 服务器接收到请求之后，要获取到会话对象 session。获取到会话对象 session 之后，要给浏览器响应数据，最终在给浏览器响应数据的时候，就会携带这么一个 cookie 的名字，就是 JSESSIONID ，下一次再请求的时候，是不是又会将 Cookie 携带到服务端？

    好。此时假如又执行了一次查询操作，要查询部门的数据。这次请求到达负载均衡服务器之后，负载均衡服务器将这次请求转给了第二台 Tomcat 服务器，此时他就要到第二台 Tomcat 服务器当中。根据 JSESSIONID 也就是对应的 session 的 ID 值，要找对应的 session 会话对象。

    我想请问在第二台服务器当中有没有这个 ID 的会话对象 Session， 是没有的。此时是不是就出现问题了？我同一个浏览器发起了 2 次请求，结果获取到的不是同一个会话对象，这就是 Session 这种会话跟踪方案它的缺点，在服务器集群环境下无法直接使用 Session。

# 令牌技术 (JWT)

• # 介绍

  JWT 全称：JSON Web Token （官网：https://jwt.io/）

  • 定义了一种简洁的、自包含的格式，用于在通信双方以 json 数据格式安全的传输信息。由于数字签名的存在，这些信息是可靠的。

    简洁：是指 jwt 就是一个简单的字符串。可以在请求参数或者是请求头当中直接传递。

    自包含：指的是 jwt 令牌，看似是一个随机的字符串，但是我们是可以根据自身的需求在 jwt 令牌中存储自定义的数据内容。如：可以直接在 jwt 令牌中存储用户的相关信息。

    简单来讲，jwt 就是将原始的 json 数据格式进行了安全的封装，这样就可以直接基于 jwt 在通信双方安全的进行信息传输了。

  JWT 的组成： （JWT 令牌由三个部分组成，三个部分之间使用英文的点来分割）

  • 第一部分：Header (头）， 记录令牌类型、签名算法等。 例如：

  • 第二部分：Payload (有效载荷），携带一些自定义信息、默认信息等。 例如：

  • 第三部分：Signature (签名），防止 Token 被篡改、确保安全性。将 header、payload，并加入指定秘钥，通过指定签名算法计算而来。

    签名的目的就是为了防 jwt 令牌被篡改，而正是因为 jwt 令牌最后一个部分数字签名的存在，所以整个 jwt 令牌是非常安全可靠的。一旦 jwt 令牌当中任何一个部分、任何一个字符被篡改了，整个令牌在校验的时候都会失败，所以它是非常安全可靠的。

  JWT 是如何将原始的 JSON 格式数据，转变为字符串的呢？

  其实在生成 JWT 令牌时，会对 JSON 格式的数据进行一次编码：进行 base64 编码

  Base64：是一种基于 64 个可打印的字符来表示二进制数据的编码方式。既然能编码，那也就意味着也能解码。所使用的 64 个字符分别是 A 到 Z、a 到 z、 0- 9，一个加号，一个斜杠，加起来就是 64 个字符。任何数据经过 base64 编码之后，最终就会通过这 64 个字符来表示。当然还有一个符号，那就是等号。等号它是一个补位的符号

  需要注意的是 Base64 是编码方式，而不是加密方式。

  JWT 令牌最典型的应用场景就是登录认证：

  1. 在浏览器发起请求来执行登录操作，此时会访问登录的接口，如果登录成功之后，我们需要生成一个 jwt 令牌，将生成的 jwt 令牌返回给前端。
  2. 前端拿到 jwt 令牌之后，会将 jwt 令牌存储起来。在后续的每一次请求中都会将 jwt 令牌携带到服务端。
  3. 服务端统一拦截请求之后，先来判断一下这次请求有没有把令牌带过来，如果没有带过来，直接拒绝访问，如果带过来了，还要校验一下令牌是否是有效。如果有效，就直接放行进行请求的处理。

  在 JWT 登录认证的场景中我们发现，整个流程当中涉及到两步操作：

  1. 在登录成功之后，要生成令牌。
  2. 每一次请求当中，要接收令牌并对令牌进行校验。

  稍后我们再来学习如何来生成 jwt 令牌，以及如何来校验 jwt 令牌。

  • # 生成和校验

  简单介绍了 JWT 令牌以及 JWT 令牌的组成之后，接下来我们就来学习基于 Java 代码如何生成和校验 JWT 令牌。

  首先我们先来实现 JWT 令牌的生成。要想使用 JWT 令牌，需要先引入 JWT 的依赖：

  	<!-- JWT 依赖 -->
  	<dependency>
  	<groupId>io.jsonwebtoken</groupId>
  	<artifactId>jjwt</artifactId>
  	<version>0.9.1</version>
  	</dependency>

  在引入完 JWT 来赖后，就可以调用工具包中提供的 API 来完成 JWT 令牌的生成和校验

  工具类：Jwts

  生成 JWT 代码实现：

  	@Test
  	public void genJwt(){
  	Map<String,Object> claims = new HashMap<>();
  	claims.put("id",1);
  	claims.put("username","Tom");
  	String jwt = Jwts.builder()
  	.setClaims(claims) // 自定义内容 (载荷)
  	.signWith(SignatureAlgorithm.HS256, "itheima") // 签名算法
  	.setExpiration(new Date(System.currentTimeMillis() + 24*3600*1000)) // 有效期
  	.compact();
  	System.out.println(jwt);
  	}

  运行测试方法：

  eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjcyNzI5NzMwfQ.fHi0Ub8npbyt71UqLXDdLyipptLgxBUg_mSuGJtXtBk
  

  输出的结果就是生成的 JWT 令牌，，通过英文的点分割对三个部分进行分割，我们可以将生成的令牌复制一下，然后打开 JWT 的官网，将生成的令牌直接放在 Encoded 位置，此时就会自动的将令牌解析出来。

  第一部分解析出来，看到 JSON 格式的原始数据，所使用的签名算法为 HS256。

  第二个部分是我们自定义的数据，之前我们自定义的数据就是 id，还有一个 exp 代表的是我们所设置的过期时间。

  由于前两个部分是 base64 编码，所以是可以直接解码出来。但最后一个部分并不是 base64 编码，是经过签名算法计算出来的，所以最后一个部分是不会解析的。

  实现了 JWT 令牌的生成，下面我们接着使用 Java 代码来校验 JWT 令牌 (解析生成的令牌)：

  	@Test
  	public void parseJwt(){
  	Claims claims = Jwts.parser()
  	.setSigningKey("itheima")// 指定签名密钥（必须保证和生成令牌时使用相同的签名密钥）
  	.parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjcyNzI5NzMwfQ.fHi0Ub8npbyt71UqLXDdLyipptLgxBUg_mSuGJtXtBk")
  	.getBody();
  	System.out.println(claims);
  	}

  运行测试方法：

  {id=1, exp=1672729730}
  

  令牌解析后，我们可以看到 id 和过期时间，如果在解析的过程当中没有报错，就说明解析成功了。

  下面我们做一个测试：把令牌 header 中的数字 9 变为 8，运行测试方法后发现报错：

  原 header： eyJhbGciOiJIUzI1NiJ9

  修改为： eyJhbGciOiJIUzI1NiJ8

  结论：篡改令牌中的任何一个字符，在对令牌进行解析时都会报错，所以 JWT 令牌是非常安全可靠的。

  我们继续测试：修改生成令牌的时指定的过期时间，修改为 1 分钟

  	@Test
  	public void genJwt(){
  	Map<String,Object> claims = new HashMap<>();
  	claims.put(“id”,1);
  	claims.put(“username”,“Tom”);
  	String jwt = Jwts.builder()
  	.setClaims(claims) // 自定义内容 (载荷)
  	.signWith(SignatureAlgorithm.HS256, “itheima”) // 签名算法
  	.setExpiration(new Date(System.currentTimeMillis() + 60*1000)) // 有效期 60 秒
  	.compact();
  	System.out.println(jwt);
  	// 输出结果：eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjczMDA5NzU0fQ.RcVIR65AkGiax-ID6FjW60eLFH3tPTKdoK7UtE4A1ro
  	}
  	@Test
  	public void parseJwt(){
  	Claims claims = Jwts.parser()
  	.setSigningKey("itheima")// 指定签名密钥
  	.parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwiZXhwIjoxNjczMDA5NzU0fQ.RcVIR65AkGiax-ID6FjW60eLFH3tPTKdoK7UtE4A1ro")
  	.getBody();
  	System.out.println(claims);
  	}

  等待 1 分钟之后运行测试方法发现也报错了，说明：JWT 令牌过期后，令牌就失效了，解析的为非法令牌。

  通过以上测试，我们在使用 JWT 令牌时需要注意：

  • JWT 校验时使用的签名秘钥，必须和生成 JWT 令牌时使用的秘钥是配套的。

  • 如果 JWT 令牌解析校验时报错，则说明 JWT 令牌被篡改 或 失效了，令牌非法。

  • # 登录下发令牌

  JWT 令牌的生成和校验的基本操作我们已经学习完了，接下来我们就需要在案例当中通过 JWT 令牌技术来跟踪会话。具体的思路我们前面已经分析过了，主要就是两步操作：

  1. 生成令牌
     • 在登录成功之后来生成一个 JWT 令牌，并且把这个令牌直接返回给前端
  2. 校验令牌
     • 拦截前端请求，从请求中获取到令牌，对令牌进行解析校验

  那我们首先来完成：登录成功之后生成 JWT 令牌，并且把令牌返回给前端。

  JWT 令牌怎么返回给前端呢？此时我们就需要再来看一下接口文档当中关于登录接口的描述（主要看响应数据）：

  • 响应数据

    参数格式：application/json

    参数说明：

    名称	类型	是否必须	默认值	备注	其他信息
    code	number	必须		响应码，1 成功；0 失败
    msg	string	非必须		提示信息
    data	string	必须		返回的数据，jwt 令牌

    响应数据样例：

    	{
    	"code": 1,
    	"msg": "success",
    	"data": "eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoi6YeR5bq4IiwiaWQiOjEsInVzZXJuYW1lIjoiamlueW9uZyIsImV4cCI6MTY2MjIwNzA0OH0.KkUc_CXJZJ8Dd063eImx4H9Ojfrr6XMJ-yVzaWCVZCo"
    	}

  • 备注说明

    用户登录成功后，系统会自动下发 JWT 令牌，然后在后续的每次请求中，都需要在请求头 header 中携带到服务端，请求头的名称为 token ，值为 登录时下发的 JWT 令牌。

    如果检测到用户未登录，则会返回如下固定错误信息：

    	{
    	"code": 0,
    	"msg": "NOT_LOGIN",
    	"data": null
    	}

  解读完接口文档中的描述了，目前我们先来完成令牌的生成和令牌的下发，我们只需要生成一个令牌返回给前端就可以了。

  实现步骤：

  1. 引入 JWT 工具类
     • 在项目工程下创建 com.itheima.utils 包，并把提供 JWT 工具类复制到该包下
  2. 登录完成后，调用工具类生成 JWT 令牌并返回

  JWT 工具类

  	public class JwtUtils {
  	private static String signKey = "itheima";// 签名密钥
  	private static Long expire = 43200000L; // 有效时间
  	/**
  	* 生成 JWT 令牌
  	* @param claims JWT 第二部分负载 payload 中存储的内容
  	* @return
  	*/
  	public static String generateJwt(Map<String, Object> claims){
  	String jwt = Jwts.builder()
  	.addClaims(claims)// 自定义信息（有效载荷）
  	.signWith(SignatureAlgorithm.HS256, signKey)// 签名算法（头部）
  	.setExpiration(new Date(System.currentTimeMillis() + expire))// 过期时间
  	.compact();
  	return jwt;
  	}
  	/**
  	* 解析 JWT 令牌
  	* @param jwt JWT 令牌
  	* @return JWT 第二部分负载 payload 中存储的内容
  	*/
  	public static Claims parseJWT(String jwt){
  	Claims claims = Jwts.parser()
  	.setSigningKey(signKey)// 指定签名密钥
  	.parseClaimsJws(jwt)// 指定令牌 Token
  	.getBody();
  	return claims;
  	}
  	}

  登录成功，生成 JWT 令牌并返回

  	@RestController
  	@Slf4j
  	public class LoginController {
  	// 依赖业务层对象
  	@Autowired
  	private EmpService empService;
  	@PostMapping("/login")
  	public Result login(@RequestBody Emp emp) {
  	// 调用业务层：登录功能
  	Emp loginEmp = empService.login(emp);
  	// 判断：登录用户是否存在
  	if(loginEmp !=null ){
  	// 自定义信息
  	Map<String , Object> claims = new HashMap<>();
  	claims.put("id", loginEmp.getId());
  	claims.put("username",loginEmp.getUsername());
  	claims.put("name",loginEmp.getName());
  	// 使用 JWT 工具类，生成身份令牌
  	String token = JwtUtils.generateJwt(claims);
  	return Result.success(token);
  	}
  	return Result.error("用户名或密码错误");
  	}
  	}

  重启服务，打开 postman 测试登录接口：

  打开浏览器完成前后端联调操作：利用开发者工具，抓取一下网络请求

  登录请求完成后，可以看到 JWT 令牌已经响应给了前端，此时前端就会将 JWT 令牌存储在浏览器本地。

  服务器响应的 JWT 令牌存储在本地浏览器哪里了呢？

  • 在当前案例中，JWT 令牌存储在浏览器的本地存储空间 local storage 中了。 local storage 是浏览器的本地存储，在移动端也是支持的。

  我们在发起一个查询部门数据的请求，此时我们可以看到在请求头中包含一个 token (JWT 令牌)，后续的每一次请求当中，都会将这个令牌携带到服务端。

# Filter Interceptor (令牌的统一拦截校验)

# Filter

• # 快速入门

  什么是 Filter？

  • Filter 表示过滤器，是 JavaWeb 三大组件 (Servlet、Filter、Listener) 之一。
  • 过滤器可以把对资源的请求拦截下来，从而实现一些特殊的功能
    • 使用了过滤器之后，要想访问 web 服务器上的资源，必须先经过滤器，过滤器处理完毕之后，才可以访问对应的资源。
  • 过滤器一般完成一些通用的操作，比如：登录校验、统一编码处理、敏感字符处理等。

  下面我们通过 Filter 快速入门程序掌握过滤器的基本使用操作：

  • 第 1 步，定义过滤器 ：1. 定义一个类，实现 Filter 接口，并重写其所有方法。
  • 第 2 步，配置过滤器：Filter 类上加 @WebFilter 注解，配置拦截资源的路径。引导类上加 @ServletComponentScan 开启 Servlet 组件支持。

  定义过滤器

  	// 定义一个类，实现一个标准的 Filter 过滤器的接口
  	public class DemoFilter implements Filter {
  	@Override // 初始化方法，只调用一次
  	public void init(FilterConfig filterConfig) throws ServletException {
  	System.out.println("init 初始化方法执行了");
  	}
  	@Override // 拦截到请求之后调用，调用多次
  	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
  	System.out.println("Demo 拦截到了请求...放行前逻辑");
  	// 放行
  	chain.doFilter(request,response);
  	}
  	@Override // 销毁方法，只调用一次
  	public void destroy() {
  	System.out.println("destroy 销毁方法执行了");
  	}
  	}

  • init 方法：过滤器的初始化方法。在 web 服务器启动的时候会自动的创建 Filter 过滤器对象，在创建过滤器对象的时候会自动调用 init 初始化方法，这个方法只会被调用一次。

  • doFilter 方法：这个方法是在每一次拦截到请求之后都会被调用，所以这个方法是会被调用多次的，每拦截到一次请求就会调用一次 doFilter () 方法。

  • destroy 方法： 是销毁的方法。当我们关闭服务器的时候，它会自动的调用销毁方法 destroy，而这个销毁方法也只会被调用一次。

  在定义完 Filter 之后，Filter 其实并不会生效，还需要完成 Filter 的配置，Filter 的配置非常简单，只需要在 Filter 类上添加一个注解：@WebFilter，并指定属性 urlPatterns，通过这个属性指定过滤器要拦截哪些请求

  	@WebFilter(urlPatterns = "/*") // 配置过滤器要拦截的请求路径（ /* 表示拦截浏览器的所有请求 ）
  	public class DemoFilter implements Filter {
  	@Override // 初始化方法，只调用一次
  	public void init(FilterConfig filterConfig) throws ServletException {
  	System.out.println("init 初始化方法执行了");
  	}
  	@Override // 拦截到请求之后调用，调用多次
  	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
  	System.out.println("Demo 拦截到了请求...放行前逻辑");
  	// 放行
  	chain.doFilter(request,response);
  	}
  	@Override // 销毁方法，只调用一次
  	public void destroy() {
  	System.out.println("destroy 销毁方法执行了");
  	}
  	}

  当我们在 Filter 类上面加了 @WebFilter 注解之后，接下来我们还需要在启动类上面加上一个注解 @ServletComponentScan，通过这个 @ServletComponentScan 注解来开启 SpringBoot 项目对于 Servlet 组件的支持。

  	@ServletComponentScan
  	@SpringBootApplication
  	public class TliasWebManagementApplication {
  	public static void main(String[] args) {
  	SpringApplication.run(TliasWebManagementApplication.class, args);
  	}
  	}

  重新启动服务，打开浏览器，执行部门管理的请求，可以看到控制台输出了过滤器中的内容：

  注意事项：

  ​ 在过滤器 Filter 中，如果不执行放行操作，将无法访问后面的资源。 放行操作：chain.doFilter (request, response);

• # 拦截路径

  执行流程我们搞清楚之后，接下来再来介绍一下过滤器的拦截路径，Filter 可以根据需求，配置不同的拦截资源路径：

  拦截路径	urlPatterns 值	含义
  拦截具体路径	/login	只有访问 /login 路径时，才会被拦截
  目录拦截	/emps/*	访问 /emps 下的所有资源，都会被拦截
  拦截所有	/*	访问所有资源，都会被拦截

• # 过滤器链

  最后我们在来介绍下过滤器链，什么是过滤器链呢？所谓过滤器链指的是在一个 web 应用程序当中，可以配置多个过滤器，多个过滤器就形成了一个过滤器链。

  比如：在我们 web 服务器当中，定义了两个过滤器，这两个过滤器就形成了一个过滤器链。

  而这个链上的过滤器在执行的时候会一个一个的执行，会先执行第一个 Filter，放行之后再来执行第二个 Filter，如果执行到了最后一个过滤器放行之后，才会访问对应的 web 资源。

  访问完 web 资源之后，按照我们刚才所介绍的过滤器的执行流程，还会回到过滤器当中来执行过滤器放行后的逻辑，而在执行放行后的逻辑的时候，顺序是反着的。

  先要执行过滤器 2 放行之后的逻辑，再来执行过滤器 1 放行之后的逻辑，最后在给浏览器响应数据。

• # 登录校验 - Filter

  • # 分析

  过滤器 Filter 的快速入门以及使用细节我们已经介绍完了，接下来最后一步，我们需要使用过滤器 Filter 来完成案例当中的登录校验功能。

  我们先来回顾下前面分析过的登录校验的基本流程：

  • 要进入到后台管理系统，我们必须先完成登录操作，此时就需要访问登录接口 login。

  • 登录成功之后，我们会在服务端生成一个 JWT 令牌，并且把 JWT 令牌返回给前端，前端会将 JWT 令牌存储下来。

  • 在后续的每一次请求当中，都会将 JWT 令牌携带到服务端，请求到达服务端之后，要想去访问对应的业务功能，此时我们必须先要校验令牌的有效性。

  • 对于校验令牌的这一块操作，我们使用登录校验的过滤器，在过滤器当中来校验令牌的有效性。如果令牌是无效的，就响应一个错误的信息，也不会再去放行访问对应的资源了。如果令牌存在，并且它是有效的，此时就会放行去访问对应的 web 资源，执行相应的业务操作。

  大概清楚了在 Filter 过滤器的实现步骤了，那在正式开发登录校验过滤器之前，我们思考两个问题：

  1. 所有的请求，拦截到了之后，都需要校验令牌吗？

     • 答案：登录请求例外

  2. 拦截到请求后，什么情况下才可以放行，执行业务操作？

     • 答案：有令牌，且令牌校验通过 (合法)；否则都返回未登录错误结果

  • # 具体流程

  我们要完成登录校验，主要是利用 Filter 过滤器实现，而 Filter 过滤器的流程步骤：

  基于上面的业务流程，我们分析出具体的操作步骤：

  1. 获取请求 url
  2. 判断请求 url 中是否包含 login，如果包含，说明是登录操作，放行
  3. 获取请求头中的令牌（token）
  4. 判断令牌是否存在，如果不存在，返回错误结果（未登录）
  5. 解析 token，如果解析失败，返回错误结果（未登录）
  6. 放行

  • # 代码实现

  分析清楚了以上的问题后，我们就参照接口文档来开发登录功能了，登录接口描述如下：

  • 基本信息

    请求路径：/login
    
    请求方式：POST
    
    接口描述：该接口用于员工登录Tlias智能学习辅助系统，登录完毕后，系统下发JWT令牌。 
    

  • 请求参数

    参数格式：application/json

    参数说明：

    名称	类型	是否必须	备注
    username	string	必须	用户名
    password	string	必须	密码

    请求数据样例：

    	{
    	"username": "jinyong",
    	"password": "123456"
    	}

  • 响应数据

    参数格式：application/json

    参数说明：

    名称	类型	是否必须	默认值	备注	其他信息
    code	number	必须		响应码，1 成功；0 失败
    msg	string	非必须		提示信息
    data	string	必须		返回的数据，jwt 令牌

    响应数据样例：

    	{
    	"code": 1,
    	"msg": "success",
    	"data": "eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoi6YeR5bq4IiwiaWQiOjEsInVzZXJuYW1lIjoiamlueW9uZyIsImV4cCI6MTY2MjIwNzA0OH0.KkUc_CXJZJ8Dd063eImx4H9Ojfrr6XMJ-yVzaWCVZCo"
    	}

  • 备注说明

    用户登录成功后，系统会自动下发 JWT 令牌，然后在后续的每次请求中，都需要在请求头 header 中携带到服务端，请求头的名称为 token ，值为 登录时下发的 JWT 令牌。

    如果检测到用户未登录，则会返回如下固定错误信息：

    	{
    	"code": 0,
    	"msg": "NOT_LOGIN",
    	"data": null
    	}

  登录校验过滤器：LoginCheckFilter

  	@Slf4j
  	@WebFilter(urlPatterns = "/*") // 拦截所有请求
  	public class LoginCheckFilter implements Filter {
  	@Override
  	public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {
  	// 前置：强制转换为 http 协议的请求对象、响应对象 （转换原因：要使用子类中特有方法）
  	HttpServletRequest request = (HttpServletRequest) servletRequest;
  	HttpServletResponse response = (HttpServletResponse) servletResponse;
  	//1. 获取请求 url
  	String url = request.getRequestURL().toString();
  	log.info("请求路径：{}", url); // 请求路径：http://localhost:8080/login
  	//2. 判断请求 url 中是否包含 login，如果包含，说明是登录操作，放行
  	if(url.contains("/login")){
  	chain.doFilter(request, response);// 放行请求
  	return;// 结束当前方法的执行
  	}
  	//3. 获取请求头中的令牌（token）
  	String token = request.getHeader("token");
  	log.info("从请求头中获取的令牌：{}",token);
  	//4. 判断令牌是否存在，如果不存在，返回错误结果（未登录）
  	if(!StringUtils.hasLength(token)){
  	log.info("Token不存在");
  	Result responseResult = Result.error("NOT_LOGIN");
  	// 把 Result 对象转换为 JSON 格式字符串 (fastjson 是阿里巴巴提供的用于实现对象和 json 的转换工具类)
  	String json = JSONObject.toJSONString(responseResult);
  	response.setContentType("application/json;charset=utf-8");
  	// 响应
  	response.getWriter().write(json);
  	return;
  	}
  	//5. 解析 token，如果解析失败，返回错误结果（未登录）
  	try {
  	JwtUtils.parseJWT(token);
  	}catch (Exception e){
  	log.info("令牌解析失败!");
  	Result responseResult = Result.error("NOT_LOGIN");
  	// 把 Result 对象转换为 JSON 格式字符串 (fastjson 是阿里巴巴提供的用于实现对象和 json 的转换工具类)
  	String json = JSONObject.toJSONString(responseResult);
  	response.setContentType("application/json;charset=utf-8");
  	// 响应
  	response.getWriter().write(json);
  	return;
  	}
  	//6. 放行
  	chain.doFilter(request, response);
  	}
  	}

  在上述过滤器的功能实现中，我们使用到了一个第三方 json 处理的工具包 fastjson。我们要想使用，需要引入如下依赖：

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

  登录校验的过滤器我们编写完成了，接下来我们就可以重新启动服务来做一个测试：

  测试前先把之前所编写的测试使用的过滤器，暂时注释掉。直接将 @WebFilter 注解给注释掉即可。

  • 测试 1：未登录是否可以访问部门管理页面

    首先关闭浏览器，重新打开浏览器，在地址栏中输入：http://localhost:9528/#/system/dept

    由于用户没有登录，登录校验过滤器返回错误信息，前端页面根据返回的错误信息结果，自动跳转到登录页面了

  • 测试 2：先进行登录操作，再访问部门管理页面

    登录校验成功之后，可以正常访问相关业务操作页面

# Interceptor

• # 快速入门

  什么是拦截器？

  • 是一种动态拦截方法调用的机制，类似于过滤器。
  • 拦截器是 Spring 框架中提供的，用来动态拦截控制器方法的执行。

  拦截器的作用：

  • 拦截请求，在指定方法调用前后，根据业务需要执行预先设定的代码。

  在拦截器当中，我们通常也是做一些通用性的操作，比如：我们可以通过拦截器来拦截前端发起的请求，将登录校验的逻辑全部编写在拦截器当中。在校验的过程当中，如发现用户登录了 (携带 JWT 令牌且是合法令牌)，就可以直接放行，去访问 spring 当中的资源。如果校验时发现并没有登录或是非法令牌，就可以直接给前端响应未登录的错误信息。

  下面我们通过快速入门程序，来学习下拦截器的基本使用。拦截器的使用步骤和过滤器类似，也分为两步：

  1. 定义拦截器

  2. 注册配置拦截器

  ** 自定义拦截器：** 实现 HandlerInterceptor 接口，并重写其所有方法

  	// 自定义拦截器
  	@Component
  	public class LoginCheckInterceptor implements HandlerInterceptor {
  	// 目标资源方法执行前执行。 返回 true：放行 返回 false：不放行
  	@Override
  	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
  	System.out.println("preHandle .... ");
  	return true; //true 表示放行
  	}
  	// 目标资源方法执行后执行
  	@Override
  	public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
  	System.out.println("postHandle ... ");
  	}
  	// 视图渲染完毕后执行，最后执行
  	@Override
  	public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
  	System.out.println("afterCompletion .... ");
  	}
  	}

  注意：

  ​ preHandle 方法：目标资源方法执行前执行。 返回 true：放行 返回 false：不放行

  ​ postHandle 方法：目标资源方法执行后执行

  ​ afterCompletion 方法：视图渲染完毕后执行，最后执行

  注册配置拦截器：实现 WebMvcConfigurer 接口，并重写 addInterceptors 方法

  	@Configuration
  	public class WebConfig implements WebMvcConfigurer {
  	// 自定义的拦截器对象
  	@Autowired
  	private LoginCheckInterceptor loginCheckInterceptor;
  	@Override
  	public void addInterceptors(InterceptorRegistry registry) {
  	// 注册自定义拦截器对象
  	registry.addInterceptor(loginCheckInterceptor).addPathPatterns("/**");// 设置拦截器拦截的请求路径（ /** 表示拦截所有请求）
  	}
  	}

  重新启动 SpringBoot 服务，打开 postman 测试：

  接下来我们再来做一个测试：将拦截器中返回值改为 false

  使用 postman，再次点击 send 发送请求后，没有响应数据，说明请求被拦截了没有放行

  • # 拦截路径

  首先我们先来看拦截器的拦截路径的配置，在注册配置拦截器的时候，我们要指定拦截器的拦截路径，通过 addPathPatterns("要拦截路径") 方法，就可以指定要拦截哪些资源。

  在入门程序中我们配置的是 /** ，表示拦截所有资源，而在配置拦截器时，不仅可以指定要拦截哪些资源，还可以指定不拦截哪些资源，只需要调用 excludePathPatterns("不拦截路径") 方法，指定哪些资源不需要拦截。

  	@Configuration
  	public class WebConfig implements WebMvcConfigurer {
  	// 拦截器对象
  	@Autowired
  	private LoginCheckInterceptor loginCheckInterceptor;
  	@Override
  	public void addInterceptors(InterceptorRegistry registry) {
  	// 注册自定义拦截器对象
  	registry.addInterceptor(loginCheckInterceptor)
  	.addPathPatterns("/**")// 设置拦截器拦截的请求路径（ /** 表示拦截所有请求）
  	.excludePathPatterns("/login");// 设置不拦截的请求路径
  	}
  	}

  在拦截器中除了可以设置 /** 拦截所有资源外，还有一些常见拦截路径设置：

  拦截路径	含义	举例
  /*	一级路径	能匹配 /depts，/emps，/login，不能匹配 /depts/1
  /**	任意级路径	能匹配 /depts，/depts/1，/depts/1/2
  /depts/*	/depts 下的一级路径	能匹配 /depts/1，不能匹配 /depts/1/2，/depts
  /depts/**	/depts 下的任意级路径	能匹配 /depts，/depts/1，/depts/1/2，不能匹配 /emps/1

  • # 执行流程

    介绍完拦截路径的配置之后，接下来我们再来介绍拦截器的执行流程。通过执行流程，大家就能够清晰的知道过滤器与拦截器的执行时机。

    • 当我们打开浏览器来访问部署在 web 服务器当中的 web 应用时，此时我们所定义的过滤器会拦截到这次请求。拦截到这次请求之后，它会先执行放行前的逻辑，然后再执行放行操作。而由于我们当前是基于 springboot 开发的，所以放行之后是进入到了 spring 的环境当中，也就是要来访问我们所定义的 controller 当中的接口方法。

    • Tomcat 并不识别所编写的 Controller 程序，但是它识别 Servlet 程序，所以在 Spring 的 Web 环境中提供了一个非常核心的 Servlet：DispatcherServlet（前端控制器），所有请求都会先进行到 DispatcherServlet，再将请求转给 Controller。

    • 当我们定义了拦截器后，会在执行 Controller 的方法之前，请求被拦截器拦截住。执行 preHandle() 方法，这个方法执行完成后需要返回一个布尔类型的值，如果返回 true，就表示放行本次操作，才会继续访问 controller 中的方法；如果返回 false，则不会放行（controller 中的方法也不会执行）。

    • 在 controller 当中的方法执行完毕之后，再回过来执行 postHandle() 这个方法以及 afterCompletion() 方法，然后再返回给 DispatcherServlet，最终再来执行过滤器当中放行后的这一部分逻辑的逻辑。执行完毕之后，最终给浏览器响应数据。

    接下来我们就来演示下过滤器和拦截器同时存在的执行流程：

    • 开启 LoginCheckInterceptor 拦截器

    	@Component
    	public class LoginCheckInterceptor implements HandlerInterceptor {
    	@Override
    	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    	System.out.println("preHandle .... ");
    	return true; //true 表示放行
    	}
    	@Override
    	public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
    	System.out.println("postHandle ... ");
    	}
    	@Override
    	public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
    	System.out.println("afterCompletion .... ");
    	}
    	}

    	@Configuration
    	public class WebConfig implements WebMvcConfigurer {
    	// 拦截器对象
    	@Autowired
    	private LoginCheckInterceptor loginCheckInterceptor;
    	@Override
    	public void addInterceptors(InterceptorRegistry registry) {
    	// 注册自定义拦截器对象
    	registry.addInterceptor(loginCheckInterceptor)
    	.addPathPatterns("/**")// 拦截所有请求
    	.excludePathPatterns("/login");// 不拦截登录请求
    	}
    	}

    • 开启 DemoFilter 过滤器

    	@WebFilter(urlPatterns = "/*")
    	public class DemoFilter implements Filter {
    	@Override
    	public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
    	System.out.println("DemoFilter 放行前逻辑.....");
    	// 放行请求
    	filterChain.doFilter(servletRequest,servletResponse);
    	System.out.println("DemoFilter 放行后逻辑.....");
    	}
    	}

    重启 SpringBoot 服务后，清空日志，打开 Postman，测试查询部门：

    以上就是拦截器的执行流程。通过执行流程分析，大家应该已经清楚了过滤器和拦截器之间的区别，其实它们之间的区别主要是两点：

    • 接口规范不同：过滤器需要实现 Filter 接口，而拦截器需要实现 HandlerInterceptor 接口。
    • 拦截范围不同：过滤器 Filter 会拦截所有的资源，而 Interceptor 只会拦截 Spring 环境中的资源。

  • 登录校验 - Interceptor 和登录校验 Filter 过滤器当中的逻辑是完全一致的

# 异常处理

• 三层架构处理异常的方案：

  • Mapper 接口在操作数据库的时候出错了，此时异常会往上抛 (谁调用 Mapper 就抛给谁)，会抛给 service。
  • service 中也存在异常了，会抛给 controller。
  • 而在 controller 当中，我们也没有做任何的异常处理，所以最终异常会再往上抛。最终抛给框架之后，框架就会返回一个 JSON 格式的数据，里面封装的就是错误的信息，但是框架返回的 JSON 格式的数据并不符合我们的开发规范。

• 那么在三层构架项目中，出现了异常，该如何处理？

  • 方案一：在所有 Controller 的所有方法中进行 try…catch 处理
    • 缺点：代码臃肿（不推荐）
  • 方案二：全局异常处理器
    • 好处：简单、优雅（推荐）

• # 全局异常处理器

  我们该怎么样定义全局异常处理器？

  • 定义全局异常处理器非常简单，就是定义一个类，在类上加上一个注解 @RestControllerAdvice，加上这个注解就代表我们定义了一个全局异常处理器。
  • 在全局异常处理器当中，需要定义一个方法来捕获异常，在这个方法上需要加上注解 @ExceptionHandler。通过 @ExceptionHandler 注解当中的 value 属性来指定我们要捕获的是哪一类型的异常。

  	@RestControllerAdvice
  	public class GlobalExceptionHandler {
  	// 处理异常
  	@ExceptionHandler(Exception.class) // 指定能够处理的异常类型
  	public Result ex(Exception e){
  	e.printStackTrace();// 打印堆栈中的异常信息
  	// 捕获到异常之后，响应一个标准的 Result
  	return Result.error("对不起,操作失败,请联系管理员");
  	}
  	}

  @RestControllerAdvice = @ControllerAdvice + @ResponseBody

  处理异常的方法返回值会转换为 json 后再响应给前端

  重新启动 SpringBoot 服务，打开浏览器，再来测试一下添加部门这个操作，我们依然添加已存在的 "就业部" 这个部门：

  此时，我们可以看到，出现异常之后，异常已经被全局异常处理器捕获了。然后返回的错误信息，被前端程序正常解析，然后提示出了对应的错误提示信息。

  以上就是全局异常处理器的使用，主要涉及到两个注解：

  • @RestControllerAdvice // 表示当前类为全局异常处理器
  • @ExceptionHandler // 指定可以捕获哪种类型的异常进行处理

# AOP

# 事务管理

• 事务是一组操作的集合，它是一个不可分割的工作单位。事务会把所有的操作作为一个整体，一起向数据库提交或者是撤销操作请求。所以这组操作要么同时成功，要么同时失败。

  怎么样来控制这组操作，让这组操作同时成功或同时失败呢？此时就要涉及到事务的具体操作了。

  事务的操作主要有三步：

  1. 开启事务（一组操作开始前，开启事务）：start transaction /begin ;
  2. 提交事务（这组操作全部成功后，提交事务）：commit ;
  3. 回滚事务（中间任何一个操作出现异常，回滚事务）：rollback ;

• 简单的回顾了事务的概念以及事务的基本操作之后，接下来我们看一个事务管理案例：解散部门 （解散部门就是删除部门）

  需求：当部门解散了不仅需要把部门信息删除了，还需要把该部门下的员工数据也删除了。

  步骤：

  • 根据 ID 删除部门数据
  • 根据部门 ID 删除该部门下的员工

• ** 即使程序运行抛出了异常，部门依然删除了，但是部门下的员工却没有删除，造成了数据的不一致。** 原因分析

  原因：

  • 先执行根据 id 删除部门的操作，这步执行完毕，数据库表 dept 中的数据就已经删除了。
  • 执行 1/0 操作，抛出异常
  • 抛出异常之前，下面所有的代码都不会执行了，根据部门 ID 删除该部门下的员工，这个操作也不会执行 。

  此时就出现问题了，部门删除了，部门下的员工还在，业务操作前后数据不一致。

  而要想保证操作前后，数据的一致性，就需要让解散部门中涉及到的两个业务操作，要么全部成功，要么全部失败 。 那我们如何，让这两个操作要么全部成功，要么全部失败呢 ？

  那就可以通过事务来实现，因为一个事务中的多个业务操作，要么全部成功，要么全部失败。

  此时，我们就需要在 delete 删除业务功能中添加事务。

  

  在方法运行之前，开启事务，如果方法成功执行，就提交事务，如果方法执行的过程当中出现异常了，就回滚事务。

  思考：开发中所有的业务操作，一旦我们要进行控制事务，是不是都是这样的套路？

  答案：是的。

  所以在 spring 框架当中就已经把事务控制的代码都已经封装好了，并不需要我们手动实现。我们使用了 spring 框架，我们只需要通过一个简单的注解 @Transactional 就搞定了。

  # Transactional 注解

  @Transactional 作用：就是在当前这个方法执行开始之前来开启事务，方法执行完毕之后提交事务。如果在这个方法执行的过程当中出现了异常，就会进行事务的回滚操作。

  @Transactional 注解：我们一般会在业务层当中来控制事务，因为在业务层当中，一个业务功能可能会包含多个数据访问的操作。在业务层来控制事务，我们就可以将多个数据访问操作控制在一个事务范围内。

  @Transactional 注解书写位置：

  • 方法
    • 当前方法交给 spring 进行事务管理
  • 类
    • 当前类中所有的方法都交由 spring 进行事务管理
  • 接口
    • 接口下所有的实现类当中所有的方法都交给 spring 进行事务管理

  接下来，我们就可以在业务方法 delete 上加上 @Transactional 来控制事务 。

  	@Slf4j
  	@Service
  	public class DeptServiceImpl implements DeptService {
  	@Autowired
  	private DeptMapper deptMapper;
  	@Autowired
  	private EmpMapper empMapper;
  	@Override
  	@Transactional // 当前方法添加了事务管理
  	public void delete(Integer id){
  	// 根据部门 id 删除部门信息
  	deptMapper.deleteById(id);
  	// 模拟：异常发生
  	int i = 1/0;
  	// 删除部门下的所有员工信息
  	empMapper.deleteByDeptId(id);
  	}
  	}

  在业务功能上添加 @Transactional 注解进行事务管理后，我们重启 SpringBoot 服务，使用 postman 测试：

  

  添加 Spring 事务管理后，由于服务端程序引发了异常，所以事务进行回滚。

  

  

  说明：可以在 application.yml 配置文件中开启事务管理日志，这样就可以在控制看到和事务相关的日志信息了

  	#spring 事务管理日志
  	logging:
  	level:
  	org.springframework.jdbc.support.JdbcTransactionManager: debug

• # 事务进阶

  前面我们通过 spring 事务管理注解 @Transactional 已经控制了业务层方法的事务。接下来我们要来详细的介绍一下 @Transactional 事务管理注解的使用细节。我们这里主要介绍 @Transactional 注解当中的两个常见的属性：

  1. 异常回滚的属性：rollbackFor
  2. 事务传播行为：propagation

• rollbackFor

  • 默认情况下，只有出现 RuntimeException (运行时异常) 才会回滚事务。

    假如我们想让所有的异常都回滚，需要来配置 @Transactional 注解当中的 rollbackFor 属性，通过 rollbackFor 这个属性可以指定出现何种异常类型回滚事务。

    	@Slf4j
    	@Service
    	public class DeptServiceImpl implements DeptService {
    	@Autowired
    	private DeptMapper deptMapper;
    	@Autowired
    	private EmpMapper empMapper;
    	@Override
    	@Transactional(rollbackFor=Exception.class)
    	public void delete(Integer id){
    	// 根据部门 id 删除部门信息
    	deptMapper.deleteById(id);
    	// 模拟：异常发生
    	int num = id/0;
    	// 删除部门下的所有员工信息
    	empMapper.deleteByDeptId(id);
    	}
    	}

• propagation

  • @Transactional 注解当中的第二个属性 propagation，这个属性是用来配置事务的传播行为的。

    什么是事务的传播行为呢？

    • 就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。

    例如：两个事务方法，一个 A 方法，一个 B 方法。在这两个方法上都添加了 @Transactional 注解，就代表这两个方法都具有事务，而在 A 方法当中又去调用了 B 方法。

    

    所谓事务的传播行为，指的就是在 A 方法运行的时候，首先会开启一个事务，在 A 方法当中又调用了 B 方法， B 方法自身也具有事务，那么 B 方法在运行的时候，到底是加入到 A 方法的事务当中来，还是 B 方法在运行的时候新建一个事务？这个就涉及到了事务的传播行为。

    我们要想控制事务的传播行为，在 @Transactional 注解的后面指定一个属性 propagation，通过 propagation 属性来指定传播行为。接下来我们就来介绍一下常见的事务传播行为。

    属性值	含义
    REQUIRED	【默认值】需要事务，有则加入，无则创建新事务
    REQUIRES_NEW	需要新事务，无论有无，总是创建新事务
    SUPPORTS	支持事务，有则加入，无则在无事务状态中运行
    NOT_SUPPORTED	不支持事务，在无事务状态下运行，如果当前存在已有事务，则挂起当前事务
    MANDATORY	必须有事务，否则抛异常
    NEVER	必须没事务，否则抛异常
    …

    事务的传播行为我们只需要掌握两个：REQUIRED、REQUIRES_NEW。

    • REQUIRED ：大部分情况下都是用该传播行为即可。

    • REQUIRES_NEW ：当我们不希望事务之间相互影响时，可以使用该传播行为。比如：下订单前需要记录日志，不论订单保存成功与否，都需要保证日志记录能够记录成功。

# AOP 基础

• AOP 也是 spring 框架的第二大核心，我们先来学习 AOP 的基础。

• # 2.1 AOP 概述

什么是 AOP？

• AOP 英文全称：Aspect Oriented Programming（面向切面编程、面向方面编程），其实说白了，面向切面编程就是面向特定方法编程。

那什么又是面向方法编程呢，为什么又需要面向方法编程呢？来我们举个例子做一个说明：

比如，我们这里有一个项目，项目中开发了很多的业务功能。


然而有一些业务功能执行效率比较低，执行耗时较长，我们需要针对于这些业务方法进行优化。 那首先第一步就需要定位出执行耗时比较长的业务方法，再针对于业务方法再来进行优化。

此时我们就需要统计当前这个项目当中每一个业务方法的执行耗时。那么统计每一个业务方法的执行耗时该怎么实现？

可能多数人首先想到的就是在每一个业务方法运行之前，记录这个方法运行的开始时间。在这个方法运行完毕之后，再来记录这个方法运行的结束时间。拿结束时间减去开始时间，不就是这个方法的执行耗时吗？

<img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112154605206.png" alt="image-20230112154605206" style="zoom:80%;" />

以上分析的实现方式是可以解决需求问题的。但是对于一个项目来讲，里面会包含很多的业务模块，每个业务模块又包含很多增删改查的方法，如果我们要在每一个模块下的业务方法中，添加记录开始时间、结束时间、计算执行耗时的代码，就会让程序员的工作变得非常繁琐。

<img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112154627546.png" alt="image-20230112154627546" style="zoom:80%;" />

而 AOP 面向方法编程，就可以做到在不改动这些原始方法的基础上，针对特定的方法进行功能的增强。

AOP 的作用：在程序运行期间在不修改源代码的基础上对已有方法进行增强（无侵入性：解耦）

我们要想完成统计各个业务方法执行耗时的需求，我们只需要定义一个模板方法，将记录方法执行耗时这一部分公共的逻辑代码，定义在模板方法当中，在这个方法开始运行之前，来记录这个方法运行的开始时间，在方法结束运行的时候，再来记录方法运行的结束时间，中间就来运行原始的业务方法。

<img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112154530101.png" alt="image-20230112154530101" style="zoom:80%;" />

而中间运行的原始业务方法，可能是其中的一个业务方法，比如：我们只想通过 部门管理的 list 方法的执行耗时，那就只有这一个方法是原始业务方法。 而如果，我们是先想统计所有部门管理的业务方法执行耗时，那此时，所有的部门管理的业务方法都是 原始业务方法。 那面向这样的指定的一个或多个方法进行编程，我们就称之为 面向切面编程。

那此时，当我们再调用部门管理的 list 业务方法时啊，并不会直接执行 list 方法的逻辑，而是会执行我们所定义的 模板方法 ， 然后再模板方法中：

• 记录方法运行开始时间
• 运行原始的业务方法（那此时原始的业务方法，就是 list 方法）
• 记录方法运行结束时间，计算方法执行耗时

<img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112155813944.png" alt="image-20230112155813944" style="zoom:80%;" />

不论，我们运行的是那个业务方法，最后其实运行的就是我们定义的模板方法，而在模板方法中，就完成了原始方法执行耗时的统计操作 。(那这样呢，我们就通过一个模板方法就完成了指定的一个或多个业务方法执行耗时的统计)

而大家会发现，这个流程，我们是不是似曾相识啊？

对了，就是和我们之前所学习的动态代理技术是非常类似的。 我们所说的模板方法，其实就是代理对象中所定义的方法，那代理对象中的方法以及根据对应的业务需要， 完成了对应的业务功能，当运行原始业务方法时，就会运行代理对象中的方法，从而实现统计业务方法执行耗时的操作。

其实，AOP 面向切面编程和 OOP 面向对象编程一样，它们都仅仅是一种编程思想，而动态代理技术是这种思想最主流的实现方式。而 Spring 的 AOP 是 Spring 框架的高级技术，旨在管理 bean 对象的过程中底层使用动态代理机制，对特定的方法进行编程 (功能增强)。

AOP 的优势：

1. 减少重复代码
2. 提高开发效率
3. 维护方便

• AOP 的功能远不止于此，常见的应用场景如下：

• 记录系统的操作日志

• 权限控制

• 事务管理：我们前面所讲解的 Spring 事务管理，底层其实也是通过 AOP 来实现的，只要添加 @Transactional 注解之后，AOP 程序自动会在原始方法运行前先来开启事务，在原始方法运行完毕之后提交或回滚事务

# AOP 核心概念

1. 连接点：JoinPoint，可以被 AOP 控制的方法（暗含方法执行时的相关信息）

​ 连接点指的是可以被 aop 控制的方法。例如：入门程序当中所有的业务方法都是可以被 aop 控制的方法。

​ 

​ 在 SpringAOP 提供的 JoinPoint 当中，封装了连接点方法在执行时的相关信息。（后面会有具体的讲解）

2. 通知：Advice，指哪些重复的逻辑，也就是共性功能（最终体现为一个方法）

​ 在入门程序中是需要统计各个业务方法的执行耗时的，此时我们就需要在这些业务方法运行开始之前，先记录这个方法运行的开始时间，在每一个业务方法运行结束的时候，再来记录这个方法运行的结束时间。

​ 但是在 AOP 面向切面编程当中，我们只需要将这部分重复的代码逻辑抽取出来单独定义。抽取出来的这一部分重复的逻辑，也就是共性的功能。

​ <img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112160852883.png" alt="image-20230112160852883" style="zoom:80%;" />

3. 切入点：PointCut，匹配连接点的条件，通知仅会在切入点方法执行时被应用

​ 在通知当中，我们所定义的共性功能到底要应用在哪些方法上？此时就涉及到了切入点 pointcut 概念。切入点指的是匹配连接点的条件。通知仅会在切入点方法运行时才会被应用。

​ 在 aop 的开发当中，我们通常会通过一个切入点表达式来描述切入点 (后面会有详解)。

​ <img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112161131937.png" alt="image-20230112161131937" style="zoom:80%;" />

​ 假如：切入点表达式改为 DeptServiceImpl.list ()，此时就代表仅仅只有 list 这一个方法是切入点。只有 list () 方法在运行的时候才会应用通知。

4. 切面：Aspect，描述通知与切入点的对应关系（通知 + 切入点）

​ 当通知和切入点结合在一起，就形成了一个切面。通过切面就能够描述当前 aop 程序需要针对于哪个原始方法，在什么时候执行什么样的操作。

​ <img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112161335186.png" alt="image-20230112161335186" style="zoom:80%;" />

​ 切面所在的类，我们一般称为切面类（被 @Aspect 注解标识的类）

5. 目标对象：Target，通知所应用的对象

​ 目标对象指的就是通知所应用的对象，我们就称之为目标对象。

​ 

AOP 的核心概念我们介绍完毕之后，接下来我们再来分析一下我们所定义的通知是如何与目标对象结合在一起，对目标对象当中的方法进行功能增强的。

<img src="../../JavaWeb/day13-SpringBootWeb AOP / 讲义 /assets/image-20230112161821401.png" alt="image-20230112161821401" style="zoom:80%;" />

Spring 的 AOP 底层是基于动态代理技术来实现的，也就是说在程序运行的时候，会自动的基于动态代理技术为目标对象生成一个对应的代理对象。在代理对象当中就会对目标对象当中的原始方法进行功能的增强。

# AOP 进阶

AOP 的基础知识学习完之后，下面我们对 AOP 当中的各个细节进行详细的学习。主要分为 4 个部分：

1. 通知类型
2. 通知顺序
3. 切入点表达式
4. 连接点

• # 1 通知类型

在入门程序当中，我们已经使用了一种功能最为强大的通知类型：Around 环绕通知。

@Around("execution(* com.itheima.service.*.*(..))")

public Object recordTime(ProceedingJoinPoint pjp) throws Throwable {

    // 记录方法执行开始时间

    long begin = System.currentTimeMillis();

    // 执行原始方法

    Object result = pjp.proceed();

    // 记录方法执行结束时间

    long end = System.currentTimeMillis();

    // 计算方法执行耗时

    log.info(pjp.getSignature()+"执行耗时: {}毫秒",end-begin);

    return result;

}

只要我们在通知方法上加上了 @Around 注解，就代表当前通知是一个环绕通知。

Spring 中 AOP 的通知类型：

• @Around：环绕通知，此注解标注的通知方法在目标方法前、后都被执行
• @Before：前置通知，此注解标注的通知方法在目标方法前被执行
• @After ：后置通知，此注解标注的通知方法在目标方法后被执行，无论是否有异常都会执行
• @AfterReturning ： 返回后通知，此注解标注的通知方法在目标方法后被执行，有异常不会执行
• @AfterThrowing ： 异常后通知，此注解标注的通知方法发生异常后执行

程序发生异常的情况下：

• @AfterReturning 标识的通知方法不会执行，@AfterThrowing 标识的通知方法执行了

• @Around 环绕通知中原始方法调用时有异常，通知中的环绕后的代码逻辑也不会在执行了 （因为原始方法调用已经出异常了）

在使用通知时的注意事项：

• @Around 环绕通知需要自己调用 ProceedingJoinPoint.proceed () 来让原始方法执行，其他通知不需要考虑目标方法执行

• @Around 环绕通知方法的返回值，必须指定为 Object，来接收原始方法的返回值，否则原始方法执行完毕，是获取不到返回值的。

每一个注解里面都指定了切入点表达式，而且这些切入点表达式都一模一样。此时我们的代码当中就存在了大量的重复性的切入点表达式，假如此时切入点表达式需要变动，就需要将所有的切入点表达式一个一个的来改动，就变得非常繁琐了。

怎么来解决这个切入点表达式重复的问题？ 答案就是：抽取

Spring 提供了 @PointCut 注解，该注解的作用是将公共的切入点表达式抽取出来，需要用到时引用该切入点表达式即可。

@Slf4j

@Component

@Aspect

public class MyAspect1 {

    // 切入点方法（公共的切入点表达式）

    @Pointcut("execution(* com.itheima.service.*.*(..))")

    private void pt(){

    }

    // 前置通知（引用切入点）

    @Before("pt()")

    public void before(JoinPoint joinPoint){

        log.info("before ...");

    }

    // 环绕通知

    @Around("pt()")

    public Object around(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {

        log.info("around before ...");

        // 调用目标对象的原始方法执行

        Object result = proceedingJoinPoint.proceed();

        // 原始方法在执行时：发生异常

        // 后续代码不在执行

        log.info("around after ...");

        return result;

    }

    // 后置通知

    @After("pt()")

    public void after(JoinPoint joinPoint){

        log.info("after ...");

    }

    // 返回后通知（程序在正常执行的情况下，会执行的后置通知）

    @AfterReturning("pt()")

    public void afterReturning(JoinPoint joinPoint){

        log.info("afterReturning ...");

    }

    // 异常通知（程序在出现异常的情况下，执行的后置通知）

    @AfterThrowing("pt()")

    public void afterThrowing(JoinPoint joinPoint){

        log.info("afterThrowing ...");

    }

}

需要注意的是：当切入点方法使用 private 修饰时，仅能在当前切面类中引用该表达式， 当外部其他切面类中也要引用当前类中的切入点表达式，就需要把 private 改为 public，而在引用的时候，具体的语法为：

全类名。方法名 ()，具体形式如下：

@Slf4j

@Component

@Aspect

public class MyAspect2 {

    // 引用 MyAspect1 切面类中的切入点表达式

    @Before("com.itheima.aspect.MyAspect1.pt()")

    public void before(){

        log.info("MyAspect2 -> before ...");

    }

}

• # 2 通知顺序

在不同切面类中，默认按照切面类的类名字母排序：

• 目标方法前的通知方法：字母排名靠前的先执行
• 目标方法后的通知方法：字母排名靠前的后执行

如果我们想控制通知的执行顺序有两种方式：

1. 修改切面类的类名（这种方式非常繁琐、而且不便管理）
2. 使用 Spring 提供的 @Order 注解

通知的执行顺序大家主要知道两点即可：

1. 不同的切面类当中，默认情况下通知的执行顺序是与切面类的类名字母排序是有关系的
2. 可以在切面类上面加上 @Order 注解，来控制不同的切面类通知的执行顺序

# 切入点表达式

从 AOP 的入门程序到现在，我们一直都在使用切入点表达式来描述切入点。下面我们就来详细的介绍一下切入点表达式的具体写法。

切入点表达式：

• 描述切入点方法的一种表达式

• 作用：主要用来决定项目中的哪些方法需要加入通知

• 常见形式：

  1. execution (……)：根据方法的签名来匹配

  

  2. @annotation (……) ：根据注解匹配

  

• # 1 execution

execution 主要根据方法的返回值、包名、类名、方法名、方法参数等信息来匹配，语法为：

execution(访问修饰符?  返回值  包名.类名.?方法名(方法参数) throws 异常?)

其中带 ? 的表示可以省略的部分

• 访问修饰符：可省略（比如: public、protected）

• 包名。类名： 可省略

• throws 异常：可省略（注意是方法上声明抛出的异常，不是实际抛出的异常）

示例：

@Before("execution(void com.itheima.service.impl.DeptServiceImpl.delete(java.lang.Integer))")

可以使用通配符描述切入点

• * ：单个独立的任意符号，可以通配任意返回值、包名、类名、方法名、任意类型的一个参数，也可以通配包、类、方法名的一部分

• .. ：多个连续的任意符号，可以通配任意层级的包，或任意类型、任意个数的参数

切入点表达式的语法规则：

1. 方法的访问修饰符可以省略
2. 返回值可以使用 * 号代替（任意返回值类型）
3. 包名可以使用 * 号代替，代表任意包（一层包使用一个 * ）
4. 使用 .. 配置包名，标识此包以及此包下的所有子包
5. 类名可以使用 * 号代替，标识任意类
6. 方法名可以使用 * 号代替，表示任意方法
7. 可以使用 * 配置参数，一个任意类型的参数
8. 可以使用 .. 配置参数，任意个任意类型的参数

切入点表达式示例

• 省略方法的修饰符号

  execution(void com.itheima.service.impl.DeptServiceImpl.delete(java.lang.Integer))

• 使用 * 代替返回值类型

  execution(* com.itheima.service.impl.DeptServiceImpl.delete(java.lang.Integer))

• 使用 * 代替包名（一层包使用一个 * ）

  execution(* com.itheima.*.*.DeptServiceImpl.delete(java.lang.Integer))

• 使用 .. 省略包名

  execution(* com..DeptServiceImpl.delete(java.lang.Integer))

• 使用 * 代替类名

  execution(* com..*.delete(java.lang.Integer))

• 使用 * 代替方法名

  execution(* com..*.*(java.lang.Integer))

• 使用 * 代替参数

  execution(* com.itheima.service.impl.DeptServiceImpl.delete(*))

• 使用 .. 省略参数

  execution(* com..*.*(..))

​

注意事项：

• 根据业务需要，可以使用 且（&&）、或（||）、非（!） 来组合比较复杂的切入点表达式。

  execution(* com.itheima.service.DeptService.list(..)) || execution(* com.itheima.service.DeptService.delete(..))

切入点表达式的书写建议：

• 所有业务方法名在命名时尽量规范，方便切入点表达式快速匹配。如：查询类方法都是 find 开头，更新类方法都是 update 开头

  	// 业务类
  	@Service
  	public class DeptServiceImpl implements DeptService {
  	public List<Dept> findAllDept() {
  	// 省略代码...
  	}
  	public Dept findDeptById(Integer id) {
  	// 省略代码...
  	}
  	public void updateDeptById(Integer id) {
  	// 省略代码...
  	}
  	public void updateDeptByMoreCondition(Dept dept) {
  	// 省略代码...
  	}
  	// 其他代码...
  	}

  	// 匹配 DeptServiceImpl 类中以 find 开头的方法
  	execution(* com.itheima.service.impl.DeptServiceImpl.find*(..))

• 描述切入点方法通常基于接口描述，而不是直接描述实现类，增强拓展性

  execution(* com.itheima.service.DeptService.*(..))

• 在满足业务需要的前提下，尽量缩小切入点的匹配范围。如：包名匹配尽量不使用 ..，使用 * 匹配单个包

  execution(* com.itheima.*.*.DeptServiceImpl.find*(..))

• # 2 @annotation

已经学习了 execution 切入点表达式的语法。那么如果我们要匹配多个无规则的方法，比如：list () 和 delete () 这两个方法。这个时候我们基于 execution 这种切入点表达式来描述就不是很方便了。而在之前我们是将两个切入点表达式组合在了一起完成的需求，这个是比较繁琐的。

我们可以借助于另一种切入点表达式 annotation 来描述这一类的切入点，从而来简化切入点表达式的书写。

实现步骤：

1. 编写自定义注解

2. 在业务类要做为连接点的方法上添加自定义注解

自定义注解：MyLog

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface MyLog {

}

业务类：DeptServiceImpl

@Slf4j

@Service

public class DeptServiceImpl implements DeptService {

    @Autowired

    private DeptMapper deptMapper;

    @Override

    @MyLog // 自定义注解（表示：当前方法属于目标方法）

    public List<Dept> list() {

        List<Dept> deptList = deptMapper.list();

        // 模拟异常

        //int num = 10/0;

        return deptList;

    }

    @Override

    @MyLog  // 自定义注解（表示：当前方法属于目标方法）

    public void delete(Integer id) {

        //1. 删除部门

        deptMapper.delete(id);

    }

    @Override

    public void save(Dept dept) {

        dept.setCreateTime(LocalDateTime.now());

        dept.setUpdateTime(LocalDateTime.now());

        deptMapper.save(dept);

    }

    @Override

    public Dept getById(Integer id) {

        return deptMapper.getById(id);

    }

    @Override

    public void update(Dept dept) {

        dept.setUpdateTime(LocalDateTime.now());

        deptMapper.update(dept);

    }

}

切面类

@Slf4j

@Component

@Aspect

public class MyAspect6 {

    // 针对 list 方法、delete 方法进行前置通知和后置通知

    // 前置通知

    @Before("@annotation(com.itheima.anno.MyLog)")

    public void before(){

        log.info("MyAspect6 -> before ...");

    }

    // 后置通知

    @After("@annotation(com.itheima.anno.MyLog)")

    public void after(){

        log.info("MyAspect6 -> after ...");

    }

}

重启 SpringBoot 服务，测试查询所有部门数据，查看控制台日志：


到此我们两种常见的切入点表达式我已经介绍完了。

• execution 切入点表达式
  • 根据我们所指定的方法的描述信息来匹配切入点方法，这种方式也是最为常用的一种方式
  • 如果我们要匹配的切入点方法的方法名不规则，或者有一些比较特殊的需求，通过 execution 切入点表达式描述比较繁琐
• annotation 切入点表达式
  • 基于注解的方式来匹配切入点方法。这种方式虽然多一步操作，我们需要自定义一个注解，但是相对来比较灵活。我们需要匹配哪个方法，就在方法上加上对应的注解就可以了

# 连接点

讲解完了切入点表达式之后，接下来我们再来讲解最后一个部分连接点。我们前面在讲解 AOP 核心概念的时候，我们提到过什么是连接点，连接点可以简单理解为可以被 AOP 控制的方法。

我们目标对象当中所有的方法是不是都是可以被 AOP 控制的方法。而在 SpringAOP 当中，连接点又特指方法的执行。

在 Spring 中用 JoinPoint 抽象了连接点，用它可以获得方法执行时的相关信息，如目标类名、方法名、方法参数等。

• 对于 @Around 通知，获取连接点信息只能使用 ProceedingJoinPoint 类型

• 对于其他四种通知，获取连接点信息只能使用 JoinPoint，它是 ProceedingJoinPoint 的父类型

# SpringBoot 原理

# 1. 配置优先级

在我们前面的课程当中，我们已经讲解了 SpringBoot 项目当中支持的三类配置文件：

• application.properties
• application.yml
• application.yaml

在 SpringBoot 项目当中，我们要想配置一个属性，可以通过这三种方式当中的任意一种来配置都可以，那么如果项目中同时存在这三种配置文件，且都配置了同一个属性，如：Tomcat 端口号，到底哪一份配置文件生效呢？

• application.properties

server.port=8081

• application.yml

server:

   port: 8082

• application.yaml

server:

   port: 8082

配置文件优先级排名（从高到低）：

1. properties 配置文件
2. yml 配置文件
3. yaml 配置文件

注意事项：虽然 springboot 支持多种格式配置文件，但是在项目开发时，推荐统一使用一种格式的配置。（yml 是主流）

在 SpringBoot 项目当中除了以上 3 种配置文件外，SpringBoot 为了增强程序的扩展性，除了支持配置文件的配置方式以外，还支持另外两种常见的配置方式：

1. Java 系统属性配置 （格式： -Dkey=value）

   -Dserver.port=9000

2. 命令行参数 （格式：--key=value）

   --server.port=10010

那在 idea 当中运行程序时，如何来指定 Java 系统属性和命令行参数呢？

• 编辑启动程序的配置信息

重启服务，同时配置 Tomcat 端口 (三种配置文件、系统属性、命令行参数)，测试哪个 Tomcat 端口号生效：

删除命令行参数配置，重启 SpringBoot 服务：

优先级： 命令行参数 > 系统属性参数 > properties 参数 > yml 参数 > yaml 参数

思考：如果项目已经打包上线了，这个时候我们又如何来设置 Java 系统属性和命令行参数呢？

java -Dserver.port=9000 -jar XXXXX.jar --server.port=10010

下面我们来演示下打包程序运行时指定 Java 系统属性和命令行参数：

1. 执行 maven 打包指令 package，把项目打成 jar 文件
2. 使用命令：java -jar 方式运行 jar 文件程序

项目打包：

运行 jar 程序：

• 同时设置 Java 系统属性和命令行参数

• 仅设置 Java 系统属性

注意事项：

• Springboot 项目进行打包时，需要引入插件 spring-boot-maven-plugin (基于官网骨架创建项目，会自动添加该插件)

在 SpringBoot 项目当中，常见的属性配置方式有 5 种， 3 种配置文件，加上 2 种外部属性的配置 (Java 系统属性、命令行参数)。通过以上的测试，我们也得出了优先级 (从低到高)：

• application.yaml（忽略）
• application.yml
• application.properties
• java 系统属性（-Dxxx=xxx）
• 命令行参数（--xxx=xxx）

# 2. Bean 管理

在前面的课程当中，我们已经讲过了我们可以通过 Spring 当中提供的注解 @Component 以及它的三个衍生注解（@Controller、@Service、@Repository）来声明 IOC 容器中的 bean 对象，同时我们也学习了如何为应用程序注入运行时所需要依赖的 bean 对象，也就是依赖注入 DI。

我们今天主要学习 IOC 容器中 Bean 的其他使用细节，主要学习以下三方面：

1. 如何从 IOC 容器中手动的获取到 bean 对象
2. bean 的作用域配置
3. 管理第三方的 bean 对象

# 2.1 获取 Bean

默认情况下，SpringBoot 项目在启动的时候会自动的创建 IOC 容器 (也称为 Spring 容器)，并且在启动的过程当中会自动的将 bean 对象都创建好，存放在 IOC 容器当中。应用程序在运行时需要依赖什么 bean 对象，就直接进行依赖注入就可以了。

而在 Spring 容器中提供了一些方法，可以主动从 IOC 容器中获取到 bean 对象，下面介绍 3 种常用方式：

1. 根据 name 获取 bean

   Object getBean(String name)

2. 根据类型获取 bean

   <T> T getBean(Class<T> requiredType)

3. 根据 name 获取 bean（带类型转换）

   <T> T getBean(String name, Class<T> requiredType)

思考：要从 IOC 容器当中来获取到 bean 对象，需要先拿到 IOC 容器对象，怎么样才能拿到 IOC 容器呢？

• 想获取到 IOC 容器，直接将 IOC 容器对象注入进来就可以了

控制器：DeptController

@RestController

@RequestMapping("/depts")

public class DeptController {

    @Autowired

    private DeptService deptService;

    public DeptController(){

        System.out.println("DeptController constructor ....");

    }

    @GetMapping

    public Result list(){

        List<Dept> deptList = deptService.list();

        return Result.success(deptList);

    }

    @DeleteMapping("/{id}")

    public Result delete(@PathVariable Integer id)  {

        deptService.delete(id);

        return Result.success();

    }

    @PostMapping

    public Result save(@RequestBody Dept dept){

        deptService.save(dept);

        return Result.success();

    }

}

业务实现类：DeptServiceImpl

@Slf4j

@Service

public class DeptServiceImpl implements DeptService {

    @Autowired

    private DeptMapper deptMapper;

    @Override

    public List<Dept> list() {

        List<Dept> deptList = deptMapper.list();

        return deptList;

    }

    @Override

    public void delete(Integer id) {

        deptMapper.delete(id);

    }

    @Override

    public void save(Dept dept) {

        dept.setCreateTime(LocalDateTime.now());

        dept.setUpdateTime(LocalDateTime.now());

        deptMapper.save(dept);

    }

}

Mapper 接口：

@Mapper

public interface DeptMapper {

    // 查询全部部门数据

    @Select("select * from dept")

    List<Dept> list();

    // 删除部门

    @Delete("delete from dept where id = #{id}")

    void delete(Integer id);

    // 新增部门

    @Insert("insert into dept(name, create_time, update_time) values (#{name},#{createTime},#{updateTime})")

    void save(Dept dept);

}

测试类：

@SpringBootTest

class SpringbootWebConfig2ApplicationTests {

    @Autowired

    private ApplicationContext applicationContext; //IOC 容器对象

    // 获取 bean 对象

    @Test

    public void testGetBean(){

        // 根据 bean 的名称获取

        DeptController bean1 = (DeptController) applicationContext.getBean("deptController");

        System.out.println(bean1);

        // 根据 bean 的类型获取

        DeptController bean2 = applicationContext.getBean(DeptController.class);

        System.out.println(bean2);

        // 根据 bean 的名称 及 类型获取

        DeptController bean3 = applicationContext.getBean("deptController", DeptController.class);

        System.out.println(bean3);

    }

}

程序运行后控制台日志：

问题：输出的 bean 对象地址值是一样的，说明 IOC 容器当中的 bean 对象有几个？

答案：只有一个。 （默认情况下，IOC 中的 bean 对象是单例）

那么能不能将 bean 对象设置为非单例的 (每次获取的 bean 都是一个新对象)？

可以，在下一个知识点 (bean 作用域) 中讲解。

注意事项：

• 上述所说的 【Spring 项目启动时，会把其中的 bean 都创建好】还会受到作用域及延迟初始化影响，这里主要针对于默认的单例非延迟加载的 bean 而言。

# 2.2 Bean 作用域

在前面我们提到的 IOC 容器当中，默认 bean 对象是单例模式 (只有一个实例对象)。那么如何设置 bean 对象为非单例呢？需要设置 bean 的作用域。

在 Spring 中支持五种作用域，后三种在 web 环境才生效：

知道了 bean 的 5 种作用域了，我们要怎么去设置一个 bean 的作用域呢？

• 可以借助 Spring 中的 @Scope 注解来进行配置作用域

1). 测试一

• 控制器

// 默认 bean 的作用域为：singleton (单例)

@Lazy // 延迟加载（第一次使用 bean 对象时，才会创建 bean 对象并交给 ioc 容器管理）

@RestController

@RequestMapping("/depts")

public class DeptController {

    @Autowired

    private DeptService deptService;

    public DeptController(){

        System.out.println("DeptController constructor ....");

    }

    // 省略其他代码...

}

• 测试类

@SpringBootTest

class SpringbootWebConfig2ApplicationTests {

    @Autowired

    private ApplicationContext applicationContext; //IOC 容器对象

    //bean 的作用域

    @Test

    public void testScope(){

        for (int i = 0; i < 10; i++) {

            DeptController deptController = applicationContext.getBean(DeptController.class);

            System.out.println(deptController);

        }

    }

}

重启 SpringBoot 服务，运行测试方法，查看控制台打印的日志：

注意事项：

• IOC 容器中的 bean 默认使用的作用域：singleton (单例)

• 默认 singleton 的 bean，在容器启动时被创建，可以使用 @Lazy 注解来延迟初始化 (延迟到第一次使用时)

2). 测试二

修改控制器 DeptController 代码：

@Scope("prototype") //bean 作用域为非单例

@Lazy // 延迟加载

@RestController

@RequestMapping("/depts")

public class DeptController {

    @Autowired

    private DeptService deptService;

    public DeptController(){

        System.out.println("DeptController constructor ....");

    }

    // 省略其他代码...

}

重启 SpringBoot 服务，再次执行测试方法，查看控制吧打印的日志：

注意事项：

• prototype 的 bean，每一次使用该 bean 的时候都会创建一个新的实例
• 实际开发当中，绝大部分的 Bean 是单例的，也就是说绝大部分 Bean 不需要配置 scope 属性

# 2.3 第三方 Bean

学习完 bean 的获取、bean 的作用域之后，接下来我们再来学习第三方 bean 的配置。

之前我们所配置的 bean，像 controller、service，dao 三层体系下编写的类，这些类都是我们在项目当中自己定义的类 (自定义类)。当我们要声明这些 bean，也非常简单，我们只需要在类上加上 @Component 以及它的这三个衍生注解（@Controller、@Service、@Repository），就可以来声明这个 bean 对象了。
但是在我们项目开发当中，还有一种情况就是这个类它不是我们自己编写的，而是我们引入的第三方依赖当中提供的。

在 pom.xml 文件中，引入 dom4j：

<!--Dom4j-->

<dependency>

    <groupId>org.dom4j</groupId>

    <artifactId>dom4j</artifactId>

    <version>2.1.3</version>

</dependency>

dom4j 就是第三方组织提供的。 dom4j 中的 SAXReader 类就是第三方编写的。

当我们需要使用到 SAXReader 对象时，直接进行依赖注入是不是就可以了呢？

• 按照我们之前的做法，需要在 SAXReader 类上添加一个注解 @Component（将当前类交给 IOC 容器管理）

结论：第三方提供的类是只读的。无法在第三方类上添加 @Component 注解或衍生注解。

那么我们应该怎样使用并定义第三方的 bean 呢？

• 如果要管理的 bean 对象来自于第三方（不是自定义的），是无法用 @Component 及衍生注解声明 bean 的，就需要用到 **@Bean** 注解。

解决方案 1：在启动类上添加 @Bean 标识的方法

@SpringBootApplication

public class SpringbootWebConfig2Application {

    public static void main(String[] args) {

        SpringApplication.run(SpringbootWebConfig2Application.class, args);

    }

    // 声明第三方 bean

    @Bean // 将当前方法的返回值对象交给 IOC 容器管理，成为 IOC 容器 bean

    public SAXReader saxReader(){

        return new SAXReader();

    }

}

xml 文件：

<?xml version="1.0" encoding="UTF-8"?>

<emp>

    <name>Tom</name>

    <age>18</age>

</emp>

测试类：

@SpringBootTest

class SpringbootWebConfig2ApplicationTests {

    @Autowired

    private SAXReader saxReader;

    // 第三方 bean 的管理

    @Test

    public void testThirdBean() throws Exception {

        Document document = saxReader.read(this.getClass().getClassLoader().getResource("1.xml"));

        Element rootElement = document.getRootElement();

        String name = rootElement.element("name").getText();

        String age = rootElement.element("age").getText();

        System.out.println(name + " : " + age);

    }

    // 省略其他代码...

}

重启 SpringBoot 服务，执行测试方法后，控制台输出日志：

Tom : 18

说明：以上在启动类中声明第三方 Bean 的作法，不建议使用（项目中要保证启动类的纯粹性）

解决方案 2：在配置类中定义 @Bean 标识的方法

• 如果需要定义第三方 Bean 时， 通常会单独定义一个配置类

@Configuration // 配置类  (在配置类当中对第三方 bean 进行集中的配置管理)

public class CommonConfig {

    // 声明第三方 bean

    @Bean // 将当前方法的返回值对象交给 IOC 容器管理，成为 IOC 容器 bean

          // 通过 @Bean 注解的 name/value 属性指定 bean 名称，如果未指定，默认是方法名

    public SAXReader reader(DeptService deptService){

        System.out.println(deptService);

        return new SAXReader();

    }

}

注释掉 SpringBoot 启动类中创建第三方 bean 对象的代码，重启服务，执行测试方法，查看控制台日志：

Tom : 18

在方法上加上一个 @Bean 注解，Spring 容器在启动的时候，它会自动的调用这个方法，并将方法的返回值声明为 Spring 容器当中的 Bean 对象。

注意事项 ：

• 通过 @Bean 注解的 name 或 value 属性可以声明 bean 的名称，如果不指定，默认 bean 的名称就是方法名。

• 如果第三方 bean 需要依赖其它 bean 对象，直接在 bean 定义方法中设置形参即可，容器会根据类型自动装配。

关于 Bean 大家只需要保持一个原则：

• 如果是在项目当中我们自己定义的类，想将这些类交给 IOC 容器管理，我们直接使用 @Component 以及它的衍生注解来声明就可以。

• 如果这个类它不是我们自己定义的，而是引入的第三方依赖当中提供的类，而且我们还想将这个类交给 IOC 容器管理。此时我们就需要在配置类中定义一个方法，在方法上加上一个 @Bean 注解，通过这种方式来声明第三方的 bean 对象。

# 3.SpringBoot 原理

# 3.1 起步依赖

假如我们没有使用 SpringBoot，用的是 Spring 框架进行 web 程序的开发，此时我们就需要引入 web 程序开发所需要的一些依赖。

spring-webmvc 依赖：这是 Spring 框架进行 web 程序开发所需要的依赖

servlet-api 依赖：Servlet 基础依赖

jackson-databind 依赖：JSON 处理工具包

如果要使用 AOP，还需要引入 aop 依赖、aspect 依赖

项目中所引入的这些依赖，还需要保证版本匹配，否则就可能会出现版本冲突问题。

如果我们使用了 SpringBoot，就不需要像上面这么繁琐的引入依赖了。我们只需要引入一个依赖就可以了，那就是 web 开发的起步依赖：springboot-starter-web。

为什么我们只需要引入一个 web 开发的起步依赖，web 开发所需要的所有的依赖都有了呢？

• 因为 Maven 的依赖传递。

• 在 SpringBoot 给我们提供的这些起步依赖当中，已提供了当前程序开发所需要的所有的常见依赖 (官网地址：https://docs.spring.io/spring-boot/docs/2.7.7/reference/htmlsingle/#using.build-systems.starters)。

• 比如：springboot-starter-web，这是 web 开发的起步依赖，在 web 开发的起步依赖当中，就集成了 web 开发中常见的依赖：json、web、webmvc、tomcat 等。我们只需要引入这一个起步依赖，其他的依赖都会自动的通过 Maven 的依赖传递进来。

结论：起步依赖的原理就是 Maven 的依赖传递。

# 3.2 自动配置

我们讲解了 SpringBoot 当中起步依赖的原理，就是 Maven 的依赖传递。接下来我们解析下自动配置的原理，我们要分析自动配置的原理，首先要知道什么是自动配置。

• # 3.2.1 概述

SpringBoot 的自动配置就是当 Spring 容器启动后，一些配置类、bean 对象就自动存入到了 IOC 容器中，不需要我们手动去声明，从而简化了开发，省去了繁琐的配置操作。

比如：我们要进行事务管理、要进行 AOP 程序的开发，此时就不需要我们再去手动的声明这些 bean 对象了，我们直接使用就可以从而大大的简化程序的开发，省去了繁琐的配置操作。

下面我们打开 idea，一起来看下自动配置的效果：

• 运行 SpringBoot 启动类

大家会看到有两个 CommonConfig，在第一个 CommonConfig 类中定义了一个 bean 对象，bean 对象的名字叫 reader。

在第二个 CommonConfig 中它的 bean 名字叫 commonConfig，为什么还会有这样一个 bean 对象呢？原因是在 CommonConfig 配置类上添加了一个注解 @Configuration，而 @Configuration 底层就是 @Component

所以配置类最终也是 SpringIOC 容器当中的一个 bean 对象

在 IOC 容器中除了我们自己定义的 bean 以外，还有很多配置类，这些配置类都是 SpringBoot 在启动的时候加载进来的配置类。这些配置类加载进来之后，它也会生成很多的 bean 对象。

比如：配置类 GsonAutoConfiguration 里面有一个 bean，bean 的名字叫 gson，它的类型是 Gson。

com.google.gson.Gson 是谷歌包中提供的用来处理 JSON 格式数据的。

当我们想要使用这些配置类中生成的 bean 对象时，可以使用 @Autowired 就自动注入了：