一:背景
1. 讲故事
在.NET高级调试
的旅程中,我常常会与 Bitmap 短兵相接,它最大的一个危害就是会让程序抛出匪夷所思的 OutOfMemoryException
,也常常会让一些.NET开发者们陷入其中不能自拔,痛不欲生,基于此,这一篇我从dump分析的角度给大家深挖一下 Bitmap 背后的故事。
二:Bitmap 背后的故事
1. Bitmap 能吃多少内存
相信有很多朋友都知道 bitmap 吃的是非托管内存,但相信也有很多朋友不知道这玩意竟然能吃掉bitmap自身大小的几十倍,甚至上百倍。可能这么说有点抽象,举一个例子说明一下,用 chatgpt 生成的参考代码如下:
在 bitmap.Dispose();
之前加上一个 Console.ReadLine();
故意不销毁 bitmap 来观察下内存消耗,真是不看不知道,一看吓一跳,居然吃了高达 1.7G 的内存。
接下来按一下 Enter 观察一下 bitmap 在磁盘上的大小,居然小到无语的2M ,这差距咂舌的 1000 倍啊,截图如下:
这就是 bitmap 的恐怖之处,也是很多程序员疑惑的地方。
2. Bitmap 吃的是哪里的内存
纵然有很多朋友知道是非托管内存,但还是有必要用数据来展示一下,这个非常简单,可以用 !address -summary
观察下提交内存,用 !eeheap -gc
观察下托管堆即可。
从卦中可以清晰的看到 MEM_COMMIT=1.814 GB
同时 GC Committed Heap Size=2.8M
,妥妥的非托管泄漏。
3. 能找到 Bitmap 所属的内存段吗
要想知道 bitmap 所侵占的内存段,如果用 windbg 去调试的话,可以对 KERNELBASE!VirtualAlloc
下一个 bp 断点即可,参考如下:
但可惜的是你拿到的是 dump 文件,无法使用 bp 下断点,那怎么办呢?只要这辈子积攒的福报够多,自然不会有绝人之路,首先从托管类 Bitmap 上挖起。
从 Bitmap 的字段布局来是用 _nativeImage 字段来持有着对原生 bitmap 的引用,下面的截图也可以佐证。
说了这么多,其实我想表达的是什么呢?虽然我不知道 gdiplus 的底层源码,但有一点可以确认的是,VirtualAlloc 返回的 ptr 和 这里的 _nativeImage 肯定是有偏移关系的,有可能是一级关系,有可能是 二级关系,在我的内存地址视察下,总结如下:
- 在 Windows10 x64 环境下偏移为
+0x570
。 - 在 Windows10 x86 环境下偏移为
+0x2e8
。
接下来就可以在 windbg 中轻松做验证,先拦截 VirtualAlloc 找到大的地址段。
从卦中可以看到分配的地址段的首地址为 0000020759db0000
,解析来到 Bitmap._nativeImage+0x570
处做个验证即可,可以看到遥相呼应,输出如下:
三:总结
Bitmap使用不当危害巨大,所以一定要谨记 尽早释放
的原则,如果真的不幸被吃了很多内存,也一定要明白那些未知的大内存段是不是被 Bitmap 所关联,从而尽早的找到真正的祸根。