线程执行者(二)创建一个线程执行者

声明:本文是《 Java 7 Concurrency Cookbook 》的第四章,作者: Javier Fernández González     译者:许巧辉     校对:方腾飞

创建一个线程执行者

使用Executor framework的第一步就是创建一个ThreadPoolExecutor类的对象。你可以使用这个类提供的4个构造器或Executors工厂类来 创建ThreadPoolExecutor。一旦有执行者,你就可以提交Runnable或Callable对象给执行者来执行。

在这个指南中,你将会学习如何使用这两种操作来实现一个web服务器的示例,这个web服务器用来处理各种客户端请求。 Read more

第四章 线程执行者(一)引言

声明:本文是《 Java 7 Concurrency Cookbook 》的第四章,作者: Javier Fernández González     译者:许巧辉     校对:方腾飞

在这个章节中,我们将覆盖:

深入理解并行编程-锁

原文链接    作者:paul    译者:谢宝友,鲁阳,陈渝

在过去几十年并发研究领域的出版物中,锁总是扮演着坏人的角色,锁背负的指控包括引起死锁、锁封护(luyang注:lock convoying,多个同优先级的线程重复竞争同一把锁,此时大量虽然被唤醒而得不到锁的线程被迫进行调度切换,这种频繁的调度切换相当影响系统性能)、饥饿、不公平、data races以及其他许多并发带来的罪孽。有趣的是,在共享内存并行软件中真正承担重担的是——你猜对了——锁。

1

图1.1:锁:坏人还是懒汉? Read more

讨喜的隔离可变性(二)角色的特性

声明:本文是《Java虚拟机并发编程》的第五章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

角色是一种能够接收消息、处理请求以及发送响应的自由运行的活动(activity),主要被设计用来支持异步化且高效的消息传递机制。

每个角色都有一个内建的消息队列,该队列与手机上所使用的短信队列十分相似。假设Sally和Sean同时给Bob的手机发了短信,则运营商将会把这两条短信都保存起来以便Bob在方便的时候取走。类似地,基于角色的并发库允许多个角色并发地发送消息。默认情况下,消息发送者都是非阻塞的;它们会先把消息发送出去,然后再继续处理自己的业务逻辑。类库一般会让特定的角色顺序地拾取并处理消息队列中消息,只有将当前消息处理完或将消息委派给其他角色并发处理之后,这个角色才能够接收下一个消息。

Read more

讨喜的隔离可变性(一)用角色实现隔离可变性

声明:本文是《Java虚拟机并发编程》的第五章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

Java将OOP变成了可变性驱动(mutability-driven)的开发模式[1],而函数式编程则着重强调不可变性,而这两种极端的方式其实都是有问题的。如果每样事物都是可变的,那么我们就需要妥善处理可见性和竞争条件。而在一个真实的应用程序中,也并非所有事物都是不可变的。即使是纯函数式语言也提供了代码限制区,在该区域内允许出现带副作用的逻辑以及按顺序执行这些逻辑的方法。但无论我们倾向于哪种编程模型,避免共享可变性都是毋庸置疑的。

共享可变性——并发问题的根源所在——是指多个线程可以同时更改相同的变量。而隔离可变性——一个可以消除大部分并发问题的不错的折衷方案——是指任意时刻有且只有一个线程(或角色)可以访问某个可变变量。 Read more

讨喜的隔离可变性-前言

声明:本文是《Java虚拟机并发编程》的第五章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

曾有个的医嘱是这样说的:“如果它伤到了你,那就别再用它了”。在并发编程领域,共享可变性就是那个“它”。

虽然JDK的线程API使我们可以非常容易地创建线程,但如何防止线程冲突和逻辑混乱却又成了大问题。STM虽然可以解决部分问题,但是在一些类似Java这样的语言中,我们仍不得不非常小心谨慎地避免非托管可变变量和事务逻辑中产生某些副作用。而令人惊讶的是,当共享可变性消失的时候,所有那些令人纠结的问题也都随之消失了。 Read more

深入理解并行编程-分割和同步设计(五)

原文链接    作者:paul    译者:谢宝友,鲁阳,陈渝

并行快速路径

细粒度的设计一般要比粗粒度的设计复杂。在许多情况,绝大部分开销只由一小部分代码产生[Knu73]。所以为什么不把精力放在这一小块代码上。

这就是并行快速路径设计模式背后的想法,尽可能地并行化常见情况下的代码路径,同时不产生并行化整个算法所带来的复杂性。您必须理解这一点,不只算法需要并行化,算法所属的工作负载也要并行化。构建这种并行快速路径,需要极大的创造性和设计上的努力。 Read more

深入理解并行编程-分割和同步设计(四)

原文链接    作者:paul    译者:谢宝友,鲁阳,陈渝

设计模式与锁粒度

图1.1:设计模式与锁粒度

图1.1是不同程度同步粒度的图形表示。每一种同步粒度都用一节内容来描述。下面几节主要关注锁,不过其他几种同步方式也有类似的粒度问题。

Read more

深入理解并行编程-分割和同步设计(三)

原文链接    作者:paul    译者:谢宝友,鲁阳,陈渝

设计准则

上面的章节中给出了三个并行编程的目标:性能、生产率和通用性。但是还需要更详细的设计准则来真正的指导真实世界中的设计,这就是本节将解决的任务。在真实世界中,这些准则经常在某种程度上冲突,这需要设计者小心的权衡得失。

这些准则可以被认为是设计中的阻力,对这些阻力进行恰当权衡,这就称为“设计模式”[Ale79],[GHJV95]。

