声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
正如我们在8.7节中所看到的那样，类型化角色是吸取了面向对象的程序设计和基于角色的程序设计二者的精华所孕育出来的新编程模型。该编程模型集所有我们耳熟能详的方法于一身，既可以方便地使用函数调用，又能享受角色所带来的好处。所以，在一个OO应用程序中，相比起普通的角色，我们可能会更倾向于使用类型化的角色。然而与普通角色相类似的是，类型化角色也是各自独立运行且不提供彼此间事务协调功能的，下面我们将会使用调和类型化角色（coordinating typed actor）来解决这个问题。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
Akka transactor或事务角色为我们提供了一种将多个角色的执行过程合并到一个事务中的方法。顾名思义，transactor可以将多个角色对于托管STM Ref对象的更改变成原子操作，即仅当外围事务提交成功之后，对于那些托管对象的变更才能生效，否则所有的变更都会被丢弃。
Transactor提供了三种处理消息的方法：
总体而言，Transactor为我们提供了将其他角色链接到我们的协调事务里的弹性。此外，transactor还提供了前置和后置于事务的可选函数，以便于我们可以提前为事务做好准备或执行某些后置提交操作。
阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
角色可以帮助我们对可变状态进行很好地隔离。尤其是当问题能够被拆分成可以独立运行的多个并发任务、并且并发任务彼此之间都是通过消息进行异步通信时，角色的表现更佳。但是，角色并未提供对跨任务的一致性进行管理的方法。所以如果我们希望两个或多个角色的动作要么全部成功、要么全部失败，则角色就无法独立实现，而此时我们就需要通过引入STM来与角色配合完成此类功能。在本节中，我假定你已经阅读过第6章、以及本章中有关角色和类型化角色的相关内容。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
使用了类型化角色的EnergySource使我们能够以调用函数的形式来掩盖后台顺序处理异步消息的过程，在实现了线程安全的同时又可以免去显式同步的困扰。虽然创建类型化角色并不困难，但此时我们的EnergySource却还是一个丢失了关键特性的半成品——即还没有可以周期性自动补充电量的能力。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
到目前为止我们所接触过的角色都是可以接收消息的，而消息的类型也是五花八门，如String、元组、case类/自定义消息等。然而发送消息的行为在感觉上与我们日常编程工作中所使用的常规函数调用还是有很大区别的，为了弥合二者之间的鸿沟，类型化角色（Typed Actor）就应运而生了。这种类型的角色可以将发送消息的动作在形式上伪装成常规的函数调用，而将消息传输动作隐藏在后台执行。我们可以将类型化角色想像成为一个活动的对象，该对象运行在一个属于自己的轻量消息驱动的线程里面，并且还带有一个用于将正常的函数调用转换成异步非阻塞消息的拦截代理。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
在使用基于角色的编程模型时，只有当多个角色互相协作、同心协力解决问题时，我们才能真正从中获益并感受到其中的乐趣。为了更好地利用并发的威力，我们通常需要把问题拆分成若干个子问题。不同的角色可以负责不同的子问题，而我们则需要对角色之间的通信进行协调。下面我们将通过重写计算目录大小的例子来学习如何在进行多角色协作。
阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
通过前面的学习，我们已经了解了如何创建角色以及如何给角色发送消息，下面让我们来一起学习如何让多个角色协同工作。在第2章中，我们创建了一个统计给定区间内所有素数的程序。在该程序中，我们使用了ExecutorService、Callable、Future以及其他差不多超过一页纸那么多代码。本节我们将会学习如何用Akka角色对该示例进行重构，并且根据之前的惯例我们的介绍顺序还是先Java后Scala。
阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
我们可以向角色发送任何类型的消息——String、Integer、Long、Double、List、Map、元组(tuples)、Scala的case类…但其中有一点需要注意的是，上述所有类型的消息都必须是不可变的。在上述这些类型中，我对于元组有着特殊的偏好，这并非因为我听到别人把元组误读成“two-ples”时感到很有趣，而是由于元组是轻量的、不可变的并且是最容易创建的实例之一。例如，在Scala中，我们可以简单地用（number1，number2）来创建一个含有两个数字的元组。除了元组之外，Scala的case类也是用来定义消息的理想类型——因为case类是不可变的、可以进行模式匹配并且还很容易进行复制。在Java中，我们可以通过将消息定义为一个不可修改（unmodifiable）的Collection的方式来将多个对象塞到一个消息中。当我们向角色传递消息时，如果发送者和接收者都在同一个JVM里[1]，则默认情况下我们传递的是消息的引用。需要注意的是，保证所传递消息的不可变性是程序员自己的责任，尤其是当所发送的消息是我们自定义的类时则更需要加倍小心。为了解决这个问题，我们可以让Akka替我们先将消息序列化，然后将序列化出来的拷贝而不是原对象的引用发送出去，这样就可以避免由于类定义不严谨所造成的问题。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
正如前面曾经提到过的那样，虽然我们有很多支持角色的类库可供选择，但是在本书中我们将使用Akka。这是一个基于Scala的类库，该类库拥有非常好的性能和可扩展性、并同时支持角色和STM。此外，该类库还可以被用于多种JVM上的语言中。在本章中，我们将注意力集中在Java和Scala身上。而在下一章，我们将会学习如何在其他语言中使用Akka的角色。
 |
