每个进程都可以使用堆内存来存储和共享进程内的数据。编程中有一个规则，当我们在堆内存中占用一些空间时，需要在任务完成后释放它，否则会导致内存泄漏。
int *pIntPtr = new int;
.
.
.
delete pIntPtr;
我的问题是：堆内存是每个进程独立的吗？
如果是，
那么只有当进程处于运行状态时才可能出现内存泄漏。
如果不是，
那么这意味着操作系统能够在某个地方保留数据的内存。如果是这样的话，是否有一种方法可以让另一个进程访问这段内存？这也可以成为进程间通信的一种方式。
我认为我的问题的答案是“是”。请提供您宝贵的反馈意见。
在几乎所有当前使用的系统中，堆内存都是针对每个进程的。在没有受保护内存的旧系统上，堆内存是系统范围内共享的。(简而言之，这就是受保护内存所做的事情: 它使您的堆和栈对您的进程私有。)
因此，在任何现代系统上，如果进程在调用delete pIntPtr之前终止，pIntPtr仍将被释放(虽然它的析构函数不会被调用，因为int类型没有析构函数)。
请注意，受保护内存是实现细节，不是C++或C标准的特性。一个系统可以自由地在进程之间共享内存(现代系统之所以不这样做，是因为这是攻击者攻击的好方法。)
std::make_heap和相关的STL算法上下文中使用它。因此，这个正确的标准术语应该是“动态存储期”。因此，“堆”本身严格来说只是一个实现细节，而不是语言特性；当然，由此可以得出任何所述堆的属性也都是实现细节的结论。 - Pavel Minaevnew 使用。此外，可能存在全局堆（例如查看 Win32 GlobalAlloc() 函数家族），它在进程之间共享，在系统运行时持久存在，并且确实可用于进程间通信。brk和sbrk系统调用来从操作系统中分配更多内存以扩展堆。然后，一旦进程结束，所有这些内存都会被还给操作系统。有一些特殊用途的操作系统在进程退出时不会回收内存。如果你的目标是这样的操作系统，你可能已经知道了。
大多数系统不允许你访问另一个进程的内存，但同样存在一些独特的情况不是这样的。
C++标准处理这种情况的方式是不对未释放内存后退出会发生什么以及如果尝试访问不明确属于你的内存会发生什么做出任何声明。这就是“未定义行为”的本质，也是指针“无效”的含义核心。除了这两个问题之外，还有更多问题，但这两个问题起到了一定的作用。
从实际角度来看，你的问题的答案是肯定的。现代操作系统通常会在进程关闭时释放由该进程分配的内存。然而，依赖这种行为是一种非常糟糕的做法。即使我们可以确保操作系统总是以这种方式运行，代码也很脆弱。如果某个未能释放内存的函数突然被重新用于其他目的，它可能会导致应用程序级别的内存泄漏。
尽管如此，这个问题的性质和发布的示例要求我在道德上指出RAII给你和你的团队参考。
int *pIntPtr = new int;
...
delete pIntPtr;
这段代码存在内存泄漏的问题。如果 [...] 中出现任何异常，就会导致内存泄漏。有几种解决方案：
int *pIntPtr = 0;
try
{
pIntPtr = new int;
...
}
catch (...)
{
delete pIntPtr;
throw;
}
delete pIntPtr;
第二种解决方案使用nothrow（不一定比第一种更好，但允许在定义pIntPtr时进行合理的初始化）：
int *pIntPtr = new(nothrow) int;
if (pIntPtr)
{
try
{
...
}
catch (...)
{
delete pIntPtr;
throw;
}
delete pIntPtr;
}
还有一种简单的方法：
scoped_ptr<int> pIntPtr(new int);
...
通常情况下，当进程终止时，操作系统会回收任何泄漏的内存。
因此，我认为C++程序员可以不必显式释放在进程退出之前需要的任何内存；例如，进程中的任何“单例”通常都不会被显式释放。
尽管这种行为可能是特定于操作系统的（尽管它对于Windows和Linux等操作系统都是正确的），但这并不是C++标准的理论部分。