如何排查NUnit并行测试中无名死锁对象的问题

一、从测试日志追踪对象共享行为 #

• 开启NUnit的详细日志：测试运行时添加参数--trace=Verbose，或在测试项目的nunit.runner.json中配置"traceLevel": "Verbose"，重点关注多线程同时访问的对象记录，尤其是无显式名称/ID的内存对象。
• 给可疑对象临时加追踪标识：在怀疑的对象（比如静态工具类实例、共享连接对象）的构造或初始化逻辑中，生成临时GUID（如private Guid _tempTraceId = Guid.NewGuid();），并在对象被访问时输出这个ID，通过日志关联多线程访问记录，定位争抢目标。

二、内存快照分析共享实例 #

• 使用Visual Studio内存快照或dotMemory等工具，在死锁触发时抓取进程内存快照：
  • 筛选被多个测试线程同时持有引用的对象，重点排查无Id/Name属性的实例，比如静态类的私有字段、DI容器错误注册为单例的服务（例如EF Context被意外设为单例时，并行测试会争抢同一实例）。
  • 结合EF+Dapper场景，检查是否存在共享的SqlConnection实例或全局命令缓存对象，这类无标识对象是并行死锁的高频诱因。

三、线程阻塞点调试 #

• 用Visual Studio的线程调试窗口，在死锁发生时暂停所有线程，查看每个线程的调用栈：
  • 定位线程阻塞的同步节点（比如lock语句、Monitor.Enter、信号量），即使对象没有名称/ID，也能通过调用栈回溯到创建它的代码位置。
  • 重点排查EF Context的线程安全问题：DbContext本身不是线程安全的，若被多测试线程共享必然引发阻塞；同时检查Dapper是否在同一个连接上执行并发操作。

四、代码层面排查未隔离资源 #

• 检查测试代码中的共享资源：
  • 排查静态工具类、全局配置对象、测试基类中创建的共享实例，这些对象通常无显式标识，但会被所有并行测试访问。
  • 验证EF Context的创建逻辑：确保每个测试用例都创建独立的Context实例，而非复用单例；Dapper的数据库连接需保证每次操作都创建新实例，避免共享连接引发的并发阻塞。

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