Akka与Java内存模型的关系

原文链接：http://doc.akka.io/docs/akka/2.3.6/general/jmm.html   译者：clearity

不管你使用的Typesafe系统是Scala版本还是Java版本，都可以使你编写并发程序的过程变得更加容易。这篇文章主要讨论的是Typesafe系统，特别是针对Akka在并发程序中对共享内存的处理部分。

Java内存模型

在之前的Java 5 版本中，Java内存模型的定义是很值得商榷的。以至于在共享内存环境下的多线程处理的结果变得多种多样，比如：

1. 线程读取不到其他线程写入的值：内存可见性问题
2. 线程得到了其他线程的“非正常”行为，这也是因为底层指令没有按照期望的顺序执行的结果：指令重排序问题

Java 5版本的JSR 133规范其实已经解决了很多这样的问题。首先Java内存模型是以先序执行原则为前提的规则集合，也就是说它限制的结果是内存的访问必须是依次进行，可是它同时又允许上述的行为乱序的执行。下面是一些规则的例子：

1. 监控锁规则：在同一把锁的获取之前必须已经进行了锁的释放
2. Volatile变量规则：对同一个volatile变量的读取必须在对其写入之后

尽管Java内存模型表面上看很复杂，但是在规范的制定上一直在寻求高可用性以及使其具有可编写高性能、扩展性良好的并发程序结构。

角色（Actor）和Java内存模型

针对Akka中的角色（Actor）实现，多线程可以有两种方式来对共享内存进行操作:

1. 如果消息被发送给一个角色（Actor）。在大多数情况下消息是不可变的，但是也有可能消息并不是如理想中的那样完全不可变化，如果没有先序执行规则的保证，接受消息的角色（Actor）有可能只会看到初始化不完全的数据或者更严重的根本看不到。
2. 如果角色（Actor）通过消息处理改变了内部状态，然后处理其他的消息时又获取内部状态。在这种情况下你需要注意的是角色（Actor）模型并不能保证同一线程可以对不同的消息用相同的角色（Actor）处理。

为了避免角色（Actor）之间的可见性和重排序问题，Akka提供了下面两个先序执行的原则来保证：

1. 角色（Actor）发送规则：发送消息给一个角色（Actor）的操作必须在同一个角色（Actor）接受了那条消息之前发生。
2. 角色（Actor）后续处理规则：同一角色（Actor）的消息处理必须是串行的。

注意：通常意义下也就是当下一消息被角色（Actor）处理的时候，角色（Actor）内部字段的变化在当前是可见的。因此角色（Actor）中的字段不需要被声明为volatile，也不需要是等效的。

上述两个原则只对同一角色（Actor）实例有效，如果使用的是不同的角色（Actor）则没有任何作用。

Future和Java内存模型

注册在Future上的所有回调必须在Future操作完成之后执行。

建议多使用final变量，如果使用了过多的非final变量也必须同时被标识为volatile以便可以在回调中使用字段的最新值。

如果使用过多引用类型，这种情况下必须保证引用指向的实例是线程安全的。我们强烈建议不要使用对象锁，因为它可能造成性能低下，并且最严重的是可能导致死锁的产生。这其实也是使用synchronized的危险所在。

软件事务内存(STM)和Java内存模型

Akka的软件事务内存也支持先序执行规则：

事务引用规则：针对同一事务引用的成功写的提交操作必须发生在同一事务引用的后续读操作之前。

这个规则看起来和Java内存模型中的volatile变量很相似。当前版本的Akka软件事务模型支持延迟写入，因此对于共享内存的实际的写操作只有在事务提交的时候才会执行。事务中的所有写操作都会被置于本地缓冲并对其他事务不可见的，这就保证了不会发生脏读现象。

在Akka中这些规则到底是怎样的这都是实现细节而且都是一直在变动的，具体的下班取决于使用的配置。但是不管怎样他们都是构建在比如监控锁规则或者volatile变量规则这些Java虚拟机模型规则之上的。这就是说，如果你使用Akka，是不用添加同步来保证先序执行的关系的，因为这些Akka已经为你做了。你只需要专注于业务逻辑即可，Akka框架会替你做好这些规则的保证。

角色（Actor）和共享可变状态

但是毕竟Akka是运行在Java虚拟机上的，当然还是要遵守一些规则的。

使用内部角色（Actor）状态并且将它暴露给其他线程

消息必须是不可变的，这样可以避开共享可变状态的陷阱。