ong point = -1; // 前后都有7个元素填充，可以保证该核心变量独自在一个缓存行中
}
class RightPad extends RealValue
{
protected long p9, p10, p11, p12, p13, p14, p15;
}
public class CpuCachePadingValue extends RightPad
{
}
多线程编程中减少对锁的使用
Disruptor 整个框架的实现过程都在尽量的减少对锁的使用。比如生产者消费者中最容易出现争夺的，其实就是其中的消息队列。那么对于这个消息队列，我们可以采用的优化手段包括
- 使用循环数组代替队列，使用 CAS 算法来代替锁争夺；
- 消费者各自保存自己当前已经处理过的序号，而不是将这个序号的信息在队列中来存储，避免多线程争用。
针对上面的第二点详细展开说一下。一般来说，队列中信息的处理有两种不同的形式，第一种是这个消息需要所有消费者都处理完毕，才能认为是被使用好了。第二种是争夺到使用权的消费者线程进行消费，其他消费者线程争夺下一个。无论哪一种，都可以将消费者已经处理的序号保存在消费者线程内。而如果信息只允许被一个线程消费，可以在内部使用 CAS 来争夺。而生产者线程则需要持有消费者的类的信息，好用来判断所有消费者中消费的最小的序号，以避免在数据写入时覆盖了某个消费者尚未处理的数据信息。
指定消费者不同的处理顺序
Disruptor 可以让不同的消费者按照一定的顺序进行消息处理。比如一个消息，必须先经过日志处理 A1 保存日志，数据转换处理器 A2 清理才能最终被业务处理器 A3 进行实际的业务处理。而 A1 和 A2 并没有任何前后关系，但是 A3 必须等 A1 和 A2 都完成后才能进行。那么在实际编码时，可以让 A3 追踪 A1 和 A2 的处理序号。所有的消费者都在等待队列中可用序号达到自己需要的序号，一旦到达，排位靠后的处理器就循环检测排位靠前的处理器是否已经将数据处理完毕，处理完毕之后自己开始对数据的处理。
总结
Disruptor 这个框架在整个的编码过程中一直都在体现本地缓存数据，使用 CAS 来代替锁，尽可能无锁甚至无 CAS 这样的一种编程思想。根据官网的说明，这样的编码思想是在他们追求多线程以提高性能遇到失败后（项目复杂性、可测试性、维护性等），回过头思考在单线程下的性能可能性（单线程无锁必然是性能最高的，但是吞吐量就有待商榷）。