akka共享内存

时间:2020-12-13 05:13:43

Akka共享内存

Akka中的共享内存是基于Actor模型的,Actor模型提倡的是:通过通讯来实现共享内存,而不是用共享内存来实现通讯,这点是跟Java解决共享内存最大的区别,举个例子:
在Java中我们要去操作共享内存中数据时,每个线程都需要不断的获取共享内存的监视器锁,然后将操作后的数据暴露给其他线程访问使用,用共享内存来实现各个线程之间的通讯,而在Akka中我们可以将共享可变的变量作为一个Actor内部的状态,利用Actor模型本身串行处理消息的机制来保证变量的一致性。

当然要使用Akka中的机制也必须满足一下两条原则:

  • 消息的发送必须先于消息的接收
  • 同一个Actor对一条消息的处理先于下一条消息处理

第二个原则很好理解,就是上面我们说的Actor内部是串行处理消息,那我们来看看第一个原则,为什么要保证消息的发送先于消息的接收,是为了防止我们在创建消息的时候发生了不确定的错误,接收者将可能接收到不正确的消息,导致发生奇怪的异常。

通过前面的学习我们知道Actor是一种比线程更轻量级,抽象程度更高的一种结构,它帮我们规避了我们自己去操作线程,那么Akka底层到底是怎么帮我们去保证共享内存的一致性的呢?

一个Actor它可能会有很多线程同时向它发送消息,之前我们也说到Actor本身是串行处理的消息的,那它是如何保障这种机制的呢?

Mailbox

Mailbox在Actor模型是一个很重要的概念,我们都知道向一个Actor发送的消息首先都会被存储到它所对应的Mailbox中,那么我们先来看看MailBox的定义结构(本文所引用的代码都在akka.dispatch.Mailbox.scala中,有兴趣的同学也可以去研究一下):

private[akka] abstract class Mailbox(val messageQueue: MessageQueue)
extends ForkJoinTask[Unit] with SystemMessageQueue with Runnable {}

很清晰Mailbox内部维护了一个messageQueue这样的消息队列,并继承了Scala自身定义的ForkJoinTask任务执行类和我们很熟悉的Runnable接口,由此可以看出,Mailbox底层还是利用Java中的线程进行处理的。那么我们先来看看它的run方法:

override final def run(): Unit = {
try {
if (!isClosed) { //Volatile read, needed here
processAllSystemMessages() //First, deal with any system messages
processMailbox() //Then deal with messages
}
} finally {
setAsIdle() //Volatile write, needed here
dispatcher.registerForExecution(this, false, false)
}
}

为了配合理解,我们这里先来看一下定义:

@inline
final def currentStatus: Mailbox.Status = Unsafe.instance.getIntVolatile(this, AbstractMailbox.mailboxStatusOffset) @inline
final def isClosed: Boolean = currentStatus == Closed

这里我们可以看出Mailbox本身会维护一个状态Mailbox.Status,是一个Int变量,而且是可变的,并且用到volatile来保证了它的可见性:

@volatile
protected var _statusDoNotCallMeDirectly: Status = _ //0 by default

现在我们在回去看上面的代码,run方法的执行过程,首先它会去读取MailBox此时的状态,因为是一个Volatile read,所以能保证读取到的是最新的值,然后它会先处理任何的系统消息,这部分不需要我们太过关心,之后便是执行我们发送的消息,这里我们需要详细看一下processMailbox()的实现:


@tailrec private final def processMailbox(
left: Int = java.lang.Math.max(dispatcher.throughput, 1),
deadlineNs: Long = if (dispatcher.isThroughputDeadlineTimeDefined == true) System.nanoTime + dispatcher.throughputDeadlineTime.toNanos else 0L): Unit =
if (shouldProcessMessage) {
val next = dequeue() //去出下一条消息
if (next ne null) {
if (Mailbox.debug) println(actor.self + " processing message " + next)
actor invoke next
if (Thread.interrupted())
throw new InterruptedException("Interrupted while processing actor messages")
processAllSystemMessages()
if ((left > 1) && ((dispatcher.isThroughputDeadlineTimeDefined == false) || (System.nanoTime - deadlineNs) < 0))
processMailbox(left - 1, deadlineNs) //递归处理下一条消息
}
}

从上述代码中我们可以清晰的看到,当满足消息处理的情况下就会进行消息处理,从消息队列列取出下一条消息就是上面的dequeue(),然后将消息发给具体的Actor进行处理,接下去又是处理系统消息,然后判断是否还有满足情况需要下一条消息,若有则再次进行处理,可以看成一个递归操作,@tailrec也说明了这一点,它表示的是让编译器进行尾递归优化。

现在我们来看一下一条消息从发送到最终处理在Akka中到底是怎么执行的,下面的内容是我通过阅读Akka源码加自身理解得出的,这里先画了一张流程图:

 
akka共享内存
actor-process.png

消息的大致流程我都在图中给出,还有一些细节,必须序列化消息,获取状态等就没有具体说明了,有兴趣的同学可以自己去阅读以下Akka的源码,个人觉得Akka的源码阅读性还是很好的,比如:

  • 基本没有方法超过20行
  • 不会有过多的注释,但关键部分会给出,更能加深自己的理解

当然也有一些困扰,我们在不了解各个类,接口之间的关系时,阅读体验就会变得很糟糕,当然我用IDEA很快就解决了这个问题。

我们这里来看看关键的部分:Actor是如何保证串行处理消息的?

上图中有一根判定,是否已有线程在执行任务?我们来看看这个判定的具体逻辑:

@tailrec
final def setAsScheduled(): Boolean = { //是否有线程正在调度执行该MailBox的任务
val s = currentStatus
/*
* Only try to add Scheduled bit if pure Open/Suspended, not Closed or with
* Scheduled bit already set.
*/
if ((s & shouldScheduleMask) != Open) false
else updateStatus(s, s | Scheduled) || setAsScheduled()
}

从注释和代码的逻辑上我们可以看出当已有线程在执行返回false,若没有则去更改状态为以调度,直到被其他线程抢占或者更改成功,其中updateStatus()是线程安全的,我们可以看一下它的实现,是一个CAS操作:

@inline
protected final def updateStatus(oldStatus: Status, newStatus: Status): Boolean =
Unsafe.instance.compareAndSwapInt(this, AbstractMailbox.mailboxStatusOffset, oldStatus, newStatus)

到这里我们应该可以大致清楚Actor内部是如何保证共享内存的一致性了,Actor接收消息是多线程的,但处理消息是单线程的,利用MailBox中的Status来保障这一机制。

总结

通过上面的内容我们可以总结出以下几点:

  • Akka并不是说用了什么特殊魔法来保证并发的,底层使用的还是Java和JVM的同步机制
  • Akka并没有使用任何的锁机制,这就避免了死锁的可能性
  • Akka并发执行的处理并没有使用线程切换,不仅提高了线程的使用效率,也大大减少了线程切换消耗
  • Akka为我们提供了更高层次的并发抽象模型,让我们不必关心底层的实现,只需着重实现业务逻辑就行,遵循它的规范,让框架帮我们处理一切难点吧

作者:三分青年
链接:https://www.jianshu.com/p/36eca0696940
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。