Multi-thread v.s. Actor Models in Concurrency

The common technique for coordinating concurrent tasks takes the form of shared, mutable data structures and locking mechanisms to only allow a single caller in a flow of execution to change the shared structure at any one time.
However, these techniques prove to be difficult to scale. The problem is even more pronounced when multiple, independent machines are involved — locks and shared memory in the form described above are simply not feasible across systems.

We can group approaches used for coordinating concurrent operations in two broad camps: 

• uses locks to manage access to shared memory-based data structures or other shared resources; 
• builds on the idea of message passing. 

Thread-based Model

This approach relies on some shared state or resources that must be restricted to only be accessed by any one given thread of control at a time. java.util.concurrent package is very low-level and requires very careful coding to use it effectively.

1. What scope to place our locks. 

Locking the whole structure is a bad idea. To be clear, this is due to the bottleneck around this structure anytime a thread needs to interact with it. Unfortunately, making the locks too fine-grained results in far too much resource consumption, since the system has to manage the locking and unlocking.

2. There's the issue of lock contention and deadlock or, often worse, livelock.

One solution for deadlock is to enforce predefined ordering for any lock acquisitions -- but they usually end up being cumbersome to manage and maintain.

Actor Model

1. The primary entity of this model are these artifacts called actors, as the name implies. An actor is just a single entity, which interacts with other actors entirely via message passing. 

2. Each actor has a mailbox, which stores any messages it has not yet processed. The actor is responsible for defining what behavior will be executed when it receives a given message, but it can also, on receipt of a message, choose to change that behavior for subsequent messages. 

An actor is solely responsible for its state and this state cannot be changed directly by anything external to the actor. State changes can happen based upon messages that have been received, but the actor maintains that responsibility.

3. Each actor, while it's handling a single message and executing any behaviour defined upon receipt of that message, is working in a sequential manner. Further, it processes each message in the order in which they arrive in its mailbox, one message at a time. At any given time; however, a number of different actors can be executing their behaviours.

4. Another property of actors is that they are never referenced directly. Each actor is given an address that is used to send messages to it. For an actor to send a message to another actor, it must know that other actors address. Actors never reference each other directly, but only through these addresses.

5. The final characteristic of actors is that they can create other actors. This gives you enormous power to create complex systems of actors. In fact, it is quite common to have a hierarchy of actors where one top level actor acts as the initial starting point for your system, that is responsible for starting up other actors needed to express the remaining functionality you need.

Akka
Akka builds on the actor model, which helps us by modelling interaction between components as sequences of message passing, allows us to structure behaviors between components in a very fluid manner.
Further, it is built on the assumption that failures will occur and therefore presents us with supervisors that help your system to self-heal.
Finally, it gives us easy access to flexible routing and dispatching logic to make distributing our application across multiple systems convenient and natural.

Actors in Akka are very lightweight. The memory usage of a single instance is on the order of a few hundred bytes (less than 600).
Akka organizes actors into hierarchies, referred to as actor systems. To begin the life of any actor, you must first obtain a reference to the ActorSystem upon which all actors reside. At the top level of the system, we have three actors called guardians. 

There are important reasons Akka structures actors into these hierarchies. The first reason is for fault-tolerance. Akka includes a supervision system that allows each parent actor to determine a course of action when a child actor experiences a failure (that is, throws an exception). The choices, when this happens are: restart the child, resume the child, terminate the child, and escalate the failure to the next parent.