@Transactional 是什么
在 Spring 中，事务是用于管理数据库操作的机制，确保一系列操作要么全部成功提交，要么全部回滚到事务开始的状态。
这个注解提供了一些属性，允许你指定事务的传播行为、隔离级别、超时时间等。通过使用
@Transactional 怎么用
方法级别的使用：
import org.springframework.transaction.annotation.Transactional;
@Service
public class MyService {
@Transactional
public void myTransactionalMethod() {
// 这里是需要进行事务管理的业务逻辑
}
}
在上面的例子中，
类级别的使用：
import org.springframework.transaction.annotation.Transactional;
@Service
@Transactional
public class MyService {
public void myMethod() {
// 这里是需要进行事务管理的业务逻辑
}
}
在这个例子中，整个
你还可以使用
@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT, readOnly = false, timeout = 300)
public void myTransactionalMethod() {
// 业务逻辑
}
这里，
确保你的类或方法被 Spring 托管（例如使用
@Transactional 有什么优点
使用
-
简化事务管理配置：
@Transactional 注解允许你在方法或类级别声明事务性操作，从而简化了事务管理的配置。你不再需要显式地在配置文件中声明事务管理器和事务属性，而是可以直接在代码中使用注解。 -
提高代码可读性： 将事务性操作直接标记在方法上，使得代码更加清晰和易于理解。通过注解，你可以一目了然地知道哪些方法是需要在事务管理下运行的。
-
灵活的事务属性配置：
@Transactional 注解提供了一些属性，如传播行为、隔离级别、只读事务等，使得你可以根据具体需求灵活配置事务的行为。这使得在不同的业务场景下能够采用不同的事务属性。 -
运行时异常触发回滚： 默认情况下，
@Transactional 注解会将未捕获的运行时异常（继承自RuntimeException ）触发回滚。这有助于保持数据的一致性，因为在发生异常时，事务将回滚到起始状态。 -
支持嵌套事务：
@Transactional 注解支持嵌套事务，这意味着你可以在一个事务内调用另一个被@Transactional 注解标记的方法，形成嵌套事务。嵌套事务允许更细粒度的事务控制。
总体而言，
@Transactional 有什么缺点
尽管
-
隐式事务传播： 在使用
@Transactional 注解时，有时难以准确了解事务的传播行为。一些复杂的调用链可能导致事务的传播方式与预期不符，因此开发者需要仔细了解注解属性的含义。 -
注解滥用： 过度使用
@Transactional 注解可能导致事务管理的不透明性，使得代码更难以理解和维护。因此，需要谨慎使用，只在确实需要事务管理的地方使用。 -
性能开销： 开启事务会带来一定的性能开销，尤其是在某些情况下，比如对大量数据的批量操作。在一些读操作为主的场景中，不合理的事务管理可能影响系统性能。
-
不同数据库支持不同： 不同的数据库对事务的支持程度有所不同，因此在使用
@Transactional 注解时，需要注意数据库的特性以及对事务的支持程度，以避免潜在的兼容性问题。 -
事务嵌套复杂性： 虽然支持嵌套事务是
@Transactional 注解的一项功能，但处理嵌套事务可能增加代码的复杂性，尤其是在出现回滚时需要仔细处理嵌套事务的状态。 -
不适用于所有场景：
@Transactional 注解适用于大多数事务管理场景，但并不适用于所有情况。在某些特殊情况下，可能需要更细粒度的事务控制或者其他事务管理机制。
总体而言，虽然
@Transactional 哪些场景下会不生效
-
非 Spring 管理的 Bean 方法调用： 如果
@Transactional 注解标记的方法是由同一个类内的另一个非 Spring 管理的 Bean 方法调用的，事务可能不会生效。这是因为 Spring 的事务管理是基于代理机制实现的，只有通过代理调用的方法才能被事务管理器感知。 -
自调用问题： 如果在同一个类内的方法内部自调用一个被
@Transactional 注解标记的方法，事务可能会失效。这是因为默认情况下 Spring 使用动态代理来实现事务，自调用内部方法不会触发代理。 -
运行时异常未被抛出：
@Transactional 默认只对未捕获的运行时异常（继承自RuntimeException ）触发回滚。如果在被注解方法中捕获了异常并未重新抛出，事务可能不会回滚。 -
基于类的事务设置： 如果在类级别上使用了
@Transactional 注解，并且类中的方法没有符合事务属性的@Transactional 注解，可能会导致事务不生效。 -
使用了其他事务管理机制： 如果应用中同时使用了多个事务管理机制，可能会导致冲突。例如，如果同时使用了 Spring 的声明式事务和编程式事务管理，可能会产生不一致的结果。
-
在非公共方法上使用： 在非公共（private、protected）的方法上使用
@Transactional 注解通常是无效的，因为 Spring 无法代理非公共方法。 -
异步方法：
@Transactional 注解在异步方法上可能不会按预期生效。在异步方法上使用事务需要谨慎，可能需要额外的配置。 -
使用了 AspectJ 模式： 如果使用了 AspectJ 模式而不是 Spring 默认的动态代理模式，
@Transactional 注解的行为可能会受到影响。
在使用
@Transactional 最佳实践
以下是使用
- 应用在公共方法上： 将
@Transactional 注解应用在公共方法上，以确保 Spring 能够正确地创建代理对象并管理事务。
@Transactional
public void myPublicMethod() {
// 事务性操作
}
-
慎重使用在私有方法： 避免在私有方法上使用
@Transactional 注解，因为 Spring 默认使用动态代理，私有方法无法被代理。如果需要在同一类内部调用事务性方法，可以通过将调用方法抽取到另一个类中，并确保被调用的方法是public 的。 -
谨慎使用在构造函数中： 避免在构造函数中使用
@Transactional 注解，因为构造函数在对象创建时被调用，而此时事务可能尚未启动。将事务性操作移到其他方法中执行。 -
明确声明传播行为： 明确指定事务的传播行为，避免依赖默认值。根据业务需求选择适当的传播行为，如
Propagation.REQUIRED 、Propagation.REQUIRES_NEW 等。
@Transactional(propagation = Propagation.REQUIRED)
public void myMethod() {
// 事务性操作
}
- 了解隔离级别： 了解不同的隔离级别，并根据具体业务需求选择合适的隔离级别。常见的隔离级别包括
Isolation.DEFAULT 、Isolation.READ_COMMITTED 等。
@Transactional(isolation = Isolation.READ_COMMITTED)
public void myMethod() {
// 事务性操作
}
- 处理异常： 在事务性方法中，确保未捕获的运行时异常能够触发事务回滚。如果需要捕获异常，确保重新抛出未捕获的异常。
@Transactional
public void myMethod() {
try {
// 事务性操作
} catch (Exception e) {
// 处理异常
throw e; // 重新抛出未捕获的异常，以触发事务回滚
}
}
- 使用只读事务： 如果方法只涉及读操作而不涉及写操作，可以设置
readOnly 属性为true ，以提高性能。
@Transactional(readOnly = true)
public void myReadOnlyMethod() {
// 读操作
}
- 合理设置超时时间： 如果方法可能执行较长时间，可以通过设置
timeout 属性来定义事务的超时时间，防止长时间持有数据库连接。
@Transactional(timeout = 300) // 事务超时时间为 300 秒
public void myMethod() {
// 事务性操作
}
- 了解嵌套事务： 如果需要支持嵌套事务，了解嵌套事务的配置和行为，并确保业务逻辑与事务嵌套相符。
@Transactional(propagation = Propagation.REQUIRED)
public void myMethod() {
// 事务性操作
anotherTransactionalMethod(); // 嵌套事务
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void anotherTransactionalMethod() {
// 另一个事务性操作
}
- 监控和日志： 在生产环境中，通过合适的监控工具和日志来跟踪事务的执行情况，以便及时发现和解决潜在的事务问题。
通过以上最佳实践，可以更好地使用