摘要

想让自己的.NET代码获得zui佳的性能吗？本书将揭开CLR的神秘面纱，不仅教你如何编写性能优异的代码，还能让你“知其所以然”。作者参与设计并搭建的系统是世界上zui大型的高性能.NET系统之一，他在本书中融入了很多的经验教训。
本书不仅讲解了CLR的工作机制，还详细介绍了当前获得zui佳性能的新方法，涉及.NET环境下的优化、对CLR功能的深入剖析、免费的工具和教程推荐、颇有价值的案例轶事、评测并提升性能的具体步骤。

编写高性能的.NET代码 作 者 ：（美）沃森（Ben Watson）

编写高性能的.NET代码 出版社 : 人民邮电出版社

编写高性能的.NET代码 内容简介

本书详细介绍了如何编写高性能的.NET程序，在zui大化托管代码性能的同时，还能保证.NET的特性优势。

本书循序渐进地深入.NET的各个部分，特别是底层的公共语言运行时（Common Language Runtime，CLR），了解CLR是如何完成内存管理、代码编译、并发处理等工作的。本书还详细介绍了.NET的架构，探讨了编程方式如何影响程序的整体性能，在全书中，还分享了发生在微软的一些趣闻轶事。本书的内容偏重于服务器程序，但几乎所有内容也同样适用于桌面端和移动端应用程序。

本书条理清楚，言简意赅，适合有一定.NET基础的读者和想要提高代码性能的C#程序员学习参考。

编写高性能的.NET代码 目录

前言

致谢

第1章 性能评估及工具

1.1 选择评估内容

1.2 平均值还是百分位值

1.3 评估工具

1.4 小结

第2章 垃圾回收

2.1 基本运作方式

2.2 配置参数

2.3 减少内存分配量

2.4 首要规则

2.5 缩短对象的生存期

2.6 减少对象树的深度

2.7 减少对象间的引用

2.8 避免对象固定

2.9 避免使用终结方法

2.10 避免分配大对象

2.11 避免缓冲区复制

2.12 对长期存活对象和大型对象进行池化

2.13 减少LOH的碎片整理

2.14 某些场合可以强制执行完全回收

2.15 必要时对LOH进行碎片整理

2.16 在垃圾回收之前获得通知

2.17 用弱引用作为缓存

2.18 评估和研究垃圾回收性能

2.19 小结

第3章 JIT编译

3.1 JIT编译的好处

3.2 JIT编译的开销

3.3 JIT编译器优化

3.4 减少JIT编译时间和程序启动时间

3.5 利用Profile优化JIT编译

3.6 使用NGEN的时机

3.7 JIT无法胜任的场合

3.8 评估

3.9 小结

第4章 异步编程

4.1 使用Task

4.2 并行循环

4.3 避免阻塞

4.4 在非阻塞式I/O中使用Task

4.5 async和await

4.6 编程结构上的注意事项

4.7 正确使用Timer对象

4.8 合理设置线程池的初始大小

4.9 不要中止线程

4.10 不要改变线程的优先级

4.11 线程同步和锁

4.12 评估

4.13 小结

第5章 编码和类设计的一般规则

5.1 类和“结构”的对比

5.2 重写“结构”的Equals和GetHashCode方法

5.3 虚方法和密封类

5.4 接口的分发（Dispatch）

5.5 避免装箱

5.6 for和foreach的对比

5.7 强制类型转换

5.8 P/Invoke

5.9 委托

5.10 异常

5.11 dynamic

5.12 自行生成代码

5.13 预处理

5.14 评估

5.15 小结

第6章 使用.NET Framework

6.1 全面了解所用API

6.2 多个API殊途同归

6.3 集合类

6.4 字符串

6.5 应避免使用正常情况下也会抛出“异常”的API

6.6 避免使用会在LOH分配内存的API

6.7 使用延迟初始化

6.8 枚举的惊人开销

6.9 对时间的跟踪记录

6.10 正则表达式

6.11 LINQ

6.12 读取文件

6.13 优化HTTP参数及网络通信

6.14 反射

6.15 评估

6.16 性能计数器

6.17 小结

第7章 性能计数器

7.1 使用已有的计数器

7.2 创建自定义计数器

7.3 小结

第8章 ETW事件

8.1 定义事件

8.2 在PerfView中使用自定义事件

8.3 创建自定义ETW事件Listener

8.4 获取EventSource的详细信息

8.5 自定义PerfView分析插件

8.6 小结

第9章 Windows Phone

9.1 评估工具

9.2 垃圾回收和内存

9.3 JIT

