2、内存屏障与无锁队列：Disruptor模式在Tick流中的应用

各位好，我是老张。今天咱们聊点硬核的——内存屏障和无锁队列。

做高频Tick流处理，说白了就是跟时间赛跑。你想想看，一秒能来几千甚至几万笔Tick数据，传统加锁的方式根本扛不住。我早年做期货行情系统时，就吃过锁的亏——锁一加，延迟直接飙到微秒级，这在高频场景下简直是灾难。

那怎么办？无锁队列就是答案。而说到无锁队列，就绕不开Disruptor这个经典模式。

2.1 为什么需要无锁？

先说说锁的问题。传统队列用synchronized或ReentrantLock，线程间竞争锁时会发生上下文切换。一次切换大概几微秒，看起来不多，但Tick流每秒几千笔，累积下来延迟就爆炸了。

我遇到过最夸张的情况：某次行情峰值时，锁竞争导致队列写入延迟从2微秒飙升到200微秒。嗯，那笔交易直接滑点了好几个tick。

无锁队列的核心思路：不用锁，靠CPU原子指令和内存屏障来保证线程安全。说白了，就是让多个线程能同时读写，谁也不等谁。

2.2 内存屏障（Memory Barrier）原理

内存屏障这东西，很多同学觉得玄乎。其实说白了，它就是一道「指令墙」，用来控制CPU和编译器对指令的重排序。

为什么会重排序？因为CPU为了性能，会打乱指令执行顺序。单线程下没问题，但多线程下就出事了——你写的代码顺序是A然后B，但CPU可能先执行B再执行A。

我举个例子。假设两个线程共享一个变量flag和data：

// 线程1
data = 42;        // 普通写
flag = true;      // 普通写

// 线程2
if (flag) {       // 读flag
    int x = data; // 读data
}

没有内存屏障时，线程2可能看到flag为true，但data还是旧值。为什么？因为CPU把data的写操作重排序到了flag之后。

加上volatile关键字，就相当于插入了内存屏障：

volatile boolean flag = false;
int data = 0;

// 线程1
data = 42;
flag = true;  // volatile写：插入StoreStore屏障 + StoreLoad屏障

// 线程2
if (flag) {   // volatile读：插入LoadLoad屏障 + LoadStore屏障
    int x = data; // 保证能看到data=42
}

2.3 CAS与Volatile实战

CAS（Compare And Swap）是另一个关键武器。它是一条CPU原子指令，能做到「比较-交换」一步完成。

Java里对应的是AtomicInteger、AtomicReference这些类。底层靠的是Unsafe.compareAndSwapInt。

// 一个简单的无锁计数器
public class LockFreeCounter {
    private volatile int count = 0;
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long offset;
    
    static {
        try {
            offset = unsafe.objectFieldOffset(
                LockFreeCounter.class.getDeclaredField("count")
            );
        } catch (Exception e) {
            throw new Error(e);
        }
    }
    
    public void increment() {
        int current;
        do {
            current = unsafe.getIntVolatile(this, offset);
        } while (!unsafe.compareAndSwapInt(this, offset, current, current + 1));
    }
}

这里有个细节：volatile保证了count的可见性，CAS保证了原子性。两者配合，才能实现线程安全的无锁操作。

2.4 Disruptor模式在Tick流中的应用

Disruptor是LMAX公司开源的高性能无锁队列框架。它的核心设计思想：用环形缓冲区 + 序列号 + 内存屏障，替代传统锁队列。

我当年第一次看到Disruptor的架构图时，说实话没太看懂。后来自己动手实现了一个简化版，才真正理解它的精妙。

先看一张我画的架构图：

Disruptor的核心组件：

• Ring Buffer：预分配固定大小的数组，避免GC
• 序列号（Sequence）：用volatile + CAS实现的无锁计数器
• 生产者屏障：控制生产者写入，防止覆盖未消费的数据
• 消费者屏障：控制消费者读取，防止读到未写入的数据

来看一个简化版的Tick数据写入示例：

// 简化版Disruptor生产者
public class TickProducer {
    private final RingBuffer<TickEvent> ringBuffer;
    private final Sequence producerSequence;
    
    public void publish(TickData tick) {
        // 1. 申请下一个槽位
        long sequence = producerSequence.incrementAndGet();
        
        // 2. 等待消费者处理完旧数据（防止覆盖）
        while (sequence - ringBuffer.getConsumerSequence() >= ringBuffer.getSize()) {
            // 忙等待，不阻塞
            Thread.yield();
        }
        
        // 3. 写入数据
        TickEvent event = ringBuffer.get(sequence);
        event.setData(tick);
        
        // 4. 发布（内存屏障保证写入可见）
        ringBuffer.publish(sequence);
    }
}

这里的关键点：生产者通过CAS获取序列号，通过内存屏障保证数据可见。整个过程没有锁，只有忙等待。

看到差距了吧？Disruptor的延迟只有传统队列的十分之一，吞吐量却高出5-10倍。这就是无锁的魅力。

2.5 实战中的坑与经验

最后分享几个我踩过的坑：

1. 伪共享（False Sharing）：Disruptor的序列号如果和别的变量在同一个缓存行，性能会暴跌。解决方案是用@Contended注解或手动填充缓存行。
2. 忙等待的CPU占用：无锁队列的忙等待会占满CPU。我建议在等待时加一点Thread.yield()或LockSupport.parkNanos(1)，平衡延迟和CPU使用。
3. 内存屏障的过度使用：volatile虽然好用，但别滥用。我见过有人把整个数据结构都声明成volatile，结果性能还不如加锁。记住：只在需要保证可见性的边界处使用。

好了，这一章就聊到这儿。内存屏障和无锁队列是高频Tick流处理的基石，理解了它们，你就能设计出真正低延迟的系统。

---