malloc/new 分配一千万 int 慢的主因是首次写入触发的按需清零引发大量缺页中断，而非分配本身；预触达内存、用 vector 构造函数初始化或 resize 显式赋值可提前绑定物理页。
malloc/new 分配一千万 int 为什么慢？
分配一千万个 int（约 40MB）本身不该明显卡顿，真正拖慢的往往不是分配动作，而是操作系统首次访问这些内存页时触发的「按需清零」（zero-fill-on-demand）。Linux 和 Windows 都会对新分配的虚拟内存页在第一次写入时才真正分配物理页并清零——这会引发大量缺页中断（page fault），尤其当连续写入时，表现就像“卡住”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
mmap(MAP_ANONYMOUS | MAP_POPULATE)（Linux）或VirtualAlloc(..., MEM_COMMIT | MEM_RESERVE)（Windows）预分配+预触达，绕过懒加载 - 若必须用
new，分配后立即用memset或循环写一次首尾几页（如前 4KB + 后 4KB），强制触发关键页的物理映射 - 避免在单次分配中混用不同生命周期的缓冲区——碎片化会导致后续大块分配更难找到连续虚拟地址空间
vector::reserve 不等于分配物理内存
std::vector<int>::reserve(10000000)</int> 只申请虚拟地址空间，不触碰物理页，后续 push_back 或 resize 才真正写入并触发缺页。很多人误以为 reserve 能“预热”，其实它对首次写入延迟毫无帮助。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 需要确定大小且不增删，直接用
std::vector<int> v(10000000)</int>—— 构造函数会调用fill初始化，等价于写一遍，完成物理页绑定 - 若初始化值无关紧要（比如后续全覆盖），改用
std::vector<int> v; v.resize(10000000, 0)</int>，显式指定初值可避免默认构造开销（int无构造函数，但语义清晰） - 不要对
vector做reserve后再data()直接裸写——未初始化内存未映射，访问即段错误
换 allocator 能不能提速？
标准 new 使用 libc 的 malloc，对单次大块分配已足够高效；自定义 allocator（如 boost::pool_allocator）主要优化小对象高频分配/释放场景，对一千万 int 这种单次大块几乎没收益，反而可能因额外间接跳转引入微小开销。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 确认瓶颈是否真在分配：用
perf record -e page-faults（Linux）或 Windows Performance Recorder 查看缺页数，若 >10M 次，说明是零页问题，不是 allocator 问题 - 若真要换，优先考虑
std::pmr::monotonic_buffer_resource（C++17），但它适合短生命周期批量分配，不适合长期持有的大数组 - 跨线程频繁分配？那该怀疑是锁竞争（glibc malloc 在多线程下有 per-thread cache，但首次仍需全局锁），此时改用
jemalloc或tcmalloc动态链接可改善
还有哪些容易被忽略的耗时点？
你以为在等 new 返回，其实可能卡在别处：编译器优化关了、调试器附加着、ASLR 关闭导致地址冲突重试、甚至磁盘 swap 活跃……
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 关掉调试器再测：VS 中确保是 Release +
/O2，GDB 下用set follow-fork-mode child并禁用handle SIGUSR1 nostop noprint类干扰信号 - 检查
/proc/sys/vm/swappiness（Linux），设为1减少 swap 倾向；Windows 检查系统属性 → 高级 → 性能设置 → 关闭视觉效果 - 用
clock_gettime(CLOCK_MONOTONIC, ...)精确测new前后时间，排除前后逻辑干扰；别信std::chrono::steady_clock在某些旧内核下的低精度
真正的大头从来不是「分配指令」本身，而是操作系统怎么兑现你这张内存支票——看清 page fault 的数量和模式，比换任何 C++ 抽象层都管用。
