第4章高性能内存管理

4. 高性能内存管理：对象池技术、内存对齐、缓存行填充、减少GC压力

做量化交易系统，说白了就是跟时间赛跑。订单簿每秒要处理几万甚至几十万笔数据，内存管理稍有不慎，延迟就上去了。我个人习惯把内存管理看作系统的「地基」——地基不稳，上层再漂亮的算法也是白搭。

这一章，咱们聊聊四个实战中绕不开的话题：对象池、内存对齐、缓存行填充，还有怎么减少GC压力。嗯，每个点我都踩过坑，咱们一个一个说。

4.1 对象池技术：别让GC拖你后腿

先问个问题：订单簿里频繁创建和销毁对象，会发生什么？

GC（垃圾回收）会频繁触发。尤其是在Java或C#这类带GC的语言里，大量短生命周期对象会让GC像抽风一样反复工作。我见过一个系统，GC暂停时间占了总运行时间的15%——这还做什么高频交易？

对象池的核心思想很简单：用完了别扔，洗干净再用。

关键点：对象池适合管理那些创建成本高、复用频率高的对象。比如订单簿里的Order、Trade、Tick等数据结构。

我曾经接手过一个项目，订单簿每毫秒要处理上千笔订单。原始代码里每个订单都new一次，GC压力巨大。改成对象池后，GC暂停时间从15%降到了不到2%。

来看一个简单的对象池实现（Java示例）：

public class OrderPool {
    private final Queue<Order> pool = new ConcurrentLinkedQueue<>();
    private final int maxSize;

    public OrderPool(int maxSize) {
        this.maxSize = maxSize;
        // 预分配对象
        for (int i = 0; i < maxSize; i++) {
            pool.offer(new Order());
        }
    }

    public Order borrow() {
        Order order = pool.poll();
        if (order == null) {
            order = new Order(); // 池空了，临时创建
        }
        return order;
    }

    public void release(Order order) {
        order.reset(); // 重置状态
        if (pool.size() < maxSize) {
            pool.offer(order);
        }
    }
}

避坑指南：我曾经犯过一个错误——对象池里的对象没有正确重置状态。结果下一个线程拿到的是脏数据，查了半天bug。记住：release时一定要reset。

4.2 内存对齐：CPU喜欢整齐的数据

你想想看，CPU从内存读数据，一次读多少？通常是8字节（64位系统）。如果数据没对齐，CPU就得读两次，再拼起来。这不就慢了嘛。

内存对齐的原则：数据结构的起始地址，应该是其大小的整数倍。

举个例子，一个结构体包含一个int（4字节）和一个long（8字节）：

// 不对齐的布局
struct BadLayout {
    int a;      // 偏移0，占4字节
    long b;     // 偏移4，占8字节 —— 没对齐！
};

// 对齐后的布局
struct GoodLayout {
    int a;      // 偏移0，占4字节
    // 填充4字节
    long b;     // 偏移8，占8字节 —— 对齐了！
};

在C/C++里，可以用alignas关键字强制对齐。Java里可以用@Contended注解（JVM内部用）。

注意：内存对齐会浪费一些空间（填充字节），但换来的是访问速度。在量化交易系统里，这个取舍很值。我个人习惯用空间换时间，毕竟延迟才是第一敌人。

4.3 缓存行填充：别让伪共享毁了性能

现代CPU有多级缓存，缓存行（Cache Line）通常是64字节。如果两个线程修改的数据在同一个缓存行里，就会发生「伪共享」——明明改的是不同变量，却互相拖累。

为什么会这样？因为CPU缓存一致性协议（比如MESI）会把这个缓存行标记为「失效」，迫使其他核心重新加载。你想想看，两个线程各自改自己的数据，结果互相干扰，性能直接腰斩。

我在项目中遇到过这种情况：订单簿的买一价和卖一价，分别由两个线程更新。结果它们恰好在同一个缓存行里，性能惨不忍睹。后来加了填充，延迟降了40%。

来看一个缓存行填充的示例（Java）：

public class PaddedLong {
    // 填充64字节，避免伪共享
    public volatile long value = 0L;
    // 填充剩下的字节
    public long p1, p2, p3, p4, p5, p6, p7;
}

在Java 8之后，可以用@Contended注解，JVM会自动填充：

@Contended
public class ContendedLong {
    public volatile long value = 0L;
}

小技巧：如果你不确定是否需要缓存行填充，先跑个性能测试。我一般用JMH（Java Microbenchmark Harness）来测，数据说话最靠谱。

4.4 减少GC压力：让垃圾回收器歇着

GC是Java/C#等语言的老大难问题。在订单簿系统里，GC暂停哪怕1毫秒，都可能错过一笔交易。怎么减少GC压力？

核心思路就两条：

减少对象创建：能复用就复用，对象池就是干这个的。
使用值类型：在Java里可以用基本类型（int、long）代替包装类型（Integer、Long）。在C#里可以用struct代替class。

来看一个对比：

// 坏写法：频繁创建包装类型
Long sum = 0L;
for (int i = 0; i < 1000000; i++) {
    sum += i; // 每次都会创建新的Long对象
}

// 好写法：用基本类型
long sum = 0L;
for (int i = 0; i < 1000000; i++) {
    sum += i; // 没有对象创建
}

嗯，这里要注意：Java的自动装箱（Autoboxing）是个隐形杀手。你以为在操作基本类型，其实背后在疯狂创建对象。

实战建议：在订单簿的核心路径上，我禁止使用任何包装类型。所有价格、数量、时间戳都用long或int。字符串也尽量用byte数组代替。

另外，内存池化也是个好办法。比如用DirectBuffer（Java）或unsafe操作，直接管理堆外内存。这样GC完全管不到你，但代价是你要自己负责释放。

警告：堆外内存虽然能避免GC，但管理不当会导致内存泄漏。我曾经有个同事，用DirectBuffer忘了释放，结果系统跑了三天就OOM了。嗯，从那以后我每次分配堆外内存，都会在finally块里确保释放。

4.5 本章小结

咱们把四个技术点串起来看：

对象池解决的是「对象频繁创建」的问题
内存对齐解决的是「CPU访问效率」的问题
缓存行填充解决的是「多核竞争」的问题
减少GC压力解决的是「垃圾回收暂停」的问题

这四个点环环相扣。你想想看，如果只做对象池，但内存不对齐，CPU还是慢；如果只做对齐，但缓存行伪共享，多核性能还是上不去。所以，要一起上。

下面这张图，是我自己总结的内存优化全景图：

好了，这一章就到这里。记住：内存管理没有银弹，但对象池、内存对齐、缓存行填充、减少GC压力这四板斧，能帮你解决90%的性能问题。下一章咱们聊聊更进阶的话题——不过在那之前，先把这些基础打牢。

📚 课程目录

4. 高性能内存管理：对象池技术、内存对齐、缓存行填充、减少GC压力

4.1 对象池技术：别让GC拖你后腿

4.2 内存对齐：CPU喜欢整齐的数据

4.3 缓存行填充：别让伪共享毁了性能

4.4 减少GC压力：让垃圾回收器歇着

4.5 本章小结