Synchronized锁在Spring事务管理下？
先简单提示下，关于synchronized关键字，一定要慎用，非常影响性能。
首先说明下，synchronized是Java中的关键字，是一种同步锁。它修饰的对象有以下几种：
1. 修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码，作用的对象是调用这个代码块的对象；
2. 修饰一个方法，被修饰的方法称为同步方法，其作用的范围是整个方法，作用的对象是调用这个方法的对象；
3. 修改一个静态的方法，其作用的范围是整个静态方法，作用的对象是这个类的所有对象；
4. 修改一个类，其作用的范围是synchronized后面括号括起来的部分，作用主的对象是这个类的所有对象
我们再简单的说下spring的事务相关
Spring在不同的事务管理API之上定义了一个抽象层。而应用程序开发人员不必了解底层的事务管理API，就可以使用Spring的事务管理机制。
Spring既支持编程式事务管理(也称编码式事务)，也支持声明式的事务管理
编程式事务管理：将事务管理代码嵌入到业务方法中来控制事务的提交和回滚，在编程式事务中，必须在每个业务操作中包含额外的事务管理代码
声明式事务管理：大多数情况下比编程式事务管理更好用。它将事务管理代码从业务方法中分离出来，以声明的方式来实现事务管理。事务管理作为一种横切关注点，可以通过AOP方法模块化。Spring通过Spring AOP框架支持声明式事务管理。
Spring并不直接管理事务，而是提供了多种事务管理器，它们将事务管理的职责委托给JTA或其他持久化机制所提供的平台相关的事务实现。每个事务管理器都会充当某一特定平台的事务实现的门面，这使得用户在Spring中使用事务时，几乎不用关注实际的事务实现是什么。
spring的事务的具体配置方法这里就不赘述了。
在Spring中，声明式事务是通过事务属性来定义的，事务属性描述了事务策略如何应用到方法上。事务属性包含了5个方面，尽管Spring提供了多种声明式事务的机制，但是所有的方式都依赖这五个参数来控制如何管理事务策略。声明式事务通过传播行为，隔离级别，只读提示，事务超时及回滚规则来进行定义。
隔离级别定义了一个事务可能受其他并发事务影响的程度。在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务。并发，虽然是必须的，可是会导致下面的问题。① 脏读(Dirty reads)：脏读发生在一个事务读取了另一个事务改写但尚未提的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。
② 不可重复读(Nonrepeatable read)：不可重复读发生在一个事务执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间更新了数据
③ 幻读(Phantom read)：幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据，接着另一个并发事务(T2)插入了一些数据时。在随后的查询中，第一个事务(T1)就会发现多了一些原本不存在的记录
Spring事务的底层是Spring AOP，而Spring AOP的底层是动态代理技术
简单来说就是在调用方法前开启事务，调用方法后提交事务。
在多线程环境下，就可能会出现：方法执行完了(synchronized代码块执行完了)，事务还没提交，别的线程可以进入被synchronized修饰的方法，再读取的时候，读到的是还没提交事务的数据，这个数据不是最新的，所以就出现了这个问题。
从上面来看，问题就是两者同时使用时，加锁没有包括整个事务。所以解决方法就是将synchronized的锁加到整个spring事务上，就不会出现线程安全的问题了。
最后，我会一直在头条分享我的学习笔记，关注，点赞和转发就是对我最大的支持。
