一个关于LOH的有趣发现

[newxdlysk]

这两天在用windbg查内存问题的时候发现一个和概念不匹配的地方。
从现有的.net相关资料来看，我们知道分配在LOH上的对象必须大于85000byte。
但是实际上呢？

不知道是我操作有误还是有其他说法哈。
反正分用不掉，先甩200分。

[娃都会打酱油了]

能用windbg的，对我来说都是牛人，这东西当初看了，实在搞不定，弄个版本都折腾死，然后各种指令格式多到死

[newxdlysk]

引用 1 楼 starfd 的回复:

能用windbg的，对我来说都是牛人，这东西当初看了，实在搞不定，弄个版本都折腾死，然后各种指令格式多到死

装B神器哈

[EnForGrass]

用这两个命名再查一下呢 查找一下占用内存大对象 !dumpheap -min 85000 -stat 根据这对象再查询一下它具体内存地址 !dumpheap -type XXX -min 85000

[newxdlysk]

引用 3 楼 Chinajiyong 的回复:

用这两个命名再查一下呢 查找一下占用内存大对象 !dumpheap -min 85000 -stat 根据这对象再查询一下它具体内存地址 !dumpheap -type XXX -min 85000

这样肯定查不出来小于85000的对象啦 群友提供了一个可能的答案 http://stackoverflow.com/questions/686950/large-object-heap-fragmentation 大致看了下，可能是.net的优化机制，比如拘留池中的字符串。有空再研究研究，欢迎补充。

[newxdlysk]

哎，不过就我目前看过的关于GC，LOH相关的文章都没提及过这个。CLR via C#也没有。

[EnForGrass]

引用 4 楼 newxdlysk 的回复:

[quote=引用 3 楼 Chinajiyong 的回复:] 用这两个命名再查一下呢 查找一下占用内存大对象 !dumpheap -min 85000 -stat 根据这对象再查询一下它具体内存地址 !dumpheap -type XXX -min 85000

这样肯定查不出来小于85000的对象啦 群友提供了一个可能的答案 http://stackoverflow.com/questions/686950/large-object-heap-fragmentation 大致看了下，可能是.net的优化机制，比如拘留池中的字符串。有空再研究研究，欢迎补充。[/quote] 额，大概说的都是GC，而且他们说的跟64 bit platforms和32 bit还有关，是值得去研究。 http://stackoverflow.com/questions/30361184/loh-fragmentation-2015-update