第一章：.NET性能分析基础

各位同学，咱们今天聊聊性能分析。说实话，我做了十几年.NET后端，踩过的坑比写过的代码还多。性能分析这事儿，说白了就是给系统做体检——早发现早治疗，别等到线上崩了才手忙脚乱。

1.1 性能分析的重要性

先问大家一个问题：你遇到过系统突然变慢，CPU飙到100%，用户疯狂投诉的情况吗？

我遇到过。那是一个电商大促的晚上，订单系统响应时间从50ms直接跳到5秒。当时我盯着监控面板，手心全是汗。后来发现，问题出在一个简单的LINQ查询上——没有及时释放数据库连接，导致连接池耗尽。

性能分析的意义，说白了就三点：

• 提前发现隐患：别等用户骂娘了才去修
• 精准定位问题：到底是代码慢、数据库慢，还是网络慢？
• 量化优化效果：改完代码，性能提升了多少？得有数据说话

1.2 常见性能瓶颈类型

这些年我总结下来，.NET后端的性能瓶颈，逃不出这几类：

1.2.1 CPU密集型问题

说白了就是CPU忙不过来。常见原因：

• 死循环或无限递归——我见过有人用递归做树形结构查询，数据量一大直接炸了
• 大量字符串拼接——用+号拼接几千次，性能惨不忍睹
• 不合理的正则表达式——回溯陷阱了解一下？
• 频繁的垃圾回收——对象创建太多，GC忙不过来

1.2.2 内存问题

内存泄漏、大对象堆碎片化，这些都是老生常谈。我记得有个项目，内存占用持续增长，三天不重启就OOM。最后发现是事件订阅没有取消，导致对象无法被回收。

1.2.3 I/O瓶颈

数据库查询慢、文件读写慢、网络延迟高。这里我特别想强调一点：很多人觉得数据库慢就加索引，其实很多时候是查询写法有问题。

// 错误示例：N+1查询
var orders = db.Orders.ToList();
foreach (var order in orders)
{
    var items = db.OrderItems.Where(o => o.OrderId == order.Id).ToList();
}

// 正确做法：一次性加载
var ordersWithItems = db.Orders.Include(o => o.Items).ToList();

1.2.4 锁竞争

高并发场景下，锁的争用会导致线程阻塞。我曾经在一个支付系统中，用了全局锁来控制库存扣减，结果QPS一上来，系统直接瘫痪。

1.3 性能分析工具概览

工欲善其事，必先利其器。我常用的工具清单如下：

工具名称	适用场景	我的使用心得
Visual Studio Profiler	CPU、内存分析	适合开发阶段，集成度高，但线上环境不好用
dotMemory / dotTrace	内存泄漏、性能瓶颈	JetBrains家的，功能强大，我用了五年了
PerfView	底层性能分析	微软出品，免费但学习曲线陡峭
BenchmarkDotNet	微基准测试	写代码时随手测一下，避免写出慢代码
Application Insights	线上监控	Azure的，可以实时看到请求链路和耗时

1.3.1 开发阶段：BenchmarkDotNet

我个人习惯在写关键代码时，用BenchmarkDotNet跑一下基准测试。比如比较两种字符串拼接方式的性能：

[MemoryDiagnoser]
public class StringBenchmark
{
    [Benchmark]
    public string UseStringBuilder()
    {
        var sb = new StringBuilder();
        for (int i = 0; i < 1000; i++)
            sb.Append(i.ToString());
        return sb.ToString();
    }

    [Benchmark]
    public string UsePlusOperator()
    {
        string result = "";
        for (int i = 0; i < 1000; i++)
            result += i.ToString();
        return result;
    }
}

结果一目了然：StringBuilder快了将近100倍。嗯，这就是数据说话。

1.3.2 线上阶段：PerfView + 日志

线上问题排查，我一般先用PerfView抓一个CPU采样，看看热点在哪里。然后再结合日志，定位具体的代码路径。

1.4 性能分析的思维模型

最后，我想分享一个我自己的分析框架。遇到性能问题，我一般按这个顺序排查：

1. 先看监控：CPU、内存、磁盘I/O、网络，哪个指标异常？
2. 再看代码：最近改了什么？有没有明显的性能陷阱？
3. 然后看数据库：慢查询日志、索引使用情况、连接池状态
4. 最后看外部依赖：Redis、消息队列、第三方API，有没有超时？

你想想看，这个顺序其实是有道理的。从宏观到微观，从系统到代码，一步步缩小范围。我见过太多人一上来就盯着代码看，结果折腾半天发现是网络问题。

好了，今天就到这里。记住，性能优化是一个持续的过程，不是一锤子买卖。咱们下节课见。