概括
我们必须了解我们的代码(或第三方，可能是CLR本身)的哪一部分导致整数装箱。
问题描述
我们有一个相当大的应用程序，其中我们观察到System.Int32实例的分配率很高。在Memory Profiler的帮助下，我们可以看到少量的长期存在的Int32实例(准确地说是18个)和每秒20-25千个Int32分配。所有这些对象都是作为Gen0对象收集的GC，系统没有内存泄漏，并且可以长时间运行。创建内存快照后，GC将在快照之前执行，因此快照不包含那些“临时”对象的任何痕迹。
我们所有的代码都是专门为消除装箱而编写的，“按设计”我们应该根本看不到装箱。因此，我们怀疑这是我们代码中一些未被消除的被忘记的拳击，或者是由第三方组件和/或CLR类型本身引起的拳击。
系统使用VS2008进行编译，并使用.Net 3.5(在调试和发行版构建中均进行了测量，并且具有相同的行为)。
问题
我们如何(使用windbg，VS2008，Memory Profiler，AQTime或任何其他市售产品)检测为什么发生装箱？
最佳答案
我最喜欢的应用程序之一是CLR Profiler，它将为您提供所需的内容，它将整个应用程序映射成不同的世代。它可以从Microsoft免费下载，并且功能极其强大且易于使用。我还提供了有关如何使用它的链接。
(CLR Profiler Download)
(How to Use CLR Profiler)