背景
在项目开发中，使用 @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 方法中包含大量 非数据库操作（如远程调用、复杂计算） 的情况，这个优化手段值得尝试！
最后
往期更多干货，请点击加瓦点灯
本文由mdnice多平台发布
