AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

讨喜的隔离可变性(十一)调和类型化角色

2016-04-08 1123
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：

正如我们在8.7节中所看到的那样，类型化角色是吸取了面向对象的程序设计和基于角色的程序设计二者的精华所孕育出来的新编程模型。该编程模型集所有我们耳熟能详的方法于一身，既可以方便地使用函数调用，又能享受角色所带来的好处。所以，在一个OO应用程序中，相比起普通的角色，我们可能会更倾向于使用类型化的角色。然而与普通角色相类似的是，类型化角色也是各自独立运行且不提供彼此间事务协调功能的，下面我们将会使用调和类型化角色（coordinating typed actor）来解决这个问题。

Akka帮助我们简化了将一个普通的类型化角色转换成一个调和类型化角色的过程。我们只需简单地用一个特殊的Coordinated注解对相应的接口函数进行标记即可。为了标明某个函数调用序列运行在一个协调事务中，我们需要将这些函数调用包裹在一个coordinate()函数里。在进行下一步操作之前，该函数（默认情况下）会等待所有函数都提交或回滚。

这种方案有一个限制，那就是只有void函数才能够用Coordinated注解进行标记。这是因为void函数被翻译为单向调用，并且这些函数可以参与到事务中。而返回值不为void的函数则会被翻译成双向阻塞调用，所以这些函数将无法参与到自由运行的并发事务中。

现在让我们再次重新实现那个我们曾在8.10节中摆弄过很多次的转账示例吧。

在Java中使用调和类型化角色

为了使用类型化角色，我们需要准备一对接口/实现类，所以我们先从Account和AccountService这两个下面将会用到的接口开始入手：


1 public interface Account {
2 int getBalance();
3 @Coordinated void deposit(final int amount);
4 @Coordinated void withdraw(final int amount);
5 }
6 public interface AccountService {
7 void transfer(final Account from, final Account to, final int amount);
8 }

在Account接口中，唯一比较特别的部分就是其两个接口函数都用@Coordinated注解进行了标记。通过这两个标记，我们声明了这些函数既可以在其自身的事务中运行，也可以加入到其调用者的事务当中。与此相对的是，由于AccountService的实现类将会自行管理其事务，所以AccountService的接口函数都没有进行标记。


01 public class AccountImpl extends TypedActor implements Account {
02 private final Ref<Integer> balance = new Ref<Integer>(0);
03 public int getBalance() { return balance.get(); }
04 public void deposit(final int amount) {
05 if (amount > 0) {
06 balance.swap(balance.get() + amount);
07 System.out.println("Received Deposit request " + amount);
08 }
09 }
10 public void withdraw(final int amount) {
11 System.out.println("Received Withdraw request " + amount);
12 if (amount > 0 && balance.get() >= amount)
13 balance.swap(balance.get() - amount);
14 else {
15 System.out.println("...insufficient funds...");
16 throw new RuntimeException("Insufficient fund");
17 }
18 }
19 }

通过继承TypedActor，我们将AccountImpl声明为一个角色。在这里我们没有使用简单的本地字段，而是采用了托管的STM引用（Ref）。此外，虽然我们没有写任何针对事务的代码，但是由于AccountImpl类相关接口函数都是用@Coordinated标记过的，所以该类的所有函数都将运行在一个事务中。在deposit()函数中，如果参数amount的值大于0，则deposit()函数将负责把amount的值累加到其当前余额中。相反地，如果当前余额balance的值大于参数amount，则withdraw()函数就会在当前余额中减去amount的值。否则，withdraw()函数将会抛出一个异常以表明当前操作及外围事务执行失败。如果我们没有为这些函数指定事务，则它们将会运行在自身的默认事务中。而在转账的情境下，我们希望存款和取款操作都运行在同一个事务中，所以接下来我们要写一个AccountServiceImpl来对这两个操作进行管理：


01 public class AccountServiceImpl
02 extends TypedActor implements AccountService {
03 public void transfer(
04 final Account from, final Account to, final int amount) {
05 coordinate(true, new Atomically() {
06 public void atomically() {
07 Coordinating Typed Actors • 211
08 to.deposit(amount);
09 from.withdraw(amount);
10 }
11 });
12 }
13 }

