dotnet-dump 无法直接捕获线程阻塞或竞争状态，仅能获取内存快照，不记录执行轨迹、锁持有链或调度历史；需配合 lldb、dotnet-trace、日志与符号调试综合分析。
dotnet-dump 无法直接捕获线程阻塞或竞争状态
dotnet-dump 只能抓取进程某一时刻的内存快照（core dump），它不记录执行轨迹，也不保存锁持有链、线程调度历史或内存访问顺序。所以当你遇到 Task 卡住、Monitor.Enter 死锁、或 ConcurrentDictionary 某些 key 查不到却没报错这类问题时，仅靠 dotnet-dump analyze 很难定位——它能看到线程在哪个方法挂起，但看不到“为什么等”、“谁在持锁”、“是否自旋超时后放弃”。
实操建议：
- 先用
dotnet-dump ps确认目标dotnet进程 PID，再用dotnet-dump collect -p抓取 dump；注意：必须确保该进程启用了COMPlus_DbgEnableMiniDump=1环境变量，否则 dump 缺少托管堆符号信息 - dump 分析阶段，重点运行
clrstack -all和dumpheap -stat，看是否有大量Thread或Task实例未完成，以及哪些线程卡在WaitHandle.WaitOne、Monitor.ObjWait或SpinWait.SpinOnce - 若发现多个线程停在
Monitor.Enter同一个对象地址，用dumpobj查该对象的SyncBlockIndex，再用eeheap -syncblk找出当前持有该 sync block 的线程 ID
lldb 是唯一能实时观测托管线程调度和原生调用栈的工具
Linux 上没有 WinDbg，而 lldb 是 dotnet runtime 官方支持的调试器（通过 libsosplugin.so 插件）。它能 attach 到运行中的 dotnet 进程，设置断点、单步执行、查看寄存器，并在托管代码断点命中时自动切换到 C# 源码上下文（需有 PDB + 调试符号路径正确）。
实操建议：
- 启动前导出符号路径：
export DOTNET_SYMBOLS=1，并确保/tmp/dotnet-symbols可写（或设DOTNET_SYMBOLS_CACHE=/path） - 用
lldb --core加载 dump 时，必须手动加载插件：plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/*/libsosplugin.so（路径依 .NET 版本而异） - 调试运行中进程更实用：先
lldb -p，再plugin load ...，然后bpmd YourAssembly.dll YourNamespace.YourClass.YourMethod下托管断点；若断点不生效，检查是否用了 AOT 编译或 Tiered Compilation 导致方法未 JIT - 并发关键操作（如
Interlocked.CompareExchange、SpinLock.Enter）附近可下原生断点：b coreclr!JIT_CheckedWriteBarrier或b libpthread.so.0!pthread_mutex_lock，观察锁争用路径
并发问题必须结合日志 + 时间戳 + 线程 ID 交叉验证
单纯靠 dump 或 lldb 快照，容易误判“假死”：比如某个 Task.Delay(60000) 就是合法等待，不是 bug；而 Parallel.ForEach 中某次迭代耗时突增，可能只是 I/O 偶发延迟。没有上下文时间线，所有线程状态都是静态幻觉。
实操建议：
- 在关键同步块前后打日志，用
DateTime.UtcNow.Ticks和Thread.CurrentThread.ManagedThreadId标记，例如：log($"[T{tid}] Enter lock @ {ticks}") - 避免用
Console.WriteLine（会锁 stdout，干扰并发行为），改用System.IO.File.AppendAllText或Microsoft.Extensions.Logging的 async logger - 若使用
dotnet-trace，启用Microsoft-DotNetRuntime:1:4:0x80000000事件提供程序，它会记录ThreadPoolWorkerThreadStart、ThreadStart、ContentionStart等底层事件，配合traceconv转成 CSV 后用 Pandas 分析锁等待热区
常见陷阱：.NET 版本、符号、权限三重不匹配
在 Linux 上调试 .NET 并发问题，80% 的失败不是逻辑问题，而是环境没对齐：你用 .NET 7 SDK 编译的程序，却用 .NET 6 的 libsosplugin.so 加载 dump；或者 dotnet-dump 是全局安装的，而应用跑在容器里，符号路径根本不可见；又或者非 root 用户 attach lldb，被 ptrace_scope 拦截。
实操建议：
- 统一版本：用
dotnet --list-runtimes和dotnet-dump --version确保一致；容器内调试优先用mcr.microsoft.com/dotnet/sdk:7.0镜像，自带匹配的调试工具链 - 符号路径必须显式指定：
dotnet-dump analyze mydump.coredump --symbols /path/to/pdb/；PDB 文件名必须与 DLL 名完全一致（含大小写），且不能压缩 - 绕过 ptrace 限制：
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope（临时），或容器启动加--cap-add=SYS_PTRACE
sudo docker run --cap-add=SYS_PTRACE -v $(pwd):/app -w /app mcr.microsoft.com/dotnet/sdk:7.0 \ dotnet-dump collect -p $(pidof dotnet) --symbols ./bin/Debug/net7.0/
真正棘手的并发问题，往往藏在 JIT 编译后的指令重排、CPU cache line false sharing、或 GC suspension 导致的暂停毛刺里——这些已超出 dotnet-dump 和 lldb 的常规能力边界，需要 perf + eBPF + clrstack 多维印证。别指望一次命令就定位，留好 trace 和 dump 的时间戳，它们是你回溯的唯一锚点。
