Dispose 方法里直接调用 Thread.Abort()
会出问题
很多老代码习惯在
IDisposable.Dispose()中暴力终止线程，比如调用
Thread.Abort()。这在 .NET Core / .NET 5+ 已被彻底移除，即使在 .NET Framework 中也极不安全——它可能在任意指令中间断线程，导致静态字段损坏、锁未释放、内存泄漏或
ThreadAbortException意外抛出到非预期上下文。 永远不要在
Dispose()中调用
Thread.Abort()避免手动管理
Thread实例；优先用
Task+
CancellationToken若必须用
Thread（如需设置
IsBackground = false或特定优先级），应配合手动退出信号（如
ManualResetEvent或
volatile bool）
正确做法：用 CancellationTokenSource
协同取消长期运行的 Task
现代 C# 中，绝大多数后台工作应封装为可取消的
Task，并在
Dispose()中触发取消并等待完成（带超时）。关键点不是“杀掉线程”，而是“通知工作逻辑自行退出”。
public class Worker : IDisposable
{
private readonly CancellationTokenSource _cts = new();
private Task? _workerTask;
<pre class='brush:php;toolbar:false;'>public void Start()
{
_workerTask = Task.Run(() => DoWork(_cts.Token), _cts.Token);
}
private void DoWork(CancellationToken ct)
{
while (!ct.IsCancellationRequested)
{
// 模拟工作：I/O、计算、延时等
Thread.Sleep(100);
// 关键：所有阻塞调用都应支持 cancellation
// ✅ ct.WaitHandle.WaitOne(1000)
// ✅ Task.Delay(1000, ct)
// ❌ Thread.Sleep(1000) —— 无法响应取消
}
}
public void Dispose()
{
_cts.Cancel(); // 发出取消信号
// 等待任务自然退出（建议加超时）
_workerTask?.Wait(2000); // 最多等 2 秒
_cts.Dispose();
_workerTask?.Dispose();
}}
Dispose 被并发调用时的线程安全风险
IDisposable.Dispose()可能被多个线程同时调用（尤其在依赖注入容器或异步资源清理场景中），而标准实现通常没加锁。不处理会导致重复释放、
ObjectDisposedException、或资源二次关闭（如
FileStream.Close()被调两次）。 用
Interlocked.CompareExchange(ref _disposed, 1, 0)做一次性标记最轻量 避免在
Dispose()中加
lock—— 若内部释放逻辑本身阻塞（如等待网络响应），可能引发死锁 对非托管资源（如句柄、内存指针），仍需在
~Worker()终结器中兜底释放，但终结器不能访问托管对象（包括
CancellationTokenSource）
异步 Dispose（IAsyncDisposable
）不是万能解药
.NET 5+ 提供
IAsyncDisposable，但它只解决“释放过程本身需要 await”的场景（如异步刷新缓冲区、等待远程服务确认），**并不解决多线程并发 Dispose 的问题，也不替代取消逻辑**。 若
DisposeAsync()内部要 await 长时间操作，仍需先触发取消（
_cts.Cancel()），再 await 任务完成 不能仅因用了
IAsyncDisposable就忽略同步
Dispose()的线程安全 —— 两者可能被不同线程分别调用 常见误区：把
await Task.Delay()当作“等待线程结束”，实际只是挂起当前 async 上下文，和目标线程无关
真正难的不是写完
Dispose()，是确保所有阻塞点都响应取消信号，并且整个释放流程在并发、重入、提前中断等边界条件下依然稳定。多数崩溃不是因为没写
Dispose，而是写了但没想清楚「谁在什么时候、以什么方式停止了什么」。
