wenmo8 发布的文章

了解对象在gc堆中的布局是很有用的。在垃圾收集期间，有效的对象是通过递归访问对象来标记的，这些对象从堆栈的根和句柄开始。但是，从每个堆段的开始到结束，对象的位置以一种有组织的方式排列也很重要。！DumpHeap命令依赖于这个逻辑组织来正确地遍历堆，如果它报告了一个错误，可以打赌您的堆出了问题。

下面是代码

usingSystem;usingSystem.Reflection;usingSystem.Reflection.Emit;usingSystem.Threading;usingSystem.Runtime.InteropServices;public classEmitHelloWorld

{



      [DllImport("kernel32")]public static extern voidDebugBreak();static void Main(string[] args)

      {//create a dynamic assembly and module
            AssemblyName assemblyName = newAssemblyName();

            assemblyName.Name= "HelloWorld";

            AssemblyBuilder assemblyBuilder=Thread.GetDomain().DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.RunAndSave);

            ModuleBuilder module;

            module= assemblyBuilder.DefineDynamicModule("HelloWorld.exe");//create a new type to hold our Main method
            TypeBuilder typeBuilder = module.DefineType("HelloWorldType", TypeAttributes.Public |TypeAttributes.Class);//create the Main(string[] args) method
            MethodBuilder methodbuilder = typeBuilder.DefineMethod("Main", MethodAttributes.HideBySig | MethodAttributes.Static | MethodAttributes.Public, typeof(void), new Type[] { typeof(string[]) });//generate the IL for the Main method
            ILGenerator ilGenerator =methodbuilder.GetILGenerator();

            ilGenerator.EmitWriteLine("hello, world");

            ilGenerator.Emit(OpCodes.Ret);//bake it
            Type helloWorldType =typeBuilder.CreateType();//run it
            helloWorldType.GetMethod("Main").Invoke(null, new string[] {null});



DebugBreak();//set the entry point for the application and save it
assemblyBuilder.SetEntryPoint(methodbuilder, PEFileKinds.ConsoleApplication);

            assemblyBuilder.Save("HelloWorld.exe");

      }

}

下面这个程序有一个bug，试试看你能不能抓住它。

Test.cs (编译成 DelegateExample.exe):

    usingSystem;usingSystem.Threading;usingSystem.Runtime.InteropServices;classTest

    {delegate uintThreadProc (IntPtr arg);private uintm;public Test (uintn)

    {

    m=n;

    }uintReflect (IntPtr arg)

    {

    Console.WriteLine (m);returnm;

    }static voidMain ()

    {

    Test t= new Test (1);

    ThreadProc tp= newThreadProc (t.Reflect);

    NewThread (tp);

    Thread.Sleep (1000);

    }



    [DllImport("UsingCallback")]static extern voidNewThread (ThreadProc proc);

    }

这并不是说它很重要，而是因为它是我的一个大麻烦，我想区分真正的内存泄漏和高内存使用率。
内存泄漏是指您使用了一些内存并且丢失了指向分配的指针，因此您无法再取消分配该内存。如果你仍然有一个指向它的指针，你的内存使用率很高，这可能与进程发生的情况一样糟糕，但仍然不同。为了简单起见，我将从现在开始对这两个问题使用术语内存泄漏…
我喜欢考虑解决性能和内存泄漏问题，比如剥洋葱皮。从最明显的一个层开始，一次去掉一个层，然后定义一个限制，确定问题已解决。
有两种类型的内存泄漏，一种是逐渐的内存泄漏（内存以大致相同的速率持续增长）和突然的内存跳跃。您可以用大致相同的方式对它们进行故障排除，但在后一种情况下，您还可以尝试确定在跳转时是否发生了异常情况，例如服务器上的极端负载等。
进程的内存空间包含一些不同类型的“对象”，如线程、管理的对象堆、托管加载程序堆、本机堆、dll和虚拟分配，因此，一个好的开始是运行带有以下计数器的性能监视器日志。

  • Process/Virtual Bytes
  •   Process/Private Bytes
  •   .net CLR Memory/# Bytes in all Heaps
  •    .net CLR Memory/% Time in GC
  •    .net CLR Memory/Large Object Heap size
  •    .net CLR Loading/Bytes in Loader Heap
  •    .net CLR Loading/Current Assemblies

