Akka Java 2.3.6 开发文档：低版本 JDK 支持

需积分: 5 112 浏览量更新于2024-07-19 收藏 1.72MB PDF 举报

"AkkaJava PDF Doc 是Akka V2.3.6版本的官方Java接口开发文档，适用于使用JDK1.6的旧系统开发和维护。文档包含了Akka的基本介绍、通用概念、演员（Actor）系统、故障容忍、调度器、邮箱、路由、有限状态机、持久化、测试等内容，以及对Java lambda支持的演员、故障容忍、FSM和持久化的讲解，还有关于Futures和Agents的使用指南。" **Akka** 是一个用Scala编写的开源框架，它提供了构建分布式、高并发、容错的应用程序的能力。在Java平台上，Akka提供了丰富的API来简化并发编程。 ### 1. Akka简介 - **什么是Akka？** Akka是一个基于actor模型的工具包和运行时，用于构建高度可扩展、反应式的应用。它鼓励使用“告诉”而不是“询问”的通信方式，以避免阻塞和同步问题。 - **为什么选择Akka？** Akka通过提供内置的故障恢复、消息传递和并发机制，使开发者能够更容易地构建可靠和可扩展的系统。 - **入门与Hello World** 文档中的例子展示了如何创建和交互基本的Actor，以快速理解Akka的工作原理。 ### 2. 通用概念 - **术语与概念** Akka的核心概念包括Actor、ActorSystem、路径和地址等。 - **ActorSystem** 是Akka应用程序的顶级容器，负责管理Actor生命周期和资源。 - **什么是Actor？** Actor是Akka的基础单元，它们是独立执行的实体，通过异步消息传递进行通信，每个Actor都有自己的邮箱和状态。 - **监督与监控** Akka引入了监督策略，允许Actor在出错时自我修复或重启，以实现容错。 - **地址和路径** 演员可以通过路径唯一标识，这使得它们可以在分布式环境中被定位和通信。 - **位置透明性** Akka支持位置透明性，意味着Actor的网络位置对使用者来说是隐藏的，简化了分布式系统的开发。 - **内存模型** Akka遵循Java内存模型，确保在多线程环境下的正确性。 - **消息传递可靠性** Akka提供了不同级别的消息传递可靠性，如At-Least-Once和Exactly-Once。 ### 3. Actors - **Actor** 部分详细介绍了如何创建、配置和使用Actor，包括其行为定义、消息处理和生命周期管理。 - **Typed Actors** 提供了一种类型安全的方式来与Actor交互，增强了代码的可读性和安全性。 - **故障容忍** 讲述了如何设置和使用监督策略，以及如何处理Actor的故障。 - **Dispatchers** 详细介绍了如何配置和选择不同的调度器来处理Actor的消息，如Dispatcher、BalancingDispatcher等。 - **Mailboxes** 是Actor接收消息的队列，可以定制以满足特定性能需求。 - **Routing** 说明了如何通过路由器将消息批量发送给多个Actor，如BroadcastRouter、RoundRobinRouter等。 - **有限状态机（FSM）** 展示了如何构建和管理状态转换的Actor。 - **持久化** 描述了如何使用Akka的持久化功能，以便在系统崩溃后恢复Actor的状态。 ### 4. Java Lambda支持的Actors 这部分针对使用Java 8及以上版本，利用Lambda表达式简化Actor的创建和交互，同时涵盖故障容忍、FSM和持久化。 ### 5. Futures和Agents - **Futures** 提供了一种异步编程模型，允许在操作完成时进行回调。 - **Agents** 是一种简单的并发数据结构，用于线程安全的数据存储和更新。 ### 6. 网络（未完整展示）这部分可能涵盖了Akka的网络通信能力，如远程Actor、集群和TCP/UDP支持。 AkkaJava PDF Doc 提供了全面的指导，帮助开发者理解和利用Akka构建健壮、分布式的Java应用程序。

Akka Java Documentation, Release 2.3.16

The ﬁrst possibility is especially well-suited for resources which are single-threaded in nature, like database han-

dles which traditionally can only execute one outstanding query at a time and use internal synchronization to

ensure this. A common pattern is to create a router for N actors, each of which wraps a single DB connection and

handles queries as sent to the router. The number N must then be tuned for maximum throughput, which will vary

depending on which DBMS is deployed on what hardware.

Note: Conﬁguring thread pools is a task best delegated to Akka, simply conﬁgure in the application.conf

and instantiate through an ActorSystem [Java, Scala]

2.2.5 What you should not concern yourself with

An actor system manages the resources it is conﬁgured to use in order to run the actors which it contains. There

may be millions of actors within one such system, after all the mantra is to view them as abundant and they