9.4 异步编程和内存模式

9.5 其他问题

9.6 小结

第10章 代码安全性

10.1 充分理解底层的操作系统、API和硬件

10.2 把API调用限制在一定范围的代码内

10.3 把性能要求很高、难度很大的代码集中起来并加以抽象

10.4 把非托管代码和不安全代码隔离出来

10.5 除非有证据证明，不然代码清晰度比性能更重要

10.6 小结

第11章 建立追求性能的开发团队

11.1 了解最影响性能的关键区域

11.2 有效的测试

11.3 性能测试平台和自动化

11.4 只认数据

11.5 有效的代码复查

11.6 训练

11.7 小结

附录A 尽快启动对应用程序的性能讨论

附录B 大O表示法

附录C 参考文献

编写高性能的.NET代码 精彩文摘

1.1 选择评估内容

在收集性能数据之前，你需要知道评估的内容是什么。听上去这显而易见，但实际上涉及面远比想象的要广泛得多。就拿内存来说，很显然需要评估内存的占用情况，以便减少内存消耗。但要查看哪类内存呢？专用工作集内存（Private Working Set）、提交大小（Commit Size）、页面缓冲池（Paged Pool）、峰值工作集（Peak Working set）、.NET堆内存大小，还是大对象堆内存（Large Object Heap，LOH）？为了保证负载的均衡，是否要查看各个处理器的堆内存？是否还需要关心其他类型的内存？为了跟踪一段时间内的内存占用情况，是否需要知道每小时的平均值和峰值？内存的占用是否和系统负载相关？现在你明白了吧，光是针对内存，就能轻易地列出一大堆指标。而且目前我们还没有涉及私有堆内存（Private Heap），也没有对程序本身进行评估，还不知道都是哪些对象正在消耗内存呢。

请尽可能明确地描述评估内容。

故事

我曾经负责过一个大型的服务程序，当时我把进程专有内存的大小作为关键的性能指标，根据它来决定是否要在启动内存需求很高的大型任务之前重启进程。这导致了大量的“专有内存”被交换出去，对降低系统的内存负载毫无意义，而我们真正的目标就是要降低内存的负载。我们后来修改了评估系统，转而评估工作集内存，这才产生了效果，把内存占用量减少了几个GB（我说过这是一个大型应用）。

一旦确定了需要评估的内容，接下来就是选择每个指标的目标值。在开发阶段初期，这些目标值可能比较易变，甚至不可能知道。其实在初始阶段不需要满足这些目标值，但这能迫使你建立一套评价体系，依据这些值来自动评估你的工作。这些目标值应该是可量化的。我们对程序的较高要求也许就是要“快”，当然这没错。但这不算是一个很好的指标，因为“快”比较主观，没有什么明确的途径来判断是否达标。你必须能把目标定义成某个数字，而且是可测量的数字。

差的目标：用户界面应该响应迅速。

好的目标：任何操作都不会阻塞UI线程超过20 ms。

但只是能被量化还不够，还需要十分精确，正如前面的内存优化案例中所述。

差的目标：内存占用应该小于1 GB。

好的目标：当负载为每秒100个请求时，工作集内存的占用不能超过1 GB。

第二个版本的目标值给定了非常明确的前提条件，你可以明确知道是否满足需求。实际上，这已给出了一个良好的测试用例。

目标值中的另一个决定因素是应用程序的类型。带有用户界面的程序必须不惜一切代价保证UI线程的响应能力，无论执行任何任务时都应如此。而服务器端程序每秒要处理几十、几百，甚至几千个请求。它必须非常高效地完成I/O操作和数据同步，以保证吞吐量和CPU利用率的最大化。因此服务器端程序的设计完全不同于其他程序。如果某个应用程序的基础架构先天不足，对效率问题考虑欠佳，那么再回头去修正就很难了。

在设计系统和规划性能评估方案时，有一条经验也许很有用，那就是设想一下理论上的最佳性能。如果你能去掉其他所有开销，比如垃圾回收、JIT、线程中断，以及其他任何你能想到的开销，然后还能剩下什么资源用来干活呢？对于负载、内存占用、CPU占用、内部同步等资源，你能想到的理论极限是多少？这通常依赖于程序所处的硬件和操作系统。比如，有1台16个处理器、64GB内存的服务器，带有2条10GB的网络，你需要估计一下最大并行处理能力、内存中最多能存放多少数据，以及每秒的网络吞吐量是多少。这能帮助你作出规划，假如1台服务器不够用，那到底需要多少台同档次的机器。所有这些信息都是性能评估目标的绝佳来源。