主要要寻找的是私有字节的增长率是否与虚拟字节的增长率大致相同，以及所有堆中的字节是否都遵循相同的曲线。
如果私有字节持续增加，但是所有堆中的字节没有增加，那么很可能会看到本机内存泄漏（即，在COM组件或类似组件中泄漏），但如果所有堆中的字节以与私有字节相同的速率增加，则托管代码中可能会出现泄漏。
同样，如果您看到虚拟字节稳步增加，但是您的私有字节保持相当稳定，那么您的应用程序可能存在一个问题，即它保留了大量未使用的虚拟内存。
一旦进程启动并且加载了所有应用程序域，加载程序堆和当前程序集中的字节应该保持相当恒定。如果此值持续增加，则很可能存在总成泄漏。

所以现在你大概知道你在哪里泄露了，下一步就是找出原因

到目前为止，!dumpheap 是调试托管内存泄漏时最强大的命令。它将向您显示托管堆上的所有对象，并使用的不同开关你可以用你想要的任何方式显示输出。
!dumpheap是sos.dll框架安装附带的扩展（在framework目录中），如果安装了SDK，则可以在C:\Program files\ Microsoft Visual Studio.NET\2003\SDK\v1.1工具开发人员指南示例SoS中找到有关其使用的一些基本帮助。
堆上存储有两种类型的对象。以某个地方为根的对象，即应用程序中的某个对象有指向它们的指针；自上次垃圾回收后已创建或取消根目录的对象。如果您想知道泄漏在哪里，并且希望避免查看大量即将被垃圾收集的数据，那么一个好方法是运行一个压力测试，然后通过调用GC.Collect(3) ，获取一个内存转储，然后再强调一点，再次诱导GC并获取另一个内存转储并比较堆上的对象。
-stat开关（statistics）显示堆上每种类型的对象的摘要。

0:000> !dumpheap -stat
0x79c489a0 1 12System.Runtime.Remoting.Messaging.ClientContextTerminatorSink0x79bf9aec 1 12 System.IO.TextReader/NullTextReader0x79be7078 1 12System.Runtime.Remoting.Proxies.ProxyAttribute0x79bce8e0 1 12System.Runtime.InteropServices.ComVisibleAttribute0x79bce7c8 1 12System.CLSCompliantAttribute0x79bc08e0 1 12System.Empty0x0618ae68 1 12System.Web.Configuration.CustomErrorsConfigHandler0x061887f8 1 12System.Web.UI.WebControls.UnitConverter0x06180848 1 12System.Drawing.ColorConverter0x05dbfbc4 1 12System.Data.Res<… cut to save space …>

0x03f1236c 625 2,820,896System.Char[]0x04ad88f4 102,874 2,880,472System.Web.UI.ControlCollection0x0469bdf0 156,650 3,133,000System.Collections.Specialized.HybridDictionary0x04ad91bc 164,516 3,290,320System.Web.UI.Triplet0x03f134a8 7,582 3,799,704 System.Collections.Hashtable/bucket[]0x04ade5e4 47,395 4,549,920System.Web.UI.WebControls.Label0x061826bc 58,197 4,888,548System.Web.UI.DataBoundLiteralControl0x04adff44 323,119 5,169,904System.Web.UI.StateItem0x0618788c 63,437 6,089,952System.Web.UI.WebControls.TableCell0x0469c5c4 309,132 6,182,640 System.Collections.Specialized.ListDictionary/DictionaryNode0x0011cec0 305 6,240,720Free0x79ba2ee4 270,831 6,499,944System.Collections.ArrayList0x03f16d9c 222 7,703,284System.DateTime[]0x04add34c 105,502 8,018,152System.Web.UI.LiteralControl0x0615c6f4 558,019 11,160,380System.Data.DataRowView0x03f15d1c 3,783 15,447,528System.Boolean[]0x060bcc74 570,274 22,810,960System.Data.DataRow0x03f15fd4 702 50,930,472System.Decimal[]0x03f131e8 21,013 60,573,352System.Int32[]0x03f1209c 508,734 75,399,184System.Object[]0x79b94638 5,286,303 697,441,440System.String