weigh in at an overhead of only roughly 300 bytes per instance. Naturally, the exact order in which messages are

processed in large systems is not controllable by the application author, but this is also not intended. Take a step

back and relax while Akka does the heavy lifting under the hood.

2.3 What is an Actor?

The previous section about Actor Systems explained how actors form hierarchies and are the smallest unit when

building an application. This section looks at one such actor in isolation, explaining the concepts you encounter

while implementing it. For a more in depth reference with all the details please refer to Actors (Scala) and Untyped

Actors (Java).

An actor is a container for State, Behavior, a Mailbox, Children and a Supervisor Strategy. All of this is encapsu-

lated behind an Actor Reference. Finally, this happens When an Actor Terminates.

2.3.1 Actor Reference

As detailed below, an actor object needs to be shielded from the outside in order to beneﬁt from the actor model.

Therefore, actors are represented to the outside using actor references, which are objects that can be passed around

freely and without restriction. This split into inner and outer object enables transparency for all the desired

operations: restarting an actor without needing to update references elsewhere, placing the actual actor object on

remote hosts, sending messages to actors in completely different applications. But the most important aspect is

that it is not possible to look inside an actor and get hold of its state from the outside, unless the actor unwisely

publishes this information itself.

2.3.2 State

Actor objects will typically contain some variables which reﬂect possible states the actor may be in. This can be an

explicit state machine (e.g. using the fsm-scala module), or it could be a counter, set of listeners, pending requests,

etc. These data are what make an actor valuable, and they must be protected from corruption by other actors. The

good news is that Akka actors conceptually each have their own light-weight thread, which is completely shielded

from the rest of the system. This means that instead of having to synchronize access using locks you can just write

your actor code without worrying about concurrency at all.

Behind the scenes Akka will run sets of actors on sets of real threads, where typically many actors share one

thread, and subsequent invocations of one actor may end up being processed on different threads. Akka ensures

that this implementation detail does not affect the single-threadedness of handling the actor’s state.

Because the internal state is vital to an actor’s operations, having inconsistent state is fatal. Thus, when the actor

fails and is restarted by its supervisor, the state will be created from scratch, like upon ﬁrst creating the actor. This

is to enable the ability of self-healing of the system.

2.3. What is an Actor? 13

Akka Java Documentation, Release 2.3.16

Optionally, an actor’s state can be automatically recovered to the state before a restart by persisting received

messages and replaying them after restart (see persistence-scala).

2.3.3 Behavior

Every time a message is processed, it is matched against the current behavior of the actor. Behavior means a

function which deﬁnes the actions to be taken in reaction to the message at that point in time, say forward a

request if the client is authorized, deny it otherwise. This behavior may change over time, e.g. because different

clients obtain authorization over time, or because the actor may go into an “out-of-service” mode and later come

back. These changes are achieved by either encoding them in state variables which are read from the behavior

logic, or the function itself may be swapped out at runtime, see the become and unbecome operations. However,

the initial behavior deﬁned during construction of the actor object is special in the sense that a restart of the actor

will reset its behavior to this initial one.

2.3.4 Mailbox

An actor’s purpose is the processing of messages, and these messages were sent to the actor from other actors (or

from outside the actor system). The piece which connects sender and receiver is the actor’s mailbox: each actor

has exactly one mailbox to which all senders enqueue their messages. Enqueuing happens in the time-order of

send operations, which means that messages sent from different actors may not have a deﬁned order at runtime

due to the apparent randomness of distributing actors across threads. Sending multiple messages to the same target

from the same actor, on the other hand, will enqueue them in the same order.

There are different mailbox implementations to choose from, the default being a FIFO: the order of the messages

processed by the actor matches the order in which they were enqueued. This is usually a good default, but

applications may need to prioritize some messages over others. In this case, a priority mailbox will enqueue not

always at the end but at a position as given by the message priority, which might even be at the front. While using

such a queue, the order of messages processed will naturally be deﬁned by the queue’s algorithm and in general

not be FIFO.

An important feature in which Akka differs from some other actor model implementations is that the current

behavior must always handle the next dequeued message, there is no scanning the mailbox for the next matching

one. Failure to handle a message will typically be treated as a failure, unless this behavior is overridden.

2.3.5 Children

Each actor is potentially a supervisor: if it creates children for delegating sub-tasks, it will automatically supervise

them. The list of children is maintained within the actor’s context and the actor has access to it. Modiﬁcations to

the list are done by creating (context.actorOf(...)) or stopping (context.stop(child)) children

and these actions are reﬂected immediately. The actual creation and termination actions happen behind the scenes

in an asynchronous way, so they do not “block” their supervisor.

2.3.6 Supervisor Strategy

The ﬁnal piece of an actor is its strategy for handling faults of its children. Fault handling is then done transparently

