std::atomic提供原子操作与内存序控制，确保线程安全；volatile仅禁用编译器优化，不保证原子性、同步或内存可见性，不能用于多线程同步。
std::atomic 不是万能锁，volatile 更不是线程同步方案——C++ 内存模型不是“概念”，而是你每次调用 new、读写全局变量、启动线程时都在隐式依赖的执行契约。
栈区和堆区怎么分？别靠猜，看分配方式和生命周期
栈上变量（比如 int x = 42;、std::string s;）在函数进入时由编译器自动压栈，函数返回即销毁。它快、连续、无碎片，但空间极小（Linux 默认 8MB，Windows 常为 1MB），超限直接触发 stack overflow。
堆上内存（new int[1000000]、malloc(1024)）由程序员显式申请释放，大小只受虚拟内存限制，但分配慢、有碎片、易泄漏或野指针。
- 局部大数组（如
char buf[2*1024*1024]）必须放堆，否则一运行就崩 -
static局部变量看似在函数里，实则存在全局/静态区，生命周期贯穿程序全程 - 栈上对象构造/析构是自动的；堆上对象用
new会调构造函数，用malloc只得原始内存，不调构造——混用等于放弃对象语义
为什么 new 和 malloc 不能混着 delete 和 free？
new 是复合操作：先调 operator new 分配内存，再调类型构造函数初始化；delete 则先析构、再调 operator delete 释放。
立即学习“C++免费学习笔记（深入）”；
malloc 和 free 完全不感知类型，不调任何构造/析构——如果你用 malloc 分配了 std::vector 内存，又用 delete 释放，析构函数不会执行，内部堆内存永远泄漏。
-
new[]必须配delete[]：前者记录元素个数以便逐个析构，后者依赖该记录；错配会导致部分析构、内存未清空 -
new (std::nothrow) T返回nullptr而非抛异常，但构造失败仍会自动调operator delete回滚——这是new表达式的内建保障，malloc没这机制
结构体大小为什么不是成员之和？对齐规则才是真相
结构体 struct { char a; int b; } 在 x86-64 上占 8 字节，不是 5 字节——因为 int 要求 4 字节对齐，编译器在 a 后插入 3 字节填充（padding），使 b 地址能被 4 整除。
整个结构体的对齐值（alignof）取其成员中最大 alignof，比如含 double（alignof=8）或指针（alignof=8）的 struct，自身也按 8 对齐。
- 成员顺序影响体积：把大类型（
long long、指针）放前面，小类型（char、bool）集中放后面，可显著减少 padding -
#pragma pack(1)可禁用填充，但可能引发未对齐访问——ARM/RISC-V 上直接SIGBUS，x86-64 虽能跑但慢 2–3 倍 - 跨平台二进制通信（如网络协议、文件格式）必须显式控制布局，否则
sizeof和字段偏移在不同编译器下可能不一致
std::atomic 的内存序（memory order）选错会怎样？
默认 std::memory_order_seq_cst 最安全但最重；但若只用于标志位（如 ready_flag），用 std::memory_order_acquire / std::memory_order_release 就够了——它禁止编译器/CPU 把相关读写重排到屏障外，却不限制无关操作。
用错的典型表现：一个线程写 data 后设 ready = true，另一个线程看到 ready == true 却读到未初始化的 data——这就是没用 release + acquire 配对导致的可见性失效。
-
std::atomic<bool></bool>本身保证原子性，但不保证其他变量的同步；同步靠的是内存序约束的“操作边界” -
volatile对多线程完全无效：它只禁用编译器优化，不影响 CPU 乱序或缓存一致性 - 调试时加
std::this_thread::yield()或短 sleep 可能“掩盖”问题，但本质是未定义行为，换 CPU 或编译器版本就暴露
真正难的不是记住五区划分，而是当你在写一个跨线程共享的 std::shared_ptr 缓存、或调试一个偶发的 double-free、或对接硬件寄存器映射内存时，要本能反应出：这块内存落在哪区？谁负责释放？对齐是否满足？它的修改对其他核是否可见？——这些判断，没有一行代码能绕过去。
