如何审计Rails应用依赖gem的线程安全性？

关于公开汇总目录的说明 #

目前不存在权威、全量、持续更新的gem线程安全属性公开目录，相关信息只有零散的社区沉淀：

• 主流成熟gem通常会在官方文档、版本更新日志、issue区明确标注自身的线程安全适配情况，尤其是支持多线程部署的版本会专门做说明
• Rails官方生态的并发适配相关文档，会列出框架默认依赖、高频使用热门gem的线程安全兼容状态
• 少量Ruby并发方向的社区维护清单，会收录经过生产环境多线程部署验证的常用gem，但这类清单覆盖范围窄，更新速度普遍滞后于gem版本迭代，参考价值有限。

自动化检测的可行方案 #

纯静态扫描的漏报率很高，你目前在用的rubocop -r rubocop-thread_safety --only ThreadSafety,Style/GlobalVars,Style/ClassVars,Style/MutableConstant命令是静态检测的常规操作，但它只能识别代码里明写的类变量、全局变量、可变常量这类最表层的风险，没法覆盖逻辑层面的竞态、未做同步的共享资源修改、底层C扩展的非线程安全实现这类隐性问题。可以搭配多层检测手段提升覆盖率：

• 扩展静态扫描规则：在rubocop-thread_safety的基础上，补充自定义扫描规则，遍历所有依赖gem的源码、gemspec做特征匹配：比如识别是否存在未加锁的类级别可变状态写入、是否依赖已知存在线程安全问题的底层扩展、是否使用了非线程安全的标准库方法，这一步可以把大部分低级的显性线程安全问题筛出来。
• 补充并发场景动态测试：针对业务核心链路用到的gem依赖，编写多线程并发测试用例，开启Rails多线程运行模式（对应配置config.threadsafe!，新版本Rails为默认开启项），用原生Thread或者并发工具类启动多线程重复调用gem的核心接口，配合竞态检测逻辑捕获运行时的数据不一致、死锁、状态错乱问题。动态测试的准确率远高于静态分析，能发现大部分逻辑层面的并发缺陷。
• 预发布/灰度环境运行时观测：如果生产环境用Puma这类多线程应用服务器，可以在灰度环境开启线程状态监控，采集锁等待、死锁、共享资源异常修改等指标，跑真实业务流量做验证，这是最贴近实际运行场景的检测手段。

实操建议 #

线程安全问题不存在100%准确率的自动化检测方案，不要盲目信任单一工具的输出结果，审计时可以按优先级推进降低工作量：

• 先拉取所有直接依赖的gem清单，优先排查维护停滞超过3年、下载量极低、issue区存在大量并发相关bug反馈的小众gem，这类gem出线程安全问题的概率远高于成熟主流gem
• 核心业务链路用到的依赖，除了静态扫描必须补充并发压测验证
• 层级较深的间接依赖可以先通过静态扫描做初筛，标记出存在显性风险的项后，再评估是替换依赖还是在业务层加锁做防护

内容的提问来源于stack exchange，提问作者modulitos