在上面的代码中，transfer()函数保证了存取款操作都将在同一事务中完成。需要在事务中执行的代码都被包装在Atomically接口的成员函数atomically()里。而从akka.transactor.Coordination类中静态引入的coordinate()函数则将以事务的形式运行atomically()函数中的代码块。其第一个参数true的作用是指示coordinate()要等待其事务完成（成功或回滚）之后才能返回。所有事务中的函数调用本质上都是（发送）单向消息，所以coordinate()函数只关心事务是否完成，而不会阻塞式地等待各函数的返回结果。

除了角色对象的创建过程略有不同之外，使用这些类型化角色的代码与使用普通对象的代码看起来没什么两样。在创建对象时，我们没有直接把对象new出来，而是使用了一个工厂类来负责创建工作，具体代码如下所示：


01 public class UseAccountService {
02 public static void main(final String[] args)
03 throws InterruptedException {
04 final Account account1 =
05 TypedActor.newInstance(Account.class, AccountImpl.class);
06 final Account account2 =
07 TypedActor.newInstance(Account.class, AccountImpl.class);
08 final AccountService accountService =
09 TypedActor.newInstance(AccountService.class, AccountServiceImpl.class);
10 account1.deposit(1000);
11 account2.deposit(1000);
12 System.out.println("Account1 balance is " + account1.getBalance());
13 System.out.println("Account2 balance is " + account2.getBalance());
14 System.out.println("Let's transfer $20... should succeed");
15 accountService.transfer(account1, account2, 20);
16 Thread.sleep(1000);
17 System.out.println("Account1 balance is " + account1.getBalance());
18 System.out.println("Account2 balance is " + account2.getBalance());
19 212 • Chapter 8. Favoring Isolated Mutability
20 System.out.println("Let's transfer $2000... should not succeed");
21 accountService.transfer(account1, account2, 2000);
22 Thread.sleep(6000);
23 System.out.println("Account1 balance is " + account1.getBalance());
24 System.out.println("Account2 balance is " + account2.getBalance());
25 Actors.registry().shutdownAll();
26 }
27 }

上述代码行为与我们之前在8.10节中所使用的示例完全相同。其输出结果如下所示：


01 Account1 balance is 1000
02 Received Deposit request 1000
03 Account2 balance is 1000
04 Let's transfer $20... should succeed
05 Received Deposit request 20
06 Received Withdraw request 20
07 Account1 balance is 980
08 Account2 balance is 1020
09 Let's transfer $2000... should not succeed
10 Received Deposit request 2000
11 Received Withdraw request 2000
12 ...insufficient funds...
13 Account1 balance is 980
14 Account2 balance is 1020

正如我们所期待的那样，调和类型化角色版本的输出结果与transactor版本的输出结果基本相同——最后一个失败的转账事务所产生的所有变更最终都被丢弃。

在Scala中使用调和类型化角色

下面让我们将上述Java版本的示例代码翻译成Scala。在Scala中，我们才采用trait来代替接口，而这也是两种语言在实现方面的第一个不同点。


1 trait Account {
2 def getBalance() : Int
3 @Coordinated def deposit(amount : Int) : Unit
4 @Coordinated def withdraw(amount : Int) : Unit
5 }
6 trait AccountService {
7 def transfer(from : Account, to : Account, amount : Int) : Unit
8 }

Account trait的实现是从Java版本直译过来的：


01 class AccountImpl extends TypedActor with Account {
02 val balance = Ref(0)
03 def getBalance() = balance.get()
04 def deposit(amount : Int) = {
05 if (amount > 0) {
06 balance.swap(balance.get() + amount)
07 println("Received Deposit request " + amount)
08 }
09 }
10 def withdraw(amount : Int) = {
11 println("Received Withdraw request " + amount)
12 if (amount > 0 && balance.get() >= amount)
13 balance.swap(balance.get() - amount)
14 else {
15 println("...insufficient funds...")
16 throw new RuntimeException("Insufficient fund")
17 }
18 }
19 }

同样地， AccountService trait的实现也从Java代码直译过来即可：


1 class AccountServiceImpl extends TypedActor with AccountService {
2 def transfer(from : Account, to : Account, amount : Int) = {
3 coordinate {
4 to.deposit(amount)
5 from.withdraw(amount)
6 }
7 }
8 }

