我有一个 .NET/ native C++ 应用程序。目前，C++ 代码在默认堆上分配内存，该堆在应用程序的生命周期内一直存在。基本上，函数/命令在 C++ 中执行，这会导致当前持久内存的分配/修改。我正在研究一种在执行过程中取消其中一个函数/命令的方法。我们有数百个这样的命令，其中许多是非常复杂的(遗留)代码。
我试图避免的蛮力方法是修改每个命令/函数以检查取消并进行所有适当的清理(释放堆内存)。我正在研究一种多线程方法，其中一个附加线程接收取消请求并终止命令执行线程。我希望使用 HeapCreate() (Win32) 在“私有(private)堆”上分配所有动态内存。这样，私有(private)堆可以被处理取消请求的线程销毁。但是，如果命令运行完成，我需要动态内存来保留。在这种情况下，我想在逻辑上等效于将私有(private)堆内存“移动”到默认/进程堆，而不会产生实际拷贝的成本。这有可能吗？这有意义吗？
或者，我认识到我可以为每个命令/函数执行(每个都是一个新线程)只拥有一个新的私有(private)堆。如果命令被取消，私有(private)堆可能会被销毁，或者如果命令完成，它会继续存在。无限增长的堆的数量是否有问题？我知道每个堆都有一些开销。我可能会遇到哪些限制？
我在 64 位 Windows 7 上运行，内存为 8GB(将其视为目标平台)。我正在使用的应用程序大约有 100 万个 SLOC(一半是 C++，一半是 C#)。我正在寻找有关私有(private)堆管理的任何经验/建议，或者只是我的解决方案的替代方案。
最佳答案
使用单独的进程而不是单独的线程可能会更好:
- 使用内存映射文件(即根本不是文件 - 只是交叉处理的共享内存)
- 杀死一个进程比杀死一个线程“更干净”
- 我认为你可以让共享内存在杀戮中“幸存”而无需移动 - 你映射/取消映射而不是移动
尽管您可能需要自己进行一些内存管理。
无论如何，值得研究。我正在研究将进程间内存用于其他一些事情，它有一些不寻常的属性(可以清楚地记忆起所有这些，那是不久前的事)，你也许可以利用它。
只是一个想法!
关于c++ - Win32 "move"能否堆分配内存？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2096897/