第一章：非托管句柄泄露检测
非托管互操作的隐藏威胁
当 C# 程序通过 P/Invoke 与 C++ 交互时，就进入了"非托管泥潭"。即使是一个简单的 C++ 调用也可能引入从托管代码角度几乎不可见的句柄泄露问题。
场景：C# 应用调用一个创建 Event 句柄但从未关闭它的 C++ 原生方法：
extern “C” {
_declspec(dllexport) void CSharpCreateEvent();
}
#include <Windows.h>
void CSharpCreateEvent() {
HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
printf(“\nEvent句柄值: %#08x\t”, hEvent);
// 缺失: CloseHandle(hEvent);
}
C# 调用方：
internal class Program {
[DllImport(“Example.dll”, CallingConvention = CallingConvention.Cdecl)]
extern static void CSharpCreateEvent();
static void Main(string[] args) { while (true) { Task.Run(() => CSharpCreateEvent()); Thread.Sleep(10); } }}
1.2 使用 WinDbg 识别泄露的句柄
使用 !handle 命令检查句柄类型和数量：
0:004> !handle
Handle 16fc
Type Event
1411 Handles
Type Count
None 6
Event 1337 <- 异常高！
File 16
Directory 4
Mutant 3
…
1.3 使用 !htrace 追踪句柄分配
!htrace 命令启用句柄追踪并比较快照以找到泄露的句柄：
0:011> !htrace -enable
Handle tracing enabled.
Handle tracing information snapshot successfully taken.
0:011> g
(一段时间后中断)
0:007> !htrace -diff
Handle tracing information snapshot successfully taken.
0xad new stack traces since the previous snapshot.
Outstanding handles opened since the previous snapshot:
Handle = 0x0000199c - OPEN
Thread ID = 0x000017c8, Process ID = 0x00000e14
…
0x770e2b04: KERNELBASE!CreateEventW+0x00000024
0x6ac91755: Example_20_1_5!CSharpCreateEvent+0x00000035
1.4 结合断点与托管栈检查
在原生方法上设置断点并捕获托管调用栈：
0:007> bp Example_20_1_5!CSharpCreateEvent “k; gc”
0:007> g
ChildEBP RetAddr
00 0848f9e4 080674f3 Example_20_1_5!CSharpCreateEvent
02 0848f9f0 0806e3dd Example_20_1_4!Program.<>c.b__1_0+0x1b
03 0848f9fc 0806e38d System_Private_CoreLib!Task.InnerInvoke+0x3d
…
第二章：终结器队列瓶颈
2.1 理解终结器内存泄露
终结器队列是内存泄露的常见来源。当带析构函数的对象创建速度超过单个终结器线程的处理速度时，内存就会累积。
场景：一个具有慢速析构函数的类：
public class Person {
public string Name { get; set; }
public int Age { get; set; }
~Person() { Thread.Sleep(new Random().Next(0, 3000)); // 慢速终结 Console.WriteLine($"name={Name} finalized..."); }}
// 创建对象的速度超过终结速度
for (int i = 0; i < 1000000; i++) {
var person = new Person { Name = $“jack{i}”, Age = i };
}
2.2 诊断终结器队列积压
在 WinDbg 中使用 !fq（终结器队列）命令：
0:015> !fq
SyncBlocks to be cleaned up: 0
Free-Threaded Interfaces to be released: 0
generation 0 has 28423 finalizable objects
generation 1 has 4 finalizable objects
generation 2 has 21 finalizable objects
Ready for finalization 971560 objects <- 严重积压！
Statistics for all finalizable objects:
MT Count TotalSize Class Name
00007ffdbaa4fb58 999987 31999584 ConsoleApp2.Person <- 罪魁祸首
2.3 调查终结器线程活动
检查终结器线程正在做什么：
0:001> !t
5 2 3f4c 000000001AA94090 202b220 Preemptive … MTA (Finalizer)
0:001> ~~[3f4c]s
ntdll!NtDelayExecution+0x14:
00007ffe`8908c634 c3 ret
0:005> !clrstack
OS Thread Id: 0x3f4c (5)
000000001ACEF868 00007ffe8908c634 [HelperMethodFrame] System.Threading.Thread.SleepInternal(Int32)
000000001ACEF960 00007ffe19f0c46b System.Threading.Thread.Sleep(Int32)
000000001ACEF990 00007ffdba986e15 ConsoleApp2.Person.Finalize() <- 阻塞在 Sleep
2.4 使用 PerfView 测量终结时间
使用 ETW 事件测量终结持续时间：
打开 PerfView 并开始收集
在 Events 视图中搜索 Finalize 事件
分析 FinalizersStart、FinalizerObject 和 FinalizersStop 事件
计算连续 FinalizerObject 事件之间的时间差
第三章：线程同步内部机制
3.1 理解 Monitor.Wait/Pulse 机制
Monitor.Wait 和 Monitor.Pulse 机制对于线程协调至关重要，但常常被误解。
场景：Worker1 等待 Worker2 完成：
static Person lockObject = new Person();
static void Worker1() {
lock (lockObject) {
Console.WriteLine(“1. Execute worker1…”);
Monitor.Wait(lockObject); // 释放锁并等待
Console.WriteLine(“4. Continue worker1…”);
}
}
static void Worker2() {
lock (lockObject) {
Console.WriteLine(“3. worker2 completed…”);
Monitor.Pulse(lockObject); // 唤醒一个等待线程
}
}
3.2 WaitEventLink 数据结构
CoreCLR 内部使用 WaitEventLink 来追踪等待线程：
struct WaitEventLink {
SyncBlock* m_WaitSB; // 当前对象的 syncblock
CLREvent* m_EventWait; // 当前线程的等待事件
PTR_Thread m_Thread; // 所属线程
PTR_WaitEventLink m_Next; // 链接到下一个 SyncBlock
SLink m_LinkSB; // 链接到下一个等待线程
DWORD m_RefCount; // 同一 SyncBlock 上的等待计数
};
3.3 Monitor.Wait 执行流程
Monitor.Wait 方法执行以下步骤：
创建 WaitEventLink：用当前 SyncBlock 和线程信息初始化
入队到线程队列：添加到 m_LinkSB 队列以便 Pulse 通知
释放 Monitor：调用 LeaveMonitorCompletely() 释放锁
阻塞线程：等待 m_EventWait 直到 Pulse 被调用
BOOL SyncBlock::Wait(INT32 timeOut) {
WaitEventLink* walk = pCurThread->WaitEventLinkForSyncBlock(this);
CLREvent* hEvent = &(pCurThread->m_EventWait);
waitEventLink.m_WaitSB = this; waitEventLink.m_EventWait = hEvent; waitEventLink.m_Thread = pCurThread; ThreadQueue::EnqueueThread(pWaitEventLink, this); syncState.m_EnterCount = LeaveMonitorCompletely(); isTimedOut = pCurThread->Block(timeOut, &syncState); return !isTimedOut;}
3.4 Monitor.Pulse vs PulseAll
Pulse：只唤醒队列中的第一个线程：
void SyncBlock::Pulse() {
WaitEventLink* pWaitEventLink;
if ((pWaitEventLink = ThreadQueue::DequeueThread(this)) != NULL)
pWaitEventLink->m_EventWait->Set();
}
PulseAll：唤醒所有等待线程：
void SyncBlock::PulseAll() {
WaitEventLink* pWaitEventLink;
while ((pWaitEventLink = ThreadQueue::DequeueThread(this)) != NULL)
pWaitEventLink->m_EventWait->Set();
}
第四章：使用 Harmony 进行运行时补丁
4.1 Harmony 是什么？
Harmony 是一个强大的库，用于运行时修补、替换和装饰 .NET 方法。它跨所有主要平台工作，并提供类似 AOP 的功能，无需修改源代码。
4.2 关键注入点
补丁类型 描述 使用场景
Prefix 在原始方法之前运行 验证、日志
Postfix 在原始方法之后运行 结果转换
Transpiler 直接修改 IL 代码 高级代码操作
Finalizer 用 try/finally 包装整个方法 异常隔离
Reverse Patch 创建指向原始方法的代理 跨模块调用
4.3 实际用例：追踪线程创建
问题：线程数突然飙升到 1000+，但不知道原因。
解决方案：Hook Thread.Start() 来捕获调用栈：
var harmony = new Harmony(“com.example.threadhook”);
harmony.PatchAll();
[HarmonyPatch(typeof(Thread), “Start”, new Type[] { })]
public class ThreadStartHook {
public static void Prefix(Thread __instance) {
Console.WriteLine($“Thread {__instance.ManagedThreadId} starting:”);
Console.WriteLine(Environment.StackTrace);
}
}
4.4 底层原理：JMP 指令 Hook
Harmony 通过重写 JIT 编译方法的开头，使其跳转到动态生成的代理：
0:013> !U 00007ff85bd0e440
preJIT generated code
System.Threading.Thread.Start()
00007ff8
5bd0e440 e9cb22fba2 jmp 00007ff7fecc0710 <- 跳转到代理
0:013> !U 00007ff7`fecc0710
Normal JIT generated code
DynamicClass.System.Threading.Thread.Start_Patch1(System.Threading.Thread)