虚拟字节增长 2 倍私有字节的原因可能是什么？
应用程序的虚拟字节增长为专用字节的 2 倍。
这是否表明内存泄漏？应用程序设计不好？
操作系统是 32 位，
欢迎任何想法。 应用程序是流数据库。
An application's virtual bytes grow 2-times the private bytes.
does this indicate memory leak? bad application design?
OS is 32Bit
any thoughts are welcome.
application is stream database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
碎片化。
如果您分配以下内存块：
，然后释放 8KB 的内存块，您的应用程序将拥有 32 KB 的专用字节，但有 40 KB 字节的虚拟内存，这实际上是有史以来最高的虚拟内存地址已被您的进程使用（为了简单起见，忽略其他内存部分）。
考虑（如果可能）使用另一个内存管理器。一些替代方案是：
第四种替代品是编写自己的内存管理器。这并不容易，但如果做得好，它可以带来很多好处。特别是对于某些利基或特殊应用程序，编写自己的内存管理器可能很有用。
Fragmentation.
If you allocate the following chunks of memory:
and you then free the chunk of 8KB, your application will have 32 KB of private bytes, but 40 KB bytes of virtual memory, which is actually the highest virtual memory address that has ever been in use by your process (ignoring the other memory parts for sake of simplicity).
Consider (if possible) using another memory manager. Some alternatives are:
A fourth alternative is to write your own memory manager. It's not that easy, but if done right, it can have quite some benefits. Especially for certain niche or special applications, writing your own memory manager can be useful.
如果应用程序仅分配堆，那么对我来说，这将是应用程序分配大量内存但从未真正触及它的标志。例如：
会吃掉16MB的虚拟内存。但只要应用程序不对内存块执行任何操作，操作系统就不会尝试将虚拟内存映射到 RAM。强制实际分配私有内存的最简单方法是 memset() 它：
或者两者兼而有之。或者两者都不是。
响应的较长变体：未知，取决于应用程序分配的内存、应用程序使用的其他资源、操作系统、硬件平台等。
如果不确定，请使用内存泄漏分析工具进行调查，例如 valgrind。阅读 SO 了解有关 C++ 中的内存泄漏分析的更多信息。
If application allocates only heap, then to me it would be the sign that application allocates lots of memory but never actually touches it. For example:
would eat up 16MB of virtual memory. But as long as application doesn't perform any actions with the memory block, OS wouldn't even attempt to map the virtual memory to the RAM. Simplest way to force the actual allocation of private memory is to memset() it:
Or both. Or neither.
The longer variant of the response: unknown, depends on what memory application allocates, what other resources application uses, OS, h/w platform, etc.
If unsure, use a memory leak analysis tools to investigate, e.g. valgrind. Read up SO for more information on memory leak analysis in C++.
内存分配会产生存储有关分配内容的管理信息的开销。如果您分配的缓冲区非常小，则额外信息可能占总数的很大一部分。这可能就是你所看到的。
Memory allocation has overhead to store management information about what was allocated. If you're allocating very small buffers the extra information can be a significant percentage of the total. That might be what you're seeing.
一种可能性是，如果您使用链接器选项 /STACK:reserve_bytes 为线程设置较大的堆栈保留大小，然后启动大量线程。
例如，如果您有 ATL 服务，则默认情况下它会自动启动 4*numberOfCores 单元消息调度线程。用 /STACK:12000000（12 MB）编译并链接这样一个服务，然后在 16 核服务器上运行它，它将启动 64 个线程，每个线程有 12MB 堆栈，立即消耗 768MB 虚拟地址空间，尽管实际提交内存可能会低很多。
One possibility is if you set a large stack reserve size for your threads with linker option /STACK:reserve_bytes and then you start a lot of threads.
For example, if you have an ATL service, it automatically starts 4*numberOfCores apartment message dispatching threads by default. Compile and link such a service with /STACK:12000000 (12 megabytes), then run it on a 16-core server and it will start 64 threads, each with a 12MB stack, immediately consuming 768MB of virtual address space, although the actual committed memory may be much lower.