在Scala版本的示例中，调用定义了事务各个组成部分的coordinate()函数的方式比在Java版里简化了很多。默认情况下，coordinate()函数需要等待其事务执行完毕（成功或回滚）之后才能返回。同时，由于事务中所有的函数调用本质上都是（发送）单向消息，所以coordinate()函数只关心事务是否完成，而不会阻塞式地等待各函数的返回结果。此外，我们还可以向其传递一个可选参数，如coordinate(wait=false)，来告知coordinate()函数不用等待事务完成。

最后，我们还需要一个检验上述代码的测试用例：


01 object UseAccountService {
02 def main(args : Array[String]) = {
03 val account1 =
04 TypedActor.newInstance(classOf[Account], classOf[AccountImpl])
05 val account2 =
06 TypedActor.newInstance(classOf[Account], classOf[AccountImpl])
07 val accountService =
08 TypedActor.newInstance(
09 classOf[AccountService], classOf[AccountServiceImpl])
10 account1.deposit(1000)
11 account2.deposit(1000)
12 println("Account1 balance is " + account1.getBalance())
13 println("Account2 balance is " + account2.getBalance())
14 println("Let's transfer $20... should succeed")
15 accountService.transfer(account1, account2, 20)
16 Thread.sleep(1000)
17 println("Account1 balance is " + account1.getBalance())
18 println("Account2 balance is " + account2.getBalance())
19 println("Let's transfer $2000... should not succeed")
20 accountService.transfer(account1, account2, 2000)
21 Thread.sleep(6000)
22 println("Account1 balance is " + account1.getBalance())
23 println("Account2 balance is " + account2.getBalance())
24 Actors.registry.shutdownAll
25 }
26 }

正如我们从下面的输出结果中所看到的那样，Scala实现版本的行为与Java版本完全相同：


01 Received Deposit request 1000
02 Received Deposit request 1000
03 Account1 balance is 1000
04 Account2 balance is 1000
05 Let's transfer $20... should succeed
06 Received Deposit request 20
07 Received Withdraw request 20
08 Account1 balance is 980
09 Coordinating Typed Actors • 215
10 Account2 balance is 1020
11 Let's transfer $2000... should not succeed
12 Received Deposit request 2000
13 Received Withdraw request 2000
14 ...insufficient funds...
15 Account1 balance is 980
16 Account2 balance is 1020
文章标签：
Java
Scala
ali清英
目录
相关文章
wljslmz
|
3月前
|
调度
忙旋转：概念、用途及考量
【8月更文挑战第21天】
wljslmz
35 0
嘟嘟嘟嘟嘟嘟
|
4月前
|
容器
通用研发提效问题之区分女娲上下文中的共享字典和隔离字典，如何解决
通用研发提效问题之区分女娲上下文中的共享字典和隔离字典，如何解决
嘟嘟嘟嘟嘟嘟
39 0
timerring
|
编解码
失真的概念和定义
失真的概念和定义
timerring
234 0
-编程工程师-
|
消息中间件 存储 运维
难住了，微服务之间的几种调用方式哪种最佳？
难住了，微服务之间的几种调用方式哪种最佳？
-编程工程师-
303 0
范大脚脚
|
JavaScript
【重构笔记03】对象之间搬迁特性
范大脚脚
1131 0
余二五
|
关系型数据库 C++
面相对象的三大基本特性五大基本原则
余二五
1491 0
boxti
|
Java Scala 测试技术
讨喜的隔离可变性(十一)调和类型化角色
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。 正如我们在8.7节中所看到的那样，类型化角色是吸取了面向对象的程序设计和基于角色的程序设计二者的精华所孕育出来的新编程模型。
boxti
1103 0
boxti
|
Java 测试技术 Scala
讨喜的隔离可变性(八)类型化角色和Murmurs
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。 使用了类型化角色的EnergySource使我们能够以调用函数的形式来掩盖后台顺序处理异步消息的过程，在实现了线程安全的同时又可以免去显式同步的困扰。
boxti
1921 0
boxti
|
监控 Java 开发者
讨喜的隔离可变性(十二)基于角色模型的局限性和小结
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。 截至目前我们所写的关于角色的例子中，所有角色及其客户端都运行于同一JVM进程中。但在现实生活中，有一部分开发者认为角色也应该像在Erlang中那样被用于进程间通信。
boxti
1459 0
boxti
|
Java API Scala
讨喜的隔离可变性（三）创建角色
boxti
1296 0