Total9,712,896 objects, Total size: 1,032,127,612

当你你有1000个w3wp.exe文件在eventviewer中意外停止，或者您的进程以某种奇怪的未定义方式退出，您不知道原因。
当一个进程崩溃或退出时，将触发一个称为EPR（Exit process）的特殊事件，因此使用类似于windbg.exe文件我们可以附加到进程中，等待epr被抛出，然后进行内存转储。安装windows调试工具时，会得到一个名为adplus的vbs脚本，它将为您自动执行此操作，并打印进程生命周期中发生的大多数异常的日志。
调试提示：当您在-crash模式下打开一个转储时，您将自动定位到崩溃发生时处于活动状态的线程（最有可能是可疑的线程）。如果您切换线程并想返回出错线程，请键入~列出所有线程，错误线程将被标记为一个点。
如果dump只显示进程中的一个活动线程，并且该线程是主线程，则该进程可能被外部的东西（运行状况监视、低系统内存、iisreset等）终止

不分先后顺序，以下是我们看到的支持率最高的一些：

Stack Overflow Exceptions

当为线程的堆栈分配的内存用完时，将发生堆栈溢出异常。默认情况下，它是1 MB，所以你的调用堆栈可能很深，所以大多数情况下发生这种情况是因为无限递归，也就是说，function调用FunctionB，后者再次调用FunctionB，后者再次调用FunctionB。。。没有停止条件。
不幸的是，异常处理应用程序块的错误使用是一个相当常见的模糊的无限递归情况。想象一下这个场景：你的应用程序得到一个异常，异常处理程序启动，你已经将它设置为记录到一个文件中。在记录日志时，您会得到某种类型的异常（比如访问被拒绝），并且您已经设置了异常处理程序来处理此异常。在这种情况下，您将在一个无限递归循环中处理一个异常，抛出另一个异常，处理它，抛出另一个。。。你明白要点了。这个故事的寓意是什么？不要在异常处理程序中使用异常处理程序来处理异常。
如果您运行“kb2000”（查看本机堆栈）和“！clrstack”（从sos.dll要查看托管堆栈），您可以找到递归模式以跟踪递归发生的位置/原因。

Out Of Memory Exceptions

大多数情况下，发生内存不足异常是由设计问题引起的，在设计问题中，缓存或会话作用域中存储的内存过多。如果以正确的方式使用缓存，那么缓存对于提高性能是非常有用的，也就是说，缓存的数据最多，而且缓存的时间不会超过需要的时间。在旧的ASP中，如果将对象存储在session范围内，就会出现问题，相信我，这是一种伪装，因为开发人员只在session范围内存储了最必要的项。例如，在会话范围内存储大型数据集通常会适得其反，因为您减少了网站可以处理的并发用户数，而且当内存足够大时，在缓存中进行垃圾收集和搜索所需的时间可能比从数据库中请求数据的开销要多真的需要它。
在何时应该在会话/缓存中存储内容以及何时不应该存储时，这里没有一刀切的解决方案。最好的做法是在早期阶段，确定应用程序需要能够处理的用户数，并在此基础上确定每个用户可以允许的存储量。然后对超过最大用户数的用户进行压力测试，以确保你能应付。最好是对处于会话状态的对象进行压力测试，看看性能如何。不同的用户数量不同。
在生产过程中，内存问题是很难解决的，因为它们通常需要大量的重新设计，所以在早期阶段花费一分钱可以节省很多钱。
调试提示：运行!dumpheap -type System.Web.Caching.Cache获取缓存根，然后对这些地址进行！do objsize，以了解您在缓存中为不同的应用程序存储了多少。（注意：InProc会话状态也存储在缓存中）

Unhandled exception in COM Component

如果应用程序调用本机COM组件，如果其中出现未经处理的异常，则可能会崩溃。例如，如果您引用的是已释放的内存或类似内存。kb2000将在堆栈上显示COM组件，这样您就可以缩小它的范围。

  1. 1
  2. ...
  3. 1308
  4. 1309
  5. 1310
  6. 1311
  7. 1312
  8. 1313
  9. 1314
  10. ...
  11. 1376