|
图 8‑2 某个角色的生存周期 |
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
角色是一种能够接收消息、处理请求以及发送响应的自由运行的活动（activity），主要被设计用来支持异步化且高效的消息传递机制。
每个角色都有一个内建的消息队列，该队列与手机上所使用的短信队列十分相似。假设Sally和Sean同时给Bob的手机发了短信，则运营商将会把这两条短信都保存起来以便Bob在方便的时候取走。类似地，基于角色的并发库允许多个角色并发地发送消息。默认情况下，消息发送者都是非阻塞的；它们会先把消息发送出去，然后再继续处理自己的业务逻辑。类库一般会让特定的角色顺序地拾取并处理消息队列中消息，只有将当前消息处理完或将消息委派给其他角色并发处理之后，这个角色才能够接收下一个消息。
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
Java将OOP变成了可变性驱动（mutability-driven）的开发模式[1]，而函数式编程则着重强调不可变性，而这两种极端的方式其实都是有问题的。如果每样事物都是可变的，那么我们就需要妥善处理可见性和竞争条件。而在一个真实的应用程序中，也并非所有事物都是不可变的。即使是纯函数式语言也提供了代码限制区，在该区域内允许出现带副作用的逻辑以及按顺序执行这些逻辑的方法。但无论我们倾向于哪种编程模型，避免共享可变性都是毋庸置疑的。
共享可变性——并发问题的根源所在——是指多个线程可以同时更改相同的变量。而隔离可变性——一个可以消除大部分并发问题的不错的折衷方案——是指任意时刻有且只有一个线程（或角色）可以访问某个可变变量。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
曾有个的医嘱是这样说的：“如果它伤到了你，那就别再用它了”。在并发编程领域，共享可变性就是那个“它”。
虽然JDK的线程API使我们可以非常容易地创建线程，但如何防止线程冲突和逻辑混乱却又成了大问题。STM虽然可以解决部分问题，但是在一些类似Java这样的语言中，我们仍不得不非常小心谨慎地避免非托管可变变量和事务逻辑中产生某些副作用。而令人惊讶的是，当共享可变性消失的时候，所有那些令人纠结的问题也都随之消失了。 阅读全文
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
STM消除了显式的同步操作，所以我们在写代码时就无需担心自己是否忘了进行同步或是否在错误的层级上进行了同步。然而STM本身也存在一些问题，比如在跨越内存栅栏失败或遭遇竞争条件时我们捕获不到任何有用的信息。我似乎可以听到你内心深处那个精明的程序员在抱怨“怎么会这样啊？”。确实，STM是有其局限性的，否则本书写到这里就应该结束了。STM只适用于写冲突非常少的应用场景，如果你的应用程序存在很多写操作竞争，那么我们就需要在STM之外寻找解决方案了。
下面让我们进一步讨论STM的局限性。STM提供了一种显式的锁无关编程模型，这种模型允许多个事务并发地运行，并且在没有发生冲突时所有事务都能毫无滞碍地运行，所以相对其他编程模型而言STM可以提供更好的并发性和线程安全方面的保障。当事务对相同对象或数据的写访问发生冲突时，只有一个事务能够顺利完成，其他事务都会被自动重做。这种重做机制延缓了写操作冲突时竞争失败的那些写者的执行，但却提升了读者和竞争操作的胜利者的执行速度。当对于相同对象的并发写操作不频繁时，其性能就不会受到太大影响。但是随着冲突的增多，程序整体性能将因此变得越来越差。
阅读全文
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
将实体与状态分离的做法有助于STM（软件事务内存）解决与同步相关的两大主要问题：跨越内存栅栏和避免竞争条件。让我们先来看一下在Clojure上下文中的STM是什么样子，然后再在Java里面使用它。
通过将对内存的访问封装在事务（transactions）中，Clojure消除了内存同步过程中我们易犯的那些错误（见《Programming Clojure》[Hal09]和《The Joy of Clojure》[FH11]）。Clojure会敏锐地观察和协调线程的所有活动。如果没有任何冲突——例如，每个线程都在存取不同账户——则整个过程中就不会涉及到任何锁，于是也就不会有延迟，并最终达到最大的并发度。当有两个线程试图访问相同数据时，事务管理器就会介入解决冲突，而我们的代码也就无需涉及任何显式加锁的操作。下面让我们一起研究一下这套系统是如何运作的。
在设计上，值（values）是不可变的，而实体（identities）也仅在Clojure的事务中是可变的。在Clojure中，压根就没有改变状态的方法，也没有任何相关的编程工具可用。而如果出现任何试图在事务之外改变实体的动作时，系统就会抛出illegalStateException异常。换句话说，一旦与事务进行了绑定，在没有冲突时，所有变更都是即时生效的；而一旦发生冲突，Clojure将会自动将事务回滚并重试。我们程序员的主要职责是保证事务中的代码都是幂等的——这是我们在函数式编程中避免副作用的常用手段，而这种手段在Clojure的编程模型中也同样适用。 阅读全文
Loading...