优化@Transactional事务性能(LazyConnectionDataSourceProxy)

标签：事务 return 数据库 equals method getName LazyConnectionDataSourceProxy Transactional

背景

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

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

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

@Service
public class OrderService {

    @Transactional
    public 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 {

    @Bean
    public DataSource realDataSource() {
        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/test");
        dataSource.setUsername("root");
        dataSource.setPassword("password");
        return dataSource;
    }

    @Bean
    public DataSource dataSource() {
        return new LazyConnectionDataSourceProxy(realDataSource());
    }

    @Bean
    public 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() 这样的调用，可能会导致代理对象提前获取连接，影响延迟获取的效果。

总结

在 Spring 事务管理中，@Transactional 非常方便，但如果方法内部的 非数据库操作占比高，就可能造成数据库连接的长期占用，事务的长时间占用，影响系统性能

使用 LazyConnectionDataSourceProxy 可以 延迟数据库连接的获取，让事务管理更加高效，减少数据库连接池的压力，特别适用于高并发、复杂业务逻辑的场景。

对于 @Transactional 方法中包含大量 非数据库操作（如远程调用、复杂计算） 的情况，这个优化手段值得尝试！

转自：https://blog.csdn.net/qq_35249342/article/details/145245085

标签：事务,return,数据库,equals,method,getName,LazyConnectionDataSourceProxy,Transactional
From： https://www.cnblogs.com/tiancai/p/18680715