优化@Transactional事务性能(LazyConnectionDataSourceProxy)-编程知识

优化@Transactional事务性能(LazyConnectionDataSourceProxy)

news/2025/3/9 10:52:04/文章来源:https://www.cnblogs.com/tiancai/p/18680715

背景

在项目开发中，使用 @Transactional 注解来管理事务非常方便，且优雅。但是也存在一个问题：长事务问题

很多被 @Transactional 标记的方法，实际上并不需要进行数据库操作，或者说，它们在执行的很长一段时间内都不会真正触发数据库访问。

举个例子，我们的业务逻辑可能如下：

@Service
public class OrderService {@Transactionalpublic void processOrder(Long orderId) {// 1. 复杂的业务校验（纯计算，无数据库操作）validateOrder(orderId);// 2. 调用外部服务（可能是一个耗时操作，比如支付、物流）callExternalService(orderId);// 3. 数据库操作（此时才真正需要数据库连接）updateOrderStatus(orderId);}
}

在这个 processOrder() 方法中：

只有 updateOrderStatus(orderId) 这一行代码涉及数据库操作。
但由于 @Transactional 的作用，Spring 在 方法一开始 就会从数据库连接池获取连接，即便前面两步根本不需要用到数据库。
如果 validateOrder() 或 callExternalService() 是一个耗时操作，就会导致数据库连接长时间被占用，影响系统吞吐量。

这种情况下，我们可以使用 LazyConnectionDataSourceProxy 来优化数据库连接的获取时机，避免不必要的连接占用。

解决办法：使用Spring提供的LazyConnectionDataSourceProxy

Spring给我们提供了一个非常好的利器：可以解决此类长事务的问题，来看具体用法示例， 后面我会分析它的原理。

LazyConnectionDataSourceProxy 用法示例

在 Spring 配置中，我们可以用 LazyConnectionDataSourceProxy 代理现有的 DataSource，使得数据库连接不会在事务开始时立即获取，而是在真正执行 SQL 时才获取。

Spring Boot 配置示例

@Configuration
public class DataSourceConfig {@Beanpublic DataSource realDataSource() {HikariDataSource dataSource = new HikariDataSource();dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/test");dataSource.setUsername("root");dataSource.setPassword("password");return dataSource;}@Beanpublic DataSource dataSource() {return new LazyConnectionDataSourceProxy(realDataSource());}@Beanpublic PlatformTransactionManager transactionManager() {return new DataSourceTransactionManager(dataSource());}
}

在这里，我们用 LazyConnectionDataSourceProxy 包装了真正的数据库 DataSource，然后让 TransactionManager 使用这个代理数据源。

LazyConnectionDataSourceProxy 的原理

LazyConnectionDataSourceProxy 的核心机制就是 延迟获取数据库连接，它的主要逻辑如下：

事务开启时，Spring 事务管理器不会立即从连接池获取数据库连接，而是返回一个 Connection 代理对象。
当代码真正执行数据库操作（如 prepareStatement()、createStatement()）时，代理对象才会去获取真实的数据库连接。
事务提交或回滚时，如果 Connection 代理对象从未真正执行过 SQL，则根本不会创建数据库连接，从而节省资源。

关键源码如下：

