Actor 模型的优缺点

并发程序一定避不开以下三个问题：

starvation, deadlock, and race conditions

饥饿，死锁，竞争

Limitations of the Actor-Based Model

The actor-based model makes it easy to program with isolated mutability, but it does have some limitations.

Actors run asynchronously but coordinate by passing messages. The unexpected failure of actors may result in starvation—one or more actors may be waiting for messages that would never arrive because of the failure. We must program defensively and handle exceptions within the actors and propagate error messages to actors awaiting a response.

Actors do not prevent deadlocks; it’s possible for two or more actors to wait on one another for messages. We have to design carefully to ensure that the coordination between actors doesn’t fall into a deadlock state. Also, we should use timeouts to ensure we don’t wait endlessly for a response from an actor.

Actors can handle only one message request at a time. So, both action messages and messages requesting a response or state run sequentially. This can result in lower concurrency for the tasks that are interested only in reading the value. It is better to design applications with coarse-grain messages instead of fine-grain messages. Also, we can reduce waits by de- signing with one-way “fire and forget” messages instead of two-way messages.

Not all applications are well-suited for an actor-based model. Actors serve well when we can divide the problem into parts that can run quite indepen- dently and need to communicate only sporadically. If frequent interaction is required or the parts or tasks need to coordinate to form a quorum, the actor-based model is not suitable. We may have to mix other concurrency models or consider significant redesign.



基于 Actor Model的优点：

Actors are single-threaded and communicate with each other by passing messages.

We learned that actors do the following:

Make it easy to work with isolated mutability

Eliminate synchronization concerns at its root

Provide efficient one-way messaging but also provide the less efficient send-and-wait facility

Are very scalable; while being single-threaded, they efficiently share a pool of threads

Allow us to send messages but also provide typed versions (in Akka) backed by interfaces

Allow us to coordinate with other actors using transactions

Although actors provide a powerful model, they also have limitations. There is potential for actor starvation and also deadlock if we’re not careful in de- signing with them. Also, we have to ensure that the messages are immutable.