WCHAR内存分配疑问：calloc与make_unique的差异及分配方式影响

问题背景 #

我原本以为用calloc()分配内存会立刻占用操作系统内存，但实际观察发现操作系统和进程的已用内存都没变化；而用auto结合std::make_unique()时，确实会消耗当前进程的活跃内存。

想请教两个问题：

1. 上述几种内存分配方式（calloc()、new[]()、std::make_unique）的差异是什么？
2. 除了内存释放的问题外，进程采用的内存分配方式还有哪些其他影响？

附测试代码：

#include <iostream>
using namespace std;
int main()
{
wchar_t *asdf = (wchar_t*)calloc(10240000000, sizeof(wchar_t));

wchar_t *asdf2 = new WCHAR[10240000000]();

getchar();

auto dBuffer = std::make_unique <wchar_t[]>(640000000);  // 32-bit process can't use more than this

std::cout << "Hello World!\n";

getchar();
}

问题1：几种内存分配方式的差异 #

1. 内存分配与初始化逻辑 #

• calloc()：C标准库函数，分配指定大小内存后会将所有字节初始化为0。它底层调用操作系统虚拟内存接口，但现代操作系统采用延迟物理内存分配策略——仅在进程地址空间预留虚拟内存区域，不会立刻分配物理内存，只有向这块内存写入数据时，才会触发缺页中断，系统才会真正分配物理内存。你观察到内存无变化，就是因为只分配了虚拟地址空间，没有实际写入操作。
• new WCHAR[10240000000]()：C++带值初始化的数组new运算符，会将数组元素初始化为对应类型默认值（wchar_t为0）。底层通常基于malloc实现，同样依赖延迟分配机制，不会立刻占用物理内存。另外要注意：这行代码分配的是20GB左右内存，32位进程地址空间仅4GB，实际分配已失败（返回空指针），所以没占用任何内存。
• std::make_unique<wchar_t[]>(640000000)：C++11智能指针创建函数，本质封装了new[]行为，返回std::unique_ptr管理数组内存。你观察到内存消耗，是因为这次分配的约1.2GB在32位进程地址空间范围内，分配成功；后续cout输出或系统后台操作可能触发了内存写入，进而让系统分配了物理内存。

2. 内存所有权管理 #

• calloc和new返回裸指针，必须手动调用free或delete[]释放内存，遗漏就会造成内存泄漏。
• std::make_unique返回的unique_ptr依靠RAII机制，会在指针生命周期结束时自动调用delete[]释放内存，无需手动管理，从根源避免内存泄漏。

问题2：除内存释放外的其他影响 #

1. 性能差异 #

• 初始化开销：calloc、new[]()都会初始化内存，比不初始化的malloc或new[]（不带括号）多一层开销；若业务无需内存初始化，选择后者更高效。
• 智能指针开销：std::unique_ptr开启编译器优化后是零开销的，无额外性能负担；但误用shared_ptr这类智能指针，会有引用计数的维护开销。

2. 地址空间碎片化 #

像代码里的超大内存分配（20GB），即使分配失败，也会尝试在进程地址空间预留区域。频繁进行这类无效超大分配，会导致地址空间碎片化，后续正常内存分配可能因找不到连续空间而失败。

3. 异常安全性 #

• 裸指针（calloc/new）在异常场景下极易泄漏内存：比如new之后、delete之前抛出未捕获异常，内存会永久泄漏。
• std::make_unique是异常安全的：智能指针生命周期由栈管理，发生异常时栈展开会自动销毁指针，触发内存释放，避免泄漏。

4. 代码兼容性与风格 #

• calloc是C标准库函数，兼容C和C代码；new和std::make_unique是C特性，仅适用于C++环境。
• 使用智能指针的代码更符合现代C++风格，可读性和可维护性更高，减少手动管理内存的出错概率。

内容的提问来源于stack exchange，提问作者JeffR