SpringMVC常用注解及其介绍
前言：在介绍SpringMVC常用注解之前，有兴趣的可以先了解一下SpringMVC的工作流程。SpringMVC工作流程详解
OK，接下来进入本次主题。
在实际项目中，我们最常用的几个注解，包括 @Controller、@RestController、 @RequestMapping、@PathVariable、@RequestParam 以及 @RequestBody，此次主要介绍下这几个注解常用的使用方式和特点。
1.@Controller
在SpringMVC中，controller主要负责处理前端控制器(DispatcherServlet )发过来的请求，经过业务逻辑层处理之后封装层一个model，并将其返回给view进行展示。@controller注解通常用于类上，如果结合Thymeleaf模板使用的话，会返回一个页面。如果是前后端分离的项目，则使用@RestController，表明返回的是json格式数据。
2.@RestController
在介绍RestController之前，我们先点进去看一下：
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {
@AliasFor(
annotation = Controller.class
)
String value() default “”;
}
1
2
3
4
5
6
7
8
9
10
11
可以发现，@RestController注解里面包含了@Controller注解和@ResponseBody注解，@ResponseBody 注解是将返回的数据结构转换为 JSON 格式，所以说可以这么理解：@RestController = @Controller + @ResponseBody ，省了很多事，我们使用 @RestController 之后就不需要再使用 @Controller 了。
3.@RequestMapping
@RequestMapping 是一个用来处理请求地址映射的注解，它可以用于类上，也可以用于方法上。用于类上的注解会将一个特定请求或者请求模式映射到一个控制器之上，表示类中的所有响应请求的方法都是以该地址作为父路径；方法的级别上注解表示进一步指定到处理方法的映射关系。
该注解有6个属性，一般在项目中比较常用的有三个属性：value、method 和 produces。
value 属性：指定请求的实际地址，value 可以省略不写；
method 属性：指定请求的类型，主要有 GET、PUT、POST、DELETE，默认为 GET。
produces 属性：指定返回内容类型，如 produces = “application/json; charset=UTF-8”。
@RequestMapping 注解比较简单，举个例子：
@RestController
@RequestMapping(value = “/test”, produces = “application/json; charset=UTF-8”)
public class TestController {
@RequestMapping(value = "/get", method = RequestMethod.GET)
public String testGet() {
return "success";
}
}
1
2
3
4
5
6
7
8
9
这个很简单，启动项目在浏览器中输入 localhost:8080/test/get 测试一下即可。
四种不同的请求方式，都有相应的注解。不用每次在 @RequestMapping 注解中加 method 属性来指定，上面的 GET 方式请求可以直接使用 @GetMapping("/get") 注解，效果一样。相应地，PUT 方式、POST 方式和 DELETE 方式对应的注解分别为 @PutMapping、@PostMapping 和 DeleteMapping。
4.@PathVariable
@PathVariable 注解主要用来获取 URL 参数，Spring Boot 支持 Restfull 风格的 URL，比如一个 GET 请求携带一个参数 id，我们将 id 作为参数接收，可以使用 @PathVariable 注解。如下：
@GetMapping("/user/{id}")
public String testPathVariable(@PathVariable Integer id) {
System.out.println(“获取到的id为：” + id);
return “success”;
}
1
2
3
4
5
这里需要注意一个问题，如果想要 URL 中占位符中的 id 值直接赋值到参数 id 中，需要保证 URL 中的参数和方法接收参数一致，否则将无法接收。如果不一致的话，其实也可以解决，需要用 @PathVariable 中的 value 属性来指定对应关系。如下：
@RequestMapping("/user/{idd}")
public String testPathVariable(@PathVariable(value = “idd”) Integer id) {
System.out.println(“获取到的id为：” + id);
return “success”;
}
1
2
3
4
5
对于访问的 URL，占位符的位置可以在任何位置，不一定非要在最后，比如这样也行：/xxx/{id}/user。另外，URL 也支持多个占位符，方法参数使用同样数量的参数来接收，原理和一个参数是一样的，例如：
@GetMapping("/user/{idd}/{name}")
public String testPathVariable(@PathVariable(value = “idd”) Integer id, @PathVariable String name) {
System.out.println(“获取到的id为：” + id);
System.out.println(“获取到的name为：” + name);
return “success”;
}
1
2
3
4
5
6
运行项目，在浏览器中请求：localhost:8080/test/user/2/zhangsan， 可以看到控制台输出如下信息：
获取到的id为：2
获取到的name为：zhangsan
所以它支持多个参数的接收。同样地，如果 URL 中的参数和方法中的参数名称不同的话，也需要使用 value 属性来绑定两个参数。
5.@RequestParam
@RequestParam 注解顾名思义，也是获取请求参数的，上面我们介绍了 @PathValiable 注解也是获取请求参数的，那么 @RequestParam 和 @PathVariable 有什么不同呢？
@PathValiable 是从 URL 模板中获取参数值， 即这种风格的 URL：
http://localhost:8080/user/{id}
1
@RequestParam 是从 Request 里获取参数值，即这种风格的 URL：
http://localhost:8080/user?id=1
1
对于@RequestParam 注解代码测试如下：
@GetMapping("/user") //注意这里请求路径的写法是不一样的
public String testRequestParam(@RequestParam Integer id) {
System.out.println(“获取到的id为：” + id);
return “success”;
}
1
2
3
4
5
同样的@RequestParam 注解的value 属性是比较常用的，其作用和@PathVariable注解的value属性是一样的。此外@RequestParam 注解还有两个属性比较常用：
required 属性：true 表示该参数必须要传，否则就会报 404 错误，false 表示可有可无。
defaultValue 属性：默认值，表示请求中没有同名参数时的默认值。
从 URL 中可以看出，@RequestParam 注解用于 GET 请求上时，接收拼接在 URL 中的参数。除此之外，该注解还可以用于 POST 请求，接收前端表单提交的参数，假如前端通过表单提交 username 和 password 两个参数，那我们可以使用 @RequestParam 来接收，用法和上面一样。
6.@RequestBody
RequestBody 注解用于接收前端传来的实体，接收参数也是对应的实体，比如前端通过 JSON 提交传来两个参数 username 和 password，此时我们需要在后端封装一个实体来接收。在传递的参数比较多的情况下，使用 @RequestBody 接收会非常方便。例如：
定义User类代码此处省略…
@PostMapping("/user")
public String testRequestBody(@RequestBody User user) {
System.out.println(“获取到的username为：” + user.getUsername());
System.out.println(“获取到的password为：” + user.getPassword());
return “success”;
}
1
2
3
4
5
6
可以看出，@RequestBody 注解用于 POST 请求上，接收 JSON 实体参数。它和上面我们介绍的表单提交有点类似，只不过参数的格式不同，一个是 JSON 实体，一个是表单提交。在实际项目中根据具体场景和需要使用对应的注解即可。
事务四大特性
⑴ 原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，这和前面两篇博客介绍事务的功能是一样的概念，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
⑵ 一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
⑶ 隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
⑷ 持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。
以上介绍完事务的四大特性(简称ACID)，现在重点来说明下事务的隔离性，当多个线程都开启事务操作数据库中的数据时，数据库系统要能进行隔离操作，以保证各个线程获取数据的准确性，在介绍数据库提供的各种隔离级别之前，我们先看看如果不考虑事务的隔离性，会发生的几种问题：
1，脏读
脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。
当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。例如：用户A向用户B转账100元，对应SQL命令如下
update account set money=money+100 where name=’B’; (此时A通知B)
update account set money=money - 100 where name=’A’;
1
2
3
当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。
2，不可重复读
不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。
例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。
不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。
在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如对于同一个数据A和B依次查询就可能不同，A和B就可能打起来了……
3，虚读(幻读)
幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。
幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。
现在来看看MySQL数据库为我们提供的四种隔离级别：
① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
③ Read committed (读已提交)：可避免脏读的发生。
④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。
————————————————
版权声明：本文为CSDN博主「李自富」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_44162368/article/details/90480751
一般来说，在用SSH框架开发项目的时候，一般都是将事务设置在Service层。那么在调用Service层的某个方法的时候，它能够保证这个方法中执行的所有对数据库的更新操作都保持在一个事务中，在事务层里面调用的这些方法要么全部成功，要么全部失败。
那么事务的传播特性也是从这里引出的。
如果在Service层的这个方法中，除了调用了Dao层的方法之外，还调用了本类的其他的Service方法。那么在调用其他的 Service方法的时候，这个事务是怎么规定的呢？规定就是：必须保证在这个方法里调用的那些“本类的其他的Service方法”与我本身的这个方法处在同一个事务中，否则就无法保证事务的一致性。
事务的传播特性就是解决这个问题的。在Spring中有针对事务传播特性的多种配置，大多数情况下只用其中的一种：PROPAGATION_REQUIRED，这个配置项的意思就是，当调用service层的某个方法时已经开启了一个事务(具体调用哪一层的方法开始创建事务，要看具体的AOP配置)，那么在调用那些“本类的其他的Service方法”的时候，如果当前方法产生了事务，就用当前方法产生的事务，否则就创建一个新的事务。这个工作是由Spring来完成。
以前没有Spring来帮助我们完成事务的时候，我们必须自己手动控制事务。例如，当项目中仅仅使用hibernate，而没有集成进 spring的时候，在一个service层中调用其他的业务逻辑方法，为了保证事务一致性，必须要把当前的hibernate session传递到下一个方法中，或者采用ThreadLocal的方法，将session传递给下一个方法，其实都是一个目的。现在这个工作由 spring来帮助我们完成，就可以让我们更加专注于业务逻辑，而不用去关心事务的问题。
默认情况是，当发生RuntimeException时，事务才会回滚。所以要注意一下，如果你在程序发生错误的情况时自定义了异常处理机制，拥有自定义的Exception，那么这个自定义的Exception必须继承RuntimeException类，这样事务才会回滚！
其实，除了上述提到的PROPAGATION_REQUIRED传播机制外，spring总共有6大事务传播机制：
- Propagation required，如果当前没有事务，就新建一个事务。
- Propagation supports， 如果当前没有事务，就以非事务方式执行。
- Propagation mandatory， 如果当前没有事务，就抛出异常。
- Propagation requires new， 如果当前存在事务，挂起当前事务，新建事务。
- Propagation not supported,，如果当前存在事务，把当前事务挂起，以非事务方式执行。
- Propagation never，如果当前存在事务，抛出异常。以非事务方式执行。
————————————————
版权声明：本文为CSDN博主「zj_daydayup」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012556994/article/details/81154348
来源：CSDN
作者：mybatisss
链接：https://blog.csdn.net/mybatisss/article/details/103846218