C#的内存分配探索

  • [x] C#的内存分配探索

    • C++中默认的operator new底层调用的是malloc,在分配内存时会带上上下cookie用于内存回收和内存碎片合并,现在到了C#中,因为C#有独有的垃圾回收机制,那我就比较好奇C#中对于对象内存的排列是怎么样的,还有没有上下cookie存在呢?所以我进行了下面的测试

      public class MyClassInt
      {
          private long a;
      }
      
      public class MyClassLong
      {
          private int a;
      }
      
      static class Program
      {
          for (int i = 0; i < 3; i++)
          {
              printMemory(new MyClassInt());
          }
          Console.WriteLine();
          for (int i = 0; i < 3; i++)
          {
              printMemory(new MyClassLong());
          }
      
          public static void printMemory(object o) // 获取引用类型的内存地址方法  
          {
              GCHandle h = GCHandle.Alloc(o, GCHandleType.WeakTrackResurrection);
      
              IntPtr addr = GCHandle.ToIntPtr(h);
      
              Console.WriteLine("0x" + addr.ToString("X"));
          }
          /*
          输出
          0xF010F8
          0xF010F4
          0xF010F0
      
          0xF010EC
          0xF010E8
          0xF010E4
          */
      }
      

      起初对于MyClassInt的输出我很惊讶,因为int的size刚好是4,我本来认为是C#对于内存分配器进行了特殊的管理,比如类似gunc的pool_alloc这样的设计,去掉了cookie,使得对象的大小就是纯粹的size大小间隔,结果想想不太对劲,还是不能靠猜,在试试其他的,一试就试出来了。。。换成了long以后按推理方式来说应该是间隔8,才是纯粹的size大小,结果一看并不是,还是4...fuck,所以其实这个C#中通过new内存并没有带上对象的地址,所以可以看出来打印的应该是引用的地址段,每个地址段4字节,没有cookie,至于指针指向的地方有没有cookie?不得而知,不过这里可以看出这这这样的设计和C#的垃圾回收器有很大关系。且还有个好玩的点,不同类型的内存地址也是连续的,用的是一同一个地址段。接下来再进行一个测试:

      for (int i = 0; i < 100000; i++)
      {
          printMemory(new MyClassInt());
      }
      /*
      其他代码不变
      0x12F10F8
      0x12F10F4
      0x12F10F0
      ...
      0x12F1000
      0x12F14FC
      0x12F14F8
      0x12F14F4
      ...
      0x12F1400
      0x12F15FC
      0x12F15F8
      ...
      0x12FFF08
      0x12FFF04
      0x12FFF00
      0x31E10FC
      0x31E10F8
      0x31E10F4
      ...
      0x31EFF00
      0x31F10FC
      ...
      0x31FFF00
      0x57E10FC
      */
      

      这里我想知道一次分配器分配的大小是多少,不够的时候是什么时候要新的内存块?所以我进行了这个测试,测试下来结果我总结了一下:

      • 首先先是开始的时候总是以XXXXF8开始的,十进制是248

      • 然后新分配的内存会递减这个内存段,直到变成00

      • 变成00后会去要当前这个地址段前三位(F10)后最近的可用的地址段,比如当前是F10就去看看F11可用吗,不行就找F12,依次,比如例中找到了F10用完找到了F14,F14用完找F15依次内推

      • 找到后分配的大小是从FC开始,252,对比于256差了4,很可能用了这个4记录了这个内存块用于GC的信息,比如这个内存块的引用计数。

      • 然后当倒数第五到第三这两位也用完后(变为FFF),那就会分配新的地址段,也是递增搜寻。所以新地址是31E,默认从E10FC开始(921836),结束是FFF00(1048320),可用126484,每个对象为4的话就是31621个对对象

    • 继续探索,如果想要继续往下的话就得去深挖看看GCHandle.Alloc的分配

      • 如果深入研究GCHandle.Alloc,您会看到它调用了一个本地方法InternalAlloc

        [System.Security.SecurityCritical]  // auto-generated
        [MethodImplAttribute(MethodImplOptions.InternalCall)]
        [ResourceExposure(ResourceScope.None)]
        internal static extern IntPtr InternalAlloc(Object value, GCHandleType type);
        

        其中InternalAlloc是CLR公共库的代码,其中就有这里核心的一个部分,CLR 垃圾回收器

        其中InternalAlloc的核心就是这一句:hnd = GetAppDomain()->CreateTypedHandle(objRef, type);

        依次调用ObjectHandle::CreateTypedHandle-> HandleTable::HndCreateHandle-> HandleTableCache->TableAllocSingleHandleFromCache,如果缓存堆中存在则返回,不存在则分配,这里方法调用的时候我已经new了这个对象了,所以对象是存在的,存在会返回这个对象的IntPtr。在托管堆中发生的唯一分配是IntPtr,它保存指向表中地址的指针。所以我疯狂print的都是这个指针的地址,所以我探究的也是这个intPtr的分配策略,当我明白这一点的时候,我就发现,诶嘿,我又可以水一篇C#GC探索的文章了,所以我跟到了CLR的库,开始研究CLR的GC原理,看看没有官方的解释和源码来论证我上述的猜想,所以...下期再见~

C#的内存分配探索

上一篇:Windows系统中R、RStudio安装问题解决之中文用户名


下一篇:win10实用软件推荐