基于三个并行编程目标的设计准则是加速、竞争、开销、读写比率和复杂性。 Read more

硬件的习性

原文链接    作者:paul    译者:谢宝友,鲁阳,陈渝

大多数人根据直觉就知道,在系统间传递消息要比在单个系统上执行简单计算更加耗时。不过,在共享同一块内存的系统的线程间传递消息是不是也更加耗时,这点可就不一定了。本章主要关注共享内存系统中的同步和通信的开销,只涉及了一些共享内存并行硬件设计的皮毛,想了解更多信息的读者,可以翻看Hennessy和Patterson的经典教材最新版[HP95]。

小问题4.1:为什么并行软件程序员需要如此痛苦地学习硬件的低级属性?如果只学习更高级些的抽象是不是更简单,更好,更通用?

Read more

软件事务内存导论

  1. 前言
  2. 软件事务内存
  3. 用Akka/Multiverse STM实现并发
  4. 创建事务
  5. 创建嵌套事务
  6. 配置Akka事务
  7. 阻塞事务
  8. 提交和回滚事件
  9. 集合与事务
  10. 处理写偏斜异常
  11. STM的局限性

软件事务内存导论(十一)-STM的局限性

声明:本文是《Java虚拟机并发编程》的第六章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

1.1    STM的局限性

STM消除了显式的同步操作,所以我们在写代码时就无需担心自己是否忘了进行同步或是否在错误的层级上进行了同步。然而STM本身也存在一些问题,比如在跨越内存栅栏失败或遭遇竞争条件时我们捕获不到任何有用的信息。我似乎可以听到你内心深处那个精明的程序员在抱怨“怎么会这样啊?”。确实,STM是有其局限性的,否则本书写到这里就应该结束了。STM只适用于写冲突非常少的应用场景,如果你的应用程序存在很多写操作竞争,那么我们就需要在STM之外寻找解决方案了。

下面让我们进一步讨论STM的局限性。STM提供了一种显式的锁无关编程模型,这种模型允许多个事务并发地运行,并且在没有发生冲突时所有事务都能毫无滞碍地运行,所以相对其他编程模型而言STM可以提供更好的并发性和线程安全方面的保障。当事务对相同对象或数据的写访问发生冲突时,只有一个事务能够顺利完成,其他事务都会被自动重做。这种重做机制延缓了写操作冲突时竞争失败的那些写者的执行,但却提升了读者和竞争操作的胜利者的执行速度。当对于相同对象的并发写操作不频繁时,其性能就不会受到太大影响。但是随着冲突的增多,程序整体性能将因此变得越来越差。
Read more

Mutex和内存可见性

原文链接  作者:Loïc  译者:林永听

介绍

POSIX线程遵守共享内存模型[1],此模型各线程可以访问一组共享对象。多个并发的线程需要协同访问共享对象。为此该模型引入了以下两个属性来简化程序设计:

  • 原子访问:避免线程在访问数据对象时,另一线程正在修改它。
  • 内存可见性:一旦线程修改数据对象,其它线程在修改行为发生之后马上能看见此对象的新状态,如图1所示。

Read more

软件事务内存导论(十)处理写偏斜异常

声明:本文是《Java虚拟机并发编程》的第六章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

处理写偏斜异常

在6.6节中,我们曾经简单讨论了写偏斜(write skew)以及Clojure STM是如何解决这个问题的。Akka同样提供了处理写偏斜问题的支持,但是需要我们配置一下才能生效。OK,一听到配置这个词可能让你觉得有些提心吊胆,但实际操作起来其实起来还是蛮简单的。下面就让我们首先了解一下Akka在不进行任何配置情况下的默认行为。

Read more

软件事务内存导论(九) 集合与事务

声明:本文是《Java虚拟机并发编程》的第六章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

集合与事务

在我们努力学习这些示例的过程中,很容易就会忘记我们所要处理的值都必须是不可变的。只有实体才是可变的,而状态值则是不可变的。虽然STM已经为我们减轻了很多负担,但如果想要在维护不可变性的同时还要兼顾性能的话,对我们来说也将是一个非常严峻的挑战。

为了保证不可变性,我们采取的第一个步骤是将单纯用来保存数据的类(value classes)及其内部所有成员字段都置为final(在Scala中是val)。然后,我们需要传递地保证我们自己定义的类里面的字段所使用的类也都是不可变的。可以说,将字段和类的定义置为final这一步是整个过程的基础,这同时也是避免并发问题的第一步。

虽说不可变性可以使代码变得又好又安全,但是由于性能问题,程序员们还是不大愿意使用这一特性。其症结在于,为了维护不可变性,我们可能在数据没发生任何变动的情况下也要进行拷贝操作,而这种无谓的拷贝对性能伤害很大。为了解决这个问题,我们在3.6节中曾经讨论过持久化数据结构以及如何使用这类数据结构来减轻程序在性能方面的负担。而在持久化数据结构的实现方面,已经有很多现成的第三方库可供使用,而Scala本身也提供了这类数据结构。由于Java也有实现好的持久化数据结构可用,所以我们就无需专门为使用这个特性而去换用自己不熟悉的语言。

除了不可变性之外,我们还希望能获得一些事务运行所需要的数据结构——这些数据结构的值是不可变的,但其实体可以在托管事务中被改变。Akka提供了两种托管数据结构——TransactionalVector和TransactionalMap。这两种数据结构源自于高效的Scala数据结构,其工作原理和Java的list、map类似。下面就让我们一起来学习如何在Java和Scala中使用TransactionalMap

Read more

return top