关于MMGR的问题
我一直在查看 MMGR 的内存分配检查器，我有一些在互联网上其他地方没有看到的问题。
1) 有“报告尺寸”和“实际尺寸”。我明白“报告尺寸”是什么，它是新收到的尺寸，但是“实际尺寸”是什么？为什么会有差异？
2）日志记录真的安全吗？我看到日志记录发生在类的静态释放结束时，但是，这是否会产生内存泄漏的误报？ 2A）可以肯定的是，静态释放总是最后发生，对吗？
3）这段代码线程安全吗？如果不是，如何才能成为线程安全的呢？
I have been taking a look at MMGR for a memory allocation checker and I have a few questions that I don't see anywhere else on the internet.
1) There is a "reported size" and an "actual size". I understand what the "reported size" is, with it being the size that new receives, however, what is "actual size"? Why is there a difference?
2) Is the logging exactly safe? I see that the logging happens at the end of a static deallocation of a class, however, could this give a false positive of memory leaks?
2A) Just to be sure, static deallocations always happen last, right?
3) Is this code thread safe? If not, how can it become thread safe?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恐怕我没有任何MMGR经验，所以我只能回答你的第一个问题。
一些内存调试器提到报告（或请求）和实际分配大小的原因与内存分配器的工作方式有关。他们很少准确地分配所要求的大小 - 通常他们会多保留一点。有多种可能的原因：
对齐问题：我认为没有一个分配器可以在现代 32 位（或更多）系统上分配例如 3 个字节。该值将四舍五入到至少字大小的下一个倍数或4，具体取决于体系结构。
管理问题：某些分配器仅处理大小为 2 的幂的分配。所以你会得到 4、8、16、32、64、128、256 等字节的块。这在用户空间分配器中很少见，但在内核空间分配器中很常见。
普罗维登斯：一些分配器每次都会分配多一点，以应对可能的重新分配。
无论如何，保留的内存通常会比请求的数量多一些，因此存在两个数字。
I'm afraid I do not have any experience with MMGR, so I can only provide an answer for your first question.
The reason some memory debuggers mention a reported (or requested) and an actual allocation size has to do with the way memory allocators work. They rarely allocate exactly the requested size - usually they reserve a bit more. There are various possible reasons:
Alignment issues: I don't think that there is an allocator that will allocate e.g. exactly 3 bytes on a modern 32-bit (or more) system. The value will be rounded to at least the next multiple of the word-size or 4, depending on the architecture.
Management issues: some allocators will only handle allocations sized to powers of two. So you get blocks of 4, 8, 16, 32, 64, 128, 256 etc bytes. This is rare in userspace allocators, but common in kernel-space ones.
Providence: Some allocators will allocate a bit more each time in anticipation of a possible reallocation.
In any case, the reserved memory will often be somewhat more than the amount requested, hence the existence of two numbers.