by Akka, applying one of the strategies described in Supervision and Monitoring for each incoming failure. As

this strategy is fundamental to how an actor system is structured, it cannot be changed once an actor has been

created.

Considering that there is only one such strategy for each actor, this means that if different strategies apply to

the various children of an actor, the children should be grouped beneath intermediate supervisors with matching

strategies, preferring once more the structuring of actor systems according to the splitting of tasks into sub-tasks.

2.3. What is an Actor? 14

Akka Java Documentation, Release 2.3.16

2.3.7 When an Actor Terminates

Once an actor terminates, i.e. fails in a way which is not handled by a restart, stops itself or is stopped by its

supervisor, it will free up its resources, draining all remaining messages from its mailbox into the system’s “dead

letter mailbox” which will forward them to the EventStream as DeadLetters. The mailbox is then replaced within

the actor reference with a system mailbox, redirecting all new messages to the EventStream as DeadLetters. This

is done on a best effort basis, though, so do not rely on it in order to construct “guaranteed delivery”.

The reason for not just silently dumping the messages was inspired by our tests: we register the TestEventLis-

tener on the event bus to which the dead letters are forwarded, and that will log a warning for every dead letter

received—this has been very helpful for deciphering test failures more quickly. It is conceivable that this feature

may also be of use for other purposes.

2.4 Supervision and Monitoring

This chapter outlines the concept behind supervision, the primitives offered and their semantics. For details on

how that translates into real code, please refer to the corresponding chapters for Scala and Java APIs.

2.4.1 What Supervision Means

As described in Actor Systems supervision describes a dependency relationship between actors: the supervisor

delegates tasks to subordinates and therefore must respond to their failures. When a subordinate detects a failure

(i.e. throws an exception), it suspends itself and all its subordinates and sends a message to its supervisor, signaling

failure. Depending on the nature of the work to be supervised and the nature of the failure, the supervisor has a

choice of the following four options:

1. Resume the subordinate, keeping its accumulated internal state

2. Restart the subordinate, clearing out its accumulated internal state

3. Stop the subordinate permanently

4. Escalate the failure, thereby failing itself

It is important to always view an actor as part of a supervision hierarchy, which explains the existence of the fourth

choice (as a supervisor also is subordinate to another supervisor higher up) and has implications on the ﬁrst three:

resuming an actor resumes all its subordinates, restarting an actor entails restarting all its subordinates (but see

below for more details), similarly terminating an actor will also terminate all its subordinates. It should be noted

that the default behavior of the preRestart hook of the Actor class is to terminate all its children before

restarting, but this hook can be overridden; the recursive restart applies to all children left after this hook has been

executed.

Each supervisor is conﬁgured with a function translating all possible failure causes (i.e. exceptions) into one of

the four choices given above; notably, this function does not take the failed actor’s identity as an input. It is quite

easy to come up with examples of structures where this might not seem ﬂexible enough, e.g. wishing for different

strategies to be applied to different subordinates. At this point it is vital to understand that supervision is about

forming a recursive fault handling structure. If you try to do too much at one level, it will become hard to reason

about, hence the recommended way in this case is to add a level of supervision.

Akka implements a speciﬁc form called “parental supervision”. Actors can only be created by other actors—where

the top-level actor is provided by the library—and each created actor is supervised by its parent. This restriction

makes the formation of actor supervision hierarchies implicit and encourages sound design decisions. It should

be noted that this also guarantees that actors cannot be orphaned or attached to supervisors from the outside,

which might otherwise catch them unawares. In addition, this yields a natural and clean shutdown procedure for

(sub-trees of) actor applications.

2.4. Supervision and Monitoring 15

Akka Java Documentation, Release 2.3.16

Warning: Supervision related parent-child communication happens by special system messages that have

their own mailboxes separate from user messages. This implies that supervision related events are not deter-

ministically ordered relative to ordinary messages. In general, the user cannot inﬂuence the order of normal

messages and failure notiﬁcations. For details and example see the Discussion: Message Ordering section.

2.4.2 The Top-Level Supervisors

An actor system will during its creation start at least three actors, shown in the image above. For more information

about the consequences for actor paths see Top-Level Scopes for Actor Paths.

/user: The Guardian Actor

The actor which is probably most interacted with is the parent of all user-created actors, the guardian named

"/user". Actors created using system.actorOf() are children of this actor. This means that when this

guardian terminates, all normal actors in the system will be shutdown, too. It also means that this guardian’s

supervisor strategy determines how the top-level normal actors are supervised. Since Akka 2.1 it is possible to

conﬁgure this using the setting akka.actor.guardian-supervisor-strategy, which takes the fully-

qualiﬁed class-name of a SupervisorStrategyConfigurator. When the guardian escalates a failure, the