    public Connection getConnection() throws SQLException {// 返回的是代理对象return (Connection)Proxy.newProxyInstance(ConnectionProxy.class.getClassLoader(), new Class[]{ConnectionProxy.class}, new LazyConnectionInvocationHandler());}public Connection getConnection(String username, String password) throws SQLException {return (Connection)Proxy.newProxyInstance(ConnectionProxy.class.getClassLoader(), new Class[]{ConnectionProxy.class}, new LazyConnectionInvocationHandler(username, password));}

其中，getConnection() 方法返回的 Connection 是一个 JDK 动态代理对象，它会拦截 prepareStatement()、createStatement() 等方法，直到真正执行 SQL 时才去获取连接。这里我们主要关注LazyConnectionInvocationHandler类的invoke方法，因为根据JDK动态代理的特性，当Connection代理对象的方法执行时，会触发到invoke方法

LazyConnectionInvocationHandler源码解析

主要需要关注LazyConnectionInvocationHandler的invoke方法，关键代码部分有增加注释，感兴趣的可以看看

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {// 以下的这些 if …… else 的判断，主要就是通过排除法锁定prepareStatement 方法// 只要 method.getName 不为：prepareStatement 则spring都使用了硬编码做了模拟方法实现，可以仔细分析一下源代码if (method.getName().equals("equals")) {return proxy == args[0];} else if (method.getName().equals("hashCode")) {return System.identityHashCode(proxy);} else {if (method.getName().equals("unwrap")) {if (((Class)args[0]).isInstance(proxy)) {return proxy;}} else if (method.getName().equals("isWrapperFor")) {if (((Class)args[0]).isInstance(proxy)) {return true;}} else if (method.getName().equals("getTargetConnection")) {return this.getTargetConnection(method);}
// 当没有执行 prepareStatement 方法，则 hasTargetConnection() 的返回值恒为 false // 但是该 if 逻辑内部恰好排除了 prepareStatement 方法的执行，// 也就是说当 Connection 执行 prepareStatement 时会进入else 的处理逻辑if (!this.hasTargetConnection()) {if (method.getName().equals("toString")) {return "Lazy Connection proxy for target DataSource [" + LazyConnectionDataSourceProxy.this.getTargetDataSource() + "]";}if (method.getName().equals("getAutoCommit")) {if (this.autoCommit != null) {return this.autoCommit;}} else {if (method.getName().equals("setAutoCommit")) {this.autoCommit = (Boolean)args[0];return null;}if (method.getName().equals("getTransactionIsolation")) {if (this.transactionIsolation != null) {return this.transactionIsolation;}} else {if (method.getName().equals("setTransactionIsolation")) {this.transactionIsolation = (Integer)args[0];return null;}if (method.getName().equals("isReadOnly")) {return this.readOnly;}if (method.getName().equals("setReadOnly")) {this.readOnly = (Boolean)args[0];return null;}if (method.getName().equals("getHoldability")) {return this.holdability;}if (method.getName().equals("setHoldability")) {this.holdability = (Integer)args[0];return null;}if (method.getName().equals("commit")) {return null;}if (method.getName().equals("rollback")) {return null;}if (method.getName().equals("getWarnings")) {return null;}if (method.getName().equals("clearWarnings")) {return null;}if (method.getName().equals("close")) {this.closed = true;return null;}if (method.getName().equals("isClosed")) {return this.closed;}if (this.closed) {throw new SQLException("Illegal operation: connection is closed");}}}}
// 这里才真正获取数据库连接try {return method.invoke(this.getTargetConnection(method), args);} catch (InvocationTargetException var5) {throw var5.getTargetException();}}}

原理一句话总结：

使用JDK动态代理connection，使得原有@Transaction注解在方法第一行就会获取数据库连接的模式，改变为只有当真正需要执行sql时，才获取连接，也即懒加载模式获取连接，这样就大大减少了连接的占用时间，也可以缩短事务的占用时间

性能优化效果

在引入 LazyConnectionDataSourceProxy 之后，数据库连接的获取时机由 “事务开始” 变为 首次执行 SQL 时，这带来了几个优化点：

减少数据库连接池的压力：原本事务开启就会立即获取数据库连接，现在只有在执行 SQL 语句时才会获取，避免连接池资源被长期占用。
提高系统吞吐量：在高并发场景下，多个 @Transactional 方法可能会并发执行，如果它们的前半部分是耗时操作，LazyConnectionDataSourceProxy 可以减少数据库连接的浪费，从而提高整体性能。
优化 @Transactional 在无数据库操作事务中的表现：如果 @Transactional 方法最终根本没有执行 SQL，那么 LazyConnectionDataSourceProxy 会使得这个事务 从头到尾都不会获取数据库连接，减少了不必要的资源开销。

实际使用中的注意点

LazyConnectionDataSourceProxy 仅仅优化了数据库连接的获取时机，并不会改变事务的传播机制。如果方法确实需要事务，@Transactional 仍然是必不可少的。
不能直接替代数据库连接池，LazyConnectionDataSourceProxy 需要和 HikariCP、Druid 等连接池配合使用，保证高效的连接管理。
不适用于直接管理 Connection 的代码。如果代码中有 connection.unwrap() 或 connection.getMetaData() 这样的调用，可能会导致代理对象提前获取连接，影响延迟获取的效果。