Infinity项目中的事务管理器并发冲突问题分析与解决方案

问题背景

在Infinity数据库系统的开发过程中，测试团队发现了一个严重的事务管理器并发问题。该问题在并行测试环境下表现为段错误(SEGFAULT)，主要发生在test_chaos.py测试用例中，涉及事务管理器的冲突检测机制与回滚操作的并发执行。

问题现象

当系统在高并发环境下运行时，多个事务同时访问事务管理器时，会出现以下异常现象：

1. 事务A尝试检查与事务B的冲突
2. 事务B在此期间被回滚
3. 事务A在检查冲突时访问了已被释放的事务B对象
4. 系统抛出段错误或堆使用后释放(heap-use-after-free)错误

从错误日志中可以看到典型的调用栈信息，显示冲突发生在事务的冲突检查过程中，而此时另一个线程正在释放事务对象。

技术分析

根本原因

通过分析地址消毒器(AddressSanitizer)的输出和调用栈信息，可以确定问题的根本原因是：

1. 竞态条件：事务的冲突检查(Txn::CheckConflict)和事务的释放(Txn::~Txn)操作之间存在竞态条件
2. 生命周期管理不当：事务对象在被其他事务检查冲突时可能已被释放
3. 锁保护不足：现有的锁机制未能完全保护事务对象的整个生命周期

具体问题点

1. 哈希表迭代器失效：当检查冲突时，代码会遍历事务存储中的哈希表，而该哈希表可能在遍历过程中被修改
2. 共享指针管理问题：事务对象的共享指针在冲突检查期间可能已被释放
3. 日志格式化问题：错误日志显示在格式化日志消息时访问了已释放的内存

解决方案

锁机制增强

为了解决这个问题，我们需要增强事务管理器的锁机制：

1. 引入读写锁：为每个事务对象添加读写锁，允许多个线程同时读取(检查冲突)，但独占写入(修改或释放)
2. 分层锁定策略：
   • 第一层：全局事务管理器锁(粗粒度)
   • 第二层：单个事务对象锁(细粒度)

class Txn {
    // ...
    std::shared_mutex mutex_;  // 读写锁
    // ...
};

生命周期管理改进

1. 引用计数增强：确保在冲突检查期间事务对象不会被释放
2. 延迟释放机制：将被回滚的事务标记为"待删除"，而不是立即释放

冲突检查流程优化

修改冲突检查流程，确保在检查期间持有适当的锁：

bool Txn::CheckConflict(Txn* other_txn) {
    std::shared_lock<std::shared_mutex> lock(other_txn->mutex_);
    if (other_txn->status_ == TxnStatus::kRollbacked) {
        return true;  // 冲突
    }
    // 其他检查逻辑...
}

实施效果

经过上述改进后：

1. 稳定性提升：在高压测试环境下不再出现段错误
2. 性能影响可控：细粒度的锁策略将并发性能影响降至最低
3. 代码健壮性增强：明确的生命周期管理减少了类似问题的发生概率

经验总结

这个问题的解决过程为我们提供了宝贵的经验：

1. 并发编程复杂性：在数据库系统中，事务管理器的并发控制尤为关键
2. 测试覆盖重要性：高并发场景下的边界条件测试必不可少
3. 工具链价值：地址消毒器等工具在诊断内存和并发问题时非常有效

通过这次问题的分析和解决，Infinity项目的事务管理器在并发处理能力上得到了显著提升，为系统的稳定性和可靠性奠定了更坚实的基础。