root guardian’s response will be to terminate the guardian, which in effect will shut down the whole actor system.

/system: The System Guardian

This special guardian has been introduced in order to achieve an orderly shut-down sequence where logging re-

mains active while all normal actors terminate, even though logging itself is implemented using actors. This

is realized by having the system guardian watch the user guardian and initiate its own shut-down upon re-

ception of the Terminated message. The top-level system actors are supervised using a strategy which

will restart indeﬁnitely upon all types of Exception except for ActorInitializationException and

ActorKilledException, which will terminate the child in question. All other throwables are escalated,

which will shut down the whole actor system.

/: The Root Guardian

The root guardian is the grand-parent of all so-called “top-level” actors and supervises all the special actors

mentioned in Top-Level Scopes for Actor Paths using the SupervisorStrategy.stoppingStrategy,

whose purpose is to terminate the child upon any type of Exception. All other throwables will be escalated

. . . but to whom? Since every real actor has a supervisor, the supervisor of the root guardian cannot be a real

2.4. Supervision and Monitoring 16

Akka Java Documentation, Release 2.3.16

actor. And because this means that it is “outside of the bubble”, it is called the “bubble-walker”. This is a

synthetic ActorRef which in effect stops its child upon the ﬁrst sign of trouble and sets the actor system’s

isTerminated status to true as soon as the root guardian is fully terminated (all children recursively stopped).

2.4.3 What Restarting Means

When presented with an actor which failed while processing a certain message, causes for the failure fall into three

categories:

• Systematic (i.e. programming) error for the speciﬁc message received

• (Transient) failure of some external resource used during processing the message

• Corrupt internal state of the actor

Unless the failure is speciﬁcally recognizable, the third cause cannot be ruled out, which leads to the conclusion

that the internal state needs to be cleared out. If the supervisor decides that its other children or itself is not

affected by the corruption—e.g. because of conscious application of the error kernel pattern—it is therefore best

to restart the child. This is carried out by creating a new instance of the underlying Actor class and replacing

the failed instance with the fresh one inside the child’s ActorRef; the ability to do this is one of the reasons for

encapsulating actors within special references. The new actor then resumes processing its mailbox, meaning that

the restart is not visible outside of the actor itself with the notable exception that the message during which the

failure occurred is not re-processed.

The precise sequence of events during a restart is the following:

1. suspend the actor (which means that it will not process normal messages until resumed), and recursively

suspend all children

2. call the old instance’s preRestart hook (defaults to sending termination requests to all children and

calling postStop)

3. wait for all children which were requested to terminate (using context.stop()) during preRestart

to actually terminate; this—like all actor operations—is non-blocking, the termination notice from the last

killed child will effect the progression to the next step

4. create new actor instance by invoking the originally provided factory again

5. invoke postRestart on the new instance (which by default also calls preStart)

6. send restart request to all children which were not killed in step 3; restarted children will follow the same

process recursively, from step 2

7. resume the actor

2.4.4 What Lifecycle Monitoring Means

Note: Lifecycle Monitoring in Akka is usually referred to as DeathWatch

In contrast to the special relationship between parent and child described above, each actor may monitor any other

actor. Since actors emerge from creation fully alive and restarts are not visible outside of the affected supervisors,

the only state change available for monitoring is the transition from alive to dead. Monitoring is thus used to tie

one actor to another so that it may react to the other actor’s termination, in contrast to supervision which reacts to

failure.

Lifecycle monitoring is implemented using a Terminated message to be received by the monitoring actor,

where the default behavior is to throw a special DeathPactException if not otherwise handled. In order to

start listening for Terminated messages, invoke ActorContext.watch(targetActorRef). To stop

listening, invoke ActorContext.unwatch(targetActorRef). One important property is that the mes-

sage will be delivered irrespective of the order in which the monitoring request and target’s termination occur, i.e.

you still get the message even if at the time of registration the target is already dead.

2.4. Supervision and Monitoring 17

剩余421页未读，继续阅读

alprah

粉丝: 2
资源: 3

Akka Java 2.3.6 开发文档：低版本 JDK 支持

Java实现doc、xml、pdf文件预览技术解析

Java库spire.doc用法介绍：免费转三页或带水印PDF

PDF Magic-crx插件：轻松转换PDF至DOC格式

akka-2.3.14.doc

Akka-doc-zh:Akka 官方文档中文

ReleaseDoc（HI3516DV300）pdf doc

Solid Converter PDF 5.0 pdf转doc doc转pdf 破解版 压缩包2

java生成DOC文件

PDF转换DOC

pdf 转 doc

最新资源

Solid Converter PDF 5.0 pdf转doc doc转pdf 破解版压缩包2