你要是随口答个 ，那可就掉坑里了。在x64环境下用VS一测， 稳稳地给你返回个24！惊不惊喜？意不意外？这多出来的10个字节可不是白给的，这就是"内存对齐"这位老铁在背后使劲儿。今儿个咱就把它扒个底儿掉，看看它到底是个啥规矩，又能给咱们的程序带来啥实在的好处。
一、内存对齐是个啥规矩？
说白了，内存对齐就是CPU这大爷在读取内存时的"臭脾气"。它不喜欢从任意地址开始拿数据，就爱从特定倍数的地址（比如4、8字节）开始干活。你要是没伺候好它，让它从个奇数地址或者不对齐的地址读取一个int或者double，它轻则给你掉速，重则在某些架构上（比如ARM）直接甩你个硬件异常，程序当场崩溃没商量。
编译器为了伺候好CPU这位爷，就定下了一套对齐的规矩。最基本的原则就是：每个成员的起始地址，必须是其自身大小或平台对齐系数（两者取较小值）的整数倍。 整个结构体的大小也得是其中最宽基本类型成员大小的整数倍。
咱们就拿开头的 开刀：
：1字节，从0地址开始放，没毛病。
：4字节。它得从4的整数倍地址开始。下一个可用地址是1，不行！编译器只能含泪在后面插入3个字节的"空洞"（Padding），让从地址4开始安家。
：1字节，紧跟着，放在地址8。
：8字节。这位爷得从8的整数倍地址开始。下一个地址是9，不行！继续在后面插7个字节的空洞，让从地址16开始。
这么一顿操作下来，自己1字节，补3字节空洞，占4字节，自己1字节，补7字节空洞，占8字节。1+3+4+1+7+8 = 24。结构体总大小24，也得是最宽基本类型(8字节)的整数倍，正好，齐活！
二、内存对齐带来的性能红利
你可能会嘀咕："这不纯纯浪费内存吗？" 兄弟，眼光放长远点，这在计算机科学里是典型的"空间换时间"。对齐带来的性能提升，那可是实实在在的：
访问速度起飞：CPU从对齐地址读取数据，通常一次总线事务就能搞定。要是数据没对齐，跨在了两个内存块上，CPU就得发起两次甚至更多次的内存访问，然后再像拼积木一样把数据拼起来，这速度能快得了吗？在高性能计算和游戏引擎里，这种损耗是绝对不能被接受的。
缓存命中率飙升：现代CPU严重依赖缓存。缓存是以"缓存行"（Cache Line，通常64字节）为单位加载的。如果一个紧挨着的热门数据因为没对齐，导致它和前面的被分割在两个不同的缓存行里，CPU要访问就可能得多加载一个缓存行。缓存就这么点大，这不光拖慢的访问，还可能把别的有用数据挤出去，造成缓存污染。
三、手动优化，榨干性能
编译器默认会按自己的规则对齐，但咱们老司机可以手动优化，在性能和内存之间找到最佳平衡点。
- 重排成员变量（最牛的一招）
这是成本最低、效果最显著的优化。只需要调整一下声明顺序，把尺寸大的成员往前放，或者仔细排列减少空洞。
把刚才的结构体改改：
你再算算：从0到7，从8到11（8是4的倍数），和紧挨着放12和13。现在总大小是14。为了满足整体是(8字节)的倍数，编译器在末尾补了2个字节，最终大小是16。
从24字节到16字节，内存节省了三分之一！访问效率还一点没丢。这一招，在需要实例化成千上万个结构体的场景（比如游戏对象、网络数据包）下，收益巨大。
- 使用编译器指令（按需使用）
有时候，比如需要与硬件寄存器映射或者网络协议这种严格按1字节布局的数据交互时，我们不需要对齐。
GCC/Clang: 用
MSVC: 用 和
但是！ 打包结构体要慎用。访问未对齐的成员可能导致性能下降，甚至在有些平台上引发错误。对于这种结构体，建议通过逐字节拷贝到对齐的变量后再进行计算。
四、总结与最佳实践
内存对齐不是敌人，而是并肩作战的伙伴。吃透它，才能写出既快又省的高质量C++代码。
黄金法则：声明结构体/类时，有意识地将成员按类型尺寸从大到小排序，能极大减少内存空洞。
理解代价：明确使用 等指令取消对齐是以牺牲性能为代价的，仅在特定场景下使用。
利用工具：多使用 和 宏来观察和理解你的对象布局，做到心中有数。
保持可读性：在重排成员时，也要兼顾变量之间的逻辑关联性，别为了极致优化把代码搞得谁也看不懂。
好了，关于内存对齐的这点事儿，基本就唠明白了。下次写代码的时候，多留个心眼，让你的结构体站有站相，坐有坐相，CPU大爷一高兴，你的程序性能自然就蹭蹭往上窜！