Apache Seata 项目中DataSourceProxy重复创建导致OOM问题分析

问题背景

在Apache Seata分布式事务框架的使用过程中，开发者遇到了一个典型的内存溢出问题。当系统并发量上升时，线程数量持续增长且无法释放，最终导致java.lang.OutOfMemoryError: unable to create native thread错误。这个问题特别出现在从Seata 1.5.2版本升级到1.7.0版本后。

问题现象

异常堆栈显示，OOM错误发生在创建新线程时，具体是在TableMetaCacheFactory$TableMetaRefreshHolder初始化过程中。深入分析发现，这是由于在每次获取数据库连接时都创建了新的DataSourceProxy实例，而没有进行合理的缓存和资源管理。

根本原因分析

1. DataSourceProxy创建机制：在Seata 1.7.0版本中，每次创建新的DataSourceProxy实例时，都会初始化一个TableMetaRefreshHolder，这会创建一个线程池用于表元数据刷新。

2. 不当的使用模式：在APIJSON框架的扩展实现中，getConnection方法在每次需要新连接时都会执行new DataSourceProxy(dataSource).getConnection()，而没有重用已创建的DataSourceProxy实例。

3. 资源泄漏：随着并发请求增加，不断创建新的DataSourceProxy实例，每个实例都会创建自己的线程池，最终耗尽系统资源。

技术细节

在Seata的实现中，DataSourceProxy的初始化过程包含以下关键步骤：

1. 调用init()方法注册表元数据
2. 通过TableMetaCacheFactory.registerTableMeta()创建元数据缓存
3. 初始化TableMetaRefreshHolder，这会创建一个单线程的ScheduledExecutorService

当频繁创建DataSourceProxy实例时，每个实例都会创建自己的定时任务线程，这是导致线程数暴增的直接原因。

解决方案

正确的做法应该是：

1. 缓存DataSourceProxy实例：将DataSourceProxy与底层DataSource一起缓存，而不是每次创建新实例。

2. 连接池管理：确保数据库连接的正确关闭和回收，避免连接泄漏。

3. 单例模式：对于同一个数据源URL，应该只创建一个DataSourceProxy实例。

示例改进代码结构：

// 在类初始化时创建缓存
private static final Map<String, DataSourceProxy> proxyCache = new ConcurrentHashMap<>();

public Connection getConnection(SQLConfig config) throws Exception {
    String dbUri = config.getDBUri();
    if (StringUtils.isNotBlank(dbUri)) {
        DataSourceProxy proxy = proxyCache.computeIfAbsent(dbUri, 
            k -> new DataSourceProxy(getOrCreateDataSource(config)));
        return proxy.getConnection();
    }
    // 其他逻辑...
}

最佳实践建议

1. 资源复用：在中间件开发中，类似DataSourceProxy这样的重量级对象应该设计为可复用的。

2. 版本升级注意事项：从Seata 1.5.2升级到1.7.0时，需要注意内部实现的变化，特别是资源管理方面的改进。

3. 监控与告警：对系统的线程数、连接数等关键指标建立监控，提前发现问题。

4. 压力测试：在版本升级后，应进行充分的压力测试，验证资源管理机制的有效性。

总结

这个问题典型地展示了在中间件使用过程中资源管理的重要性。通过分析我们可以学到：在使用类似Seata这样的分布式事务框架时，必须理解其内部资源管理机制，避免不当的使用模式导致系统资源耗尽。正确的做法是重用重量级对象，合理管理生命周期，并在版本升级时充分测试资源管理相关的功能。