声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
角色是一种能够接收消息、处理请求以及发送响应的自由运行的活动（activity），主要被设计用来支持异步化且高效的消息传递机制。
每个角色都有一个内建的消息队列，该队列与手机上所使用的短信队列十分相似。假设Sally和Sean同时给Bob的手机发了短信，则运营商将会把这两条短信都保存起来以便Bob在方便的时候取走。类似地，基于角色的并发库允许多个角色并发地发送消息。默认情况下，消息发送者都是非阻塞的；它们会先把消息发送出去，然后再继续处理自己的业务逻辑。类库一般会让特定的角色顺序地拾取并处理消息队列中消息，只有将当前消息处理完或将消息委派给其他角色并发处理之后，这个角色才能够接收下一个消息。
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
Java将OOP变成了可变性驱动（mutability-driven）的开发模式[1]，而函数式编程则着重强调不可变性，而这两种极端的方式其实都是有问题的。如果每样事物都是可变的，那么我们就需要妥善处理可见性和竞争条件。而在一个真实的应用程序中，也并非所有事物都是不可变的。即使是纯函数式语言也提供了代码限制区，在该区域内允许出现带副作用的逻辑以及按顺序执行这些逻辑的方法。但无论我们倾向于哪种编程模型，避免共享可变性都是毋庸置疑的。
共享可变性——并发问题的根源所在——是指多个线程可以同时更改相同的变量。而隔离可变性——一个可以消除大部分并发问题的不错的折衷方案——是指任意时刻有且只有一个线程（或角色）可以访问某个可变变量。 阅读全文
声明：本文是《Java虚拟机并发编程》的第五章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
曾有个的医嘱是这样说的：“如果它伤到了你，那就别再用它了”。在并发编程领域，共享可变性就是那个“它”。
虽然JDK的线程API使我们可以非常容易地创建线程，但如何防止线程冲突和逻辑混乱却又成了大问题。STM虽然可以解决部分问题，但是在一些类似Java这样的语言中，我们仍不得不非常小心谨慎地避免非托管可变变量和事务逻辑中产生某些副作用。而令人惊讶的是，当共享可变性消失的时候，所有那些令人纠结的问题也都随之消失了。 阅读全文
原文链接 作者：paul 译者：谢宝友，鲁阳，陈渝
图1.1：设计模式与锁粒度
图1.1是不同程度同步粒度的图形表示。每一种同步粒度都用一节内容来描述。下面几节主要关注锁，不过其他几种同步方式也有类似的粒度问题。
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
STM消除了显式的同步操作，所以我们在写代码时就无需担心自己是否忘了进行同步或是否在错误的层级上进行了同步。然而STM本身也存在一些问题，比如在跨越内存栅栏失败或遭遇竞争条件时我们捕获不到任何有用的信息。我似乎可以听到你内心深处那个精明的程序员在抱怨“怎么会这样啊？”。确实，STM是有其局限性的，否则本书写到这里就应该结束了。STM只适用于写冲突非常少的应用场景，如果你的应用程序存在很多写操作竞争，那么我们就需要在STM之外寻找解决方案了。
下面让我们进一步讨论STM的局限性。STM提供了一种显式的锁无关编程模型，这种模型允许多个事务并发地运行，并且在没有发生冲突时所有事务都能毫无滞碍地运行，所以相对其他编程模型而言STM可以提供更好的并发性和线程安全方面的保障。当事务对相同对象或数据的写访问发生冲突时，只有一个事务能够顺利完成，其他事务都会被自动重做。这种重做机制延缓了写操作冲突时竞争失败的那些写者的执行，但却提升了读者和竞争操作的胜利者的执行速度。当对于相同对象的并发写操作不频繁时，其性能就不会受到太大影响。但是随着冲突的增多，程序整体性能将因此变得越来越差。
阅读全文
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
在6.6节中，我们曾经简单讨论了写偏斜（write skew）以及Clojure STM是如何解决这个问题的。Akka同样提供了处理写偏斜问题的支持，但是需要我们配置一下才能生效。OK，一听到配置这个词可能让你觉得有些提心吊胆，但实际操作起来其实起来还是蛮简单的。下面就让我们首先了解一下Akka在不进行任何配置情况下的默认行为。
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
在我们努力学习这些示例的过程中，很容易就会忘记我们所要处理的值都必须是不可变的。只有实体才是可变的，而状态值则是不可变的。虽然STM已经为我们减轻了很多负担，但如果想要在维护不可变性的同时还要兼顾性能的话，对我们来说也将是一个非常严峻的挑战。
为了保证不可变性，我们采取的第一个步骤是将单纯用来保存数据的类（value classes）及其内部所有成员字段都置为final（在Scala中是val）。然后，我们需要传递地保证我们自己定义的类里面的字段所使用的类也都是不可变的。可以说，将字段和类的定义置为final这一步是整个过程的基础，这同时也是避免并发问题的第一步。
虽说不可变性可以使代码变得又好又安全，但是由于性能问题，程序员们还是不大愿意使用这一特性。其症结在于，为了维护不可变性，我们可能在数据没发生任何变动的情况下也要进行拷贝操作，而这种无谓的拷贝对性能伤害很大。为了解决这个问题，我们在3.6节中曾经讨论过持久化数据结构以及如何使用这类数据结构来减轻程序在性能方面的负担。而在持久化数据结构的实现方面，已经有很多现成的第三方库可供使用，而Scala本身也提供了这类数据结构。由于Java也有实现好的持久化数据结构可用，所以我们就无需专门为使用这个特性而去换用自己不熟悉的语言。
除了不可变性之外，我们还希望能获得一些事务运行所需要的数据结构——这些数据结构的值是不可变的，但其实体可以在托管事务中被改变。Akka提供了两种托管数据结构——TransactionalVector和TransactionalMap。这两种数据结构源自于高效的Scala数据结构，其工作原理和Java的list、map类似。下面就让我们一起来学习如何在Java和Scala中使用TransactionalMap
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
Java的try-catch-finally语法结构不但使我们可以安全地处理异常，还能够在程序抛出异常时选择性地执行一些代码。同样地，我们也可以控制程序在事务成功提交之后去执行某段代码，而当事务回滚时则去执行另一段代码。StmUtils中的deferred()和compensatiing()这两个函数分别提供了上述功能。特别地，在实现事务的过程中，为保证事务能顺利完成，我们通常会加入一些带副作用的逻辑，而deferred()函数则是一个执行所有这部分逻辑的绝佳地点。
原文下载链接 作者： Javier Fernández González 译者：郑玉婷
前言
当你用计算机工作的时候，你在同时做多样事情。你可以边听音乐边写文档边读取邮件。你可以这样做的原因是你的操作系统运行并发任务。并发编程是关于基础与进程的一个 提供多任务或者程序同时运行还相互沟通来交换数据和相互同步的平台。Java是一个并发平台，在Java程序中提供很多执行并发任务的类。每个版本，Java提升了促进程序员开发并发程序的功能。这本书包含了在Java版本7的并发API中最重要和最有用的技巧，所以你可以直接在你的应用程序中使用的，以下这些：
• 基本线程管理
• 线程同步机制
• 执行者代表的线程的创建与管理
• Fork/Join框架来提高应用程序的性能
• 并发程序的数据结构
• 按照需要来调整一些并发类的默认行为
• 测试Java的并发应用程序
声明：本文是《Java虚拟机并发编程》的第六章，感谢华章出版社授权并发编程网站发布此文，禁止以任何形式转载此文。
我们经常会遇到这样一种情况，即某事务T能否成功完成依赖于某个变量是否发生了变化，并且由于这种原因所引起的事务运行失败也可能只是暂时性的。作为对这种暂时性失败的响应，我们可能会返回一个错误码并告诉事务T等待一段时间之后再重试。然而在事务T等待期间，即使其他任务已经更改了事务T所依赖的数据，事务T也没法立即感知到并重试了。为了解决这一问题，Akka为我们提供了一个简单的工具——retry()，该函数可以先将事务进行回滚，并将事务置为阻塞状态直到该事物所依赖的引用对象发生变化或事务阻塞的时间超过了之前配置的阻塞超时为止。我本人更愿意将这一过程称为“有意识地等待”，因为这种说法听起来比“阻塞”更合适一些。下面让我们将阻塞（或有意识地等待）用于下面的两个例子当中。
Loading...