- 论坛徽章:
- 2
|
回复 #13 HJLin 的帖子
原帖由 HJLin 于 2009-8-15 00:49 发表
内存没有一直增加,释放增加的不断过程。
那你也没什么好怀疑的了……
1. operator new, operator delete
上面测了。
2. allocator
虽然allocator调用op new, op delete的时机、次数未知, 但vector, string析构的时候, 调用deallocate却是一定的。
更上面那个117有关的, 也测了。
它们确实没有泄露, 只是可能没有归还而已。 c++真没动什么手脚……
原帖由 HJLin 于 2009-8-15 00:49 发表
getchar 没有没有关系,即使它可能会new空间的话,它自己也会释放它的!
我写getchar嘛 …… 为的是可以等待一下 ……
为什么你对getchar可以如此信任, 对c++ , operator new, operator delete, allocator 不信任呢 ……
它们都“释放”了的, 只是可能没归还而已。
原帖由 HJLin 于 2009-8-15 00:09 发表
减少峰值的话确实可以办到
要解决问题, 就只能这样。 强制归还也没用。
原帖由 HJLin 于 2009-8-15 00:09 发表
但是现在发现了问题。不仅仅是为了解决问题而解决问题。
我是比较想弄清底层运作的人了
就冲你这2句话, 我再多说几句 ……
win32下, 最底层的分配就是VirtualAlloc了。 以page大小的整数倍为单位。
类unix上我不清楚了。 mmap吗?
C库的malloc, calloc, realloc, free, 就是将这种整块整块的内存管理起来, 再小块小块分配给调用xalloc,的用户。
用户free(ptr)的时候, 并不一定能恰好使得ptr所在的page全部空闲, 这时候, 显然是不能将该page归还。
即使用户若干次使用free, 并且某次使用 free(p)时, p所在的page确实全部没有使用了, 该page可以归还给OS。
但C库不一定会这样做, 它可能只是标记该page未使用、不归还,并供以后使用。
或者, 再折中一点, 空闲page比较多, 甚至连续的时候, 考虑归还一部分。 (win32上比较麻烦, 分了保留与提交, 前者以64k为粒度,后者以page为粒度……)
所以fun返回调用的时候, 117M依然被“使用”, 它被某个层次的分配器"使用", 也许是allocator, 或者 op new, op delete, 或者 xalloc,free。
但没有"泄露", 依然被"管理"。 反复调用fun没有继续增长就可以说明。
所以, 如果lz想强制归还,要么, 去查你使用的crt是否提供了这种函数; 要么, 就自己实现分配器, 就保证能强制归还了(所以我说代价很高, 不值得这样做)。 |
|