Akka Actors: How do they actually work

Table of contents

Reading Time: 2 minutes

You might have used akka actors for building concurrent and distributed systems. But do you know how actors actually works under the hood? So let us understand in this blog how akka actors actually work.

First of all, let us understand what are akka actors.

Introduction

Akka is an open-source library that helps to easily develop concurrent and distributed applications using Java or Scala by leveraging the Actor Model. It alleviates the developer from having to deal with explicit locking and thread management, making it easier to write correct concurrent and parallel systems.

Akka is a truly reactive framework because everything in the sense of sending and receiving a message to Actors, is lock-less, non-blocking IO, and asynchronous. Building application with Akka has several advantages like:

High performance – Akka delivers up to 50 million messages per second on commodity hardware having ~2.5 million Actors per GB of RAM.
Resilient by design – Akka system has self-healing properties for local and remote Actors.
Distributed and Elastic – Akka has all the mechanisms to scale Applications, such as cluster, load balancing, partitioning, and sharding.

How actors actually work?

An actor has the following things:

Mailbox: Whenever an actor receives a message, it stores that message inside the mailbox in the form of message queue.
Message handler: The message handler process the messages which are stored inside the mailbox one by one.

Communication

The communication with the actor takes places in the following ways:

When an actor receives a message, it enqueues that message in it’s mailbox. This process is thread safe and akka manages it behind the scenes.
An actor is basically a data structure which needs a thread to execute any code. So akka schedules a thread to run the actor.
Then the messages are extracted from the mailbox, in order.
The thread invokes the message handler for each message for it’s processing. During this message processing, actor might change it’s state or send messages to other actors.
After that, the message is simply discarded and this whole process happens a bunch of times.
At some point, the akka thread scheduler decides to unschedule this actor for execution at which point the thread releases the control of this actor.

Guarantees

Only one thread operates on an actor at any time which effectively makes it single-threaded. We don’t need to do any synchronization over the actor’s state because only one thread has access to the actor’s internal state at any time.
The thread may never release the actor in the middle of processing messages. So processing messages is atomic.
The receiving actor receives a message at most once. It will never receive duplicates.
For any sender-receiver pair, the message order is maintained. What this means is that if there are 2 actors – Harry and Jack. Harry sends 2 messages – A and then B. Then Jack will always receive message A before message B. Jack may also receive messages from other actors and those might be intermingled between A and B but the order – A then B is always guaranteed.