81、Actor模式（Actor）：Actor模型、消息传递、状态封装，以及Akka框架实践

Actor模式，说白了就是一套「谁干活谁负责」的并发模型。我早年做高并发系统时，被Java的共享内存并发模型折磨得不轻——锁、同步、死锁，光是调试就让人头大。后来接触到Actor模型，才感觉找到了组织。

这个模式的核心思想很简单：每个Actor是一个独立的计算单元，它有自己的状态，只能通过消息与其他Actor通信。没有共享内存，没有锁，没有同步。你想想看，这得多省心。

什么是Actor模型？

Actor模型由Carl Hewitt在1973年提出，但真正火起来是在Erlang语言和Akka框架出现之后。它的三个基本特性是：

• 消息传递：Actor之间只能通过异步消息通信
• 状态封装：每个Actor维护自己的私有状态，外部无法直接访问
• 行为响应：Actor收到消息后，可以执行计算、创建新Actor、发送消息给其他Actor

我在项目中遇到过这样一个场景：一个实时交易系统，需要处理大量订单。如果用传统的线程池+共享队列，光是订单状态的同步就能写出一堆bug。后来改用Actor模型，每个订单对应一个Actor，状态完全隔离，问题一下子就清晰了。

消息传递：Actor的通信方式

消息传递是Actor模型的命脉。每个Actor有一个邮箱（Mailbox），消息被投递到邮箱中，Actor按顺序处理。这个过程是异步的，发送者不会阻塞。

消息可以是任何不可变对象。我个人习惯用case class（Scala）或POJO（Java）来定义消息类型。举个例子：

// Java示例：定义消息类型
public class Greet {
    public final String name;
    public Greet(String name) { this.name = name; }
}

public class Greeting {
    public final String message;
    public Greeting(String message) { this.message = message; }
}

// Actor处理消息
public class GreeterActor extends AbstractActor {
    @Override
    public Receive createReceive() {
        return receiveBuilder()
            .match(Greet.class, greet -> {
                System.out.println("Hello, " + greet.name);
                sender().tell(new Greeting("Hi " + greet.name), self());
            })
            .build();
    }
}

这里有个坑：消息一定要是不可变的。我曾经因为消息对象里有个可变List，导致两个Actor同时修改同一个对象，查了两天才找到原因。嗯，这个教训很深刻。

状态封装：为什么Actor不需要锁？

每个Actor内部的状态是私有的，只有Actor自己可以修改。外部只能通过发送消息来间接影响状态。这就意味着：没有并发访问，自然不需要锁。

你想想看，传统并发模型里，两个线程同时修改一个HashMap，你得加锁。但在Actor模型里，这个HashMap属于某个Actor，只有它自己能改。其他Actor想改？发消息给它，让它自己改。这不就避免了所有竞争条件吗？

// Java示例：Actor内部状态管理
public class CounterActor extends AbstractActor {
    private int count = 0;  // 私有状态，只有本Actor能修改

    @Override
    public Receive createReceive() {
        return receiveBuilder()
            .match(Increment.class, msg -> {
                count++;
                System.out.println("Count: " + count);
            })
            .match(GetCount.class, msg -> {
                sender().tell(count, self());
            })
            .build();
    }
}

这个例子很简单，但体现了核心思想：count变量只在这个Actor内部可见，外部无法直接访问。想增加计数？发Increment消息。想获取当前值？发GetCount消息。一切通过消息。

Akka框架实践

Akka是JVM上最流行的Actor框架，支持Java和Scala。它提供了完整的Actor实现，包括生命周期管理、错误处理、路由、集群等高级特性。

下面是一个完整的Akka Actor示例：

// 1. 定义Actor
public class WorkerActor extends AbstractActor {
    @Override
    public Receive createReceive() {
        return receiveBuilder()
            .match(String.class, msg -> {
                System.out.println("Processing: " + msg);
                // 模拟耗时操作
                Thread.sleep(100);
                sender().tell("Done: " + msg, self());
            })
            .build();
    }
}

// 2. 创建Actor系统
ActorSystem system = ActorSystem.create("MySystem");
ActorRef worker = system.actorOf(Props.create(WorkerActor.class), "worker");

// 3. 发送消息
worker.tell("Task 1", ActorRef.noSender());

// 4. 带回复的消息
Patterns.ask(worker, "Task 2", Duration.ofSeconds(5))
    .thenAccept(response -> System.out.println("Response: " + response));

Akka还提供了几个很实用的特性：

特性	说明	使用场景
Actor生命周期	preStart、postStop等回调方法	资源初始化、清理
监督策略	父Actor监控子Actor，处理异常	错误恢复、容错
路由	将消息分发到一组Actor	负载均衡、并行处理
集群	跨JVM的Actor通信	分布式系统

监督策略是我特别喜欢的一个特性。传统编程中，异常处理往往很分散。但在Akka里，父Actor可以统一处理子Actor的异常，决定是重启、停止还是升级。这让我想起了微服务中的熔断机制，思路是相通的。

Actor模型的核心流程图

下面这张图展示了Actor模型的核心工作流程：

从这张图可以看出，Actor模型的核心就是「隔离」和「通信」。每个Actor有自己的状态和邮箱，消息在Actor之间流转，没有共享内存，没有锁。这种设计让并发编程变得简单而安全。

什么时候用Actor模式？

不是所有场景都适合Actor模型。我个人总结了几条经验：

• 适合：高并发、状态隔离、分布式系统、事件驱动架构
• 不适合：计算密集型任务、需要强一致性的场景、简单的CRUD应用

举个例子，如果你在做聊天系统，每个用户是一个Actor，消息在用户Actor之间传递，这非常自然。但如果你在做科学计算，需要大量CPU运算，Actor模型反而会增加开销。

好了，Actor模式就讲到这里。记住三个关键词：消息传递、状态封装、行为响应。下次你遇到并发问题，不妨想想：能不能用Actor模型来解决？