_aligned_malloc比new更适合SIMD/GPU数据传输，因其支持显式指定对齐（如AVX-512需64字节），且分配地址本身满足对齐；但必须配对使用_aligned_free释放，不可用delete或free，否则导致堆损坏或内存泄漏。
为什么 _aligned_malloc 比 new 更适合 SIMD 或 GPU 数据传输
因为 new 只保证基本对齐（通常是 8 或 16 字节），而 AVX-512 需要 64 字节对齐，某些 DMA 通道甚至要求 4096 字节；_aligned_malloc 允许你显式指定对齐边界，且分配的内存块地址本身满足该对齐——这点比用 std::aligned_alloc（C++17）更早可用、Windows 上更稳定。
注意：它分配的内存**不能用 delete 释放**，必须配对使用 _aligned_free，否则会触发堆损坏或静默崩溃。
-
_aligned_malloc是 Windows CRT 提供的函数，头文件为<malloc.h></malloc.h> - Linux/macOS 不支持，跨平台项目请改用
std::aligned_alloc或posix_memalign - 对齐值必须是 2 的幂，且 ≥
sizeof(void*)（通常 ≥ 8）；传入 32 却得到 64 对齐？那是正常行为——底层可能向上取整
_aligned_malloc 的典型误用与内存泄漏风险
最常见错误是把返回指针当普通指针处理：直接赋给 std::vector<float>*</float>、传进 std::unique_ptr 默认删除器、或在析构中调用 delete[]。
正确做法是封装成 RAII 类型，或用自定义删除器：
立即学习“C++免费学习笔记（深入）”；
auto ptr = static_cast<float*>(_aligned_malloc(1024 * sizeof(float), 32)); // ... 使用 _aligned_free(ptr); // 必须用这个，不是 free() 也不是 delete[]
- 忘记配对调用
_aligned_free→ 内存泄漏，且后续_aligned_malloc可能失败（CRT 内部计数异常） - 用
free()释放 → Windows 下大概率触发断言或 heap corruption - 对齐值传错（如传 12）→ 返回
nullptr，但不报错，容易被忽略 - 分配 0 字节 → 行为未定义，部分 CRT 版本返回
nullptr，部分返回非法地址
写一个支持对齐的 C++ 自定义分配器模板
目标是让 std::vector<int aligned_allocator>></int> 能自动用 64 字节对齐分配内部缓冲区。关键点在于：标准分配器接口不暴露对齐参数，所以得重载 allocate 并内部调用 _aligned_malloc。
注意：MSVC 的 std::allocator_traits 对 allocate 的对齐支持较弱，所以不要依赖 allocate(size, hint) 的 hint 参数，直接在 allocate 里硬编码对齐值更可靠。
- 模板参数
Alignment必须是编译期常量（static constexpr size_t） -
deallocate必须调用_aligned_free，且不能对ptr做任何偏移计算（_aligned_malloc返回的就是对齐起始地址） - 不要尝试在
construct/destroy里做额外对齐检查——对象布局由编译器控制，分配器只管内存块对齐
template <typename T, size_t Alignment = 16>
struct aligned_allocator {
using value_type = T;
T* allocate(size_t n) {
if (n == 0) return nullptr;
auto ptr = _aligned_malloc(n * sizeof(T), Alignment);
if (!ptr) throw std::bad_alloc{};
return static_cast<T*>(ptr);
}
void deallocate(T* ptr, size_t) noexcept {
_aligned_free(ptr);
}
};
AVX 加速场景下，对齐分配器的实际性能差异
在循环中对 1024 个 float 执行 _mm256_load_ps 时，若数据未 32 字节对齐，CPU 会触发 #GP 异常或降级为慢路径（跨缓存行加载），实测吞吐下降 3–5 倍。
但要注意：对齐只是必要条件，不是充分条件。即使用了 aligned_allocator<float></float>，仍需确保：
- 访问时地址确实是 32 字节对齐的（
reinterpret_cast<uintptr_t>(ptr) % 32 == 0</uintptr_t>） - 避免 vectorizer 优化绕过你的分配器（比如用
std::vector::reserve后再 push_back，底层仍走普通 new） - 调试时用
__builtin_assume_aligned（GCC/Clang）或__assume（MSVC）提示编译器对齐属性，否则 auto-vectorization 可能失效
真正卡住性能的，往往不是分配器本身，而是你没验证最终运行时地址是否对齐，或者忘了关掉编译器的“松散对齐”优化选项（如 MSVC 的 /Qvec-）。
