Signal-Android数据库锁竞争导致的收发消息异常问题分析

问题背景

在Signal-Android 7.20.2及升级到7.22.1版本后，部分Android设备出现了无法正常收发消息的问题。具体表现为：

1. 消息接收失败，界面持续显示"正在检查新消息"
2. 已读回执和消息发送功能异常
3. 顶部通知栏出现"您可能有新消息"的提示卡住

技术分析

核心问题定位

通过调试日志分析，发现系统存在严重的数据库锁竞争问题。所有线程都被阻塞在net.zetetic.database.sqlcipher.SQLiteConnectionPool.waitForConnection处，等待获取数据库连接。

关键发现

1. 慢查询问题：日志中出现了执行时间长达数百秒的DELETE语句：

   DELETE FROM message WHERE thread_id = ? AND message.date_received < 1727477102671
   

   这条语句用于清理过期消息，但在某些情况下执行效率极低。

2. 锁竞争链：

   • 慢查询持有数据库锁
   • 其他线程（如消息发送线程）等待数据库锁
   • 同时存在会话锁的竞争

3. 影响范围：

   • 主要影响启用了"消失消息"功能的用户
   • 设备性能较差的用户更易受影响（如三星Galaxy Tab A等旧设备）

根本原因

数据库设计因素

1. 虽然thread_id字段已建立索引，但复合查询条件仍可能导致性能问题
2. SQLite在删除操作时需要处理：
   • 全文检索索引(FTS)的触发器
   • 外键约束检查
   • 级联删除操作

系统架构因素

1. 消息清理操作未采用异步批处理机制
2. 数据库连接池管理策略有待优化
3. 缺乏对长时间运行查询的超时处理

解决方案与建议

临时解决方案

1. 启用代理或关闭消息过滤功能（可能改善网络连接状况）
2. 在存储设置中选择"删除消息历史记录"（彻底但激进）

长期优化建议

1. 查询优化：

   • 为复合查询条件创建更合适的索引
   • 将大删除操作分批执行

2. 架构改进：

   • 实现异步消息清理机制
   • 优化数据库锁获取策略
   • 添加查询执行超时监控

3. 性能监控：

   • 增加慢查询日志记录
   • 实现数据库操作性能指标收集

经验总结

此案例展示了在即时通讯应用中处理大量数据时可能遇到的典型性能挑战。特别是在实现"消失消息"这类功能时，需要特别注意：

1. 数据库操作的性能影响
2. 锁竞争对系统整体性能的影响
3. 旧设备上的性能表现差异

Signal团队在后续版本中应持续优化数据库操作，特别是在处理大量消息清理任务时的性能表现，以确保所有用户都能获得流畅的使用体验。