disruptor笔记之八:知识点补充(终篇)

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos

内容:所有原创文章分类汇总及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;

《disruptor笔记》系列链接

快速入门

Disruptor类分析

环形队列的基础操作(不用Disruptor类)

事件消费知识点小结

事件消费实战

常见场景

等待策略

知识点补充(终篇)

本篇概览

本文是《disruptor笔记》系列的终篇,前面咱们看了那么多代码,也写了那么多代码,现在咱们去看几个知识点,在轻松的阅读过程中完成disruptor之旅;

要关注的知识点有以下四处:

伪共享

Translators

Lambda风格

清理数据

接下来开始逐个了解;

伪共享

下图是多核处理器的CPU缓存,可见每个核都有自己的L1和L2缓存,而L3缓存是共享的:

在这里插入图片描述

假设disruptor的Sequence是long型,那么一个生产者和一个消费者的disruptor应该有两个long型Sequence,在L1中缓存这两个数字时,因为每个缓存行大小是64字节,所以两个Sequence很有可能在一个缓存行中

此时如果程序修改了生产者Sequence的值,就会让L1上对应的缓存行失效,再从Main memory中读取最新的值,此时因为消费者Sequence也在同一个缓存行中,因此也被失效了,这就导致一个没有变化的值也被清理掉,还要再去Main memory中取一次,这是影响性能的行为

看到这里,聪明的您一定想到解决问题的思路:不要让两个Sequence在同一个缓存行中

具体的手段呢?您有没有联想到日常生活中的占座位,在身边座位放个背包,其他人就不能使用了(这是不文明行为,仅举例用)

实际上disruptor用的也是占座的套路,咱们来看看Sequence的源码就一目了然了,如下图所示,Sequence的值是Value对象的成员变量value:

// 父类, class LhsPadding { protected long p1, p2, p3, p4, p5, p6, p7; } class Value extends LhsPadding { protected volatile long value; } class RhsPadding extends Value { protected long p9, p10, p11, p12, p13, p14, p15; } public class Sequence extends RhsPadding { ...

类图如下,可见Value的父子类中都是占位的long型:

在这里插入图片描述

因此,Sequence对象有16个成员变量,在L1 cache中是下图的排列方式:

在这里插入图片描述

想像一下,L1 cache的缓存行,每64字节为一个,也就是说上面那一串,每八个就占据一个缓存行(每个long型8字节),于是就有以下三种排列的可能:

V出现在一个缓存行的首位;

V出现在一个缓存行的末尾;

V出现在一个缓存行的首位和末尾之间的其他六个位置之一;

也就是下图三种可能(U是L1 cache中的其他内容),可见不论哪种可能,V都能用P把自己所在缓存行全部占座,这样就不会出现两个Sequence出现在同一个缓存行的情况了:

在这里插入图片描述

Translators

Translators是个小的编程技巧,disruptor帮使用者做了些封装,让发布事件的代码更简洁;

打开disruptor-tutorials项目的consume-mode这个module,回顾一下,业务发布事件要调用的方法,在OrderEventProducer.java中:

public void onData(String content) { // ringBuffer是个队列,其next方法返回的是下最后一条记录之后的位置,这是个可用位置 long sequence = ringBuffer.next(); try { // sequence位置取出的事件是空事件 OrderEvent orderEvent = ringBuffer.get(sequence); // 空事件添加业务信息 orderEvent.setValue(content); } finally { // 发布 ringBuffer.publish(sequence); } }

上面的代码中,其实开发者最关注的是orderEvent.setValue(content)这部分,其他几行是我从官方demo抄的...

显然disruptor也发现了这个小问题,于是从3.0版本开始提供了EventTranslatorOneArg接口,开发者将业务逻辑放入放在此接口的实现类中,至于前面代码中的ringBuffer.next()、ringBuffer.get(sequence)这些,以及try-finally代码块这些东西统统都省去了,咱们可以将OrderEventProducer.java改造成一个新的类,代码如下,可见新增内部类EventTranslatorOneArg,里面是将数据转为事件的业务逻辑,对外提供调用的onData方法中,只需一行代码即可,和业务无关的代码全部省掉了:

package com.bolingcavalry.service; import com.lmax.disruptor.EventTranslatorOneArg; import com.lmax.disruptor.RingBuffer; public class OrderEventProducerWithTranslator { // 存储数据的环形队列 private final RingBuffer<OrderEvent> ringBuffer; public OrderEventProducerWithTranslator(RingBuffer<OrderEvent> ringBuffer) { this.ringBuffer = ringBuffer; } /** * 内部类 */ private static final EventTranslatorOneArg<OrderEvent, String> TRANSLATOR = new EventTranslatorOneArg<OrderEvent, String>() { @Override public void translateTo(OrderEvent event, long sequence, String arg0) { event.setValue(arg0); } }; public void onData(String content) { ringBuffer.publishEvent(TRANSLATOR, content); } }

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zggzsx.html