一、事务不生效
1.访问权限问题
众所周知，java 的访问权限主要有四种：private、default、protected、public，它们的权限从左到右，依次变大。
但如果我们在开发过程中，把某些事务方法，定义了错误的访问权限，就会导致事务功能出问题。
方法的访问权限被定义成了private，这样会导致事务失效，spring 要求被代理方法必须是public的。
也就是说，如果我们自定义的事务方法（即目标方法），它的访问权限不是public，而是 private、default 或 protected 的话，spring 则不会提供事务功能。
2. 方法用 final 修饰
有时候，某个方法不想被子类重写，这时可以将该方法定义成 final 的。普通方法这样定义是没问题的，但如果将事务方法定义成 final，会导致事务失效。
如果你看过 spring 事务的源码，可能会知道 spring 事务底层使用了 aop，也就是通过 jdk 动态代理或者 cglib，帮我们生成了代理类，在代理类中实现的事务功能。
但如果某个方法用 final 修饰了，那么在它的代理类中，就无法重写该方法，而添加事务功能。
注意：如果某个方法是 static 的，同样无法通过动态代理，变成事务方法。
3.方法内部调用
有时候我们需要在某个 Service 类的某个方法（无事务）中，调用另外一个事务方法。
那么问题来了，如果有些场景，确实想在同一个类的某个无事务方法中，调用它自己的另外一个方法，该怎么办呢？
3.1 新加一个 Service 方法
这个方法非常简单，只需要新加一个 Service 方法，把 @Transactional 注解加到新 Service 方法上，把需要事务执行的代码移到新方法中。具体代码如下：
3.2 在该 Service 类中注入自己
如果不想再新加一个 Service 类，在该 Service 类中注入自己也是一种选择。具体代码如下：
@Servcie public class ServiceA { @Autowired prvate ServiceA serviceA; public void save(User user) { queryData1(); queryData2(); serviceA.doSave(user); } @Transactional(rollbackFor=Exception.class) public void doSave(User user) { addData1(); updateData2(); } }
可能有些人会有这样的疑问：这种做法会不会出现循环依赖问题？其实 spring ioc 内部的三级缓存保证了它不会出现循环依赖问题。
3.3 通过 AopContent 类
在该 Service 类中使用 AopContext.currentProxy() 获取代理对象。
上面的方法 2 确实可以解决问题，但是代码看起来并不直观，还可以通过在该 Service 类中使用 AOPProxy 获取代理对象，实现相同的功能。具体代码如下：
@Servcie public class ServiceA { public void save(User user) { queryData1(); queryData2(); ((ServiceA)AopContext.currentProxy()).doSave(user); } @Transactional(rollbackFor=Exception.class) public void doSave(User user) { addData1(); updateData2(); } }
4.未被 spring 管理
在我们平时开发过程中，有个细节很容易被忽略，即使用 spring 事务的前提是：对象要被 spring 管理，需要创建 bean 实例。
通常情况下，我们通过 @Controller、@Service、@Component、@Repository 等注解，可以自动实现 bean 实例化和依赖注入的功能。
如果有一天，你忘了加 @Service 注解，那么该类不会交给 spring 管理，所以它的 add 方法也不会生成事务。
5.多线程调用
在实际项目开发中，多线程的使用场景还是挺多的。如果 spring 事务用在多线程场景中，会有问题吗？
这样会导致两个方法不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务。如果想 doOtherThing 方法中抛了异常，add 方法也回滚是不可能的。
如果看过 spring 事务源码的朋友，可能会知道 spring 的事务是通过数据库连接来实现的。当前线程中保存了一个 map，key 是数据源，value 是数据库连接。
private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");
我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。
6.表不支持事务
有时候我们在开发的过程中，发现某张表的事务一直都没有生效，最好确认一下你使用的那张表，是否支持事务。
7.未开启事务
有时候，事务没有生效的根本原因是没有开启事务。
如果你使用的是 springboot 项目，那么你很幸运。因为 springboot 通过DataSourceTransactionManagerAutoConfiguration类，已经默默地帮你开启了事务。
但如果你使用的还是传统的 spring 项目，则需要在 applicationContext.xml 文件中，手动配置事务相关参数。如果忘了配置，事务肯定是不会生效的。
另外，如果在 pointcut 标签中的切入点匹配规则，配错了的话，有些类的事务也不会生效。
二、事务不回滚
1.错误的传播特性
2.自己吞了异常
3.手动抛了非RuntimeException的异常
即使开发者没有手动捕获异常，但如果抛的异常不正确，spring 事务也不会回滚。
@Slf4j @Service public class UserService { @Transactional public void add(UserModel userModel) throws Exception { try { saveData(userModel); updateData(userModel); } catch (Exception e) { log.error(e.getMessage(), e); throw new Exception(e); } } }
上面的这种情况，开发人员自己捕获了异常，又手动抛出了异常：Exception，事务同样不会回滚。
因为 spring 事务，默认情况下只会回滚RuntimeException（运行时异常）和Error（错误），对于普通的 Exception（非运行时异常），它不会回滚。
所以自定义异常时，还是继承RuntimeException
4.异常不匹配
在使用 @Transactional 注解声明事务时，有时我们想自定义回滚的异常，spring 也是支持的。可以通过设置rollbackFor参数，来完成这个功能。
但如果这个参数的值设置错了，就会引出一些莫名其妙的问题，例如：
@Slf4j @Service public class UserService { @Transactional(rollbackFor = BusinessException.class) public void add(UserModel userModel) throws Exception { saveData(userModel); updateData(userModel); } }
如果在执行上面这段代码，保存和更新数据时，程序报错了，抛了 SqlException、DuplicateKeyException 等异常。而 BusinessException 是我们自定义的异常，报错的异常不属于 BusinessException，所以事务也不会回滚。
5.嵌套事务回滚多了
外层调用内层的@Transactional时，内层抛了异常，结果外层也被动抛了异常导致整个事务回滚，原本可能只是希望回滚内部的事务。
【参考】
https://blog.csdn.net/hanjiaqian/article/details/120501741