Animation

The Piagmatic Programmers TURING 图灵程序设计丛书 Seven Concurrency Models in Seven Weeks When Threads Unravel 七周七并发模型借助Java、Go等多种语言的特长深度部析所有主流并发编程模型【美】PaulButcher著黄炎译游涨 VI 中国工信出版集团器器人民邮电出版社 POSTS&TELECOMPRESS 提供各种IT类书籍pdf下载，如有需要，请 QQ: 2011705918 注：链接至淘宝，不喜者勿入! 整理那么多资料也不容易，请多多见谅！非诚勿扰！更多资源请点击 TURING 图灵程序设计丛书 Seven Concurrency Models in Seven Weeks WhenThreadsUnravel 七周七并发模型【美】PaulButcher著黄炎译人民邮电出版社北京图书在版编目（CIP）数据七周七并发模型／（美）布彻（Butcher,P.）著；黄炎译．=-北京：人民邮电出版社，2015.4 （图灵程序设计丛书） ISBN 978-7-115-38606-9 I．①七I．①布②黄ⅢI．①并行程序一程序设计V：①TP311.11 中国版本图书馆CIP数据核字（2015)第038645号内容提要并发编程近年逐渐热起来，Go等并发语言也对并发编程提供了良好的支持，使得并发这个话题受到越来越多人的关注。本书延续了《七周七语言》的写作风格，通过以下七个精选的模型帮助读者了解并发领域的轮廓：线程与锁，函数式编程，Clojure，actor，通信顺序进程，数据级并行，Lambda架构。书中每一章都设计成三天的阅读量。每天阅读结束都会有相关练习，巩固并扩展当天的知识。每一章均有复习，用于概括本章模型的优点和缺陷。本书适合所有想了解并发的程序员。 ·著译 [美] Paul Butcher 黄炎责任编辑朱巍执行编辑陈婷婷责任印制杨林杰人民邮电出版社出版发行邮编100164 北京市丰台区成寿寺路11号电子邮件315@ptpress.com.cn 网址http://www.ptpress.com.cn 北京鑫正大印刷有限公司印刷开本：800×10001/16 印张：15.25 字数：366千字印数：1-4000册 2015年4月第1版 2015年4月北京第1次印刷著作权合同登记号图字：01-2014-6027号定价：49.00元读者服务热线：（010)51095186转600印装质量热线：（010)81055316 反盗版热线：（010)81055315 广告经营许可证：京崇工商广字第0021号译者序作者认为写作本书非常不易，译者深以为然。翻译本书的主要困难源自于我们与作者在知识积累上的巨大差距，作者在前言中写道“我从1989年开始攻读博士学位，在并行计算和分布式计算的领域深造”，那年我只有一岁。我无法精通本书介绍的七个模型中的所有技术细节，因此没有自信确保全无差错，只能竭尽所能保证译文不会有大的偏差。在此要向提供帮助的人们致以谢意。首先，感谢图灵的编辑老师，他们辛勤的工作完善了本书的每个细节：其次，要感谢我的父亲一一大连海事大学的黄映辉教授，他为本书进行了三次审校，对字句进行了细致酌，大幅提升了本书的可读性；然后，要感谢我的挚友一一工作于Fox NewsDigital的孙培源，他为本书进行了中英文的对照审校，帮助矫正了翻译过程中的很多谬误；还要感谢工作于喜马拉雅的柳飞提供的莫大帮助：最后，要感谢这个时代，让我们有机会能参与到这个伟大的丛书系列中。本书介绍了七种并发模型，行文通俗易懂，有数量充足且设计精良的样例来帮助读者理解。读完本书，我最大的感受是世界变得更大了，想要学习的有趣的东西变得更多了。希望大家读完后也有类似有趣的体验。用一个亲身经历的趣事来结束本序。几年前，我去某软公司应聘，电话面试中与面试官有如下番对话。面试官：你了解多线程并发吗？我：不了解，我之前做业务系统，多线程很大程度上都是委托给容器的…· 面试官：我理解了。你不太熟悉并发是吗？我：是的。面试官：那我们还是来聊一聊并发吧。祝大家线程安全。黄炎 2014年12月31日本书将讲述一个完整的故事。推荐序将此作为一本书的首要定位似乎有点奇怪，但对我而言这很重要。我们曾回绝数十位申请撰写“七周系列丛书”的作者，他们认为只要将七个分散主题拼凑起来就是一本书，但这有违我们的初衷。先前的《七周七语言：理解多种编程范型》の讲述了个面向对象编程语言的故事，这是很适应当时的环境的。但在多核架构的驱动下，软件复杂度的增长和并发技术的发展所带来的压力，将函数式编程推到舞台之上，并对今后的编程方式有着深远的影响。PaulButcher是《七周七语言》最给力的审校者之一，相识四年后，我开始理解其中原因。 Paul一直奋斗在将高可扩展的并发技术应用于实际业务系统的第一线。读过《七周七语言》后，对于他所处的日益重要但日趋复杂的问题领域，Paul觉得可以从编程语言级别获得些启发。几年后，Paul表示要写一本自已的书。他解释道：尽管编程语言在整个故事中有着重要的作用但也只触及了问题的表面。他要为读者讲述一个更完整的故事，为非专业人士介绍现代应用程序用以解决大型并行问题的扩展性良好的重要工具。一开始我们是持怀疑态度的。这类书是很难写的一一比起其他领域的书，这类书需要花费更长的时间，而且失败的几率很高一一Paul显然选择了一块难啃的骨头。作为一个团队，我们不断磨合前进，终于从最初的大纲中研磨出一个优秀的故事。随着书稿逐渐完成，我们更加自信于 Paul的技术能力和攻关热情。现在，我们已经确信这是一本特别的书，而且恰逢其时。随着阅读的深入，我相信你也会同意这个观点。当你在开篇阅读到“线程与锁”这种当今最广泛使用的并发解决方案时，可能会不以为然。不过你很快就会看到这种解决方案的不足之处，并开始思考如何解决。Paul将引领你学习多种非常不同的技术，从一些社交平台使用的Lambda架构，到现令世界上许多最大最可靠的电信系统使用的actor模型。你会学到职业高手使用的一些语言，从Java到Clojure，再到基于Erlang的闪亮新秀Elixir。旅途中的每一步，Paul都将从专业的角度为你部析其中的玄妙和精彩。在此，我诚意奉上《七周七并发模型》。希望你和我二样乐享其中。 BruceA.Tate icanmakeitbetter.com网站CTO，七周系列丛书主编于美国德克萨斯州奥斯汀 ①本书中文版电子书在图灵社区有售：http://www.ituring.com.cn/book/829。—编者注前言我从1989年开始攻读博士学位，在并行计算和分布式计算的领域深造，当时我便深信并发编程将成为主流。二十年后，我的观点终于得以验证一一整个世界都在讨论多核以及如何发挥其优势学习并发不仅是为了利用多核来获得更好的性能。若正确使用并发，我们还能在程序的响应性、容错性、效率和简洁程度上获得大幅提升。关于本书本书延续了PragmaticBookshelf的七周系列丛书（《七周七语言》《七周七数据库》《七周七网络框架》）的架构，通过七个精选的模型帮助读者了解并发领域的轮廓。这些模型中，一些已经成为主流，一些很快会成为主流，另二些虽难以成为主流，但在特定领域会威力无穷。当面对一个并发问题时，你可以借助本书准确选择合适的工具，这就是我的期望所在。本书的每一章都设计成三天的阅读量。每天阅读结束都会有相关练习，巩固并扩展当天的知识。每一章均有复习，用于概括本章模型的优点和缺陷。尽管有少量具有哲学意味的讨论，但本书还是侧重于实践。我强烈建议你在阅读样例时能亲手实践一下一一没什么比代码更有说服力了。本书未涉及的内容本书不是语言参考手册。我们会使用一些较新的语言，例如Elixir和Clojure，但本书关注的是并发而不是编程语言，所以不会深人介绍这些语言的具体特性。希望你通过上下文可以初步了解这些语言的主要特性，如果要对其深人探究以期充分理解，就得依靠自身的努力了。阅读本书时，如果手边开着浏览器可随时查阅语言参考手册，就会事半功倍。本书不是安装配置手册。要运行本书的配套代码，就需要安装和运行相应工具一一配套代码的README文件会给出一些提示，但还是要依靠你自已。本书所有的样例都采用主流工具编写，如果遇到困难，你可以在网络上找到许多帮助资料。本书也不是面面俱到一一无法囊括所有议题的每个细节。对于某些议题，本书会一笔带过或 ①本书中文版电子书在图灵社区有售："http://www.ituring.com.cn/book/1369。—编者注 vi前言者根本不予讨论。在某些章节中，我会特意使用一些不规范的代码，目的是便于不熟悉该语言的读者来理解代码。如果你有意深入学习本书中的某种技术，建议阅读本书所提及的权威文献。样例代码本书讨论的所有样例都可以从本书的网站下载。每个样例都包括源码和构建系统。对于每一种语言，本书都选用最通用的构建系统（Java使用Maven，Clojure使用Leiningen，Elixir使用 Mix，Scala使用sbt，C使用GNUMake)。大多数情况下，构建系统不仅会编译代码，而且会下载所需的额外依赖。sbt和Leiningen甚至会下载对应版本的Scala和Clojure的编译器，所以你只需要下载并安装构建系统即可（在网络上可以找到详尽的安装步骤）。不过第7章中使用的C代码是个特例，需要根据你的操作系统和显卡类型安装相应的OpenCL 工具包（除非你使用的是Mac，因为Xcode会搞定一切）。给IDE用户的建议本书使用的构建系统都在命令行下测试通过。如果你是成熟的IDE用户，一定知道如何将构建系统导人到IDE中大多数IDE都会兼容Maven，主流IDE也都有兼容sbt和Leiningen的插件。不过我没有在IDE中测试过，所以你与我一样使用命令行也许会容易一些。给Windows用户的建议所有的样例均在OSX和Linux上测试通过。理论上，它们也可以在Windows上运行良好，但我并没有验证过。第7章中使用的C代码是个特例，其使用了GNUMake和GCC。理论上是能被迁移到Visual C++中，但我没有尝试过这种可能。在线资源本书中的样例都可以在本书网站上找到。如果你要提交勘误或者给出建议，也可以在网站上找到勘误表格和交流论坛。 Paul Butcher Ten Tenths Consulting paul@tententhsconsulting.com 2014年6月于英国剑桥 ①http://pragprog.com/book/pb7con 致谢当我宣告决定写本书时，一个朋友提醒道：“你是不是已经忘记写第一本书时的艰辛了？” 我当时一定是太天真，误认为写第二本书会容易一些。现在想来，如果不参与七周系列丛书，而是选择容易一些的题材，我的日子会好过很多。若没有主编BruceTate和策划编辑JackieCarter的鼎力相助，本书定然无法完成。感谢两位在本书写作过程中的大力支持，同时感谢Dave和Andy让我有幸参与到这个伟大的系列丛书中。感谢许多朋友在成书早期提供的建议和反馈，他们是（排名不分先后）：SimonHardy-Francis、 SamHalliday、MikeSmith、NeilEccles、MatthewRudyJacobs、JoeOsborne、DaveStrauss、Derek Law、FrederickCheung、HugoTyson、PaulGregory、StephenSpencer、AlexNixon、BenCoppin、 KitSmithersAndrewEacott、FreeiandAbbott、JamesAley、MatthewWilson、SimonDobson、Doug Orr、Jonas Boner、Stu Halloway、Rich Morin、David Whittaker、Bo Rydberg、Jake Goulding、Ari Gold, Juan Manuel Gimeno Illa,Steve Bassett,Norberto Ortigoza, Luciano Ramalho, Siva Jayaraman, ShaunParry、JoelVanderWerf。感谢本书的技术审校者（排名不分先后）：CarlosSessa、DannyWoods、VenkatSubramaniam、 Simon Wood.Paidi Creed、Ian Roughley、Andrew Thomson、Andrew Haley、Sean Ellis、Geoffrey Clements、Loren Sands-Ramshaw、PaulHudson。最后，要向我的朋友、同事、家人致以谢忧和歉意。感谢你们的支持和鼓励，也请原谅过去 18个月中我的种种偏执。版权声明 Copyright 2014 Paul Butcher. Original English language edition, entitled Seven Concurrency ModelsinSevenWeeks:WhenThreadsUnravel Simplified Chinese-language edition copyright 2015 by Posts & Telecom Press. All rights reserved. 本书中文简体字版由ThePragmaticProgrammers，LLC.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。版权所有，侵权必究。第1章概述 1.1并发还是并行？ 1.2并行架构 1.3.并发：不只是多核 1.4七个模型线程与锁第2章 2.1 简单粗暴 2.2 第二天：互斥和内存模型· 2.3-第二天：超越内置锁第三天：站在巨人的肩膀上 2.4 2.5复习… 函数式编程第3章若不爽，就另辟径 3.1 3.2：第一天：抛弃可变状态 3.3 第二天：函数式并行第三天：函数式并发 3.4 3.5 第4章 4.1 4.2 4.3 复习· Clojure之道状态· 混搭的力量自 6 8 17·27 38 :41 41·42 51 61 70 分离标识与 ·73 73 第一天：原子变量与持久数据结构73 第二天：代理和软件事务内存 4.4 第三天：深人学习 4.5 第5章复习 Actor 5.1 更加面向对象 5.2 第一天：消息和信箱 5.3 第二天：错误处理和容错性 ..·84 92·98 100 100 101 111 5.4·第三天：分布式. 5.5复习…. 第6章通信顺序进程 6.1·万物皆通信… 6.2第一天：channel和go块. 6.3第二天：多个channel与IO… 6.4·第三天：客户端CSP. 6.5复习. 第7章数据并行 120 132 135·135·136.146 157 164 167 7.1隐藏在笔记本电脑中的超级计算机167 7.2‘第一天：GPGPU编程… ·167 第二天多维空间与工作组77 7.3 第三天：OpenCL和OpenGL一一全部 7.4 在GPU上运行 7.5 第8章 8.1 8.2 8.3 8.4 8.5 复习 Lambda架构并行计算搞定大数据第一天：MapReduce: 第二天：批处理层第三天：加速层· 复习第9章 9.1 9.2 9.3 圆满结束君欲何往未尽之路越过山丘参考书目 187 194 196：196 197 208 218 229 231·231·232 234 235 第1章概述并发编程的概念并不新，却直到最近才火起来。一些编程语言，如Erlang、Haskell、Go、Scala、 Clojure，也因对并发编程提供了良好的支持，而受到广泛关注。并发编程复兴的主要驱动力来自于所谓的“多核危机”。正如摩尔定律所预言的那样，芯片性能仍在不断提高，CPU的速度会继续提升，但计算机的发展方向已然转向多核化?。 HerbSutter曾经说过：“免费午餐的时代已然终结。”③为了让代码运行得更快，单纯依靠更快的硬件已无法满足要求，我们需要利用多核，也就是发掘并行执行的潜力 1.1 并发还是并行？本书的主题是“并发”，那么又为何涉及了“并行”呢？虽然两者有所关联又常被混淆，但并发和并行的含义却是不同的。一字之差也是差：并发程序含有多个逻辑上的独立执行块，它们可以独立地并行执行，也可以串行执行。并行程序解决问题的速度往往比串行程序快得多，因为其可以同时执行整个任务的多个部分。并行程序可能有多个独立执行块，也可能仅有一个。我们还可以从另一种角度来看待并发和并行之间的差异：并发是问题域中的概念一一程序需@http://en.wikipedia.org/wiki/Moore%27s_law ②作者在本章不断使用“core”“CPU”“processor”，译者在此尊重原文分别翻译成“核”“CPU”“处理器"。但译者认为此处指的都是广义的处理单元，而不是狭义的硬件。一 ③http://www.gotw.ca/publications/concurrency-ddj.htm 译者注 ④原文是“logicalthreadsofcontrol”，直译为“控制逻辑线程”，但在此语境下“控制”或“线程”指的并不是我们常见的“控制”和“线程”。为便于理解，在此将其译成“独立执行块”，这个概念来自于GoogleIO2012的演讲“Go concurrency patterns”中引用的文档“Concurrency is notParallelism”（http://tinyurl.com/goconcnotpar），其将这个概念称为“independentlyexecutingprocesses"。一 —译者注第1章概述 2 要被设计成能够处理多个同时（或者几乎同时）发生的事件；而并行则是方法域中的概念一一通过将问题中的多个部分并行执行，来加速解决问题。引用RobPike的经典描述?：并发是同一时间应对（dealingwith）多件事情的能力；并行是同一时间动手做（doing）多件事情的能力。那么这本书讲述的是并发还是并行？ V小乔爱问并发？并行？我妻子是一位教师。与众多教师一样，她极其善于处理多个任务。她虽然每次只能做一件事，但可以同时处理多个任务。比如，在听一位学生朗读的时候，她可以暂停学生的朗读，以维持课堂秩序，或者回答学生的问题。这是并发，但并不并行（因为仅有她一个人，某一时刻只能进行一件事）。但如果还有一位助教，则她们中一位可以听朗读，而同时另一位可以回答问题。这种方式既是并发，也是并行。假设班级设计了自已的资卡并要批量制作。一种方法是让每位学生制作五枚贺卡。这种方法是并行，而（从整体看）不是并发，因为这个过程整体来说只有一个任务。超越串行编程模型并发和并行的共同点就是它们比传统的串行编程模型更优秀。本书将同时涵盖并发和并行（学究可能会给这本书起名为“七周七并发模型和并行模型”，不过那样的话，封面会变得很难看）并发和并行经常被混淆的原因之一是，传统的“线程与锁”模型并没有显式支持并行。如果要用线程与锁模型为多核进行开发，唯一的选择就是写一个并发的程序，并行地运行在多核上。然而，并发程序的执行通常是不确定的，它会随着事件时序的改变而给出不同的结果。对于真正的并发程序，不确定性是其与生俱来且伴随始终的属性。与之相反，并行程序可能是确定的例如，要将数组中的每个数都加倍，一种做法是将数组分为两部分并把它们分别交给一个核处理， ①http://concur.rspace.googlecode.com/hg/talk/concur.html 1.2并行架构 3 这种做法的运行结果是确定的。用支持并行的编程语言可以写出并行程序，而不引人不确定性。 1.2并行架构人们通常认为并行等同于多核，但现代计算机在不同层次上都使用了并行技术。比如说，单核的运行速度现今仍能每年不断提升的原因是：单核包含的晶体管数量，如同摩尔定律预测的那样变得越来越多，而单核在位级和指令级两个层次上都能够并行地使用这些晶体管资源。位级（bit-level）-并行为什么32位计算机的运行速度比8位计算机更快？因为并行。对于两个32位数的加法，8位计算机必须进行多次8位计算，而32位计算机可以一步完成，即并行地处理32位数的4字节。计算机的发展经历了8位、16位、32位，现在正处于64位时代。然而由位升级带来的性能改善是存在瓶颈的，这也正是短期内我们无法步入128位时代的原因。指令级（instruction-leve）并行现代CPU的并行度很高，其中使用的技术包括流水线、乱序执行和猜测执行等。程序员通常可以不关心处理器内部并行的细节，因为尽管处理器内部的并行度很高，但是经过精心设计，从外部看上去所有处理都像是串行的。而这种“看上去像串行”的设计逐渐变得不适用。处理器的设计者们为单核提升速度变得越来越困难。进入多核时代，我们必须面对的情况是：无论是表面上还是实质上，指令都不再串行执行了。我们将在2.2节的“内存可见性”部分展开讨论。数据级（data）并行数据级并行（也称为“单指令多数据”，SIMD）架构，可以并行地在大量数据上施加同一操作。这并不适合解决所有问题，但在适合的场景却可以大展身手。图像处理就是一种适合进行数据级并行的场景。比如，为了增加图片亮度就需要增加每一个像素的亮度。现代GPU（图形处理器）也因图像处理的特点而演化成了极其强大的数据并行处理器。任务级（task-level）并行终于来到了大家所认为的并行形式一一多处理器。从程序员的角度来看，多处理器架构最明显的分类特征是其内存模型（共享内存模型或分布式内存模型）。 4 第1章概述对于共享内存的多处理器系统，每个处理器都能访问整个内存，处理器之间的通信主要通过内存进行，如图1-1所示。内存 y 总线缓存处理器缓存处理器图1-1共享内存的多处理器系统大处理器对于分布式内存的多处理器系统，每个处理器都有自已的内存，处理器之间的通信主要通过网络进行，如图1-2所示。网络处理器内存处理器内存图1-2分布式内存的多处理器系统 y 处理器内存通过内存通信比通过网络通信更简单更快速，所以用共享内存编程往往更容易。然而，当处理器个数逐渐增多，共享内存就会遭遇性能瓶颈- 一此时不得不转向分布式内存。如果要开发一个容错系统，就要使用多台计算机以规避硬件故障对系统的影响，此时也必须借助于分布式内存。 1.3并发：不只是多核 1.3并发：不只是多核 5 使用并发的目的，不仅仅是为了让程序并行运行从而发挥多核的优势。若正确使用并发，程序还将获得以下优点：及时响应、高效、容错、简单。并发的世界，并发的软件世界是并发的，为了与其有效地交互，软件也应是并发的。手机可以同时播放音乐、上网浏览、响应触屏动作。我们在IDE中输人代码时，IDE正在后台悄悄检查代码语法。飞机上的系统也同时兼顾了好几件事情：监控传感器、在仪表盘上显示信息、执行指令、操纵飞行装置调整飞行姿态。并发是系统及时响应的关键。比如，当文件下载可以在后台进行时，用户就不必一直町着鼠标沙漏而烦心了。再比如，Web服务器可以并发地处理多个连接请求，一个慢请求不会影响服务器对其他请求的响应。分布式的世界，分布式的软件有时，我们要解决地理分布型问题。软件在非同步运行的多台计算机上分布式地运行，其本质是并发。此外，分布式软件还具有容错性。我们可以将服务器一半部署在欧洲，另一半部署在美国，这样如果一个区域停电就不会造成软件整体不可用。下面就介绍容错性不可预测的世界，容错性强的软件软件有bug，程序会崩溃。即使存在完美的没有bug的程序，运行程序的硬件也可能出现故障。为了增强软件的容错性，并发代码的关键是独立性和故障检测。独立性是指一个故障不会影响到故障任务以外的其他任务。故障检测是指当一个任务失败时（原因可能是任务崩溃、失去响应或硬件故障），需要通知负责故障处理的其他任务来处理。串行程序的容错性远不如并发程序，复杂的世界，简单的软件如果曾经花费数小时纠结在一个难以诊断的多线程bug上，那你可能很难接受这个结论，但 ①作者在此处用到了两个词：fault-tolerant和resilient，中文都译为“容错性”，但两者略有区别。由于这种微小的区别不会影响对本书的理解，因此之后的译文不再区分两者，统一使用“容错性”以方便读者理解。一译者注 6第1章概述在选对编程语言和工具的情况下，比起串行的等价解决方案，一个并发的解决方案会更简洁清晰。在处理现实世界的并发问题时，这个结论可以得到印证。用串行方案解决一个并发问题往往需要付出额外的代价，而且解决方案会嗨涩难懂。如果解决方案有着与问题类似的并发结构，就会简单许多：我们不需要创建一个复杂的线程来处理问题中的多个任务，只需要用多个简单的线程分别处理不同的任务即可。 1.4七个模型本书精心挑选了七个模型来介绍并发与并行。线程与锁：线程与锁模型有很多众所周知的不足，但仍是其他模型的技术基础，也是很多并发软件开发的首选。函数式编程：函数式编程日渐重要的原因之一，是其对并发编程和并行编程提供了良好的支持。函数式编程消除了可变状态，所以从根本上是线程安全的，而且易于并行执行。 Clojure之道分离标识与状态：编程语言Clojure是一种指令式编程和函数式编程的混搭方案，在两种编程方式上取得了微妙的平衡来发挥两者的优势。 actor：actor模型是一种适用性很广的并发编程模型，适用于共享内存模型和分布式内存模型，也适合解决地理分布型问题，能提供强大的容错性。通信顺序进程（CommunicatingSequentialProcesses，CSP）：表面上看，CSP模型与actor模型很相似，两者都基于消息传递。不过CSP模型侧重于传递信息的通道，而actor模型侧重于通道两端的实体，使用CSP模型的代码会带有明显不同的风格。数据级并行：每个笔记本电脑里都藏着一台超级计算机一一GPU。GPU利用了数据级并行不仅可以快速进行图像处理，也可以用于更广阔的领域。如果要进行有限元分析、流体力学计算或其他的大量数字计算，GPU的性能将是不二选择。 Lambda架构：大数据时代的到来离不开并行一一现在我们只需要增加计算资源，就能具有处理TB级数据的能力。Lambda架构综合了MapReduce和流式处理的特点，是一种可以处理多种大数据问题的架构。以上每种模型都有各自的甜区。请带着以下的问题来阅读之后的章节。口这个模型适用于解决并发问题、并行问题，还是两者皆可？口这个模型适用于哪种并行架构？口这个模型是否有利于我们写出容错性强的代码，或用于解决分布式问题的代码？下一章将介绍第一个模型：线程与锁模型。 ①球类运动中球拍上最适合击球的区域。—一译者注第2章线程与锁线程与锁模型就像一辆福特T型车：驾驶它可以到达目的地，但与新的技术相比，它显得原始且难以驾驭，不可靠还有点儿危险。抛开那些众所周知的缺点，线程与锁模型仍是开发并发软件的首选技术，它也支撑了本书将要介绍的其他技术。你可能不会直接用到这个模型，但也应该了解它是如何工作的。 2.11 简单粗暴线程与锁模型其实是对底层硬件运行过程的形式化。这种形式化既是该模型最大的优点，也是它最大的缺点。线程与锁模型非常简单直接，几乎所有编程语言都以某种形式对其提供了支持，且不对其使用方式加以限制。换句话说，对于不精通该模型的程序员，编程语言没有提供足够的帮助，使得程序容易出错且难以维护。我们将借助Java语言来学习线程与锁模型，但所述内容也适用于其他语言。第一天，将学习 Java的多线程代码、潜在的坑以及一些避免踩坑的原则。第二天，将进一步学习java.util. concurrent包提供的工具。第三天，学习一些由标准库提供的并发数据结构，尝试使用其解决一个现实问题。第一天的学习将从Java提供的底层服务开始。现在的优秀代码很少直接使用底层服务，而是使用将在随后讨论的高层服务。要理解高层服务，我们必须先理解基础的底层服务，但请注意：不应在产品代码上直接使用Thread类等底层服务。 8 第2章线程与锁第一天：互斥和内存模型 2.2 如果你曾经接触过并发编程，那一定熟悉互斥这个概念一一用锁保证某一时间仅有一个线程可以访问数据。你也肯定熟悉互斥带来的麻烦，比如说竞态条件和死锁（如果对此不熟悉也无妨，稍后都会介绍）我们会详细讨论实践中使用共享内存带来的一些问题，但首先需要关注更基础更重要的内容一一内存模型。如果你认为竞态条件和死锁会导致一系列很奇怪的现象，那就对共享内存的诡异程度拭目以待吧。想超越自我？让我们从创建一个线程开始。创建线程 Java中，并发的基本单元是线程，可以将线程看作控制流（threadofcontrol）。线程之间通过共享内存进行通信。俗话说：一切编程皆始于“Hello，World!”。我们也不免俗地来个多线程版本： ThreadsLocks/HelloWorld/src/main/java/com/paulbutcher/HelloWorld.java public class Helloworld { public static void main(Stringl) args) throws InterruptedException { ThreadmyThread=newThread() pubiic void run() { System.out.printin("Hello from new thread");; myThread.start(); Thread.yield(); System.out.println("Heilo from main thread"); myThread.join(); 这段代码创建并启动了一个Thread实例。首先从start（）开始，myThread.run（）函数与 main（）函数的余下部分一起并发执行。最后main线程调用join（）来等待myThread线程结束（即 run(函数返回）运行这段代码的结果可能是 Hello from main thread Hello from new thread 也可能是 Hello from new thread Hello from main thread 2.2第一天：互斥和内存模型究竞是哪种运行结果完全取决于哪个线程先执行println（）（我的测试结果是各占50%）。多线程编程很难的原因之一就是运行结果可能依赖于时序，多次运行的结果并不稳定。小乔爱问： Thread.yield的作用？在多线程版本的“Hello,World!”中我们使用了Thread.yield(），根据相关的Java文档，其作用是：通知调度器：当前线程想要让出对处理器的占用。如果不调用Thread.yield（），由于创建新线程要花费一些时间，那么main线程几儿乎肯定会先执行println（）（当然并不保证一定会如此一稍后我们将学到一个规律：并发编程中如果某事可能会发生，那么不论多艰难它一定会发生，而且可能发生在最不利的时刻。试将Thread.yield（）注释掉，看看会发生什么如果换成Threadsleep（l）呢？第一把锁多个线程同时使用共享内存时，它们往往会“打成一片”。为避免如此，我们可以使用锁达到线程互斥的目的，即某一时间至多有一个线程能持有锁。先创建两个线程，并使其交互： ThreadsLocks/Counting/src/main/java/com/paulbutcher/Counting.java public class Counting ( pubiic static void main(stringll args) throws InterruptedException class Counter private int count = o; public void increment()++count;} public int getCount(){return count;} final Counter counter = new Counter(); class CountingThread extends Thread pubiic void run() for(int X = 0; ×< 10000; ++x) counter.increment(); CountingThread tl = new CountingThread(); CountingThread t2=new CountingThread() tl.start();t2.start(); tl.join();t2.join); System.out.println(counter.getCount()); 10 第2章线程与锁这段代码创建了二个简单的counter类和两个线程，每个线程都调用counter.increment（） 10000次。这段代码看上去很简单但很脆弱。运行这段代码，每次都将获得不同的结果。最后三次测试的结果是13850、11867和12616。各操作的时序）如果不能理解上面这段话，那让我们来考虑一下Java编译器是如何解释++count的。其字节码是： getfield #2 iconst_1 iadd putfield #2 即使你不熟悉JVM字节码，也可以瑞测出这段代码的意图：getfield#2用于获取count 的值，iconst1和iadd将获得的值加l，putfield#2将更新的值写回count中。这就是通称的读一改-写（read-modify-write）模式。假如两个线程同时调用increment（），线程1执行getfield#2，获得值42。在线程1执行其他动作之前，线程2也执行了getfield#2，获得值42。糟糕的是，现在两个线程都将获得的值加l，将43写回count中。结果count只被递增了一次，而不是两次。竞态条件的解决方案是对count进行同步（synchronize）访问。一种方法是使用Java对象原生的内置锁（也被称为互斥锁（mutex）、管程（monitor）或临界区（criticalsection））来同步对 increment（）的调用： ThreadsLocks/CountingFixed/src/main/java/com/paulbutcher/Counting.java classCountert private int count =o; pubuic synchronized void increment(){++count;} pubuic int getCount() f return count;} 线程进入increment（）函数时，将获取Counter对象级别的锁，函数返回时将释放该锁。某一时间至多有一个线程可以执行函数体，其他线程调用函数时将被阻塞直到锁被释放（稍后我们将了解到：对于这种只涉及一个变量的互斥场景，使用java.util.concurrnet.atomic包是更好的选择。毋庸置疑，对于增加了同步功能的代码，每次执行都将得到正确结果20000。但前路漫漫一一代码中仍隐藏了一个bug，我们马上介绍其中的关穷。诡异的内存我们用一个小测试来开场，请猜测一下这段代码的输出： 2.2第一天：互斥和内存模型 ThreadsLocks/Puzzle/src/main/java/com/paulbutcher/Puzzle.java Line1 publicclass Puzzlef static boolean answerReady = false; static int answer = o; static Thread tl = new Thread() f public void run() answer=42; answerReady - true; 10 15 20 static Thread t2 = new Thread(){ public void run() if (answerReady) System.out.println("The meaning of ife is: " + answer); etse System.out.println("I don't know the answer"); public static void main(String[l args) throws InterruptedException tl.start(); t2.start(); tl.join();t2.join; 11 如果你的第一反应是“竞态条件”，那么恭喜你答对了。根据线程执行的时序，这段代码的输出可能是Themeaningof lifeisXx或者Idontknowtheanswer。但不止于此，还有一种结果可能是： The meaning of life is:o 什么？！当answerReady为true时answer可能为o吗？这仿佛是第6行和第7行在我们眼皮底下颠倒了执行顺序。但是乱序执行是完全有可能发生的。以下所述均为事实：口编译器的静态优化可以打乱代码的执行顺序；口JVM的动态优化也会打乱代码的执行顺序；口硬件可以通过乱序执行来优化其性能。比乱序执行更糟糕的是，有时一个线程产生的修改可能对另一个线程不可见。如果将run（）写成： public void run() { while (!answerReady) Thread.sleep(100); System.out.println("The meaning of life is: " + answer); answerReady可能不会变成true，代码运行后无法退出。 12第2章线程与锁从直觉上来说，编译器、JVM、硬件都不应插手修改原本的代码逻辑。但是，近几年的运行效率提升，尤其是共享内存架构的运行效率提升，都仰仗于此类代码优化。因此我们也无法摆脱此类优化的副作用的影响。显然，需要有标准来明确告诉我们，可能发生怎样的副作用，这就是Java内存模型内存可见性 Java内存模型定义了何时一个线程对内存的修改对另一个线程可见。基本原则是，如果读线程和写线程不进行同步，就不能保证可见性。我们已经见过一种同步的方法一一就是通过获取对象的内置锁。其他的方法包括：开启一个线程并通过join（）检查线程是否已经终止；使用java.util.concurrent包提供的工具。很容易被忽略的一个重点是：两个线程都需要进行同步。只在其中一个线程进行同步是不够的，这正是之前竞态条件解决方案中潜藏bug的原因：除了increment（)之外，getCount（)方法也需要进行同步。否则，调用getCount（）的线程可能获得一个失效的值（对于前面交互的两个线程，getCount（)在join（）之后被调用，因此是线程安全的。但这种设计为其他调用 getCounter（)的代码埋下了隐患）。至此，我们讨论了竞态条件和内存可见性，这两类问题都可能让多线程程序运行结果出错。下面我们将介绍第三类问题：死锁。多把锁综上所述，很容易得出一个结论：让多线程代码安全运行的方法只能是让所有的方法都同步。然而，这也会带来问题。首先这样做效率低下。如果每个方法都同步，大多数线程会频繁阻塞，使程序失去了并发的意义。问题不止于此，当使用多把锁时（Java中每一个对象都有自已的内置锁），线程之间可能发生死锁。我们将借助一个学术论文中经常使用的经典模型来诠释死锁一一哲学家进餐问题。问题场景是五位哲学家围绕一个圆桌就坐，如图2-1所示，桌上摆着五支（不是五双）筷子。哲学家的状态可能是“思考”或者“饥饿”。如果饥饿，哲学家将拿起他两边的筷子并进餐一段时间（当然，这些哲学家都是男性，女性在餐桌上会更优雅一些）。进餐结束，哲学家就会放回筷子。 ①http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4 ②对不同对象的方法进行同步就会用到多把锁。一译者注图2-1 下面的代码实现了哲学家的行为： 2.2 哲学家进餐问题第一天；互斥和内存模型 ThreadsLocks/DiningPhilosophers/src/main/java/com/paulbutcher/Philosopher.java Line1 class Philosopher extends Thread private Chopstick left, right; private Random random; 5 10 15 20 public Philosopher(Chopstick left, Chopstick right){ this.left =left; this.right = right; random = new Random(); public void run() try while(true) ( Thread.sleep(random.nextInt(1ooo)); synchronized(left) synchronized(right) 思考一段时间 1/拿起筷子1 //拿起筷子2 Thread.sleep(random.nextInt(1ooo））；//进餐一段时间 }catch(InterruptedException e){) 第14、15行使用了另一种方式来获取对象的内置锁：synchronized（object）。 13 在我的计算机上测试过五个哲学家实例，它们可以愉快地运行很久（最长时间是一周），直到某个时刻一切突然都停了下来。稍加分析就知道发生了什么：如果所有哲学家同时决定进餐，都拿起左手边的筷子，那么就 ①第一种方式是在函数上使用synchronized关键字。译者注 14 第2章线程与锁无法进行下去一一所有人都持有一只筷子并等待右手边的人放下筷子。这时死锁就出现了。一个线程想使用多把锁时，就需要考虑死锁的可能。幸运的是，有一个简单的规则可以避开死锁一一总是按照一个全局的固定的顺序获取多把锁。其中一种实现如下： ThreadsLocks/DiningPhilosophersFixed/src/main/java/com/paulbutcher/Philosopher.java classPhilosopher extendsThread private Chopstick first, second; private Random random; public Philosopher(Chopstick left,Chopstick right) if(left.getId() listeners; pubuicDownloader(URLurl,String outputFilename)throws IoException in=url.openConnection().getInputstream(); out = new Fileoutputstream(outputFilename); listeners = new ArrayList(); public synchronized void addListener(ProgressListener listener) listeners.add(listener); public synchronized void removeListener(ProgressListener listener) f listeners.remove(listener); private synchronized void updateProgress(int n) for (ProgressListener listener: listeners) listener.onProgress(n); public void run() t int n =o, total =o; byte[] buffer = new byte[1024]; try t while((n = in.read(buffer)) != -1){ out.write(buffer, o, n); total +=n; updateProgress(total); out.flush(); catch (IOException e){ 16第2章线程与锁 addListener（）、removeListener（）和updateProgress（）都是同步方法，多线程可以安全地使用这些方法。尽管这段代码仅使用了一把锁，但仍隐藏着一个死锁陷阱。陷阱在于updateProgress（)调用了一个外星方法一但对于这个外星方法一无所知。外星方法可以做任何事情，例如持有另外一把锁。这样一来，我们就在对加锁顺序一无所知的情况下使用了两把锁。就像前面提到的，这就有可能发生死锁。唯一的解决思路是避免持有锁时调用外星方法。一种方法是在遍历之前对listeners进行保护性复制（defensivecopy），再针对这份副本进行遍历： ThreadsLocks/HttpDownloadFixed/src/main/java/com/paulbutcher/Downloader.java private void updateProgress(int n)f ArrayListTistenersCopy; synchronized(this){ listenersCopy = (ArrayList)listeners.clone(); for (ProgressListener listener:listenersCopy) listener.onProgress(n); 这是个一石多鸟的方法。不仅在调用外星方法时不用加锁，而且大大减少了代码持有锁的时间。长时间地持有锁将影响性能（降低了程序的并发度），也会增加死锁的可能。保护性复制也修复了与并发无关的另一个bug一修复后如果监听器在onProgress（)中调用removeListener(），将不会影响到正在进行遍历的副本。第一天总结第一天的学习即将结束。我们通过代码学习了Java多线程的基础，在第二天的学习中将介绍标准库提供的更好的实现方式。第一天我们学到了什么本节介绍了如何创建线程，并用Java对象的内置锁实现互斥。还介绍了线程与锁模型带来的三个主要危害一一竞态条件、死锁和内存可见性，并讨论了一些帮助我们避免危害的准则：口对共享变量的所有访问都需要同步化：口读线程和写线程都需要同步化；口按照约定的全局顺序来获取多把锁；口当持有锁时避免调用外星方法；口持有锁的时间应尽可能短。第一天自习查找口阅读WilliamPugh的网站“Java内存模型”。口自学JSR133（Java内存模型）的FAQ。 2.3第二天：超越内置锁 17 口Java内存模型是如何保证对象初始化是线程安全的？是否必须通过加锁才能在线程之间安全地公开对象？口了解反模式“双重检查锁模式”（double-checkedlocking）以及为什么称其为反模式。实践口对于哲学家进餐问题，用最开始有死锁隐患的代码做一些试验。尝试变更哲学家思考状态的时长、进餐状态的时长以及哲学家的人数。这些变量对于出现死锁的时机有什么影响？设想我们正在进行调试，那应该如何增大重现死锁的几率？口（困难）编写一段程序，在不使用同步的前提下，模拟内存写操作的乱序执行。这个任务之所以有难度，是因为Java内存模型可能不会优化过于简单的例子，故找到这个优化场景比较困难。 2.3第二天：超越内置锁第一天我们学习了Java的Thread类和Java对象的内置锁。在过去的很长一段时间内，这几乎是Java对并发编程提供的所有支持。Java5通过引l人java，util.concurrent包改善了这个状况。今天我们将学习这种增强的锁机制。内置锁虽然方便但限制很多：口一个线程因为等待内置锁而进入阻塞之后，就无法中断该线程了；口尝试获取内置锁时，无法设置超时；口获得内置锁，必须使用synchronized块。 synchronized(object）（《使用共享资源》这种用法的限制是获取锁和释放锁的代码必须严格嵌在同一个方法中。另外，声明 synchronized的函数其实只是个“语法糖”，其等价于将函数体按以下形式进行包装： synchronized(this){《函数体》与synchronized不同，ReentrantLock提供了显式的lock和unlock方法，可以突破上述几个限制。在深人学习之前，先来看一下ReentrantLock是如何替代synchronized工作的： Lock lock = new ReentrantLock(); lock.lock(); tryt 18 第2章线程与锁《使用共享资源》 finally lock.unlock(); 这段代码中，使用try，：：finally是个很好的实践，无论被锁保护的代码发生了什么，都可以确保锁会被释放。现在我们来看看ReentrantLock是如何突破限制的。可中断的锁使用内置锁时，由于阻塞的线程无法被中断，程序不可能从死锁中恢复。我们来看一个小例子，制造一个死锁并尝试中断线程。 ThreadsLocks/Uninterruptible/src/main/java/com/paulbutcher/Uninterruptible.java pubtic class Uninterruptible public staticvoid main(stringll args)throwsInterruptedException final Objectol =newObject();finalobject o2=new object(); Threadti =new Thread() pubtic void run() f try synchronized(ol){ Thread.sleep(1000); synchronized(o2) catch (InterruptedException e){ System.out.println("tlinterrupted");}; Threadt2=newThread() public void run() f try synchronized(o2) Thread.sleep(1000); synchronized(ol) } catch(InterruptedException e){system.out.println("t2 interrupted"); tl.start(); t2.start(); Thread.sleep(2000); tl.interrupt();t2.interrupt(); tl.join(); t2.join(); 2.3第二天：超越内置锁这段程序将永远死锁下去一一跳出死锁唯一的方法是终止JVM的运行。小乔爱间真的没办法终止死锁的线程吗？ 19 你可能认为肯定有某种方法来终止一个死锁线程。遗憾的是确实没有。所有这类方法都被证明有缺陷而不推荐使用。终止线程的最终手段是让run（）函数返回（可能是通过抛出InterruptedException）。不过，如果你的线程由于等待内置锁而陷入死锁，且不能中断其等待锁的状态，那么要终止死锁线程就只剩下终止JVM运行这条路了。 a.http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html 不过还是有办法解决这个限制的。我们可以用ReentrantLock替代内置锁，使用它的 lockInterruptibly()方法： ThreadsLocks/lnterruptible/src/main/java/com/paulbutcher/lnterruptiblejava final ReentrantLock ll = new ReentrantLock(); final ReentrantLock 12 = new ReentrantLock(); Thread tl = new Thread() { public void run()t try li.lockInterruptibly(); Thread.sleep(1000); 12.lockInterruptibly(); j catch (InterruptedException e)( system.out.println("ti interrupted");} 这一次Thread，interrupt（）可以让线程终止。代码的确比之前稍微复杂一点，这就算是为中断死锁线程付出的一点代价吧。超时 ReentrantLock突破了内置锁的另一个限制：可以为获取锁的操作设置超时时间。利用这个功能，我们可以通过另一种方法来解决第一天的哲学家进餐问题。下面是修改后的Philosopher类，拿起两根筷子失败时会超时： ThreadsLocks/DiningPhilosophersTimeout/src/main/java/com/paulbutcher/Philosopher.jav class Philosopher extends Thread ↑ private ReentrantLock leftChopstick, rightChopstick; 20 第2章线程与锁 privateRandomrandom; public Philosopher(ReentrantLock leftChopstick, ReentrantLock rightChopstick) this.leftChopstick=leftChopstick;this.rightChopstick=rightchopstick; random=newRandom(); public void run() tryt while(true){ Thread.sleep（random.nextInt(1ooo))；//思考一段时间 leftChopstick.lock(); tryt if(rightChopstick.tryLock(iooo,TimeUnit.MILLISECoNDS)) //获取右手边的筷子 tryt Thread.sleeprandom.nextInt(1ooo）)；//进餐一段时间 Jfinalyrightchopstick.unlock(O;) Telse //没有获取到右手边的筷子，放弃并继续思考 finally fleftChopstick.unlock();) catch(InterruptedException e)（) 这段代码用到了tryLock(）。相比lock（），它在获取锁失败时有超时机制。我们虽然没有遵循“按全局的固定的顺序获取锁”的准则，但这个版本的代码并不会死锁（至少不会无尽地死锁下去）。活锁虽然tryLock（方案避免了无尽地死锁，但这并不是一个足够好的方案。首先，这个方案并不能避免死锁一一它只是提供了从死锁中恢复的手段。其次，这个方案会受到活锁现象的影响一如果所有死锁线程同时超时，它们极有可能再次陷入死锁。虽然死锁没有永远持续下去，但对资源的争夺状况却没有得到任何改善。有一些方法可以减小活锁的几率。比如为每个线程设置不同的超时时间，来减少所有线程同时超时的几率。但通过设置超时来处理死锁不能说是一个好的方案一一以后我们还可以做得更好。交替锁（hand-over-handlocking）设想我们要在链表中插人一个节点。一种做法是用锁保护整个链表，但链表加锁时其他使用 2.3第二天：超越内置锁 21 者无法访问链表。而交替锁可以只锁住链表的一部分，允许不涉及被锁部分的其他线程自由访问链表，如图2-2所示。 o 2 图2-2交替锁插入新的链表节点时，需要将待插入位置两边的节点加锁。首先锁住链表的前两个节点。如果这两节点之间不是待插人位置，那么就解锁第一个节点，并锁住第三个节点。如果被锁住的两节点之间仍不是待插入位置，就解锁第二个节点，并锁住第四个节点。以此类推，直到找到待插入位置并插入新的节点，最后解锁两边的节点。这种交替式的加锁和解锁顺序是无法用内置锁实现的，但使用ReentrantLock就可以在需要的地方调用lock（）和unlock（）。我们用下面的类来实现使用交替锁的有序链表。 ThreadsLocks/LinkedList/src/main/java/com/paulbutcher/ConcurrentSortedList.java Line1classConcurrentSortedList private class Node { int value; Nodeprev; Nodenext; ReentrantLocklock=newReentrantLock(); Node( 22 10 15 20 25 30 35 40 第2章·线程与锁 Node(int value, Node prev, Node next) { this.value =value; this.prev = prev; this.next = next; private final Node head; private final Node tail; pubtic ConcurrentSortedList() head = new Node(); tail = new Node(); head.next = tail; tail.prev = head; public void insert(int value) { Node current = head; current.lock.lock(); Node next = current.next; try while(true) next.lock.lock(); try if (next == tail ll next.value < value) ( Node node = new Node(value, current, next); next.prev= node: current.next = node; return; finally( current.lock.unlock();) current = next; next = current.next; }finaulynext.lock.unlock();} insert（）方法保证链表是有序的：遍历链表直到找到第一个值小于新插入值的节点位置，在这个位置前插入新节点。第26行锁住了链表的头节点，第30行锁住了下一个节点。接下来检测两个节点之间是否是待插入位置。如果不是，则在第38行解锁当前节点并继续遍历。如果找到待插入位置，第33~36 行构造新节点并将其插入链表后返回。两把锁的解锁操作在两个finally块中进行（第38行和第42行）。这种方案不仅可以让多个线程并发地进行链表插人操作，还能让其他的链表操作安全地并发。比如计算链表节点个数，只需倒序遍历链表即可： ThreadsLocks/LinkedList/src/main/java/com/paulbutcher/ConcurrentSortedList.java public int size(){ Node current = tail; int count = o; while (current.prev !=head){ ReentrantLock lock = current.lock; lock.lock(); try t ++count; current - current.prev; finallytlock.unlock();} C return count; 1小乔爱问：难道不会违背“全局顺序”规则吗？ 2.3第二天：超越内置锁 23 ConcurrentSortedList的insert（）方法从链表头开始向链表尾依次获取锁。size（）方法从链表尾向链表头依次获取锁。难道这样不违背“总是按照一个全局的固定的顺序获取多把锁”的规则吗？答案是并不违背，因为size()方法从不持有多把锁其在某一时间并不持有一把以上的锁。接下来我们学习ReentrantLock的另一个特性—条件变量。条件变量并发编程经常需要等待某个事件发生。比如从队列删除元素前需要等待队列非空、向缓存添加数据前需要等待缓存有足够的空间。条件变量就是为这种情况而设计的。建议按照下面的模式使用条件变量： ReentrantLocklock=newReentrantLock(); Conditioncondition=lock.newCondition(); lock.lock(); tryt while（！《条件为真》） condition.await();《使用共享资源》 +finaly lock.unlock();} 一个条件变量需要与一把锁关联，线程在开始等待条件之前必须获取这把锁。获取锁后，线程检查所等待的条件是否已经为真。如果条件为真，线程将解锁并继续执行。 24 第2章线程与锁如果所等待的条件不为真，线程会调用await（），它将原子地解锁并阻塞等待该条件。所谓个操作是原子的，指的是从另一个线程的角度看上去，该操作的状态只能是“已发生”或者“未发生”，而不会是发生了一半。当另一个线程调用了signal（)或signalAll（），意味着对应的条件可能变为真，await（）将原子地恢复运行并重新加锁。需要注意的是当await（）函数返回时，只意味着等待的条件可能为真。这就是为什么要在一个循环中调用await（）的原因一一从await（）返回后，需要重新检查等待的条件是否为真，必要的话可能再次调用await（)并阻塞。我们又有了解决“哲学家进餐问题”的新方法： ThreadsLocks/DiningPhilosophersCondition/src/main/java/com/paulbutcher/Philosopher.java class Philosopher extends Thread { private boolean eating; private Philosopher left; private Philosopher right; private ReentrantLock table; private Condition condition; private Random random; publicPhilosopher(ReentrantLocktable) eating = falsei this.table = table; condition = table.newCondition(); random =new Random(); public void setLeft(Philosopher left) { this.left = left; } pubiicvoid setRight(Philosopher right)(this.right=right;} public void run()t try while (true){ think(); eat(); catch（InterruptedException e）() private void think()throws InterruptedException { table.lock(); try eating = false; left.condition.signal(); right.condition.signal(); finally(table.unlock(); Thread.sleep(10oo); private void eat() throws InterruptedException table.lock(); try while (left.eating Il right,eating) condition.await(); eating = true; finally(table.unlock();} Thread.sleep(10oo); 2.3第二天：超越内置锁 25 与之前不同，现在的方法只使用一把锁（table），且没有Chopstick类。我们将竞争从对筷子的争夺转换成了对状态的判断：仅当哲学家的左右邻座都没有进餐时，他才可以进餐。换句话说，一个饥饿的哲学家是在等待下面的条件： !(left.eating I right.eating) 当一个哲学家饥饿时，他首先锁住餐桌，这样其他哲学家无法改变状态，然后查看左右邻座当一个哲学家进餐结束并开始思考时，他首先锁住餐桌并将eating设为false，然后通知左右邻座可以进餐了，最后解锁餐桌。如果左右邻座目前正在等待，那么他们将被唤醒，重新锁住餐桌，并判断是否可以开始进餐。虽然这段代码看上去比之前的解决方案复杂得多，但换来的是并发度的显著提升。在前一个解决方案中，经常出现的状况是只有一个哲学家能进餐，因为其他人都持有一根筷子并在等待另外一根。在这个解决方案中，当一个哲学家理论上可以进餐（他的邻座都没有进餐）时，他肯定可以进餐。我们已经介绍了ReentrantLock。下面将介绍另一个内置锁的替代方案一一原子变量。原子变量在第一天的学习中，我们为多线程计数器的increment（方法增加了同步特性（参见2.2节的“第一把锁”部分）。java.util.concurrent，atomic包提供了更好的方案： ThreadsLocks/CountingBetter/src/main/java/com/paulbutcher/Counting.java public class Counting public static void main(stringll args)throwsInterruptedException finalAtomicIntegercounter=newAtomicInteger(); class CountingThread extends Thread pubuic void run(){ for(int X=o;×<10000;++x) counter.incrementAndGet(); 26 第2章线程与锁 CountingThread ti = new CountingThread(); CountingThreadt2=newCountingThread(); ti.start();t2.start(); tl.join();t2.join(); system.out.printin(counter.get()); AtomicInteger的incrementAndGet（）方法功能上等价于++count（AtomicInteger也提供了getAndIncrement方法，等价于count++）。不过与++count不同，incrementAndGet（）方法是原子操作。与锁相比，使用原子变量有诸多好处。首先，我们不会忘了在正确的时候获取锁。例如，因 getCount（)忘了同步而引发的Counter内存可见性的问题将不会发生。其次，由于没有锁的参与，对原子变量的操作不会引发死锁。最后，原子变量是无锁（lock-free）非阻塞（non-blocking）算法的基础，这种算法可以不用锁和阻塞来达到同步的目的。无锁的代码比起有锁的代码更为复杂。幸运的是， java.util.concurrent包中的类都尽量使用了无锁的代码，我们可以在一定程度上免于亲自实现的痛苦。我们将在第三天来学习这些类，而现在先来完成第二天的最后一点内容。小乔爱间： volatile变量？我们可以将Java变量标记成volatile。这样可以保证变量的读写不被乱序执行。在之前的测试中（参见2.2节的“诡异的内存”部分），我们可以将answerReady标记成volatile，来解决Puzzle类的问题。 volatile是一种低级形式的同步。它并不能解决Counter的问题（参见2.2节的“第一把锁”部分），因为将count标记成volatile并不能保证count++操作是原子的。随着JVM被不断优化，其提供了一些低开销的锁，volatile变量的适用场景也越来越少。如果你考虑使用volatile，也许应当在java.utit.concurrent.atomic包中寻找更合适的工具。第二天总结我们在第一天的基础上，学习了java，util.concurrent.locks包和java.util.concurrent， 2.4第三天：站在巨人的肩膀上 27 atomic包提供的更复杂更灵活的工具。学习和理解这些工具很重要，但经过第三天的学习后我们就会发现实际上很少会直接使用锁。第二天我们学到了什么 ReentrantLock和java.util.concurrent.atomic突破了使用内置锁的限制，利用新的工具我们可以做到：口在线程获取锁时中断它；口设置线程获取锁的超时时间口按任意顺序获取和释放锁；口用条件变量等待某个条件变为真；口使用原子变量避免锁的使用。第二天自习查找口ReentrantLock创建时可以设置一个描述公平性的变量。什么是“公平”的锁？何时适合使用公平的锁？使用非公平的锁会怎样？口什么是ReentrantReadwriteLock？它与ReentrantLock有什么区别？适用于什么场景？口什么是“虚假唤醒”（spuriouswakeup）？什么时候会发生虚假唤醒？为什么符合规范的代码不用担心虚假唤醒？口什么是AtomicIntegerFieldUpdater？它与AtomicInteger有什么区别？适用于什么场景？实践口在用条件变量解决哲学家进餐问题时，如果将条件变量所在的循环换成if会发生什么？将看到哪些失败的现象？如果将signal（）换成signalAll（）会发生什么？会引发什么问题？口内置锁比ReentrantLock限制更多，与之类似，内置锁也支持一种限制较多的条件变量。用内置锁、wait（）、notify（)或notifyAul（)重新解决哲学家进餐问题。为什么内置锁比ReentrantLock效率更低？口重写concurrentSortedList，用一把锁代替交替锁。测试两个方案的性能。交替锁是否有更好的性能？什么情况适用于交替锁？什么情况不适用？ 2.4第三天：站在巨人的肩膀上 java.util.concurrent包不仅提供了第二天介绍的比内置锁更好的锁，还提供了一些通用、高效、bug少的并发数据结构和工具。在实际应用中，较之自已生成解决方案，我们应更多地使 2 28 第2章主线程与锁用这些久经考验的工具。创建线程之终极版第一天我们学习了如何创建线程，但在实际应用中很少会直接创建线程。举个例子，下面是一个非常简单的服务器，回显接收到的数据： ThreadsLocks/EchoServer/src/main/java/com/paulbutcher/EchoServer.java public class EchoServer f public staticvoidmain(string[i args)throwsIoException( class ConnectionHandler implements Runnable { Inputstream in; outputstream out; ConnectionHandler(Socket socket) throws IoException f in = socket.getInputstream(); out = socket.getoutputstream(); public void run()f tryt int n; bytel] buffer = new byte[1024]; white((n=in.read(buffer))!=-1){ out.write(buffer,o,n); out.flush(); t catch(I0Exceptione)（) ServerSocket server = new ServerSocket(4567); while (true) Socketsocket=server.accept() Threadhandler =newThread(new ConnectionHandler(socket)); handler.start(); A 子标记出来的代码行用于接受一个连接请求并创建一个处理线程。这样的设计虽然能正常工作，但存在两个隐患：第一，创建线程的代价虽然很低，但也没低到能直接忽略的程度，而每个连接都花费了这个代价；第二，如果为每个连接都创建一个线程，当请求连接的速度高于处理连接的速度时，系统的线程数也会随之快速增长，服务器将停止服务甚至崩溃。这就给那些想对服务器进行拒绝服务攻击的人提供了可乘之机。我们可以用线程池来避免这些问题： 2.4第三天：站在巨人的肩膀上 ThreadsLocks/EchoServerBetter/src/main/java/com/paulbutcher/EchoServer.java intthreadPoolsize=Runtime.getRuntime().availableProcessors()*2; ExecutorServiceexecutor =Executors.newFixedThreadPool(threadPoolSize); white(true）{ Socket socket server.accept(); executor,execute(new ConnectionHandler(socket)); 29 这段代码创建了一个线程池，线程池的大小设为可用处理器数的2倍。如果同一时间有超过线程池大小的execute（）请求存在，超出的部分将进行排队直到某线程被释放。现在我们不必再为每个连接都消耗资源来创建线程，而且服务器在面临高负载时也能继续运转（不能保证服务器对所有连接都及时响应，但至少可以响应其中一部分）。写入时复制第一天我们曾学习过在并发程序中如何安全地调用监听器，当时在updateProgress（)中创建了一个保护性复制（参见2.2节中“来自外星方法的危害”部分）。Java标准库提供了更优雅的现成方案—CopyonwriteArrayList： ThreadsLocks/HttpDownloadBetter/src/main/java/com/paulbutcher/Downloader.java private CopyOnwriteArrayList listeners; public void addListener(ProgressListener listener)( listeners.add(listener); public void removeListener(ProgressListener listener){ listeners.remove(listener); private void updateProgress(int n) { for (ProgressListener listener: listeners) listener,onProgress(n); 顾名思义，CopyonwriteArrayList使用了保护性复制的策略。它并不是在遍历列表前进行复制，而是在列表被修改时进行，已经投入使用的迭代器会使用当时的旧副本。这种方式对许多用例并不适用，但非常适用于我们当下的场景。首先，使用了CopyonwriteArrayList的代码会变得非常简洁。事实上除了定义listeners 的部分稍有不同，其他代码与最初的非线程安全的版本没有什么区别。其次，代码将变得更高效，因为我们不必在每次调用updateProgress（)时都创建副本，而只在listeners被更新时创建即可（更新listeners的概率相对较低）。 ①新的连接会复用连接池中的已有线程，而不必创建新线程。译者注 30 第2章线程与锁 17 小乔爱问线程池应该有多大？影响线程池最优大小的因素有很多，例如硬件的性能、线程任务是CPU密集型还是IO 密集型、是否有其他任务在同时运行。还有很多其他原因也会产生影响。话虽如此，但也存在经验法则：对于CPU密集型的任务，线程池大小应接近于可用核数：对于10密集型的任务，线程池可以设置得更大些当然，最佳的方法是建立一个真实环境下的压力测试来衡量性能。个完整的程序到目前为止，我们单独学习了一些工具。剩下的时间我们将解决一个实际的小问题：Wikipedia 上出现频率最高的词是什么？乍看上去这应当不难一一只需要下载XMLdump文件?，然后写一个程序解析它们并计算词频就可以了。但dump文件差不多有40GiB，处理起来需要一些时间，我们是否可以借助并行来加速运行？先从基本场景开始一个简单的串行程序统计前100000页（page）的词频需要花费多久？ ThreadsLocks/WordCount/src/main/java/com/paulbutcher/WordCount.java public class WordCount{ private static final HashMap counts newHashMap(); public static void main(Stringll args) throws Exception ( Iterable pages = new Pages(1ooooo, "enwiki.xmt"); for(Page page: pages) Iterable words = new Words(page.getText()); for (String word:words) countword(word); private static void countword(string word)f Integer currentCount = counts.get(word); if (currentCount = nuil) counts.put(word, 1); else http://dumps.wikimedia.org/enwiki/ counts.put(word, currentCount + 1); 在我的MacBookPro上，这需要花费105秒。 2.4第三天：站在巨人的肩膀上那应该从何处下手研发并行的版本呢？主循环的每一次循环都完成了两个任务析XML并构造一个Page，然后“消费”这个page，对page中的内容统计词频。 31 首先解这类问题可以归结为一种经典模式一一生产者-消费者（producer-consumer）模式。相比只用一个线程自产自销，我们可以创建两个线程：一个生产者和一个消费者。首先，定义一个生产者Parser： ThreadsLocks/WordCountProducerConsumer/src/main/java/com/paulbutcher/Parser.java class Parser implenents Runnable { private BtockingQueue queue; public Parser(BlockingQueue queue) [ this.queue queue; public void run() try Iterablepages=new Pages(10oooo,"enwiki.xml"): for (Page page: pages) queue.put(page); }catch.（Exceptione)e.printstackTrace()；) run（）的方法体是之前串行版本的外层循环，但对所产生的page不直接统计词频，而是将该 page加人到队列末尾。然后，定义一个消费者： ThreadsLocks/WordCountProducerConsumer/src/main/java/com/paulbutcher/Counter.java class Counter implements Runnable private BlockingQueue queue; private Map counts; public Counter(BlockingQueue queue Map counts) this.queue = queue; this.counts = counts; public void run() try while(true){ Page page = queue.take(); if (page,isPoisonPitl()) 32 A 子第2章线程与锁 break; Iterable words = new Words(page.getText()); for(stringword:words) countword(word); catch(Exceptione)e.printstackTrace();) 你可能已经猜到了，方法体是之前串行版本的内层循环，从队列里获取输入。最后，创建两个线程： ThreadsLocks/WordCountProducerConsumer/src/main/java/com/paulbutcher/WordCount.java ArrayBlockingQueue queue =new ArrayBlockingQueue(1oo); HashMap counts = new HashMap(); Thread counter = new Thread(new Counter(queue, counts)); Thread parser=new Thread(newParser(queue)); counter.start(); parser.start(); parser.join(); queue.put(newPoisonPill()); counter.join(); java.util，concurrent包中的ArrayBlockingQueue是一个并发队列，非常适合实现生产者-消费者模式。其提供了高效的并发方法put（）和take（），这些方法会在必要时阻塞：当对一个空队列调用take（)时，程序会阻塞直到队列变为非空；当对一个满队列调用put（)时，程序会阻塞直到队列有足够空间。 1/ 小乔爱问为什么用阻塞队列？ java.util.concurrent包不仅提供了阻塞队列，还提供了一种容量无限，操作不需等待、非阻塞的队列ConcurrentLinkedQueue。这些特性听上去非常诱人，那为什么在这个场景下它不是一个好的解决方案呢？关键在于生产者和消费者可能不会（几乎肯定不会）保持相同的速度。比如，当生产者的速度快于消费者的速度时，队列会越来越大。Wikipedia的dump差不多有40GiB，很容易就让队列大小超过内存容量。相比之下，阻塞队列只充许生产者的速度在一定程度上超过消费者的速度，但不会超过很多。 2.4第三天：站在巨人的肩膀上另一个有趣的话题是消费者如何知道何时应该退出： 33 ThreadsLocks/WordCountProducerConsumer/src/main/java/com/paulbutcher/Counterjava if（page.isPoisonPilt()) break; 毒丸（poisonpill）是一个特殊的对象，告诉消费者“数据已经取完了，你可以退出了”。这非常类似于C/C++中用nul字符作为字符串的结尾。用生产者-消费者模式进行优化后，程序运行提速了—一从105秒提升到了95秒。而我们可以做得更好。生产者-消费者模式的优点不仅在于可以并行地生产和消费，还可以存在多个生产者和/或多个消费者。那么我们应该重点加速生产者的速度还是消费者的速度？哪段代码占用了大量的运行时间？如果临时改动一下代码，只运行生产者的部分，会发现分析前100000页花费了近10秒。仔细想一下就可以解释这个现象。最初的串行版本花费了105秒，而生产者-消费者版本花费了95秒。显然解析文件花费了10秒，而统计词频花费了95秒。所以当解析和统计并行时，整体运行时间会减少到两者中较长的时间一 —95秒要进一步优化，就要对统计过程进行并行化，建立多个消费者。图2-3示意了我们要做的事情。队列 XML Dump 解析器计数器计数结果计数器计数器图2-3建立多个消费者，对统计过程进行并行化 Aardvark3 Abacus-5 Acrobat-12 Advert-→6 如果多个线程要同时统计词频，就需要一种方法来同步对counts对象的访问。首先，我们想到由Collections包的synchronizedMap（）提供的同步的map。遗憾的是这类同步的集合并不提供原子的读-改-写的方法，所以不能使用它们。如果使用HashMap，就必须自已实现对访问的同步。 34 第2章线程与锁下面是修改后的countword（）： ThreadsLocks/WordCountSynchronizedHashMap/src/main/java/com/paulbutcher/Counter.java private void countword(String word) lock.lock(); try Integer currentCount = counts.get(word); if (currentCount == null) counts.put(word,1); else counts.put(word, currentCount + 1); finallylock.unlock();) 然后，修改代码来运行多个消费者： ThreadsLocks/WordCountSynchronizedHashMap/src/main/java/com/paulbutcher/WordCount.java ArrayBlockingQueue queue = new ArrayBlockingQueue(1oo); HashMap counts = new HashMap(); ExecutorService executor =Executors.newCachedThreadPool(); for(int i=o;i e:localCounts.entrySet())( stringword=e.getKey(); Integer count = e.getValue(); while(true){ Integer currentCount = counts.get(word); if（currentCount==nulu){ if(counts.putIfAbsent(word,count)==nulu) break; } else if (counts.replace(word, currentCount, currentCount + count)) break; 这次离理想的4倍提速又近了一步，如表2-3所示。表2-3 消费者 1 2 3 4 5 6 7 时间 (秒）) 95 57 40 39 35 33 41 加速比 1.10 1.83 2.62 2.69 2.96 3.14 2.55 2.4第三天：站在巨人的肩膀上 37 现在的程序性能不仅随着消费者的增加而快速提升，而且超过4个消费者后性能仍会继续提升。这大概是因为我的MacBook支持“超线程” 会返回8。图2-4展示了三个不同版本程序的性能。加速比同步的HashMap 2 3 虽然只有4个物理核，但是availableProcessors（）多个ConcurrentHashMap ConcurrentHashMap 4 消费者数量 5 图2-4消费者个数对词频统计程序性能的影响 6 并行程序的性能曲线大多与此类似。起初性能快速线性增长，之后增长趋势放缓，最终性能达到极值，线程数再增加性能则会下降。现在回顾一下我们已经完成了什么：建立了一个相对复杂的生产者-消费者程序，多个消费者通过一个并发队列和一个并发map进行协作，程序中没有显式地使用锁，而是使用了标准库提供的并发工具。第三天总结我们已经完成了线程与锁模型最后一天的学习，第三天我们学到了什么 java.util.concurrent包提供的工具不仅让并发编程更容易，而且在以下方面让程序更安 2 38第2章线程与锁全高效：口使用线程池，而不直接创建线程；口使用copyOnwriteArrayList让监听器相关的代码更简单高效：口使用ArrayBlockingQueue让生产者和消费者之间高效协作；口ConcurrentHashMap提供了更好的并发访问。第三天自习查找口阅读ForkJoinPool的文档一一fork/join框架与线程池有什么区别？分别适用于什么场景？口什么是work-stealing？它适用于什么场景？如何用javautil.concurrent包提供的工具实现work-stealing？口CountDownLatch和CyclicBarrier有什么区别？分别适用于什么场景？口什么是阿姆达尔定律（Amdahl'slaw）？如何计算出词频统计程序的最大理论加速比？实践口修改生产者-消费者版本的代码，用“数据结束”标识取代毒丸，在生产者与消费者有速度差异时要确保程序运行正常。队列被置“数据结束”标识时，如果消费者尝试从队列中移除元素会发生什么？为什么毒丸方法会被广泛采用？口在不同的电脑上运行不同版本的词频统计程序。不同电脑上的性能曲线有什么区别？如果在一台32核电脑上运行，是否会得到近32倍的提速？ 2.5复习线程与锁模型可能是这本书介绍的最具有争议的模型。很多程序员觉得它难以驾驭而感到惧怕，不顾一切地避免多线程编程。而另一些程序员却不以为然，他们觉得只要遵守一些规则，线程与锁模型其实别无他样。让我们来看一下这个模型的优点和缺点。优点线程与锁模型的最大优点是其适用面很广。它是本书介绍的其他许多技术的基础，适用于解决很多类型的问题。同时，线程与锁模型更接近于“本质”一一近似于对硬件工作方式的形式化一一正确使用时，其效率很高。这也意味着它能够解决从小到大不同粒度的问题。另外，这个模型可以被轻松地集成到大多数编程语言中。语言设计者们可以轻易让一门指令式语言或面向对象语言支持线程与锁模型。缺点 2.5复习 39 线程与锁模型没有为并行提供直接的支持（之前我们提到过并发与并行的区别和联系，参见 1.1节）。在之前词频统计的例子中，我们确实用这个模型将一个串行算法并行地运行，但前提是该程序被改造成了并发形式，同时引了不确定性的隐患。除了一些特例，比如实验性的研究分布式共享内存的系统，线程与锁模型仅支持共享内存模型。如果要支持分布式内存模型（无论是地理分布型或者容错型），就需要寻求其他技术的帮助。这也意味着线程与锁模型不适用于单个系统无力解决的问题。使用这个模型最大的缺点在于无助。语言设计者很容易将其集成到某一门语言中，但对于我们这些可怜的程序员，编程语言层面并没有提供足够的帮助。不易察觉的错误我认为应用多线程的难点不在于难以编程，而在于难以测试。在多线程编程中，从坑里爬出来并不难，难的是我们不知道自已是不是已在坑里。以内存模型为例。如2.2节的“内存可见性”部分所述，两个线程在没有同步的情况下访问同一片内存，奇怪的事情就会接而至。但我们怎么知道自已的程序是不是正确的？是否能写一个测试来证明访问内存时相应的代码都有同步保护？可惜我们做不到。确实可以写一段代码来进行压力测试，但这些测试成功并不意味着被测代码是正确的。例如，在解决哲学家进餐问题时，我们曾讨论过产生死锁的代码，而这段代码曾经正常运行了一周多后才出现死锁。测试中的一个大问题是多线程的bug很难重现一一我不止一次在凌晨被叫醒，因为服务器在正常运行几个月后突然出了问题。如果一个问题每十分钟就会发生一次，我们很快就能定位该问题，但如果要正常运行几个月才能重现问题，这就很难进行调试。更糟糕的是，我们很有可能写出一个包含多线程bug的程序，但无论怎样彻底地长期地进行测试，该程序从不会被测出错误来。假如用一种可能被乱序执行的方式访问内存，并不意味着乱序执行真的会发生。这样，我们就完全不知道程序有bug，直到升级JVM或者使用不同的硬件时，才会发生一些诡异的事情。可维护性上述问题在编写代码时已经让人很头疼了，更过分的是代码不可能不变更。我们要全程保证所有对象的同步都是正确的、必须按照顺序来获取多把锁、持有锁时不调用外星方法。还要保证12个月之后换了另外10个程序员仍然按照这个规则维护代码。过去十几年，自动测试让我们信心十足地进行重构，但如果不能对多线程问题进行可靠的测试，就无法对多线程代码进行可靠的重构。 2 40第2章线程与锁最终我们仅有的方法是谨慎地思考多线程代码。除了谨慎地思考，就是更谨慎地思考。当然，这种方法并不容易，而且无法量化。收拾残局我认为诊断多线程问题的感觉，非常类似于一级方程式赛车的工程师诊断引擎故障：引擎在正常运行几个小时后，突然在没有任何征兆的情况下发生严重故障，机油和零件散落一地，狼猜不堪。当赛车被拖回维修厂后，可岭的工程师要面对一堆残找出故障的原因。故障原因可能是很小的一一个坏的油泵轴承或者阀门，但应该如何从一片混乱中找出原因呢？经常使用的方法是尽可能地完善对引擎数据的记录，并让赛车手使用新的引擎。希望下次发生故障时数据能提供一些有用的信息。其他语言如果你想深人研究JVM的线程与锁模型，由java，util，concurrent包的作者撰写的Java ConcurrencyinPractice[Goeo6]是个不错的起点。不同语言之间，多线程编程的细节可能有所不同，但本章我们介绍的原理普遍适用，包括下面这些规则：访问共享变量时需要同步、按照全局的固定的顺序来获得多把锁、持有锁时避免调用外星方法。值得一提的是，虽然我们仅讨论了Java的内存模型，但是会对内存访问进行乱序执行的却不止Java。大多数语言没有对内存模型做出完善的定义，没有明确地说明乱序执行何时发生以及如何发生。在这方面Java是先驱者，是第一个完整定义内存模型的主流语言。C和C++是在C11和 C++11的标准中才补充了内存模型。结语伴随着种种挑战，在可预见的将来多线程编程将一直伴随着我们。我们也会在之后的章节中介绍其他一些有用的相关知识。下一章我们将学习函数式编程，它不使用可变状态，从而避免了线程与锁模型的很多缺陷。即使你不打算写函数式的代码，理解函数式编程背后的原理也很有价值一一我们以后学习的很多并发模型也应用了这些原理。第3章函数式编程函数式编程（FunctionalProgramming）就像一辆高端、新潮的氢燃料汽车，虽然还未被广泛使用，但二十年后我们的生活将与它密不可分。函数式编程与命令式编程（ImperativeProgramming）不同。命令式编程的代码由一系列改变全局状态的语句构成，而函数式编程则是将计算过程抽象成表达式求值。这些表达式由纯数学函数构成，而这些数学函数是第一类对象（我们可以像操作数值一样操作第一类对象）并且没有副作用。由于没有副作用，函数式编程可以更容易做到线程安全，因此特别适合于并发编程。这也是我们学习的第一个可以直接支持并行的模型。 3.1若不爽，就另辟蹊径第2章提到的有关锁的一些规则，都是针对于线程之间共享的可变的数据一一换个说法就是共享可变状态。而对于不变的数据，多线程不使用锁就可以安全地进行访问。这就是为什么在解决并发和并行问题时函数式编程会如此引人注目一一它没有可变状态，所以不会遇到由共享可变状态带来的种种问题。本章中我们将用Clojure语言来介绍函数式编程，这是一门运行在JVM上的Lisp方言。Clojure 是动态类型语言，如果你是Ruby或Python程序员，肯定不会对此感到陌生。虽然Clojure不是一门纯粹的函数式语言，但本章只会讨论其函数式的特征。本书只能按需介绍Clojure，如果你还想深人学习，推荐阅读StuartHalloway和AaronBedra编写的《Clojure程序设计》2。第一天，我们将学习函数式编程的基础，并了解如何并行化一个函数式算法。第二天，深人学习Clojure的reducer框架，以及在该框架下是如何进行并行化的。第三天，将注意力从并行转向并发，利用future模型和promise模型创建一个并发的函数式Web服务。 ①http:/clojure.org ②该书中文版已由人民邮电出版社出版。——编者注 42第3章函数式编程 3.2第一天：抛弃可变状态当程序员初次学习函数式编程时，第一反应通常是怀疑一一正常程序怎么可能不更新变量。经过后面的学习你会发现，这不仅是可能的，而且要比写命令式的代码更简单。可变状态的风险今天将重点讨论并行。我们将创建一个简单的函数式程序，并演示如何轻松地将其并行化。不过要先来学习几个Java的例子，看看为什么要避免使用可变状态。隐藏的可变状态下面这个类没有使用可变状态，看上去肯定是线程安全的： FunctionalProgramming/DateFormatBug/src/main/java/com/paulbutcher/DateParser.java classDateParserf private final DateFormat format = new SimpleDateFormat("yyyy-MM-dd"); public Date parse(String s) throws ParseException { returnformat.parse(s); 但当多个线程使用这个类的同一对象时（源码可以在本书配套代码中找到），首次运行可能会得到如下错误： Caught:java.lang.NumberFormatException:For input string:".12012E4.12012E4" Expected:Sun Jan 01 00:00:00 GMT 2012,got:WedApr 1500:00:00BST 2015 再次运行，可能又会得到如下错误： Caught:java.lang.ArrayIndexoutofBoundsException:-1 第三次运行，可能还会得到另一个错误： Caught: java.lang.NumberFormatException: multiple points Caught:java.lang.NumberFormatException: multiple points 虽然这段代码只有一个成员变量，而且被标记成不可变（即final），但显然这段代码根本达不到线程安全，为什么呢？造成问题的原因是SimpleDateFormat内部有隐藏的可变状态。你可能会认为这应该是个 bug"，但对我们来说是不是bug并不重要。Java这类语言为了让代码写起来简单，在此隐藏了可变状态，这也使我们无法判断何时会发生问题一一从API无法判断SimpleDateFormat是否是线程安全的。 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228335 3.2第一天：抛弃可变状态隐藏的可变状态还不是唯一需要留意的问题，我们再来看一个。逃逸的可变状态 43 假设我们要创建一个管理比赛的Web服务。需求是能管理一个运动员列表，我们会习惯地写出如下代码： pubtic class Tournamentt privateListplayers=newLinkedList(); publicsynchronizedvoidaddplayer(Playerp) players.add(p): pubiic synchronized Iterator getPlayerIterator()[ returnplayers.iterator(); 乍一看上去这段代码是线程安全的一一players是私有变量，仅被addPlayer（）和 getPlayerIterator（)使用，且两个方法都标记了synchronized。然而它并不是线程安全的，因为getPlayerIterator（）返回的送代器仍引i用了players内部的可变状态一一如果在迭代器被使用时，另一个线程调用了addPlayer（）方法，那么程序就会抛出ConcurrentModification Exception或者变得更糟。也就是说可变状态从Tournament的重重防护下逃逸了。在并发编程中，隐藏和逃逸仅仅是两种可变状态带来的风险一一还有很多其他风险。如果能找到一种不使用可变状态的方法，就可以避开这些风险，这正是函数式编程为我们带来的曙光。 Clojure旋风之旅了解Clojure的Lisp语法只需要几分钟。体验Cloiure最简单的方法是使用它的REPL（Read-Evaluate-PrintLoop），可以通过leinrepl 来启动REPL（lein是Clojure的构建工具）。在REPL中输入代码，代码将被立刻执行，既不需要创建源文件，也不需要编译，这在进行代码试验时会出人意料地方便。REPL启动后，会看到如下提示符： user=> 在提示符后输人的Clojure代码将立刻被执行。 Clojure代码由s-表达式构成，可以将s-表达式视为带括号的列表。主流语言中的max（3，5）在Clojure中写成： user=> (max35) 数学运算符也是同样的表示方式。比如1+2*3，写成： 44 第3章函数式编程 user=> (+ 1 (* 2 3)) 7 使用def可以定义常量： user=> (def meaning-of-1ife 42) #'user/meaning-of-life user=> meaning-of-iife 42 控制结构也可以写成s-表达式： (()a"non-negative" Clojure的大多数语句都是一个s-表达式，然而也有个别例外。矢量（数组）字面量是用方括号表示的： user=>(def droids ["Huey""Dewey""Louie"j)#'user/droids user=> (count droids) 3 user=> (droids 0)"Huey" user=>(droids 2)"Louie" map字面量是用花括号表示的： user=>(def me (:name "paul":age 45 :sex :male))#'user/me user=> (:age me) 45 map的键通常是关键字（keyword），关键字以冒号开头，非常类似于Ruby中的符号（symbol）或Java中的保留字符串（interned string）。使用defn可以定义函数，函数参数是失量形式的： user=>(defn percentage [xp] (*x (/ p 1oo.o)))#'user/percentage user=> (percentage 200 10) 20.0 Clojure旋风之旅就此结束。以后我们还会介绍Clojure的其他特性。第一个函数式程序我们一直说函数式编程最有趣的地方是不使用可变状态，但一直没有举例说明。现在就来补充一个例子。 ①此处关键字是指Clojure中的数据类型，而并非编程语言中的for、while这一类关键字。一一译者注 3.2第一天：抛弃可变状态对一个数列求和，如果使用Java这种命令式语言，会写成下面这样： pubiicint sum(intll numbers) int accumulator = o; for(int n:numbers) accumulator += n; return accumulator; 45 这段代码中accumulator是可变的：在for循环中每次都会更新值，因此这段代码不是函数式的。相比之下，使用Clojure的方案可以不使用可变状态： FunctionalProgramming/Sum/src/sum/core.clj(defn recursive-sum [numbers] (if(empty?numbers) o (+(first numbers)(recursive-sum(restnumbers))))) 这是一个递归的的方案一一recursive-sum递归地调用自己。如果numbers为空，则返回o。否则，将numbers的第一个元素（first）与其他元素（rest）的和相加，并返回结果。这个方案是可行的，但还能做得更好。下面这种方案更简单高效： FunctionalProgramming/Sum/src/sum/core.clj(defn reduce-sum [numbers] (reduce(fn[accx(+acc x)) numbers)) 这段代码使用了Clojure的reduce函数，其有3个参数集合。一个化简函数、一个初始值和一个代码中用fn定义了一个匿名化简函数，其接受两个参数并返回参数的和。这个匿名化简函数被传给reduce，reduce为集合中的每一个元素都调用一次化简函数一一第一次，初始值（本例中是0）和集合中的第一个元素被传给化简函数；第二次，将第一次调用的结果和集合中的第二个元素传给化简函数；以此类推。先别鼓掌，我们还可以继续改进一+是个现成的函数，接受两个参数并返回参数的和。直接用+来替换匿名化简函数： FunctionalProgramming/Sum/src/sum/core.clj (defn sum[numbers](reduce + numbers)) 现在可以鼓掌了。我们得到了二个比命令式编程更简单明了的方案，这种体验可以说是将命令式方案转换成函数式方案时的普遍感受。 46 第3章函数式编程 10 小乔爱间如果将空集合传给reduce会发生什么？ sum函数的最终版中我们没有向reduce传初始值：(reduce + numbers) 这可能会引发你的思考，如果向reduce传入一个空集合会发生什么？答案是一切运行正常，并且reduce会返回0： sum.core=>(sum[) 那么，reduce如何知道应该返回0（而不是其他值，比如1或nil）？这涉及Clojure 中很多操作符都具有的一个特性一操作符知道自己的特征值（identityvalue）是什么。以十函数为例，其可以接受任意数目的参数，包括0个参数： user=> (+ 1 2) 3 user=>(+1234) 10 user=> (+ 42) 42 (+)<=uesn 0 当用0个参数调用函数时，函数会返回加法的特征值，即0。类似地，*返回乘法的特征值，即1。 user=> (*) 1 如果不向reduce传初始值，那reduce将使用0个参数来调用函数，并用其作为初始值。顺便一提，由于+可以接受若干个参数，因此我们也可以用apply来实现sum函数。apply 可以接受一个函数和一个失量，调用函数时将这个矢量展开作为函数的参数： FunctionalProgramming/Sum/src/sum/core.clj (defn apply-sum[numbers](apply+numbers)) 但是，与使用reduce不同，使用apply的代码不能轻易地并行化。轻松并行 3.2第一天：抛弃可变状态 47 我们已经有了一些函数式的代码，那怎么让它并行呢？需要如何修改sum函数呢？其实只需要做非常小的改动： FunctionalProgramming/Sum/src/sum/core.clj(ns sum.core (:require [clojure.core.reducers :as rl)) (defn parallel-sum [numbers](r/fold + numbers)) 唯一的修改是这段代码用clojure.core，reducers包（代码中使用其缩写r）提供的fold 函数替换了reduce。下面是REPL的一组运行结果，展示了性能的提升： sum.core=> (def numbers (into [l (range o 10oo0o0o)))#sum.core/numbers sum.core=> (time (sum numbers))"Elapsed time:1099.154 msecs" 49999995000000 sum.core=> (time (sum numbers))"Elapsed time: 125.349 msecs" 49999995000000 sum.core=>(time(parallel-sum numbers)) "Elapsed time: 236.609 msecs" 49999995000000 sum.core=> (time (parallel-sum numbers)) "Elapsed time: 49.835 msecs 49999995000000 这段代码先用into函数将0到10000000之间的数字添加到一个空矢量中，以此构造一个初始矢量。接着使用time来打印某段代码的运行时间。由于代码是运行在JVM中，就需要多次运行代码，以便预热JIT编译器，这样才能得到比较客观的运行时间。在我的四核的Mac上，使用fold让代码的运行时间从125ms降到了50ms，加速比为2.5。第二天中我们将展开学习fold的实现细节，现在先来看看之前Wikipedia词频统计的例子，实现其函数式版本。 Wikipedia词频统计的函数式版本我们先来写一个Wikipedia词频统计的串行执行版本一一明天再来对它进行并行化。程序需要以下三个函数。口函数1，接受WikipediaXMLdump，返回dump中的页面序列。口函数2，接受一个页面，返回页面上的词序列。 48 第3章函数式编程口函数3，接受一个词序列，返回含有词频的map。我们不会详细介绍前两个函数一一毕竟本书的主题是并发，而不是XML或字符串处理（相关细节请参见本书的配套代码）。在此着重讨论如何统计词频，因为之后我们还将对这部分进行并行化处理。函数式map 要得到一个包含词频的map，就需要理解Clojure的两个map处理函数一一get和assoc： user=> (def counts {"apple" 2"orange" 1})#user/counts (e) 2 (eeaon)a(eensnoose)an{"banana"1,"orange"1,"apple"2) (o)a["orange","apple"3] get从map中查找键，如果找到则返回对应值，否则返回默认值。assoc接受一个map和一个键值对，在原有map的基础上返回一个包含指定键值对的新map。词频统计函数我们已经准备好实现词频统计函数了，这个函数接受一个词序列，并返回一个map，这个map 的键是词，值是该词出现的次数： FunctionalProgramming/WordCount/src/wordcount/wordfrequencies.cl (defn word-frequencies [words](reduce (fn [counts word)(assoc counts word (inc (get counts word o)))) words)) 这段代码将一个空的map作为初始值传给reduce。再对words中的每个元素，将其现有次数加1。试用一下： oeoaeoreoaaoaaoa aoeotato Clojure标准库已经走在了我们前面一一提供了frequencies函数，该函数能针对任何集合，输出集合中每个元素的出现次数： oeaooeoeoaoaaa toaatotooao 我们已经学会了如何统计词频，剩下的就是将其与XML处理结合起来。插播一些与序列相关的函数 3.2第一天：抛弃可变状态为了理解今后的代码，得插播一些与序列相关的机制。首先，介绍映射函数map： user=> (map inc [012345])(123456) user=> (map (fn [x] (* 2 x)) [0 1 2 3 4 5])(0246810) 49 map函数接受一个函数f和一个序列，并返回一个新序列，对于输入序列中的每个元素都会调用一次函数f，并以元素的值作为f的参数，f的返回值则成为新序列的对应元素。然后，介绍partial函数，利用partial函数可以将上面代码的第二个调用简化一下。 partial接受一个函数和若干参数，返回一个被局部代人的函数： #'user/multiply-by-2 user=> (multiply-by-2 3) 6 (s(e)e)a(0246810) 最后，假设有一个函数会返回一个序列，比如用正则表达式将字符串切割成词的序列： user=> (defn get-words [text] (re-seq #"lw+" text))#user/get-words user=> (get-words "one two three four")("one""two""three""four") 显然，对一个字符串序列用get-words进行映射，会得到一个二维序列： saooa (aaas.)sa)aattao) 如果需要包含所有输出的一维序列，则可以使用mapcat： sa anaasaatunoaatota) 一切准备就绪，现在可以组装我们的词频统计函数了。组装我们将这个词频统计函数命名为count-words-seguential，它接受一个页面序列，同时返回含有对应词频的map： FunctionalProgramming/WordCount/src/wordcount/core.clj(defn count-words-sequential [pages] (frequencies(mapcatget-words pages))) ①举例说明，假设有一个数学函数f(a,b,c），partial(f，1)返回的是数学函数f(1,b,c)，函数的参数a已经被代人了。——译者注 3 50第3章函数式编程这段代码首先用（mapcatget-wordspages）将页面序列转化成词序列，再将词序列传给 frequencies。与之前命令式版本（参见2.4节中“一个完整的程序”部分）相比，函数式版本的简洁优美又一次得到印证。懒情一点好你可能有一个困惑一—Wikipediadump的大小将近40GiB。如果count-words将其中的词都存放到一个序列中，内存应该会不够用。实际情况并不是这样，因为Clojure中序列是懒惰的（lazy）一一其中的元素仅在需要时被求值。举例说明： range函数会产生一个数列： user=>(range 10)(0123456789) 上面的数列在REPL中会被完全求值并输出。我并不能阻止你对一个超大范围进行求值，但这样做，你的电脑很有可能变成一台高热的暖风机。比如下面的这个例子，需要花费很长时间才会得到输出（假设内存足够用)： user=> (range 0 100000000) 再试试下面的例子，能立刻得到输出： user=>(take 10(range 10000000))(0123456789) 由于take只需要数列的前10个元素，因此range只需要产生10个元素。这个机制适用于任意层次的嵌套： (((o000eooot hue) (z * eeed) de) e) asn(024681012141618) 甚至可以使用无穷序列。比如，iterate函数会不断将某个函数应用到初始值、第一次的返回值、第二次的返回值···来构成无穷序列· user=> (take 1o (iterate inc 0))(0123456789) ())(024681012141618) 所谓序列是懒惰的，不仅意味着其仅在需要时（也可能永远不需要）才生成序列的尾元素，还意味着序列的头元素在使用后（如果不再需要使用）可以被舍弃。比如，下面的例子需要运行一段时间，但不会耗尽内存： user=>(take-last 5(range o 10000o)) （66666666 86666666 26666666 96666666 56666666） 3.3第二天：函数式并行 51 回到词频统计，get-pages返回的页面序列是懒情的，因此count-words完全可以处理4 GiB的Wikipediadump。另外这段代码很容易被并行化，明天将具体介绍。第一天总结第一天的学习结束了。第二天我们会对词频统计进行并行化，还要深人了解fold函数。第一天我们学到了什么由于普遍使用了共享可变状态，用命令式语言进行并发编程的难度是比较高的。函数式编程抛弃了共享可变状态，让并发编程变得更容易也更安全。本节中我们学习了以下知识：口用map或mapcat对一个序列的每个元素进行映射；口用序列的懒惰特性来处理较大的序列，甚至无穷序列；口用reduce将序列化简为一个（可能比较复杂的）值；口用fold对reduce进行并行化。第一天自习查找口阅读Clojure的cheatsheet，快速查阅Clojure的常用函数。口阅读lazy-seg的相关文档，使用lazy-seg可自建一个懒情序列。实践口与许多函数式语言不同，Clojure并不支持尾调用消除（tail-callelimination），因此Clojure 代码通常很少使用递归。重写recursive-sum函数（参见本节“第一个函数式程序”部分），用loop和recur替换递归。口重写reduce-sum函数（参见本节“第一个函数式程序”部分），用读取器宏（readermacro）#()替换(fn.：）。 3.3第二天：函数式并行今天先来学习如何将Wikipedia词频统计程序并行化，然后再深人研究fold函数的细节，以说明如何用函数式编程来实现并行。每次一页第一天我们学习了map函数，其将某函数依次应用于输入序列的每个元素，并返回函数应用 52第3章函数式编程后的新序列。但这个过程其实没有必要串行执行一Clojure提供了功能类似于map的pmap函数，其应用函数的过程是可以并行的。pmap在需要结果时可以并行计算，但仅生成所需要的而不是全部的结果，这个特性称为半懒惰（semi-lazy）。用下面的代码可以并行地将Wikipedia的页序列转换成词频map的序列：(pmap#(frequencies（get-words%)）pages）上述代码用读取器宏#（：：，）来声明传给pmap的函数，读取器宏可以快速创建匿名函数。函数的参数通过%1、%2等来标识，如果只有一个参数，可以通过%进行标识： #(frequencies (get-words %)) 与其等价的代码为： (fn[pagel(frequencies(get-wordspage))）来测试一下： # #"wordcount.core/pages "five potato six potato seven potato more"j) wordcount.core=>（pmap#(frequencies(get-words%)）pages） ({"one"1，"potato"3,"two"1，"three"1,"four"1) o 现在可以将所得的序列化简成一个map，从而得到我们需要的词频总数。化简函数将按照以下规则合并两个map：口输出map的键是两个输人map的键的并集；口若某键存在于一个输入map中，那在输出map中的对应值等于在输入map中的对应值：口若某键存在于两个输入map中，那在输出map中的对应值等于在输入map中的对应值的和。如图3-1所示。我们可以自建一个化简函数，但（与以往一样）标准库已经提供了合适的函数。API文档如下： (merge-withfmaps) merge-with将maps中其余的map合并到第一个map中，返回合并后的map—一如果多个map 包含同一个键，那该键对应的多个值将被（从左向右地）合并到结果map中，合并的方法是调用(f val-in-result val-in-latter)。 ①DavidEdgarLiebke给出过一个更容易理解的描述：http://incanter.org/downloads/fjclj.pdf。一译者注 one potato W one:1 two:1 two potato:2 potato one:1 two:1 three:1 four:1 potato:3 three 3.3 第二天：函数式并行 potato V three:1 four:l potato:l four 统计词频合并词频图3-1将Wikipedia的两页合并成一个词频map 53 之前我们学习过partial函数，其返回一个被局部代人的函数，所以（partial.merge-with+）可以返回一个用于合并map的函数，这个函数使用+对同一个键的多个值进行合并： user=>(defmerge-counts(partialmerge-with+))#'user/merge-counts user=> (merge-counts (:x 1 :y 2) (:y 1 :z 1))(:z1,y3,:x1) 将上述要点组装起来，就得到了并行版本的词频统计程序： FunctionalProgramming/WordCount/src/wordcount/core.clj (defn count-words-parallel. [pages](reduce (partial merge-with +) (pmap #(frequencies (get-words %)）pages))) 搞定，现在来测试一下性能。利用批处理改善性能在我的MacBookPro上，用串行版本的词频统计程序处理Wikipedia的前100000页需要花费 140秒。并行版本需要花费94秒，加速比是1.5。我们已经使用并行得到了提速，但并不理想。与之前在线程与锁方案中分析的原因类似（参见2.4节），逐页地进行计数和合并会导致大量的合并操作。如果能对页面进行批处理，将大大减少合并操作的次数，如图3-2所示。 3 54 第3章函数式编程页面批次1页面批次2页面批次3页面批次4 时间 0 一 W 词频map! W 词频map2 -计数结果 -V 词频map3 同频map4 页面批次2页面批次3页面批次4页面批次5 W 词频map2 W 词频map3 计数结果--计数结果2 W 词频map4 W 同频maps 页面批次3页面批次4页面批次5页面批次6 y 词频map3 词频map4 计数结果计数结果3 W 词频maps 词频map6 图3-2批处理版本的词频统计统计词频合并词频举例说明，将1oo个页面作为一个批次进行处理，word-count的代码修改如下： FunctionalProgramming/WordCount/src/wordcount/core.clj(defn count-words [pages] (reduce (partial merge-with +) (pmap count-words-sequential(partition-allioopages)))) 这里用到了partition-all函数，其可以将一个序列中的元素分批（或称分区），构成多个序列： user=> (partition-all 4[1 2345678 91o])((1234)(5678)(910)) 像之前一样，可以用count-words-sequential对每批页面进行词频统计，然后合并结果。不出所料，这一版本处理Wikipedia的前100000页需要花费44秒，提速3.2倍。化简器第一天，我们曾经用fold替换reduce并获得了神奇的性能提升。想要理解fold的原理，需要先理解Clojure的reducers库。 3.3第二天：函数式并行55 化简器（reducer）描述了对集合进行化简的方法。普通版本的map接受一个函数和一个（可能是懒惰的）序列，并返回另一个（可能是懒情的）序列： ((2468) 而clojure，core.reducers提供的map则不同，接受相同的参数，但返回的是一个化简器 reducible： user=> (require"[clojure.core.reducers :as r]) nil （ # reducible不能作为值被直接使用，而是作为参数被传给reduce： ([2468] 上述代码中，conj函数的第一个参数是一个集合（初始时是空集合1），其将第二个参数合并到第一个参数中。因此这段代码的结果与只执行map的结果相同。 into函数内部使用了reduce，所以下面这段代码与上面那段是等价的： (())[2468] clojure，core提供的大部分序列处理函数都有对应的化简器版本，包括之前见过的map和 mapcat。与clojure.core提供的函数类似，其化简器版本也可以被嵌套使用： user=>(into[](r/map(partial+1)(r/filtereven?[1234])))[35] 一个化简器，并不代表函数返回的结果，而是代表如何产生结果的描述一一被传给reduce 或fold之前，化简器不会进行求值。这样做主要有两个好处：口嵌套的函数返回化简器比返回懒惰序列的效率更高，因为其不用构造处于中间状态的序列；口对整个嵌套链的集合操作，可以用fold进行并行化。化简器内幕为了理解化简器的原理，我们将创建一个略微简单却仍然高效的类似于clojure.core. reducers的库。首先需要理解Clojure的协议（protocol）。协议非常类似于Java中的接口一一其是一系列方法的集合，并定义了一个抽象的概念。Clojure的集合就是通过CollReduce协议来支持化简操作的： (defprotocol CollReduce (coll-reduce[coul f][coll f initj) 3 56第3章函数式编程 CollReduce声明了一个函数coll-reduce，这是一个可变参数（multiplearities）函数一一可以接受两个参数（colul、f），也可以接受三个参数（coll、f、init）。第一个参数类似于Java 中的this，支持多态性分派（polymorphicdispatch）。来看看这段Clojure代码： (coll-reduce coll f) 与这段代码等价的Java代码是： coll.coliReduce(f); reduce函数只是简单地调用coll-reduce，而具体的任务执行则交给集合本身。我们自已实现的类似reduce函数中使用了这个特性： FunctionalProgramming/Reducers/src/reducers/core.clj(defnmy-reduce ([f colu] (coll-reduce colu f)) ([f init coll] (coll-reduce coll f init))) （本例中是两个参数和三个参数）。my-reduce负责将参数转发给coul-reduce。来验证一下： reducers.core=> (my-reduce + [1 2 3 4]) 10 reducers.core=>(my-reduce+1o[1234]) 20 现在来实现一个类似map的函数： FunctionalProgramming/Reducers/src/reducers/core.clj (defn make-reducer [reducible transformf](reify ColiReduce (coll-reduce [_ fi] (coll-reducereducible(transformffi)(fi)))(coll-reduce ［ fl init] (coll-reduce reducible(transformf fi)init)))) (defn my-map [mapf reducible](make-reducer reducible (fn[reducef](fn [acc v] (reducef acc (mapf v)))))) 这段代码定义了make-reducer函数，其接受一个化简器reducible和一个转换函数 transformf，并返回一个ColuReduce协议的实例。用reify实现一个协议，类似于在Java中用 new创建一个接口的匿名实例这个ColiReduce协议的实例会调用reducible的coll-reduce方法。其用transformf对f1 进行转换，并用转换的结果（仍是一个函数）作为传给coll-reduce方法的一个参数。 7 小乔爱问： + 下划线的作用？ 3.3第二天：函数式并行 57 在Clojure中下划线（）通常作为未被使用的函数参数的参数名。之前的代码可以写成：(coul-reduce［thisfi] (colt-reduce reducible (transformffi)(f1))) 但用下划线可以明确地表达出this是未被使用的。对于传给make-reducer的转换函数transformf，其接受一个函数作为参数，并返回这个函数被转换后的版本。以my-map中的转换函数为例： (fn[reducef](fn[accv] (reducef acc (mapf v)))) 曾经介绍过，在化简过程中，为集合中的每个元素都会调用一次化简函数。化简函数的第一个参数是之前化简的结果（acc），第二个参数是集合中的某个元素。所以，在my-map中，对化简函数reducef的第二个参数需要用mapf（mapf是传给my-map的函数）进行转换。来验证一下： [2 468] reducers.core=>(into[1(my-map(partial+1)[1234])）[2345] 当然，my-map也支持嵌套调用： ((e[46810] 如果理解了上面的例子，就会发现其只进行了一次化简，化简函数是（partial*2）和(partial+1)组合后的函数。我们已经学习了化简器是如何提供化简操作的。接下来将学习折叠操作fold是如何让化简操作并行化的。分而治之较之逐个元素地对集合进行化简，fold则使用二分算法。首先，fold（折叠操作）将集合分为两组，每组继续分为更小的两组，以此类推，直到每个分组的规模小于某个限制值（默认值是512）。其次，fold对每个分组进行逐个元素地化简。最后，对各分组的结果进行两两合并，直到剩下一个最终的结果。整个过程类似于一个二叉树，如图3-3所示。 3 58 第3章函数式编程图3-3fold二叉树》化简合并因为fold（利用Java7的Fork/Join框架）创建了一个并行任务的处理树，化简操作和合并操作才得以并行执行。化简操作在树的叶子节点进行。下一级节点等待上一级节点的化简操作的结果，并将这些结果进行合并。整个过程将这样一直进行下去，直到树的根节点，获得最终的一组结果。作。有时也需要让化简函数与合并函数不同，以后我们会学习到这一点。对折叠的支持可以进行折叠的集合不仅需要支持CollReduce协议，也需支持CollFold协议：(defprotocol ColiFold (coll-fold [coll n combinef reducefj)) 类似于化简操作被委托给coll-reduce，折叠操作则被委托给coll-fold： FunctionalProgramming/Reducers/src/reducers/core.clj(defn my-fold ([reducef coll] (my-fold reducef reducef colt))([combinef reducef coll] (my-fold 512 combinef reducef coll))([n combinef reducef colu] (coll-fold coll n combinef reducef))) 当接受两个参数或三个参数时，my-fold为combinef和n提供了默认值，并调用自已。当接受四个参数时，my-fold将调用集合的coll-fold函数。为了让make-reducer支持折叠操作，只需要让make-reducer实现collReduce的同时再实现ColFold： FunctionalProgramming/Reducers/src/reducers/core.clj (defn make-reducer [reducible transformf](reify CollFold (coll-fold [n combinef reducef] 3.3第二天：函数式并行 (colt-fold reducible n combinef (transformf reducef))) CollReduce (coll-reduce ［_ fi] (coll-reduce reducible (transformf f1) (fi)))(coll-reduce [_fi init] (coll-reduce reducible (transformf fi) init)))) 实现CollFold非常类似于实现CollReduce 参数传给reducible的coll-fold。来验证一下： reducers.core=>(def v(into [](range 1oooo)))#"reducers.core/v reducers.core=>(my-fold +v) 49995000 59 首先对参数中的化简函数进行转换，然后将 ( 00006666 下面这个例子使用了不同函数分别进行化简和合并。用折叠实现词频统计回到之前词频统计的场景，用fold来实现frequencies函数时，非常适合使用不同的函数进行化简和合并： FunctionalProgramming/Reducers/src/reducers/parallel frequencies.clj (defn parallel-frequencies[colu](r/fold (partial merge-with +) (fn [counts x] (assoc counts x (inc (get counts x o)))) colt)) 这让我们想起了今天早些时候学习的批处理版本的count-words一—每一批次都化简成map：然后通过（partial.merge-with+）进行合并。不过由于fold不能适用于懒惰序列（因为无法对懒惰序列进行二分），因此没办法用 Wikipedia的页来测试fold。但可以用一个很长的随机数序列来进行模拟测试。 repeatedly函数反复调用传入的函数来构造一个无穷的懒惰序列。本例中传人的是 rand-int函数，每次调用rand-int会得到一个随机整数： user=> (take 1o (repeatedly #(rand-int 10)))(2628859255) 60 第3章函数式编程用下面的代码可以构造一个很长的随机数序列： reducers.core=> (def numbers (into [j (take 1ooooooo (repeatedly #(rand-int 1o)))))#'reducers.core/numbers 现在分别用frequencies和parallel-frequencies对该随机数序列的整数频率进行统计： reducers.core=> (require ['reducers.parallel-frequencies :refer :all]) nit reducers.core=> (time (frequencies numbers))"ELapsedtime:1500.306msecs" [01000983,1999528,21000515,31000283,4997717,51000101,6999993, reducers.core=>(time(parallel-frequenciesnumbers))"Elapsed time:436.691 msecs" 660021720012006668600 可以看到串行执行的frequencies运行了1500ms，而并行版本运行了400+ms，提速近3.5倍。第二天总结我们在第二天中讨论了如何用Clojure实现并行。明天将关注如何用future模型和promise模型实现并行，以及如何利用它们进行数据流式编程（dataflowprogramming）。第二天我们学到了什么 Clojure可以将串行操作轻松自然地并行化。口pmap可以将映射操作并行化，构造一个半懒惰的map。口利用partition-all可以对并行的映射操作进行批处理，以提高处理效率。口fold使用分而治之的策略，可以将化简操作并行化。口clojure.core.reducers包提供的类似map、类似mapcat、类似filter的函数返回的并不是序列，而是化简器reducible，可以说这是化简操作的关键所在。第二天自习查找口观看RichHickey在QCon2012上介绍reducers库的视频。口阅读pcalls和pvalues的相关文档一一这两个函数与pmap有什么区别？是否能利用pmap 来实现它们？实践口在my-map的基础上创建my-flatten和my-mapcat函数。注意：它们都比my-map更复杂，因为需要将输入序列的一个元素对应到输出序列的一个或多个元素。遇到困难时可以参见本书配套代码。口创建my-filter函数。它也比my-map更复杂，因为需要减少输入序列的元素个数。 3.4第三大：函数式井发 3.4第三天：函数式并发 61 前两天我们一直在关注并行，今天会将注意力转向并发。在这之前，我们将进一步探究为何函数式编程能轻易地实现并行化。同样的结构，不同的求值顺序回顾过去两天，我们的学习一直围绕着同一个主题一一使用函数式编程可以玩转程序的求值顺序。如果两个计算过程相互独立，就可以任意安排这两个计算过程的求值顺序，包括让它们并行。下面的代码，均进行相同的计算、返回同样的结果、具有相似的代码结构，但它们以完全不同的顺序进行求值： o 这段代码化简一个嵌套了懒惰序列的懒惰序列一一每个懒惰序列的元素都是按需求值的。(reduce+(doall(map(partial*2)(range100o)))) 这段代码首先构造map的输出序列（doall强迫懒赖情序列对全部元素进行求值），然后再进行化简。 ((otee)) 这段代码化简一个半懒惰的序列，这个序列是并行求值的。 o 这段代码用单个化简函数对一个懒赖惰序列进行化简，该化简函数由+和（partial、*2)组合而成。 (( 这段代码首先构造range的输出序列，然后创建进行化简和合并的处理树，并根据此树对序列进行并行地化简。在Java这类命令式语言中，求值顺序与源码的语句顺序紧密相关。虽然编译器和运行时（runtime）都可能造成一些乱序执行（比如我们在讨论线程与锁时一直在留意的乱序执行现象，参见2.2节中“诡异的内存”部分），但一般来说，求值顺序与其在代码中的顺序基本一致。函数式语言则更有一种声明式的范儿。函数式程序并不是描述“如何求值以得到结果”，而是描述“结果应当是什么样的”。因此，在函数式编程中，如何安排求值顺序来获得最终结果是相对自由的，这正是函数式代码可以轻松并行的关键所在。下一节我们将学习为什么函数式编程可以玩转求值顺序，而命令式语言却不具有这种能力。 62 第3章函数式编程引用透明性在纯粹的函数式语言中，函数都具有引用透明性一一在任何调用函数的地方，都可以用函数运行的结果来替换函数的调用，而不会对程序产生副作用。来看一些例子： (+1(+23)) 它与下面的代码是等价的：(+ 15) 其实，描述函数式代码执行方式的一种方法就是不断用函数的执行结果替换函数的调用，直到得到最终结果。例如按照下面的方式来计算（+（+12）（+34)）： OT (L E+) (L (Z T +) +) (( E+) (Z T +) +) 也可以是下面的求值顺序： (+(+12)(+34))→(+3(+34))-(+37)=10 当然，这个结论对于Java的+操作也适用。与Java不同的是，函数式编程的每个函数都具有引用透明性。这也是我们能安全地调整函数求值顺序的关键所在。 1/小乔爱间： Clojure不是不纯粹吗？下一章我们将学习到Clojure是一门不纯粹的函数式语言一在Clojure中可以构造带有副作用的函数，这样的函数不具有引用透明性。在实践中这并不会造成很大影响，因为常见的Clojure代码极少出现副作用，并且出现副作用时会非常明显。有一些规则描述了副作用在何处出现是安全的，只要遵循这些规则就不大可能遭遇由求值顺序带来的问题。数据流我们来思考一下数据是如何在函数间流动的。图3-4示意的是（+（+12）（+34））的数据流。由于（+12)和（+34)之间没有依赖关系，所以理论上这两步求值能以任何顺序进行，包括同时执行。前两步求值得到结果后，最后一步加法才能进行。 3.4第三天：函数式并发图3-4（+（+12）（+34)）的数据流 63 理论上，运行时可以从这幅图的左端出发，向右端“推进”数据。当某函数所依赖的数据都可用时，该函数就可以执行了。所有函数（至少是理论上）都可以同时执行。这种执行方式被称为数据流式编程（dataflowprogramming）Clojure提供了future模型和promise模型来支持这种执行方式。 Future模型 future函数可以接受一段代码，并在一个单独的线程中执行这段代码。其返回一个future 对象： user=>(defsum(future(+12345))) #*user/sum user=>sum # 可以利用deref或其简写@对future对象进行解引用，来获取其代表的值： user=>(deref sum) 15 user=>@sum 15 对future对象进行解引用将阻塞当前线程，直到其代表的值变得可用（或者称为被求值）。现在我们可以准确地构造出图3-4所示的数据流图了： user=>(let[a(future(+12)) #_=> 价# 10 b（future(+34)))(+ @a @b)) 这段代码首先用let将（future（+12））赋给a，并将（future（+34)）赋给b。对（+12）和(+34)的求值可以分别在不同线程中进行。最后，外层的加法将一直阻塞，直到内层的加法完成。 64第3章函数式编程当然，对于这种两个数求和的简单计算，使用future模型是大材小用一一之后我们还将学习更有现实意义的例子。不过还是先来了解一下Clojure的promise模型。 Promise模型类似于future对象，promise对象也是异步求值的，也通过defer或@解引用，在求值前也会阻塞线程。不同的是创建一个promise对象后，使用promise对象的代码并不会立刻执行，而是等到用deliver为promise对象赋值后才会执行。下面用一个REPL会话来举例： user=>(def meaning-of-life (promise))#'user/meaning-of-life # user=> (deliver meaning-of-life 42) # Themeaning of life is:42 首先，构造了一个叫meaning-of-life的promise对象。然后，用future函数创建一个线程来打印其值（像这样利用future函数创建线程是Clojure的惯例）。最后，用deliver为promise对象赋值，之前创建的线程就不再阻塞了。我们已经学习了future模型和promise模型，现在来用它们创建一个真实的应用。函数式Web服务我们将创建一个Web服务，用来接收实时的文本数据（例如，一个电视节目的脚本），并进行翻译。文本数据由片段（snippet）构成，片段都带有序号。以路易斯·卡罗尔的诗作Jabberwocky（选自《爱丽丝镜中奇遇》）的第一节为例，来说明片段这个概念： OTwasbrillig,andtheslithyroves 1Didgyreandgimbleinthewabe: 2 All mimsy were the borogoves, 3Andthemomerathsoutgrabe 如果要将片段0提交到Web服务，就要构造一个发往/snippet/O的PUT请求，其内容是“Twas brillig，andtheslithyroves。片段1将被发往/snippet/1，以此类推。这是一个非常简单的API，然而实现起来并不像看上去那么简单。首先，代码是运行在一个并发的Web服务器上的，这就要求代码是线程安全的。其次，由于网络的特性，代码需要处理一些特殊情况，例如片段丢失、重试、重复提交和乱序提交。如果需要按序号处理片段（即片段的处理与片段到达服务器的时间先后无关），就必须要记录哪些片段已经被接收、哪些片段已经被处理。当接收到新的片段时，需要检查是否可以继续处 3.4第三天：函数式并发理片段。这个任务并不容易，值得我们秀一下如何用并发来构造一个简单的解决方案。图3-5展示了解决方案。 Web服务器线程 PUT/snippet/3 PUT/snippet/5 提交片段3 提交片段5 片段缓存 4 5 6. 图3-5文本数据处理流程片段处理线程处理片段1 处理片段2 处理片段3 处理片段4(等待) 65 图3-5的左端是Web服务器创建的线程，用来处理输人请求；右端是串行处理片段的线程，正在等待下一个可用片段。下一节将讨论snippets结构，其将被用于线程之间的交互。接收片段我们用下面的结构来记录已经被接收的片段： FunctionalProgramming/TranscriptHandler/src/server/core.clj(def snippets (repeatedly promise)) snippets是一个由promise对象构成的无穷懒情序列。当某个片段可用时，调用 accept-snippet来为对应的promise对象赋值： FunctionalProgramming/TranscriptHandler/src/server/core.clj(defn accept-snippet [n text] (deliver (nth snippets n)text)) 要串行地处理片段，只需创建一个线程，按序号对每个promise对象进行解引用即可。例如，下面的代码可以串行输出每个片段的值： FunctionalProgramming/TranscriptHandler/src/server/core.clj(future (doseg [snippet (map deref snippets)](printinsnippet))) doseq会串行处理一个序列。本例中，doseq处理的序列是由解引用后的promise对象构成的， snippet指向正在处理的元素。 66 第3章函数式编程剩下的工作就是将所有这些组装成一个Web服务。下面的代码利用了Compojure库? FunctionalProgramming/TranscriptHandler/src/server/core.cljW(defroutes app-routes (PUT"/snippet/:n"[n:as【:keys[bodyJ] (accept-snippet(edn/read-string n)(slurp body))(response"oK"))) (defn-main [&args] (run-jetty(siteapp-routes)(:port3ooo)) 这段代码定义了一个PUT路由，其将调用accept-snippet函数。我们使用了内置的Web服务器Jetty?！一与大多数Web服务器类似，Jetty是多线程的，因此要求代码是线程安全的。现在可以用leinrun启动该服务器，并通过curl命令做一些验证。比如发送片段o： $ curl -x put -d "twas briulig, and the slithy toves"-H"Content-Type:text/plain" localhost:3ooo/snippet/0 OK 服务器马上输出： Twas brillig, and the slithy toves 如果在发送片段1之前发送片段2，那么就不会有任何输出： $ curl -x put -d "Ail mimsy were the borogoves," -H"Content-Type:text/plain"localhost:3ooo/snippet/2 oK 接着发送片段1： $ curt-x put-did gyreand gimble inthewabe:"-H"Content-Type: text/plain"localhost:3ooo/snippet/1 OK 现在片段1和片段2都会被输出： Did gyre and gimble in the wabe: Allmimsyiweretheborogoves, 多次发送同一个片段是没有问题的，因为当promise对象已经被赋值后，再次调用deliver 将不会触发任何动作。所以下面的命令不会带来任何问题，也不会有任何输出： $ curl -X put -d "Did gyre and gimble in the wabe:"\-H"Content-Type:text/plain" localhost:3ooo/snippet/1 OK 至此，我们已经学习了如何处理片段，下面将做一些更有趣的尝试。设想有另外一个用于翻 Dhttps://github.com/weavejester/compojure ②http://www.eclipse.org/jetty/ 3.4第三天：函数式并发译文本的Web服务，来修改一下代码，使用新的Web服务进行文本翻译。句子 67 在学习如何调用翻译服务之前，要先将片段的序列转换成句子的序列。句子的分隔符可能出现在片段的任意位置，所以需要对片段进行分割或合并，以解析出句子。首先，按照句子的分隔符进行分割： FunctionalProgramming/TranscriptHandler2/src/server/sentences.clj)(defn sentence-split [text] (map trim (re-seq #"[^\.!\?:]+[\.!\?:;]*" text))) re-seq接受一个正则表达式来匹配句子，并返回匹配的序列。可以用trim删除不必要的空格 server.core-> (sentence-split "This is a sentence. Is this?! A fragment")("This is a sentence." "Is this?!""A fragment") 接下来，使用一个正则表达式的技巧以判断某字符串是不是一个完整的句子， FunctionalProgramming/TranscriptHandler2/src/server/sentences.clj(defn is-sentence? [text] (re-matches #"^,*[\,!\?:]$" text)) server.core=> (is-sentence? This is a sentence.")"This is a sentence." server.core=> (is-sentence? "A sentence doesn't end with a comma,") nil 最后，将这些知识点组装在一起，创建strings->sentences函数。该函数接受一个字符串序列，并返回一个句子序列： FunctionalProgramming/TranscriptHandler2/src/server/sentences.clj(defn sentence-join [x y] (if (is-sentence?x)y (str xw "y))) (defn strings->sentences [strings](fitter is-sentence? (reductions sentence-join (mapcat sentence-split strings)))) 这里用到了reductions函数。顾名思义，reductions函数与reduce类似，唯一的区别是它不返回单一值，而是返回由每一步骤的中间值构成的序列： server,core=> (reduce + [1 2 3 4]) 10 server.core=> (reductions + [1 2 3 4])(13610) 在此使用了sentence-ioin作为化简函数。如果第一个参数是个完整的句子，就返回第二个 68 第3章函数式编程参数；否则，就返回将两个参数（用空格）连接后的结果： eeaa"start of another" server.core=> (sentence-join "This is" "a sentence.")"This is a sentence. 与reductions合用时： aoaaona#'server.core/fragments server.core=> (reductions sentence-join fragments) ("A""A sentence.""And another.""Last""Last sentence.") 用is-sentense?过滤结果： server.core=> (filter is-sentence? (reductions sentence-join fragments))("A sentence.""And another.""Last sentence.") 这样就得到了句子序列，现在可以将其传给负责翻译的服务器了。翻译句子使用future模型的一个典型场景是与其他服务器之间的通信。future模型允许主线程运行时，将访问网络之类的操作放在另一个线程上进行。下面是translate函数，其返回一个future对象，对这个future对象求值将获得函数参数翻译后的结果： FunctionalProgramming/TranscriptHandler2/src/server/core.clj(def translator"http://localhost:3oo1/translate") (defn translate [text](future (:body (client/post translator (:body text)))) 这段代码用到了cli-http库?提供的函数client/post，来进行POsT请求并获取返回。现在可以使用translate函数，对之前strings->sentences的结果进行翻译，其结果是一个集合。 FunctionalProgramming/TranscriptHandler2/src/server/core.clj (def translations(delay (map translate (strings->sentences (map deref snippets))))) 这里用到了delay函数，其创建一个懒惰的值一一在被解引用前不会进行求值。组装下面是文本翻译Web服务的完整代码： https://github.com/dakrone/clj-http FunctionalProgramming/TranscriptHandler2/src/server/core.clj Line1 (def snippets (repeatediy promise)) (def translator"http://localhost:3oo1/translate") 5 (defn translate [text] (future (:body (client/post translator {:body text})))) (def translations(delay 10 3.4第三天：函数式并发 (map translate (strings->sentences (map deref snippets)))))(defn accept-snippet [n text] (deliver (nth snippets n) text)) 15 (defn get-translation [n]@(nth @translations n)) (defroutes app-routes 20 25 (PUT"/snippet/:n" [n :as T:keys [body]}] (accept-snippet (edn/read-string n)(slurp body))(response"ok")) (GET"/translation/:n"[n] (response(get-translation(edn/read-string n))))) (defn -main [& args] (run-jetty (wrap-charset (api app-routes))(:port 3ooo))) 69 这段代码中添加了一个GET人口，用来获取翻译的结果（第23行）。其中使用了get-transla tion函数（第16行），用来访问translations序列。现在可以运行一下我们的成果了。首先启动上面创建的服务器，然后启动本书配套代码中的翻译服务器，最后运行TranscriptTest程序（同样也在配套代码中），现在你应当能看到诗歌 Jabberwocky被逐句翻译成法语： $leinrun Il brilgue, les toves lubricilleux Se gyrent en vrillant dans le guave: Enmimes sont les gougebosqueux Et le momerade horsgrave. Garde-toi du Jaseroque, mon fils! La gueule qui mord; la griffe qui prend! aaiaoo K 至此我们达成了目标个综合运用了懒赖惰性、future模型、promise模型的完整的并发Web 服务器。其中没有使用可变状态，也没有使用锁。比起用命令式语言实现的等价解决方案，我们的方案更简单易读。 3 70 第3章函数式编程 1/小乔爱间我们是否一直持有序列的头元素？上面的Web服务使用了两个懒情序列：snippets和translations。程序直在持有这两个序列的头元素（参见3.2节中“懒情一点好”部分），因此这两个序列将一直增长。程序也将占用越来越多的内存。下一章我们将学习如何用Clojure的引用类型来解决这个隐患，并修改Web服务，让其可以处理多个文本的数据。第三天总结我们结束了第三天的学习。这些天讨论了如何用函数式编程高效地实现并行和并发。第三天我们学到了什么函数式编程中的函数具有引用透明性。利用这个特性可以安全地对函数的求值顺序进行调整，而不会影响到程序的运行。值得一提的是，利用这个特性可以让代码在其所依赖的数据被准备好时才可运行，这也称为数据流式编程（Clojure提供future模型和promise模型对其进行支持）。我们还通过一个例子，用数据流式编程简化了Web服务的实现。第三天自习查找口future与future-cali有什么区别？如何用其中一个实现另一个？口如何鉴别一个future对象被求值时是否进行了阻塞？如何取消一个future对象？实践口修改之前创建的文本处理服务器，处理发往/translation/：n的GET请求时，如果暂时还没有翻译结果，就不进行阻塞，而是返回状态码409。口用命令式语言实现文本处理服务器。其是否与函数式版本一样简洁？如何保证它不存在竞态条件？ 3.5复习许多人对并行的理解存在一个误区一一认为并行一定会伴随着不确定性，如果不串行执行，那么我们就不能依赖某一种执行顺序的结果，必须时刻警惕竞态条件。 3.5复习71 当然，有一些并发程序一定会带有不确定性。这对它们来说是不可避免的一一有一些场景天生就依赖于时序。但这并不意味着所有的并行程序都有不确定性。例如，对0到10000之间的数求和，即使将串行加法改为并行加法，也不会改变结果；无论用多少线程对某个Wikipediadump 进行词频统计，其结果总是相同的。在使用线程与锁模型的程序中，大多数潜藏的竞态条件并不是来自于问题本身的不确定性而是隐藏于解决方案的细节中。函数式代码具有引用透明性，因此可以随意改变其执行顺序，而不会对最终结果产生影响我们可以顺理成章地让相互独立的函数并行执行一一本章的例子也利用这个特性轻易地将函数式代码并行化了。 1/小乔爱问为什么没看到单子（Monad）和么半群（Monoid）？通常介绍函数式编程时都会对一些数学概念进行阐述，例如单子、么半群、范畴论(Categorytheory）。我们用了一整章来介绍函数式编程，却没有涉及这些概念。为什么？程序员对编程语言的偏好很大程度上取决于语言的类型系统。使用Java，Scala之类的静态类型语言的体验，与使用Ruby、Python之类的动态类型语言的体验是完全不同的。静态类型语言强迫程序员在早期必须选择正确的类型。只有付出这样的代价，编译器才能确保运行时不发生类型错误，并且类型系统可以优化执行效率。动态类型语言不强追程序员在早期付出如此代价，但程序员要承担运行时发生类型错误或者运行效率较低的风险。在函数式编程的范畴也同样存在这种分歧。像Haskell这种静态类型的函数式语言利用单子和么半群等数学概念为类型系统增加了以下能力：明确限制了某些函数和某些值可以使用的位置，在保持函数性的同时可以检测代码的副作用。在使用Clojure时，学习这些数学概念对理解理论无疑非常有帮助，但Clojure使用的不是静态类型系统，因此介绍这些数学概念的实用意义不大。另一方面，由于编译器不会对相关的错误进行告警，因此程序员必须手工确认函数和值的使用场景是正确的，这无疑增加了程序员的负担。优点使用函数式编程最大的好处是我们可以确信程序是按照我们预想的方式运行的。一旦上手（这可能需要花些时间，如果你对命令式编程“中毒”已深则更是如此），比起等价的命令式程序， 72第3章函数式编程函数式程序会更简单，更容易推理，也更便于测试。如果我们写了一个函数式解决方案，利用函数式程序的引用透明性，我们可以轻松地将程序并行化，或者在一个并发环境下使用该方案。由于函数式代码不使用可变状态，大部分存在于线程与锁模型中的并发bug将销声匿迹。缺点很多人认为函数式代码比起等价的命令式代码效率较低。对于某些场景确实存在性能损失，但大部分场景性能损失是远低于预期的。而且用少许性能损失来换取程序健壮性和扩展性的提升是值得的。其他语言近期，Java8添加了一系列新特性，使用这些特性可以更容易地写出函数式代码，其中最有名的是lambda表达式和streamAPI?。streamAPI支持聚合操作，其类似于Clojure的reducer，可以并行地处理流。所有的函数式编程都会介绍Haskell。本章和之后的章节介绍的所有技术在Haskell都可以找到。SimonMarlow的教程是学习Haskell并行编程和并发编程的绝佳选择。结语本章介绍了函数式编程在并发与并行方面的诸多优势，然而其优点还远不止于此。可以断言函数式编程在未来会变得更重要。前面已经提到过，在可预见的将来，可变状态会一直伴随在我们左右。下一章我们将学习 Clojure如何处理函数的副作用，同时又不牺牲对并发的支持。 ①http://docs.oraele.com/javase/tutorial/java/javaoo/lambdaexpressions.html ②http:/docs.oracle.com/javase/tutorial/collections/streams/index.html ③ http://haskell.org/ @http://community.haskell.org/~simonmar/par-tutorial.pdf 第4章 Clojure之道分离标识与状态现代的混合动力客车同时拥有内燃机和电动机的优点。根据环境不同，有时只使用汽油，有时只使用电力，有时则同时使用两者。与之类似，Clojure也提供了一种方法，混合了函数式编程和可变状态一一这种方法平衡了两者优点，成为并发编程的利器。 4.1混搭的力量函数式编程对于某些问题是非常适用的，但对于某些状态易变的问题则不然。虽然函数式编程可以用来解决这类问题，但用传统的思路处理会更加容易一些。上一章中介绍了Clojure的纯函数子集，而本章中我们将偏离之前的内容，学习如何用Clojure提供的混搭技术来解决这类问题。第一天，我们将讨论原子变量，它是Clojure提供的用于并发的可变数据类型。我们也将学习如何使用原子变量和持久数据结构来分离标识与状态。第二天，学习Clojure的其他可变数据结构代理和软件事务内存。第三天，将分别用原子变量和STM实现一个算法，并讨论两种解决方案的利。 4.2第一天：原子变量与持久数据结构纯粹的函数式语言完全不支持可变量。相比之下，Clojure是不纯粹的一一其为不同的并发场景提供了大量的多样的可变量。通过使用可变量和持久数据结构（我们稍后会解释持久的意思），可以避开传统并发程序中共享可变状态带来的诸多问题。 ①在此将mutablevariables/data译为“可变量”，意为这些“量”在整个生命周期中其值是可能改变的。在数学领域中，应称其为“变量”。但“变量”一词在编程领域中指的是“编译期结束后其值可能改变的量”，与数学领域中“整个生命周期中其值是可能改变的量”有少许差异，为避免混淆，将其译为“可变量”。同样的差异也存在于“常量”（编译期就能确定其值不改变的量）和“不变量”（整个生命周期中其值不改变的量）。另外，在此将variable 和data统称为“量”，是为了简化相关的概念，不会影响之后的阅读。一—译者注 74 第4章Clojure之道一分离标识与状态在此要特别强调不纯粹的函数式语言与命令式语言的区别。在命令式语言中，变量默认都是状态易变的，代码会经常修改变量。而在不纯粹的函数式语言中，变量默认是状态不易变的，代码仅在十分必要时才修改变量。稍后我们会学习到：使用Cloiure的可变量，可以在保证安全性和数据一致性的同时，处理好可变状态带来的副作用。今天我们要学习如何使用可变量和持久数据结构来分离标识与状态。采用这些技术，多线程可以不使用锁（当然也就不会有死锁的风险）访问可变量，同时也不会碰到3.2节中介绍的风险（隐藏可变状态和逃逸可变状态）。先来看看Clojure提供的最简单的可变量类型一一原子变量。原子变量原子变量就是具有原子性的变量，非常类似于2.3节中介绍的原子变量（事实上Clojure的原子变量就是在java.util，concurrent.atomic的基础上建立的）。下面的例子用于创建原子变量并获取其值： user=>(defmy-atom(atom42))#user/my-atom user=> (deref my-atom) 42 user=> @my-atom 42 使用atom函数可以创建原子变量，其参数是原子变量的初始值。通过defer或@可以获得原子变量的值。使用swap！可以更新原子变量的值： user=>(swap!my-atominc) 43 user=>@my-atom 43 swap！接受一个函数，并将原子变量的当前值传给该函数，该函数的返回值将作为原子变量的新值。也可以将额外的参数传给函数，例如： (z +ore- idems)=asn 45 本例中，原子变量的新值是（+432）。一个不太常用的函数是reset！，可以用来重置原子变量的值，无论原子变量是什么值： user=> (reset! my-atom 0) 0 user=>@my-atom 0 原子变量可以是任何类型一 user=>(def session (atom ())#user/session 4.2第一天：原子变量与持久数据结构很多Web应用都是用原子map来存储会话数据的，例如： user=>(swap!session assocusername"paut"){:username"paul"} user=>(swap!sessionassoc:session-id1234){:session-id 1234, :username"paul"} 我们已经通过REPL了解了原子变量的一些特性，现在来看一个实际应用的例子。具有可变状态的多线程Web服务 75 3.2节讨论了一个假想的用于管理比赛的Web服务。这一节我们会完整实现这个Web服务，并学习如何使用Clojure的持久数据结构来避免Java中逃逸可变状态的风险。 Clojure/TournamentServer/src/server/core.clj Line1 (def players (atom ())) (defnlist-players[] (response(json/encode @players)))(defn create-player [player-name] (swap!players conj player-name)(status (response "")201)) 10(defroutesapp-routes (GET"/players"[](list-players)) (PUT"/players/:player-name"[player-name](create-player player-name)))(defn-main [&args] (run-jetty (site app-routes)(:port 30oo))) 这段代码定义了两个路由一一发往/players的GET请求会返回当前的运动员列表（JSON格式），发往/players/name的PUT请求则会添加一个运动员。与上一章的Web服务一样，由于使用的Jetty服务器是多线程的，因此需要保证代码是线程安全的。在讨论这段代码的工作原理之前，先来直接感受一下。可以在命令行中调用curl进行测试： $ curl localhost:30oo/players $ curl-Xput localhost:3ooo/players/john $ curl localhost:3ooo/players［"john"] $ curl -X put localhost:30oo/players/paul $ curl -X put localhost:3ooo/players/george $ curl -X put localhost:3ooo/players/ringo $ curl localhost:3ooo/players [o.inedaooaooo.] 76第4章Clojure之道—一分离标识与状态现在来看看core.clj的工作原理。原子变量players（第1行）被初始化成空列表（）。通过coni 可以添加新的运动员（第7行），并返回HTTP状态201（表示已创建）的空响应。通过@获取players 的值，并以JSON形式返回运动员列表（第4行）。一切看上去很简单（实际上也确实如此），但有一件事情困扰着我们。list-players和 create-player函数都访问players一一为什么这段代码不会有之前逃逸可变状态的问题？如果一个线程正在遍历players并将其转换为JsON格式，而另一个线程同时向players中添加元素，那么会发生什么？ Clojure的数据结构是持久的，因此这段代码才是线程安全的。持久数据结构我们这里说的“持久”并不是指将数据持久化到磁盘或者保存到数据库中，而是指数据结构被修改时总是保留其之前的版本，这样可以为代码提供一致的数据视角。来用REPL看一个简单的例子： user=> (def mapvl (:name"paul":age 45))#*user/mapvl user=>(defmapv2(assocmapvl:sex:male)) #user/mapv2 user=>mapv1 f:age45,:name"paut"} user=>mapv2 (:age 45,:name"paul",:sex :male) 持久数据结构被修改时看上去就像创建了一个完整的副本。如果持久数据结构在实现时也创建完整副本，那将非常低效并且使用限制很大（可以类比2.4节介绍过的CopyOnwriteArray List）。幸运的是，持久数据结构的实现选择了更精巧的方法，其中使用了共享结构。最容易理解的持久数据结构就是列表。来看一个简单的例子： user=>(def listvl (list123)) #'user/listvl user=>listvi(1 2 3) 图4-1展示了上述列表在内存中的表现形式。 2 listv1 图4-1listv1在内存中的表现形式 3 4.2第一天：原子变量与持久数据结构 77 现在用cons创建上述列表的修改版，cons返回列表的副本并在副本的首段上添加一个元素： user=> (def 1istv2 (cons 4 listvi)) #'user/listv2 user=> listv2(4123) 新列表可以完全共享原列表的结构 listv2 listv1 -不需要进行复制，如图4-2所示。 3 图4-2.listv2在内存中的表现形式再尝试创建另一一个改进版，如图4-3所示。 user=> (def listv3 (cons 5 (rest listvl))) #user/listv3 user=>listv3(523) Clistv2 listv1 listv3 图4-3listv3在内存中的表现形式本例中新列表仅共享了原列表的部分结构，但仍不需要进行复制。有些情况下是不能避免复制的。有共同尾端的列表可以共享结构一的尾端，就只能进行复制了。举例说明： user=> (def 'listvl (list 1 2 3 4))#'user/listvi user=>(def listv2 (take2listv1)) #user/listv2 user=>listv2(1 2) 一如果两个列表具有不同 78 第4章Clojure之道一分离标识与状态图4-4展示了其在内存中的形式。 listv1 listv2 图4-4具有不同尾端的两个列表在内存中的表现形式 Clojure的集合都是持久的。持久的vector、map和set在实现上都比列表复杂，但此处我们仅需知道它们都使用了共享结构，并且与Ruby和Java中对应的非持久结构具有相近的性能。 V/小乔爱问：非函数式语言中数据结构可以是持久的吗？在非函数式语言中是有可能创建持久数据结构的。我们已经在Java中看到过一个例子（CopyOnwriteArrayList），而且Clojure的核心数据结构大部分都是由Java写成的。而Java 被创造出来时还不存在Clojure，所以我们说非函数式语言是有可能创建持久数据结构的。话虽如此，用非函数式语言实现持久数据结构是比较困难的一一很难保证其正确性和效率一一主要是因为此类编程语言不能为你提供任何辅助，完全要依靠自己实现持久化。相比之下，函数式的数据结构天生就是持久的。标识与状态如果一个线程引用了持久数据结构，那么其他线程对数据结构的修改对该线程就是不可见的。因此持久数据结构对并发编程的意义非比寻常，其分离了标识（identity）与状态（state）。你的汽车有多少油？现在这一刻可能有一半油。一段时间以后油箱可能几乎空了，再过几分钟（当你加完油后）油箱就满了。“你的汽车有多少油”是一个标识，其状态是一直在改变的，也就是说，实际上它是一系列不同的值一一2012-02-2312:03，值是0.53；2012-02-2314:30，值是 0.12；2012-02-2314:31，值是1.00。命令式语言中，一个变量混合了标识与状态个标识只能拥有一个值，这让我们很容易忽略一个事实：状态实际上是随时间变化的一系列值。持久数据结构将标识与状态分离开来 4.2第一天：原子变量与持久数据结构 79 如果获取了一个标识的当前状态，无论将来对这个标识怎样修改，获取的那个状态将不再改变。赫拉克利特（Heraclitus）是这样描述这个现象的： A?Q～IBH@ET，@b 许多编程语言都错误地认为河流是不变的实体；而Clojure则认为河流是一直在改变的。重试由于Clojure是函数式语言，其原子变量是无锁的一一其内部实现使用了java.util.concu-rrent.AtomicReference包提供的compareAndSet（）方法。因此使用原子变量的效率很高且不会发生阻塞（当然也不会有死锁的风险）。但这也要求swap！必须处理下面这种情况：当swap！调用其参数函数（即由参数传入的函数）产生新值、但还未修改原子变量的值时，其他线程就修改了原子变量的值。如果发生了这种情况，swap！就需要重试（retry）。swap！将放弃从参数函数中返回的值，并用原子变量的新值重新调用参数函数。我们在2.4节中介绍concurrentHashMap时见过类似的机制。这要求swap！的参数函数必须没有副作用一一否则，在重试时这些副作用可能会发生多次。幸运的是，函数式代码天生是没有副作用的。Clojure的函数式天性让我们避免了这个麻烦。校验器假设我们需要一个非负值的原子变量。在创建原子变量时可以提供一个校验器（validator）： ((( %)#ee e ) a#user/non-negative user=> (reset! non-negative 42) 42 user=> (reset! non-negative -1) IllegalstateException Invalid reference state 校验器是一个函数，当改变原子变量的值时就会调用它。如果校验器返回true，就允许这次修改，否则就放弃这次修改。校验器在原子变量的值改变生效之前被调用。与本节“重试”部分中传给swap！的参数函数类似，当swap！进行重试时，校验器可能会被调用多次。因此校验器不应有副作用。监视器可以为原子变量添加一个监视器： user=> (def a (atom o))#'user/a 80 第4章Clojure之道一一分离标识与状态 # user=>(swap! a + 2) Changed from o to 2 2 添加监视器时需要提供一个键值和一个监视函数。键值用于区分不同的监视器（例如，有多个监视器时，可以通过键值来删除一个指定的监视器）。原子变量的值被改变时会调用监视器。监视器接受四个参数一一调用add-watch时指定的键值、原子变量的引用、原子变量的旧值和原子变量的新值。上例中再次使用了读取器宏#（，：：）来定义匿名函数，该函数用于打印原子变量的旧值（%3）和新值（%4）。与校验器不同，监视器是在原子变量的值改变之后才被调用，且无论swap！重试多少次，监视器只会被调用一次。因此，监视器可以具有副作用。注意：监视器被调用时，原子变量的值可能已经再次被改变，因此监视器必须使用参数中提供的新值，而不能通过对原子变量进行解引用来获取新值。混搭式Web服务在3.4节中，我们用Clojure创建了纯粹函数式的Web服务。尽管它运行良好，却存在两个明显的限制一一仅能处理一个文本数据，并且会持续消耗内存。在此我们会在保留原版本的函数式特性的同时，突破这两个限制。会话管理我们将引人会话（session）这个概念，使Web服务支持多个文本数据。每个会话拥有一个唯一的数字标识，通过下面的代码可生成这个标识： Clojure/TranscriptHandler/src/server/session.clj (def last-session-id (atom o))(defn next-session-id [] (swap! last-session-id inc)) 这里会用到原子变量last-session-id，创建新会话标识时会将原子变量的值递增。每次调用next-session-id都会得到比之前大1的一个值： server.core=>(in-ns "server.session)#(next-session-id) server.session=> (next-session-id) 2 server.session=>(next-session-id) 3 4.2第一天：原子变量与持久数据结构 81 还用到了原子变量sessions，它是将会话标识映射到会话的map，利用sessions可以追踪当前活跃的会话。 (def sessions(atom())) (defn new-session[initial] (let[session-id(next-session-id)] (swap!sessionsassocsession-idinitial) session-id)) (defn get-session [id](@sessionsid)）通过调用new-session并传人一个初始值，可以创建一个新的会话。new-session将获取一个新的会话标识，并调用swap！将会话添加到sessions中。用get-session获取会话的过程就是简单地用会话标识进行查找。会话过期如果要解决Web服务持续消耗内存的问题，就需要一种机制来删除不再使用的会话。虽然可以显式地进行删除（比如使用一个delete-session函数），但对于二个Web服务来说，不能依赖于客户端清理各自的会话，而是需要实现会话过期的机制。先对之前的代码做一个小改动： Clojure/TranscriptHandler/src/server/session.clj (def sessions (atom ())》 (defn now [] (System/currentTimeMiilis))）(defn new-session[initial] (let [session-id (next-session-id) session(assoc initial :last-referenced(atom (now)))) (swap! sessions assoc session-id session) session-id)) (defn get-session [id] (let [session (@sessions id)) (reset! (:last-referenced session) (now)) session)）新的辅助函数now会返回当前时间。用new-session创建新会话时，需要为会话添加新属性：last-referenced，这是含有当前时间的原子变量。当调用get-session访问会话时，用 reset！来更新这个时间戳。现在每个会话都有：last-referenced属性。程序会定期检查所有的会话，当某会话超过一定时间没有被访问时，就可以让该会话过期： Clojure/TranscriptHandler/src/server/session.clj(defn session-expiry-time [) 82 第4章Cloiure之道—一分离标识与状态 (-(now）(*10601000)))(defn expired?[session] (< @(:last-referenced session)(session-expiry-time))) (defn sweep-sessions[] (swap!sessions#(remove-vals%expired?)))(def session-sweeper (schedule:min(range 60 5)}sweep-sessions)) 在session-sweeper函数中，使用了Schejulure库?，这段代码让程序每5分钟调用一次 Sweep-sessions。sweep-sessions会（使用Useful库提供的remove-vals函数）删除expired？为true的会话，这些会话最后一次被访问是在session-expiry-time毫秒（即10分钟）之前。组装现在可以将会话这个功能添加到之前的Web服务中。首先，需要一个创建新会话的函数： Clojure/TranscriptHandler/src/server/core.clj(defn create-session [] (let[snippets（repeatedlypromise） translations (delay (map translate (strings->sentences(mapderef snippets))))] (new-session (:snippets snippets :translations translations)))) 与上一章相似，我们仍然使用一个无穷的懒惰的promise序列（snippets）来表示接收到的片段，以及一个map（translations）来表示该序列到翻译结果的映射，但这次将两个变量都保存到了会话中。接下来，修改accept-snippet和get-translation函数，使其从会话中得到：snippets 和:translations： Clojure/TranscriptHandler/src/server/core.clj(defn accept-snippet [session n text] (deliver (nth (:snippets session)n)text))(defn get-translation [session n] @(nth @(:translations session) n)) 最后，需要为路由添加会话功能： Clojure/TranscriptHandler/src/server/core.clj(defroutes app-routes (PosT"/session/create"[] (response(str(create-session)))) Dhttps://github.com/AdamClements/schejulure ②https://github.com/flatland/useful 4.2第一天：原子变量与持久数据结构 (context "/session/:session-id" [session-id] (let [session (get-session (edn/read-string session-id))](routes (PUT"/snippet/:n"[n:as(:keys [body]}] (accept-snippet session (edn/read-string n)(slurp body))(response"ok")) (GET"/translation/:n" [n] (aa) 至此，已经得到了新的Web服务，其主体仍是函数式的，并且谨慎地使用了可变状态。第一天总结 83 我们结束了第一天的学习。第二天将学习另一些可变数据类型一一代理（agent）和引用（ref）。第一天我们学到了什么 Clojure是一门不纯粹的函数式语言，提供了大量的可变数据类型。我们已经学习了其中最简单的一种——原子变量。口命令式语言和不纯粹的函数式语言的区别是今天的一个重点。 ■命令式语言中，变量默认是状态易变的，代码会经常修改变量。 ■不纯粹的函数式语言中，变量默认是状态不易变的，代码仅在必要时修改变量。口函数式语言中，数据结构是持久的，也就是说当一个线程修改它时，将不会影响到引用同一个数据结构的其他线程。口借助上述特性，我们可以分离标识与状态。与标识不同，状态实际上是一系列随时间变化的值。第一天自习查找阅读KarlKrukow的博文“UnderstandingClojure's PersistentVector Implementation”，了解比链表更复杂的持久数据结构是如何实现的。口阅读上一篇博文的后续文章，了解PersistentHashMap是如何通过HashArrayMapped Trie技术来实现的。实践口扩展本节开头的例子TournamentServer，使其可以添加和删除运动员。口扩展“混搭式Web服务”中的例子TranscriptServer，当一个片段花费1o余秒仍未接收完时，让服务器能从这个状态中恢复过来。第4章Clojure之道—分离标识与状态 84 第二天：代理和软件事务内存 4.3 我们昨天学习了原子变量，今天来学习其他两种可变数据类型：代理（agent）和引用（ref）。与原子变量性质相同，代理和引用都可以用于并发，也能与持久数据结构一起使用，实现标识与状态的分离。在学习引用时，我们将讨论Clojure如何实现对软件事务内存的支持，使变量在无锁的情况下可以被并行地修改，同时仍保持一致性。代理与原子变量类似，代理包含了对一个值的引用，可以通过deref或@获取该值： user=>(def my-agent(agent o)) #'user/my-agent user=> @my-agent 调用send函数可以修改代理的值： user=>(send my-agent inc) # user=>@my-agent user=> (send my-agent + 2)# user=> @my-agent 3 与swap！类似，send接受一个函数（可以附加额外的参数），并用代理的当前值作为参数对该函数进行调用，函数的返回值将作为代理的新值。 send与swap！的区别是，前者会（在代理的值更新之前）立刻返回一一传给send的函数将在之后的某个时间被调用。如果多个线程同时调用send，传给send的函数将被串行调用：同一时间只会调用一个。也就是说该函数不会进行重试，并且可以具有副作用。小乔爱问代理是actor吗？表面看上去Clojure的代理和actor（将在第5章介绍）非常相似。但这是一种误解，实际上两者有很大差异：口通过deref可以获得代理的值而actor没有提供直接获得值的方式；口actor可以包含行为（behavior），而代理则不可以一一对数据的操作函数必须由调用者提供；口actor提供了复杂的错误检测和错误恢复的机制，而代理仅提供了简单的错误报告机制；口actor能支持分布式，而代理则不能；口使用多个actor可能会引发死锁，而使用多个代理则不会。等待代理的操作完成 4.3第二天：代理和软件事务内存 85 之前我们在REPL的输出中看到，Send的返回值是一个代理的引用。REPL打印这个引用时也打印了代理的值—一本例中是1： user=> (send my-agent inc)# 再次调用send时，其显示的不是3，而仍然是1： (aea)a# 这是因为传给send的函数是异步运行的，在REPL获得代理的值之前，该函数可能已经运行，也可能没有运行。对于执行比较快的函数，在REPL获得代理的值之前可能已经运行了；但如果我们用Thread/sleep来延长函数的运行时间，那函数就不大可能在REPL获取代理的值之前完成运行： user=> (def my-agent (agent o))#*user/my-agent user=> (send my-agent #((Thread/sleep 20oo) (inc %)))# user=> @my-agent 0 @my-agent user=> 1 Clojure提供了await函数，这个函数将一直阻塞，直到由当前线程派给某个（或某些）代理的所有操作全部完成（Clojure还提供了await-for函数，可以指定等待的超时时间）： user=>(def my-agent(agent o))#"user/my-agent (((%）oo/e)#a）=a# user=> (await my-agent) nil user=> @my-agent 小乔爱问： Send-off和Send-via 除了 send，代理还支持send-off和send-via函数。不同的是如何执行传入的函数！ send使用公用线程池，send-off使用一个新线程，而send-via使用由参数指定的executor。如果传入的函数可能会阻塞（并占用其执行线程）或需要执行很久，推荐使用send-off 或send-via。除此之外，三个函数差别不大。 86第4章Clojure之道—分离标识与状态异步更新比同步更新有着明显的优势，尤其是当更新操作会发生阻塞或需要执行很久时。但异步更新也更复杂，尤其在错误处理方面。下面来看看Cloiure对错误处理方面的支持。错误处理代理与原子变量一样都支持校验器和监视器。下面的例子中，代理使用了一个校验器来确保其值不为负数： user=> (def non-negative (agent 1 :validator (fn [new-vau] (>= new-val o))))#"user/non-negative 递减代理的值，直到其将变为负数： user=> (send non-negative dec) # user=>@non-negative 0 user=> (send non-negative dec) # user=> @non-negative 0 不出所料，代理的值不会变为负数。但如果继续使用这个发生过错误的代理，会怎样呢？ user=> (send non-negative inc) IllegalstateException Invalid reference state clojure.lang.ARef.validate: user=>@non-negative 0 一旦代理发生错误，就会默认进入失效状态，之后对代理数据的任何操作都会失败。使用 agent-error可以查看一个代理是否为失效状态（也可以查看其失效原因），使用restart-agent 可以重置失效状态的代理： user=> (agent-error non-negative) user=>(restart-agentnon-negative o) 0 user=> (agent-error non-negative) nil user=> (send non-negative inc) # user=>@non-negative 1 创建代理时其错误处理模式默认为：fai。也可以将错误处理模式置为：continue，这意味着失效状态的代理不需要通过restart-agent重置就可以处理新的操作。如果设置了错误处理函数，那错误处理模式默认为：continue，代理出现错误时则会调用错误处理函数。下面来看一个使用代理的例子。内存日志系统 4.3第二天：代理和软件事务内存 87 进行并行编程时，我发现内存日志系统是非常有用的一一传统日志系统体量过大，在处理并发问题时往往无所禅益，比如对于每行日志都会进行多次上下文切换和IO操作。用线程与锁模型实现内存日志系统比较复杂，而使用代理来实现就非常简单： Clojure/Logger/srclogger/core.clj (def log-entries (agent []))(defn log [entry] (sendlog-entries conj【(now)entryl)) 日志被记录在代理log-entries中，其初始值是一个空数组。log函数用coni向数组中添加新元素，新元素是一个二元数组一一第一个元素是时间戳（记录着send被调用的时间，而不是 coni被代理调用的时间，coni调用的时间可能比send要晚），第二个元素是日志消息。在REPL中验证一下： logger.core=>(log"Something happened") # logger.core=> (log"Something else happened") logger.core=>@log-entries [[1366822537794"Something happened"] [1366822538932"Something else happened"]] 下一节我们来学习另一种Clojure的共享可变数据类型一一引用。软件事务内存引用（ref）比原子变量和代理更复杂，通过引用可以实现软件事务内存（SoftwareTransactional Memory，STM）。通过原子变量和代理每次仅能修改一个变量，而通过STM可以对多个变量进行并发的一致的修改，就像数据库的事务可以对多条记录进行并发的一致的修改一样。与原子变量和代理类似，引用（ref）包装了对一个值的引用（reference），可以通过deref 或@获取该值。 user=>(def my-ref(ref o)) #'user/my-ref user=> @my-ref 引用的值可以通过ref-set来设置。Clojure提供了alter函数来修改引用的值，它类似于之前提到的swap！和send，但不同点在于其使用时不能只是简单地被调用： user=> (ref-set my-ref 42) IllegalstateException No transaction running user=> (alter my-ref inc) 88 第4章Clojure之道一分离标识与状态 IllegalstateException No transaction running 只能在一个事务中才能修改引用的值。事务 STM事务具有原子性、一致性和隔离性。原子性：在其他的事务看来，当前事务的所有副作用或者全部发生，或者都不发生。一致性：事务保证全程遵守校验器定义的规范（就像我们在原子变量和代理中看到的一样）。如果事务的一系列修改中任一个校验失败，那么所有的修改都不会发生。隔离性：多个事务可以同时运行，但同时运行的事务的结果与串行运行这些事务的结果应当完全一样。你可能已经看出来了，这三个性质是许多数据库支持的ACID特性中的前三个。唯一遗漏的性质是持久性一一STM的数据在电源故障或系统崩溃时会丢失。如果需要用到持久性，就必须使用数据库。使用dosync创建一个事务： user=> (dosync (ref-set my-ref 42)) 42 user=> @my-ref 42 user=>(dosync(altermy-ref inc)) 43 user=>@my-ref 43 dosync包装的所有元素构成了一个事务。小乔爱问：这些事务必须具有隔离性吗？大多数场景适合使用完全隔离的事务，但对于有些场景，隔离性是个过强的约束。如果用commute替换alter，就可以得到不那么强的隔离性。虽然使用commute是一种有效的优化手段，但是理解其适用场景是比较复杂的，因此本书不介绍这部分内容。多个引用 4.3第二天：代理和软件事务内存 89 事务通常会涉及多个引用（否则，应使用原子变量或代理）。使用事务的典型场景是在不同银行账户之间进行转账一一大家永远不想看到“钱已经从源账户中划出、但未能划人目标账户” 的情况。下面这个函数保证了出账和人账都发生，或者都不发生： Clojure/Transfer/src/transfer/core.clj(defn transfer [from to amount](dosync (alter from -amount)(alter to + amount))) 对这个函数进行验证： user=>(defchecking(ref1eoo))#"user/checking user=> (def savings (ref 2000))#'user/savings user=>(transfer savings checking 1oo) 1100 @checking user=> 1100 @savings user=> 1900 如果STM运行时检测到几个并发事务的修改发生冲突，那其中的一个或几个事务将进行重试。就像修改原子变量一样，事务需要保证没有副作用。重试事务秉着先做实验再讲理论的精神，我们先对transfer函数进行压力测试，看看是否能找到事务被重试的现象。尝试以下代码： Clojure/Transfer/src/transfer/core.clj (def attempts (atom o))(def:transfers (agent o)) (defntransfer[fromtoamount](dosync （swap！attemptsinc）//在事务内产生副作用——产品代码中永远不要这样写！！！ (send transfers inc)(alter from - amount)(alter to + amount))) 这段代码故意打破“禁止副作用”的规则，在事务中修改原子变量来产生副作用。我们是为了做事务重现的实验才这样做，永远不要在产品代码中这样写。除了在原子变量中维护了计数器，我们还在代理中维护了计数器，稍后会对这个做法进行解释。 90 第4章·Clojure之道一分离标识与状态下面这段代码用于对transfer函数进行压力测试： Clojure/Transfer/src/transfer/core.clj (def checking (ref 100oo))(def savings (ref 20000)) (defn stress-thread [from to iterations amount] (Thread.#(dotimes【_iterations](transferfromtoamount))))(defn-main[&args] (let [tl (stress-thread checking savings 10o 100) t2 (stress-thread savings checking 200 100)) (.start tl)(.startt2)(.join ti)(.join t2)) (awaittransfers) (printin"Attempts:"@attempts)(printin"Transfers:"@transfers) ( 这段代码创建了两个线程。一个线程从支票账户往储蓄账户进行100次转账，每次100美金；另一个线程从储蓄账户往支票账户进行200次转账，每次100美金。我运行时得到以下输出： Before: Checking = 10000 Savings =20000 Attempts: 638 Transfers:300 After: Checking = 20000 Savings = 10000 太好了，我们得到了预期的结果，STM运行时确保并发事务运行得到了正确的结果。其代价是进行了多次重试（本例中进行了338次重试），而好处是全程没有使用锁，不会有发生死锁的风险。当然，这并不是现实中的情况一一两个线程在频繁的循环中访问同一个引用，在此情况下会不断发生访问冲突。实际情况中，一个设计良好的系统的事务重试次数会少得多。事务的安全副作用你也许注意到尽管原子变量维护的计数不断增大，但代理维护的计数却与事务的数量相等。其原因是代理具有事务性。如果在事务中用send来更新一个代理，那send仅在事务成功时生效。如果需要在事务成功时产生一些副作用，那send将是最佳选择。小乔爱间函数名末尾的感叹号是什么意思？你也许注意到一些函数名末尾有个感叹号 4.3第二天：代理和软件事务内存一这种命名规则在表达什么？ 91 Clojure用一个感号表示一个函数不是事务安全的，比如swap！和reset！。由于更新代理的函数使用的是send而不是send!，所以可以安全地在事务中更新代理 Cloiure对共享可变状态的支持之前已经学习了Clojure支持共享可变状态的三种机制。每种机制都有各自的适用场景。原子变量可以对一个值进行同步更新一一同步的意思是更新在swap!返回时已经完成。对多个原子变量不能进行一致地更新。代理可以对一个值进行异步更新一一异步的意思是更新可能在send返回后进行。对多个代理不能一致更新。引用可以对多个值进行一致的、同步的更新。第二天总结我们完成了第二天的学习。第三天我们将学习一些使用可变类型的复杂例子，并学习不同可变类型的适用场景。第二天我们学到了什么除了原子变量，Clojure还提供了代理和引用。口原子变量可以对单一值进行隔离的、同步的更新。口代理可以对单一值进行隔离的、异步的更新。口引用可以对多个值进行一致的、同步的更新。第二天自习查找观看Rich Hickey的演讲“Persistent Data Structures and Managed References:Clojure's ApproachtoIdentityand State。观看RichHickey的演讲“Simple MadeEasy”。 92第4章_Clojure之道—分离标识与状态实践口改进4.2节的例子TournamentServer，用引用和事务来实现一个运行井字棋游戏的服务器。口用列表存储节点，实现一个持久化的查询二叉树。最坏情况下需要进行多少次复制？平均情况下呢？口学习fingertree，并用它实现查询二叉树。它对平均情况下和最坏情况下的性能有什么影响？ 4.4第三天：深入学习我们已经学习了“Clojure之道”涉及的所有组件。今天将学习一些运用这些组件的复杂例子，以及在面对某个并发问题时应当选择原子变量还是选择STM。用STM解决哲学家进餐问题作为开场，先来回顾一下第2章提到的“哲学家进餐问题”，并用Clojure的STM来解决这个问题。该解决方案非常类似于2.3节中介绍的使用条件变量的方案（然而STM方案会更简单）。我们使用一个引用来代表一个哲学家，引用的值是哲学家的当前状态（：thinking 或：eating）。这些引用保存在数组philosophers中 Clojure/DiningPhilosphersSTM/src/philosophers/core.clj (def philosophers (into[](repeatedly 5 #(ref :thinking)))) 每个哲学家都有一个对应的线程： Clojure/DiningPhilosphersSTM/src/philosophers/core.clj Linei(defn think (Thread/sleep(rand 10oo))) (defn eat [] (Thread/sleep (rand 1000))) 5 (defn philosopher-thread [n] (Thread #(let[philosopher(philosophersn) left (philosophers (mod (- n 1)5)) 10 right(philosophers (mod(+n1)5)) (while true(think) (when(claim-chopsticks philosopher leftright) 15 (eat) (release-chopsticks philosopher)))))) (defn-main [&args] (let[threads(map philosopher-thread(range5))] 20 (doseq [thread threads] (.start thread))(doseq [thread threads](.join thread)))) 4.4第三天：深入学习 93 与Java版本的方案类似，每个线程将无限循环下去（第12行），哲学家或者进行思考，或者尝试进餐。如果claim-chopsticks执行成功（第14行），控制结构when会先调用eat再调用 release-chopsticks release-chopsticks的实现非常简单： Clojure/DiningPhilosphersSTM/src/philosophers/core.clj(defn release-chopsticks [philosopher] (dosync (ref-set philosopher :thinking))) 这段代码仅简单地用dosync创建一个事务，并用ref-set将状态置为：thinking。首次尝试 claim-chopsticks函数非常值得讨论一先尝试一种实现方法： (defn claim-chopsticks Iphilosopher left right)(dosync (when (and (= @left :thinking) (= @right :thinking))(ref-set philosopher :eating)))) 类似于release-chopsticks，这段代码首先创建了二个事务。在这个事务中，检查左边和右边的哲学家的状态一一如果两边的状态都是：thinking，就使用ref-set将当前哲学家的状态置为eating。如果条件不满足，when语句将返回nil，即当哲学家无法获得两支筷子并开始进餐时，claim-chopsticks也将返回nil。尝试运行这段代码，第一感觉是一切运行正常。但偶尔也会发现两个相邻的哲学家在同时进餐，他们共用了一支筷子，显然这是个错误的状态。到底发生了什么？造成这个问题的原因是我们用@访问了left和right的值。Clojure的STM会保证两个事务不能对同一个引用进行不一致的修改，虽然这段代码并没有修改left或者right，但却读取了它们的值。其他事务是可以修改这些值的，这也就造成了相邻的哲学家同时进餐的错误状态。确保值不被修改要解决上面的问题，可以用ensure代替@来访问left和right： Clojure/DiningPhilosphersSTM/src/philosophers/core.clj (defn claim-chopsticks[philosopher left right](dosync (when (and (= (ensure left) :thinking) (= (ensure right) :thinking))(ref-set philosopher:eating)))) 94 第4章Clojure之道一分离标识与状态 ensure函数确保了其返回的某引用的值不会被其他事务修改。与之前基于线程与锁的解决方案相比较会发现，现在的方案不仅非常简洁，而且是无锁的，即没有死锁风险。现在的解决方案使用了多个引用和事务，下一节将介绍另一种解决方案，其只使用了一个原子变量。不用STM解决哲学家进餐问题面对哲学家进餐问题，除了基于STM的方案我们还有其他选择。之前的方案将每个哲学家都用一个引用来代表，并使用事务来确保对多个引用的更新是一致的。首先，将仅用一个原子变量来表示所有哲学家的状态： Clojure/DiningPhilosphersAtom/src/philosophers/core.clj (defphilosophers（atom(into[]（repeat5:thinking)))) 原子变量的值是一个状态数组。举例说明，哲学家0和哲学家3正在进餐时，其状态数组是：[:eating :thinking :thinking :eating :thinking] 然后，要用状态数组中的序号来代表哲学家，就要对philosopher-thread做一点小修改 Clojure/DiningPhilosphersAtom/src/philosophers/core.clj (defn philosopher-thread [philosopher](Thread. #(let [left (mod (- philosopher 1) 5) right(mod (+philosopher 1)5)) (while true(think) (when (claim-chopsticks! philosopher left right)(eat) (release-chopsticks!philosopher)))))) 之后，要实现release-chopsticks！，只需要用swap！将状态数组的相关元素置为：thinking： Clojure/DiningPhilosphersAtom/src/philosophers/core.clj(defn release-chopsticks![philosopher] (swap!philosophers assoc philosopher :thinking)) 这里用到了assoc，之前我们对map用过这个函数，其对数组的效果是类似的： user=> (assoc [ia ia ia ta] 2 :b)[:a :a :b ta] 最后，实现最关键的函数claim-chopsticks！： Clojure/DiningPhilosphersAtom/src/philosophers/core.clj(defn ciaim-chopsticks! [philosopher left right] (swap!philosophers 4.4第三天：深入学习 (fn[ps) (if（and(=（psleft):thinking)(=(ps right）:thinking)) (assocpsphilosopher:eating) ps))) (=（@philosophersphilosopher）:eating)) 95 传给swap！的匿名函数的参数是状态数组philosophers的当前值，该匿名函数对邻座哲学家的状态进行检查。如果邻座都在思考，就用assoc将当前哲学家的状态置为：eating，否则直接返回philosophers而不改变philosophers的值 claim-chopsticks！的最后一行代码检查了philosophers的新值，目的是判断swap!是否成功地将当前哲学家的状态置为：eating。我们已经学习了两种哲学家进餐问题的解决方案，一种使用STM，另一种则不使用。如何在两者之间进行选择呢？原子变量还是STM？第二天已介绍过，原子变量可以对单一值进行更新，而引用可以对多个值进行一致的更新。虽然两者功能不同，但如本章所述，我们能做出一个使用STM并涉及多个引用的解决方案，也能很容易将其转换成一个使用单一原子变量的方案。现在我们面临一个尴尬的局面一一当解决一个涉及多个值需一致更新的问题时，即可以使用多个引用并通过事务来保证访问一致性，也可以将这些值整合到一个数据结构中并用一个原子变量管理这个数据结构的访问一致性。应该如何选择呢？这个问题的答案很大程度上因人而异一一两种方案都正确，所以要选择那个最简便的。在性能上，根据使用场景的特点和数据访问模式的不同，肯定会有所差异，所以需要用压力测试进行性能评估之后再进行选择。虽然STM带有更多光芒，但有经验的Clojure程序员知道：由于语言的函数性减少了对可变量的使用，因此大部分问题都可以用原子变量来解决。更简单的方案通常会更有效。定制并发函数使用原子变量解决哲学家进餐问题的代码是可以正确运行的，但claim-chopsticks！的实 ①此处作者在swap！之后调用了@philosophers，设想如果在swap！之后、@philosophers之前，另一个线程修改了当前哲学家的状态，那么claim-chopsticks！的返回值将不正确。所以不推荐这样使用，而是应将状态设置和状态检查放在同一个原子操作中。不过，此处由于当前哲学家状态仅能由当前线程修改，所以这段代码是正确的一译者注 96 第4章Clojure之道一分离标识与状态现并不优雅。如果当前哲学家可以获得两边的筷子，那调用swap！之后的那次检查是否必要？理想状况下，仅需要一个类似于swap！的函数，其接受一个参数作为判断条件，仅当判断条件为真时进行swap!操作。可以将claim-chopsticks！写成这样： Clojure/DiningPhilosphersAtom2/src/philosophers/core.clj(defn claim-chopsticks![philosopher left right](swap-when!Philosophers #(and (=(%1 left):thinking)(=(%lright):thinking)) assocphilosopher:eating)) Clojure并没有提供我们理想中的函数，但我们可以自已写一个： Clojure/DiningPhilosphersAtom2/src/philosophers/util.clj Line1 (defn swap-when! "If (pred current-value-of-atom) is true, atomically swaps the value of the atom to become (apply f current-value-of-atom args).Note that both pred and f may be called multiple times and thus shouid be free of side effects.Returns the value that was swapped in if the predicate was true, nil otherwise." [a pred f &args](loopn (let [old @a] 10 15 (if(pred old) (let [new (apply f oldargs)] (if(compare-and-set!a old new) new (recur)）)) nit)))) 这段代码用到了一些先前没出现过的语言特性。第一个特性是文档字符串。文档字符串是位于defn和参数列表之间的字符串，用于描述函数的行为。文档字符串对任何函数都是有益的，尤其是对那些为了重用而设计的辅助函数。除了在源码中查看文档字符串，也可以从REPL中获取： philosophers.core=> (require "[philosophers.util :refer :aluj) nil philosophers.core=> (clojure.repl/doc swap-when!) philosophers.util/swap-when!([atom predf&args]) If (pred current-value-of-atom) is true, atomically swaps the value of the atom to become (apply f current-value-of-atom args).Note that both pred and f may be called muitiple times and thus should be free of side effects. Returns the value that was swapped in if the predicate was true, nil otherwise. 第二个特性是参数列表中的&符号，其说明了swap-when!的参数个数是可变的（非常类似于 Java中的省略号或Ruby中的星号）。通过名为args的数组可以访问附加的参数。这里还用到了 apply，其可以将最后一个参数展开，作为附加的参数传给f（第11行）一种调用+函数的方式是等价的：举例说明，下面这两 user=>(apply+12[345]) 15 user=>(+12345) 15 4.4第三天：深入学习 97 我们还使用较底层的compare-and-set！（第12行）来替换swap！compare-and-set！接受一个原子变量、原子变量的旧值和原子变量的新值一一仅当原子变量的当前值等于旧值时，原子变量的值会被更新为新值，整个比较和更新的过程都是原子的当compare-and-set！成功时，swap-when！返回原子变量的新值。否则，使用recur（第14 行）回到第8行重新运行。 1小乔爱间：什么是Loop/Recur? 与许多函数式语言不同，Clojure不具备尾调用消除（tail-callelimination）的能力，因此 Clojure代码不常使用递归，而是用loop/recur。 Loop宏定义了一个锚点，recur可以跳到这个锚点（类似于C/C++中的setjmp()和 longjmp（））。Clojure语言手册中详述了其工作原理。第三天总结我们完成了第三天的学习，讨论了Clojure如何将函数式编程与可变量混搭使用。第三天我们学到了什么 Clojure的函数式性质极大地减少了可变量的使用。通常情况下，基于原子变量的简单并发方案“就足够了：口基于STM的解决方案（通过事务来达成多个值的一致性）可以被基于代理的解决方案（将多个值整合到一个数据结构中，并用一个代理来管理对这个数据结构的访问）替换；口在两种方案之间的选择往往基于个人风格和程序性能；口定制并发函数可以让代码更简洁。第三天自习查找 ①可以认为基于原子变量的方案是基于代理的方案的子集。——译者注第4章Clojure之道一分离标识与状态 98 口观看RichHickey的演讲“TheDatabaseasaValue”，注意Datomic是如何有效地将整个数据库视为一个单一值的。实践口改进第二天的实践部分的TournamentServer，用原子变量代替引用和事务。哪一种方案更简单？哪一份代码更易读？哪一种方案性能更好？ 4.5复习 Clojure在解决并发问题上非常务实。起先我们意识到并发编程中最大的障碍来自于共享可变状态，于是Clojure作为一门函数式语言挺身而出，编写出具有引用透明性且无副作用的代码。之后我们又意识到一些问题场景需要对某些可变状态进行维护，因此Clojure又提供了很多并发安全的可变数据类型。优点很显然，本章“Clojure之道”的优点建立在上一章介绍的函数式编程的基础上。我们可以用 Clojure“函数式地”解决函数式的问题，也可以在必要的时候突破函数式的禁。传统命令式语言的变量混淆了标识与状态这两个概念，而Clojure的持久数据结构将可变量的标识与状态分离开来。这解决了使用锁的方案的大部分缺点。专家级Clojure程序员知道解决并发问题的最佳选择是那个“刚刚够用”的方案。缺点 “Clojure之道”的主要缺点在于不支持分布式（地理分布或其他）编程。与之相关，它也无法直接提供容错性。由于Clojure在JVM中运行，很多第三方库可以为Clojure弥补这些缺点（Akka就是其中之一，它使用了下一章将要介绍的actor模型），不过对这些第三方库的介绍超出了本书的范围。其他语言 Haskell提供了类似本章介绍的功能，不过作为一种纯粹的函数式语言，使用起来会有一种不同的“体验”。值得一提的是Haskell提供了完整的STM实现，SimonPeytonJones的文章“Beautiful ①http://www.datomic.com ②http://blog.darevay.com/2011/06/elojure-and-akka-a-match-made-in Concurrency”①对其进行了详细的解说。 4.5复习 99 另外，大部分主流编程语言都提供了STM的实现，包括GCC支持的编程语言②。尽管如此有证据表明：STM模型并不适合于命令式语言?。结语 Clojure在函数式编程和可变状态之间取得了很好的平衡，比起纯粹的函数式语言，这些命令式语言的特性会让程序员感觉更亲切、更容易上手。与此同时Cloiure保留了函数式编程的大部分优点，包括对并发的完美支持。概括而言，Clojure精心设计了用于并发的语义，从而保留了共享可变状态。下一章我们将学习actor模型，它完全抛弃了共享可变状态。 ①http://research.microsoft.com/pubs/74063/beautiful.pdf ②http://gcc.gnu.org/wiki/TransactionalMemory ③http://www.infoq.com/news/2010/05/STM-Dropped 第5章 Actor 使用actor就像租车一一我们如果需要，可以快速便捷地租到一辆；如果车辆发生故障，也不需要自己修理，直接打电话给租车公司更换另外一辆即可。 actor模型是一种适用性非常好的通用并发编程模型。它可以应用于共享内存架构和分布式内存架构，适合解决地理分布型的问题。同时它还能提供很好的容错性。 5.1更加面向对象函数式编程不使用可变状态，也就避免了共享可变状态带来的问题。相比之下，使用actor 模型保留了可变状态，只是不进行共享。 actor类似于面向对象（OO）编程中的对象一一其封装了状态，并通过消息与其他actor通信。两者的区别是所有actor可以同时运行，而且，与OO式的“消息传递”（实质上只是调用一个方法）不同，actor之间的消息传递是真实地在传递消息。 actor模型是一个通用的并发编程模型，几乎可以用在任何一种编程语言里，最典型的是 Erlang。而我们将用Elixir²来介绍actor模型，它是Erlang虚拟机（BEAM）上相对较新的一门编程语言。与Clojure类似，Elixir是一门不纯粹的、动态类型的函数式语言。如果你熟悉Java或者Ruby，很容易就能看懂Elixir代码。与以往一样，我们不会把本章写成Elixir的教程（本书的主旨是并发，而不是编程语言），但仍将介绍一些必要的语言特性。如果你对这门语言并不熟悉，那就不得不在某些地方“盲目”接受本书的说法一一如果想深人学习Elixir，推荐阅读ProgrammingElixir[Thol4]。第一天，我们将学习actor模型的基础一一如何创建actor、发送消息和接收消息。第二天，学习使用actor模型的程序具有容错性的关键：失败检测和“任其崩溃”的哲学。第三天，学习如何 @http://www.erlang.org/ ②http://elixir-lang.org/ 5.2第一天：消息和信箱 101 通过actor模型编写分布式程序，将计算扩展到多台计算机，并能从一台或多台计算机的崩溃中恢复过来。 5.2第一天：消息和信箱现在我们来学习如何创建和停止进程、如何发送和接收消息，以及如何检测进程已终止。 1V/小乔爱间：是actor还是进程？类似于Erlang，在Elixir中，actor对象被称为进程。大部分场景下，进程是一个重量级的概念，它会消耗很多资源，且创建代价很高。不过在Elixir中，进程是一个轻量级的概念，比操作系统级的线程还要轻量：它消耗更少的资源，且创建代价很低。Elixir程序可以毫无困难地创建数千个进程，通常不需要依赖线程池（参见2.4节）等技术。第一个actor 先来尝试创建一个简单的actor，并向其发送一些消息。我们将创建一个叫Talker的actor，其收到不同的消息时会输出不同的结果。所发送的消息是一个元组（tuple）一一元组是一个由多个值组成的序列。在Elixir中，用花括号（0）表示元组，举例如下： (:foo,"this"，42] 这是个三元组，第一个元素是一个关键字（与Clojure类似，也是用冒号表示关键字），第二个元素是一个字符串，第三个元素是一个整数。来看看actor的代码： Actors/hello actors/hello_actors.exs defmodule Talker do defloopdo receive do (:greet,name}->Io.puts("Hello#(name}") (:praise,.name}->Io.puts("#(name},you're amazing") (:celebrate, name, age) ->Io.puts("Here's to another #[age} years,#(name}") end loop end end 102 第5章Actor 我们稍后会对这段代码进行深人分析。现在只需要知道这段代码定义了一个actor，其接受三种不同的消息，并打印不同的字符串。下面创建这个actor的实例，并向其发送一些消息： Actors/hello_actors/hello_actors.exs pid=spawn(&Talker.loop/o) send(pid,(:greet,"Huey"}) send(pid,{:praise,"Dewey"}) send(pid，(:celebrate，"Louie",16}) sleep(1000) 首先，这段代码用spawn创建了actor的实例，并获得进程标识符，这个进程标识符被保存在 pid中。进程将执行spawn的参数所指定的函数，本例中的函数是Talker模块中的loop（），该函数接受0个参数。然后，这段代码向刚创建的actor实例发送了三个消息。最后，sleep一下，让各个进程有时间处理消息（用sleep（）并不是最佳选择一一稍后将介绍如何改进)。以下是这段代码的运行结果： Hello Huey Dewey, you"re amazing Here's to another 16 years, Louie 我们已经学习了如何创建actor并向其发送消息，现在需要剖析一下其中的机制。队列式信箱异步地发送消息是用actor模型编程的重要特性之一。消息并不是直接发送到一个actor，而是发送到一个信箱（mailbox），如图5-1所示。信箱 Celebrate: Louie,16 HelloActors Praise: Dewey Greet: Huey 图5-1向信箱发送消息这样的设计解耦了actor之间的关系 Talker actor都以自己的步调运行，且发送消息时不会被阻塞虽然所有actor可以同时运行，但它们都按照信箱接收消息的顺序来依次处理消息，且仅在当 5.2第一天：消息和信箱 103 前消息处理完成后才会处理下一个消息，因此我们只需要关心发送消息时的并发问题即可。接收消息通常actor会进行无限循环，通过receive等待接收消息，并进行消息处理。现在来看一下 Talker的循环代码： Actors/hello_actors/hello_actors.exs defLoopdo receivedo :greet, name} -> I0.puts("Hello #[name}") f:praise,name} -> Io.puts("#(name},you're amazing") f:celebrate, name, age} -> Io.puts("Here's to another #age} years, #(name]") end toop end 该函数通过递归调用自已来进行无限循环，用receive块来等待一个消息，通过匹配模式来决定如何处理消息。这段代码依次用每个模式对接收到的消息进行匹配一一旦匹配成功，在箭头（->）右边的代码中，就可以通过模式中的变量（name和age）来访问消息中的对应值。处理消息的代码使用字符串插值技术来构造字符串并输出一字符串插值技术指的是#{.·}中的代码将被求值并将求值结果插入到字符串的对应位置。 “第一个actor”部分的最后一段代码在退出前sleep了1秒，这样才有足够的时间处理消息。这个解决方案不过是差强人意一一我们可以做得更好。小乔爱间：不断递归难道不会栈溢出吗？你也许已经注意到了Talker的Loop（）函数不断地进行递归，就会担心堆栈会不断被消耗。幸运的是我们并不需要担心与许多函数式语言一样（不过Clojure是个特例，参见4.4节的“小乔爱问”），Elixi实现了尾调用消除。尾调用消除指的是如果函数在最后调用了自己，那么递归调用将被替换成一个简单的跳转。连接到（linking）进程为了彻底关闭一个actor，需要满足两个条件。第一个是需要告诉actor在完成消息处理后就关闭；第二个是需要知道actor何时完成关闭。首先，通过接收一个显式的关闭消息（类似于2.4节中介绍的毒丸）来满足第一个条件： 104 第5章Actor Actors/hello_actors/hello_actors2.exs defmodule Talker do def loop do receive do (:greet，name)->Io.puts("Hello#(name)") :praise，name)->Io.puts("#(name),youreamazing") (:celebrate,name,age}->Io.puts("Here's to another #[age} years,#[name)")(:shutdown) -> exit(:normal) end loop end end 然后，需要一个方法来获知actor是否完全关闭。下述代码将：trapexit设为true，并用 spawnlink（）替换spawn（)以连接到进程： Actors/hello_actors/hello_actors2.exs Process.flag(:trap exit, true) pid = spawn_link(&Talker.loop/0) 现在当创建的进程关闭时，就会得到一个通知（是一个系统产生的消息）。这个消息是一个三元组： {:EXIT,pid,reason) 最后，发送关闭消息并收到关闭通知： Actors/hello_actors/hello_actors2.exs send(pid,{:greet,"Huey"}) send(pid,:praise,"Dewey"}) send(pid，:celebrate,"Louie"，16)) send(pid, (ishutdown)) >receive do f:ExIT,pid,reason)->Io.puts("Talker has exited(#(reasonj)") end receive模式中使用^符号（脱字符）的第二个元素，将不会绑定到消息的第二个数据，而是用pid的当前值进行模式匹配。运行这个新版本代码，输出如下： Hello Huey Dewey,you're amazing Here's to another 16 years, Louie Talker has exited (normal) 我们将在第二天深人讨论连接技术。有状态的actor 5.2第一天：消息和信箱 105 之前的Talker是没有状态的actor。创建一个有状态的actor时，很容易想到使用可变量，但实际上可以使用递归。举例说明，下面这个actor每收到一个消息时都会将计数器加1： Actors/counter/counter.ex defmodule Counter do def loop(count)do receive do[next}-> Io.puts("Current count: #(count)") end end end loop(count+1) 在交互式Elixir环境iex（Elixir版的REPL）中运行这段代码： iex(1)>counter=spawn(Counter,:loop,[1])#PID<0.47.0> iex(2)> send(counter, :next)) Current count:1(:next) iex(3)> send(counter,{:next))[:next) Current count: 2 iex(4)> send(counter,(:next))(:next) Current count: 3 这段代码使用了接受三个参数的spawn（）：第一个是模块名，第二个是模块中的函数名，第三个是参数列表。用这个版本的spawn(）可以将初始的count传给Counter.loop(）。不出所料，每发送一个{：next}消息，这个actor就会输出一个不同的计数一一有状态的actor并没有使用可变量。由于这个actor是串行处理消息的，因此actor可以安全地访问其状态，而不会引发并发问题。用API隐藏消息细节 Counter已经可以使用了，但并不方便。我们需要记住传给spawn（）的参数是什么以及消息的细节（是（：next}、：next还是{：increment}？）。为了避免这些麻烦，可以将spawn（）的调用和消息的细节全部隐藏到一组API函数中： Actors/counter/counter.ex defmodule Counter do def start(count) do spawn(MoDULE,:loop,[count]) end def next(counter) do send(counter,(:next}) 106 end 第5章Actor def loop(count) do receive do[:next]-> Io.puts("Current count: #[count)") loop(count + 1) end end end start（的实现用到了伪变量MODULE，其值是当前模块的名字。这样的API让actor的使用变得更简洁并且不易出错： iex(i)>counter=Counter.start(42)#PID<0.44.0> iex(2)> Counter.next(counter) Current count: 42:next) iex(3)> Counter.next(counter):next) Current count: 43 仅输出状态的actor没有什么实用性。下面来看看如何让两个actor进行双向通信，让一个actor 可以获取另一个actor的状态。双向通信之前提到过，actor是异步发送消息的一一发送者并不会被阻塞。那我们怎么获得一个消息的回复呢？比如在之前的Counter中，如果不输出actor的当前计数，而是将当前计数返回给发送者会怎样呢？ actor模型没有提供直接回复消息的机制，但我们可以自行解决：将发送进程的标识符包含在消息中。通过这个机制，消息的接收者可以回复消息： Actors/counter/counter2.ex defmodule Counter do def start(count) do spawn(MoDULE:loop,[count]) end def next(counter) do ref = make_ref() send(counter, {:next, self(), ref)) receive do l:ok,^ref,count} -> count end end def loop(count) do receive do [:next, sender, ref) -> end end end send(sender, {:ok, ref,count}) loop(count+1) 5.2第一天：消息和信箱 107 这个版本不再输出当前计数，而是将当前计数返回给发送者，返回的消息类似于下面的三元组： :ok,ref,count ref是发送者用makeref（)生成的唯一引用。来验证一下： iex(1)>counter=Counter,start(42)#PID<0.47.0> iex(2)> Counter.next(counter) 42 iex(3)> Counter.next(counter) 43 现在可以为Counter的进程命名，这样就可以通过名称查找到对应的进程。 1/小乔爱问：为什么回复的是一个元组？在我们改造的Counter中可以不回复一个元组，而只回复计数即可：:next, sendery -> send(sender,count) 这是正确的，但Elixir习惯用元组作为消息，且第一个元素表示消息处理是成功的还是失败的。本例中的消息还带有发送者生成的唯一引用，这样如果多个消息到达信箱中，actor 就可以通过这个唯一引用来区分这些消息。为进程命名将一个消息发送给某个进程时，需要知道进程的标识符。如果是我们自已创建的进程，那不会有什么问题。但如果要向一个别人创建的进程发送消息呢？这个问题可以用多种方法解决，最简单的方法就是为进程命名： iex(1)> pid = Counter.start(42)#PID<0.47.0> iex(2)>Process.register(pid，:counter) true 108 Actor 第5章 iex(3)> counter = Process.whereis(:counter)#PID<0.47.0> iex(4)> Counter.next(counter) 42 上面的代码用Process.register（)为进程命名，并用Process，whereis（）按名称查找进程。通过Process.registered（）可以查看已被命名的所有进程： iex(5)>Process.registered [:kernel_sup,:init,:code_server,:user,:standard_error_sup, :global name_server,:application_controller,:file_server_2,:user_drv:kernel safe_sup,:standard_error,:global_group, :error_logger, :elixircounter,:counter,:elixir_code_server,:erl_primloader,:elixir_sup,:rex, :inet db] 可以看到虚拟机在启动时已经命名了很多基本进程。之前使用send()函数时，其参数是进程变量，现在也可以使用进程名称： iex(6)> send(:counter,(:next,self(),make_ref())[:next,#PID<0.45.0>,#Reference<0.0.0.107>] iex(7)> receive do msg ->msg end[:ok, #Reference<0.0.0.107>, 43] 继续简化Counter的API，使其不再使用进程变量作为参数： Actors/counter/counter3.ex def start(count) do pid=spawn(MODULE ,:loop,[count]) Process.register(pid,:counter) pid end def next do ref = make_ref() send(:counter,:next,self(),ref)) receive do {:ok,^ref,count->count end end 来验证一下： iex(1)>Counter.start(42)#PID<0.47.0> iex(2)> Counter.next 42 iex(3)> Counter.next 43 今天的学习接近尾声。先进行一个茶歇，茶歇后我们将应用所学的知识来构造一个并行map 函数，类似于Clojure的pmap。茶歇一一函数是第一类对象 5.2第一天：消息和信箱与所有函数式语言一样，Elixir中的函数是第一类对象一 109 一函数可以被绑定到变量上，可以作为函数参数，与数据没什么区别。举例说明，用iex展示一下如何将匿名函数作为参数传给 Enum.map，使数组中每个元素增倍： iex(1)>Enum.map([1,2,3,4],fn(x)->x *2end)[2,4,6,8] 类似于Clojure的#（．．．)宏，Elixir也提供了定义匿名函数的快捷方式&（..．）： iex(2)>Enum.map([1,2,3,4],&(&1*2))[2，4,6,8] iex(3)>Enum.reduce([1,2,3,4],o,&(&1+&2)) 10 如果函数被绑定到了二个变量上，可以用.操作符来调用该变量代表的函数： iex(4)> double = &(& * 2) #Function iex(5)> double.(3) 6 再来看一个返回函数的函数： iex(6)> twice = fn(fun) -> fn(x) -> fun.(fun.(x)) end end#Function iex(7)> twice.(double).(3) 12 现在已经准备好了创建并行map（)的所有工具，只剩下组装了。并行map函数之前已经用过了Elixir提供的map()函数，它可以对一个集合施加映射操作，不过是串行执行的。下面我们将其改造成能并行处理集合的每个元素： Actors/parallel/parallel.ex defmodule Parallel do def map(collection,fun) do parent = self() processes=Enum.map(collection,fn(e) spawn_link(fn()-) send(parent,{self(),fun.(e)) end) end) Enum.map(processes,fn(pid)-> receive do 110 end end 第5章 Actor {"pid, result} -> result end end) 这段代码分为两个阶段。第一阶段，为集合的每个元素创建一个进程（如果集合有1000个元素，将创建1000个进程）。每个进程对相应元素施加fun函数，并向发送消息的父进程回复施加函数的结果。第二阶段，父进程等待所有子进程的结果。来验证一下： iex(1)> slow_double = fn(x)-> :timer.sleep(1ooo); x *2 end#Function<6.80484245in :erl_eval.expr/5> iex(2)>:timer,tc(fn()->Enum.map([1,2,3,4],slow_double) end){4003414,[2,4,6,8]] iex(3)>:timer.tc(fn()->Parallel.map([l,2,3,4],slow_double)end){1001131,[2,4,6,8]] 这段代码用到了：timer.tc（)函数，其对参数函数的运行时间进行统计，并返回一个二元组，第一个元素是运行时间，第二个元素是参数函数的返回值。可以看到串行版本运行了4秒，而并行版本运行了1秒。第一天总结第一天的学习结束了。第二天我们将学习actor模型的错误处理和容错性。第一天我们学到了什么多个actor（进程）可以同时运行、不共享状态、通过向信箱异步地发送消息来进行通信。本章中我们学习如何实现下列任务：口用spawn（）创建新进程；口用send（向进程发送消息：口通过模式匹配来处理消息；口连接两个进程，当一个进程结束时，另一个进程将接收到通知；口在异步通信的基础上，实现双向的同步通信；口为进程命名。第一天自习查找口阅读Elixir的函数库文档。口观看ErikMeijer、ClemensSzyperski和CarlHewitt在Lang.NEXT2012上关于actor模型的对话视频。实践 5.3第二天：错误处理和容错性 111 口测量在Erlang虚拟机上创建一个进程的成本，且与在JVM上创建一个线程的成本进行比较。口测量之前的并行map函数的成本，且与串行map函数的成本进行比较。何时应使用并行map 函数，何时应使用串行map函数？口参考之前的并行map函数，写一个并行reduce函数。 5.3第二天：错误处理和容错性在1.3节已提到过：并发很重要的一个特性是并发代码具有容错性。今天就来学习actor模型提供的容错性。不过首先要利用昨天的知识创建一个较复杂的贴近现实的例子，之后的讨论将在此基础上进行。一个缓存actor 本节将创建一个网页缓存：向缓存添加页面时，需提供URL以及页面文本；向缓存请求页面时，需提供URL；也可以查看缓存一共包含了多少个字节。我们需要一个字典，这个字典包含了URL到页面的映射。与Clojure的map类似，Elixir的字典是一个关联型的持久数据结构 iex(1)> d = HashDict.new#HashDict<[]> iex(2)> di = Dict.put(d, :a,"A value for a")#HashDict<[a: "A value for a"]> iex(3)> d2 = Dict.put(di,:b,"A value for b") #HashDict<[a: "A value for a",b:"A value for b"]> iex(4)> d2[:a]"A value for a" 使用HashDict.new可以创建新的字典，使用Dict.put（dict，key，value）可以向其中添加元素，使用dict［key]可以从其中查找元素。利用字典可以实现缓存： Actors/cache/cache.ex Line1 defmodule Cache do def loop(pages,size)do receive do (:put, url, page} - 5 new_pages = Dict.put(pages,url,page) new_size = size+byte_size(page) loop(new_pages,new_size) 112 10 15 第5章 Actor [:get, sender, ref, url} -> send(sender,【:okref,pages[uruj) loop(pages,size) :size,sender,ref) > send(sender,(:ok,ref,size)) loop(pages, size) ：terminate}->#终止信号终止递归 end end end 这个缓存维护了两个状态：pages和size。pages是将URL映射到页面的字典；size是当前缓存的所有字节数（在第6行由byte_size（)更新）。与之前一样，我们仍用API来隐藏创建进程和发送消息的细节。下面的代码用于创建 startlink()函数： Actors/cache/cache.ex def start_link do pid=spawn Link(MODULE :loop,[HashDict.new,o]] Process.register(pid,:cache) pid end 这段代码用空字典和o作为loop)的初始值，并将进程命名为：cache。下面的代码用于创建 put（）、get（)、size)和terminate()函数： Actors/cache/cache.ex def put(url,page)do send(:cache, (:put, url, page)) end def get(url) do ref = make_ref() send(:cache,(:get,self),ref,uruy) receive do (:ok, ^ref, page) -> page end end def size do ref = make_ref() send(:cache, {:size, self(), ref}) receive do (:ok, ^ref, s) -> s end end def terminate do send(:cache,{:terminate)) end 5.3第二天：错误处理和容错性 113 put（）和terminate（）函数只是简单地将参数包装在元组中，并将元组作为消息发送。而get（）和size（）函数比较复杂，因为它们需要等待一个消息的回复。本例中，这两个函数都在消息中带有唯一引用，正如我们昨天学过的那样。来运行一下这个actor： iex(1)> Cache.start_link#PID<0.47.0> iex(2)> Cache.put("google.com","Welcome to Google ...") f:put,"google.com"，"welcome toGoogle.,"} iex(3)>Cache.get("google,com") "Welcome to Google .. iex(4)> Cache.size() 21 一切顺利一一现在已经可以向缓存中添加数据、取出数据，还能查看缓存的大小。如果使用一些非法参数呢？比如使用ni作为页面： iex(5)> Cache.put("paulbutcher.com", niu) {:put，"paulbutcher.com"，niu} iex(6)> =ERR0R REP0RT====22-Aug-2013::16:18:41= Error in process with exit value: [badarg,[ferlang,byte_size,[nil],[]} ...**（EXITfrom#PID）{:badarg,[(:erlang,:byte_size,[niu],[]},.. 不出所料，因为没有检查参数，所以这次运行失败了。在大多数语言中，唯一的处理方法是添加一些检查参数的代码，当检查到非法参数时报错。Elixir提供了另一种方法一一将错误处理隔离到一个管理进程中。这个方法看似简单，却是一个很大的改进，使代码更简洁、更具维护性，也更可靠。在学习如何写管理进程之前，必须详细了解进程之间的连接。错误检测在5.2节中，我们用spawnlink（)建立两个进程之间的连接，这样就可以检测到某一个进程的终止。连接是Elixir编程中最重要的概念之一- 进程的异常终止通过连接进行传播现在就来深人了解。任何时候都可以用Process.ink()在两个进程之间建立连接。下面定义一个简单的actor，用来讨论连接的原理： Actors/links/links.ex defmodule LinkTest do defloopdo receivedo 0 13 2 4 6 3 6 114 第5章Actor (:exit_because，reason)->exit(reason):link_to,pid)->Process.link(pid) [:ExIT,pid,reason)->Io.puts("#inspect(pid)} exitedbecause#(reason)") end loop end end 现在创建这个actor的两个实例，将这两个进程连接起来，并让其中一个异常终止： iex(1)>pidi = spawn(&LinkTest.loop/0)#PID<0.47.0> iex(2)> pid2 = spawn(&LinkTest.loop/0)#PID<0.49.0> iex(3)> send(pidl,{:link_to,pid2})[:1inkto,#PID<0.49.0>] iex(4)>send(pid2,{:exit_because,:bad_thing_happened))(:exit_because,:bad_thing_happened) 这段代码首先创建了actor的两个实例，将其进程标识分别绑定到pid1和pid2。然后创建从 pid1到pid2的连接。最后让pid2的进程异常终止。 pidl本应打印pid2异常终止的原因，但我们注意到pid1并没有输出，原因是没有设置：trap_exit。另外，如果用Process，info（)查看两个进程的状态，会看到以下现象： iex(5)> Process.info(pid2, istatus) nil iex(6)>Process.info(pidl,:status) nil 这样一来不只是pid2终止，而是两个进程都终止了。我们先来做另一个试验，再来学习如何修复这个问题。连接是双向的如果重复上面的试验，让pid1终止，就会看到同样的结果 iex(1)pidl=spawn(&LinkTest.loop/o)#PID<0.47.0> iex(2)>pid2 = spawn(&LinkTest.loop/0)#PID<0.49.0> iex(3)>send(pid1,(:link_to,pid2)):link_to,#PID<0.49.0>} 一两个进程都终止了： iex(4)>send(pidl，(:exit_because，:another_bad_thing_happened)) fexit_because,:another_bad_thing_happened) iex(5)>Process.info(pidl, :status) nit iex(6)>Process.info(pid2, :status) ni 可见连接是双向的。建立了从pid1到pid2的连接的同时，也就建立了从pid2到pid1的连接一一所以如果其中一个进程终止，那么两个进程就都终止了。正常终止 5.3第二天：错误处理和容错性 115 如果尝试让已经连接的一个进程正常终止（用：normal这个理由退出进程），会观察到以下现象： iex(i)>pid1=spawn(&LinkTest.loop/o)#PID<0.47.0> iex(2)>pid2 = spawn(&LinkTest.loop/0)#PID<0.49.0> iex(3)>send(pidl,(:link_to,pid2))[:link_to，#PID<0.49.0>] iex(4)>send(pid2,{:exit_because,:normal))[:exit_because,:normal] iex(5)> Process.info(pid2,:status) nil iex(6)> Process.info(pidl, :status):status,:waiting) 可见进程正常终止是不会让连接的另一个进程终止的。系统进程通过设置进程的：trap_exit标识，可以让一个进程捕获另一个进程的终止消息。用专业术语来说，这是将进程转化为系统进程： Actors/links/links.ex defloop_systemdo Process.flag(:trap_exit, true) loop end 来测试一下： iex(1)>pid1= spawn(&LinkTest.loop_system/0)#PID<0.47.0> iex(2)>pid2= spawn(&LinkTest.loop/0)#PID<0.49.0> iex(3)>send(pidl,{:link_to,pid2})(:link_to，#PID<0.49.0>] iex(4)>send(pid2,(:exit_because,=yet_another_bad_thing_happenedy)(:exit because, :yet another bad thing happened) aaeaoeaoaaao iex(5)>Process.info(pid2,:status) nil iex(6)>Process.info(pidl,istatus) f:status,:waiting) 现在，可以用loop_system启动pidl。当pid2终止时，pid1会得到消息（并打印退出的消息），并且会继续运行。 116 第5章·Actor 管理进程我们已经准备好实现一个进程管理者（也就是一个系统进程），它管理着若干个工作进程，当工作进程崩溃时进行干预。下面的代码为前述的缓存actor创建一个管理者，当缓存进程崩溃时，管理者会将其重启： Actors/cache/cache.ex defmodule CacheSupervisor do def start do spawn(MoDULE，：loop_system，[J） end defloop do pid = Cache.start_link receive do (:ExIT,pid，:normal)-> Io.puts("Cacheexited normally"):ok [:EXIT,pid,reason}-> Io.puts("Cache failed with reason #(inspect reason) -restarting it") loop end end defloop_systemdo Process.flag(:trap_exit, true) loop end end 这个actor将自已转化为系统进程，并进人loop（）。loop（）创建了Cache.loop（）进程，并一直阻塞，直到所创建的进程终止。该进程若是正常终止，则管理者也正常终止（返回：ok），否则 loop()进行递归并重新创建缓存进程。现在不必直接启动Cache实例，而是启动CacheSupervisor，其将负责创建Cache实例： iex(1)> Cachesupervisor.start#PID<0.47.0> iex(2)>Cache.put("google.com"，"WelcometoGoogle...")(:put，"google.com"，"WelcometoGoogle..."} iex(3)> Cache.size 21 如果缓存崩溃，就会被自动重启： iex(4)>Cache.put("paulbutcher.com",nil)(:put,"paulbutcher.com",nil) Cache failed with reason {:badarg,[:erlang, :byte_size,[nil],[]], iex(5)> =ERROR REPORT==== 22-AUg-2013::17:49:24 =3 Error in process with exit value: [badarg,[ferlang,byte_size,[nil],[]f, iex(5)> Cache.size 0 5.3第二天：错误处理和容错性 iex(6)>Cache.put("google.com","WelcometoGoogle.") f:put,"google.com"，"welcometoGoogle..."y iex(7)>Cache.get("google.com")"Welcometo Google. 117 虽然缓存崩溃时我们会丢失之前的数据，但至少得到了一个崩溃后可以继续使用的缓存。超时将缓存自动重启是个不错的方法，但并不是万能药。如果两个进程同时向缓存发送消息，下面这些事件会依次发生： (1)）进程1向缓存发送：put消息；(2）进程2向缓存发送：get消息； (3)缓存在处理进程1的消息时崩溃了； (4)管理者将缓存重启，但进程2的消息丢失了； (5）进程2在receive处陷入死锁，一直在等待消息的回复，但这个回复永远不会发送。我们可以用after语句来为receive增加超时机制，这需要修改一下get（）（size（）函数也需要同样的修改）： Actors/cache/cache2.ex def get(url) do ref = make_ref() send(:cache, (:get, self(), ref, url) receive do [:ok,ref,page} ->page after 1000 -> nit end end 小乔爱问消息是否保证能被送达？造成上面现象的主要原因是缓存重启时消息丢失了这就牵扯到一个很重要的问题 Elixir是否能确保消息一定能被送达并被处理？ Elixir有两个规则：口如果没有异常发生，消息一定能被送达并被处理口如果某个环节出现异常，异常一定会通知到使用者（假设使用者已经连接到或正在管理发生异常的进程）第二条规则是Elixir提供容错性的基石。 5 118 第5章Actor 错误处理内核（error-Kernel）模式 TonyHoare有一句名言。软件设计有两种方式：一种方式是，使软件过于简单，明显地没有缺陷；另一种方式是，使软件过于复杂，没有明显的缺陷。 actor提供了一种容错的方式：错误处理内核模式，在两者之间找到了平衡。一个软件系统如果应用了错误处理内核模式，那么该系统正确运行的前提是其错误处理内核必须正确运行。成熟的程序通常使用尽可能小而简单的错误处理内核一一小而简单到明显地没有缺陷。对于一个使用actor模型的程序，其错误处理内核是顶层的管理者，管理着子进程一一对子进程进行启动、停止、重启等操作。程序的每个模块都有自已的错误处理内核一一模块正确运行的前提是其错误处理内核必须正确运行。子模块也会有自已的错误处理内核，以此类推。这就构成了错误处理内核的层级树，较危险的操作都会被下放给底层的actor执行，如图5-2所示。管理者工作进程风险递增图5-2错误处理的层级树错误处理内核模式主要解决了防御式编程中碰到的一些棘手问题。任其崩溃防御式编程主要通过预言可能出现的缺陷来实现容错性。举例说明，假设有一个函数，其接 ①http://zoo.cs.yale.edu/classes/cs422/2011/bib/hoare81emperor.pdf 5.3第二天：错误处理和容错性受一个字符串，当字符串全是大写时返回true，否则返回false。先草拟一个版本： defall_upper?(s)do String.upcase(s) == s end 119 看上去不错，但如果传入ni作为参数，这段代码将崩溃。为了解决这个问题，有些程序员就对其进行了如下修改： defmoduleUpperdo defall_upper?(s)do oppuon nil?(s)->false true->string.upcase(s)== s end end end 现在再碰到ni1作为参数时，代码就不会崩溃了，但如果传人另一些不按套路出牌的参数呢发一个缺陷一一只是我们暂时隐藏了这个缺陷，之后也很难意识到其存在，但总有一天它会跳起来咬我们一口。使用actor模型的程序并不进行防御式编程，而是遵循“任其崩溃”的哲学，让actor的管理者来处理这些问题。这样做有几个好处，比如：口代码会变得更加简洁且容易理解，可以清晰区分出“一帆风顺”的代码和容错代码；口多个actor之间是相互独立的，并不共享状态，因此一个actor的崩溃不太会殃及到其他 actor。尤其重要的是一个actor的崩溃不会影响到其管理者，这样管理者才能正确处理此次崩溃；口管理者也可以选择不处理崩溃，而是记录崩溃的原因，这样我们就会得到崩溃通知并进行后续处理。虽然第一眼看上去“任其崩溃”的哲学有点奇怪，但它和错误处理内核模式都在产品环境上反复进行过验证。一些系统的可用性据说提高到了99.9999999%（9个9，参见ProgrammingErlang SoftwareforaConcurrentWorld[Arml3j 第二天总结我们第一天学习了actor模型的基础知识，第二天学习了actor模型如何进行容错。第三天将学习如何用actor模型进行分布式编程。 ①该书中文版《Erlang程序设计（第2版）》已由人民邮电出版社出版：http://www.ituring.com.cn/book/1264。编者注 120 第5章Actor 第二天我们学到了什么 Elixir通过创建管理者并使用进程的连接来进行容错：口连接是双向的一如果进程a连接到进程b，那么进程b也连接到进程a；口连接可以传递错误一一如果两个进程已经连接，其中一个进程异常终止，那么另一个进程也会异常终止；口如果进程被转化成系统进程，当其连接的进程异常终止时，系统进程不会终止，而是会收到：EXIT消息。第二天自习查找口阅读Process，monitor（)的相关文档一一管理一个进程与连接一个进程有什么区别？何时使用管理，何时使用连接？口Elixi是如何进行异常处理的？何时应该使用异常处理，而不使用管理者和“任其崩溃” 的哲学呢？实践口在receive块中，如果一个消息没法匹配到任何模式，将会被留在进程的信箱中。利用这个特性和超时特性，实现一个有优先级的信箱，即使低优先级的消息可能比高优先级的消息更早地被接收，但高优先级的消息会比低优先级的消息更早地被处理。口改进今天开篇介绍的缓存actor，根据hash函数将缓存元素分配到多个actor中。创建一个管理actor，其负责创建多个工作actor，并将消息转发给对应的工作actor。如果一个工作actor 崩溃，管理actor应该怎么办？ 5.4第三天：分布式到目前为止我们学习的所有知识都只支持一台计算机，相比于已经学习过的并发模型，actoi 模型的一个很大的优点是其支持分布式一一它可以将消息发送到另一台计算机上的actor，就像发送到本地计算机上的actor一样。讨论分布式之前，要了解Elixir提供的一个强大的工具一一OTP。 OTP 过去两天，我们都在用“原始”的Elixir进行演示。这有利于我们理解其运行机制，但如果用原始的方式创建每一个工作进程和管理者，那就会变得非常无趣且容易出错。讲到这里你肯定猜到了我们将要介绍一个能解决这个问题的库一—OTP。 V/小乔爱问： OTP代表了什么？ 5.4第三天：分布式 121 缩写单词通常只为自己代言。IBM字面上是InternationalBusinessMachines的缩写，但对于大多数人来说IBM就是IBM：缩写就是约定俗成的名称。类似地，BBC也不再是British BroadcastingCorporation的缩写，OTP也不再是OpenTelecomPlatform的缩写。 Erlang（包括Elixir）最初是从电信业发展起来的，许多Erlang的最佳实践都被收录到了OTP中。但OTP不是电信业专用的，OTP就是OTP。在学习OTP之前，先来看看在Elixir中函数与模式匹配是如何交互的。函数与模式匹配之前我们仅在介绍receive块时提到过模式匹配，然而在Elixir中模式匹配随处可见。值得强调的是，每次调用函数时，其实都在进行模式匹配。用一个简单的函数来举例： Actors/patterns/patterns.ex defmodulePatternsdo def foo(x,y))do Io.puts("Got apair，first element#(x),second#ryy) end end 这段代码定义了一个函数，其接受一个参数，并用模式{x，y)匹配这个参数。如果用一个二元组进行匹配，那么二元组的第一个元素会绑定到x上，第二个元素会绑定到y上： iex(1)>Patterns.foo((:a,42)) Got a pair,first element a, second 42:ok 如果用一个不匹配的参数进行调用，将会得到一个错误： iex(2)> Patterns.foo("something else") (FunctionclauseError) no function clause matching in Patterns.foo/1 patterns.ex:3: Patterns.foo("something else") erl_eval.erl:569::erl_eval.do_apply/6 src/elixir.erl:147::elixir.eval_forms/3 根据需要可以为一个函数添加多个不同的定义： Actors/patterns/patterns.ex def foo((x,y, z)) do Io.puts("Got a triple:#[x),#(y},#{z]") end 5 122 第5章Actor 调用函数时，与参数匹配的函数将被执行： iex(2)>Patterns.foo(:a,42,"yahoo") Got a triple:a,42,yahoo:ok iex(3)> Patterns.foo((ix, :y) Got a pair, first element x, second y:ok 下面将使用OTP实现一个服务器，其中也用到了这个技术。用GenServer重新实现缓存现在学习OTP的一个组件：GenServer。GenServer是一个行为（behaviour），可以用来自动创建一个有状态的actor。我们就来利用这个组件重新实现昨天的缓存。你可能觉得behaviour这种拼写有点怪，它来源于Erlang，而Erlang用的是英式拼写。我们就入乡随俗沿用这种拼写。这里所说的“行为”非常类似于Java中的接口一一其定义了一个函数集。模块使用use来声明自已实现了行为： Actors/cache/cache3.ex defmodule Cache do use GenServer.Behaviour def handle_cast((:put,url,page),(pages,size))do new_pages = Dict.put(pages,url,page) new size = size + byte_size(page)[:noreply,(new_pages,new_size]) end def handle_call(t:get,url),_from,(pages,size))do (:reply,pages[urll,(pages,size}] end defhandle_call(t:size),_from,(pages,size))do(:reply, size,(pages, size)) end end 这段代码中Cache声明自已实现了一个行为（GenServer.Behaviour）和两个函数(handlecast()和handle call())。 handle_cast（)可以处理消息但并不回复消息。其接受两个参数：收到的消息、actor的当前状态。返回值是一个二元组(:noreply，new_state}。本例中实现了一个handle_cast()来处理：put消息。 handle_call()可以处理消息且回复消息。其接受三个参数：收到的消息、发送者标识、actor 的当前状态。返回值是一个三元组{：reply，reply_value，new_state}。本例中实现了两个 handle_call（），一个负责处理：get消息，另一个负责处理：size消息。类似于Clojure，Elixir 5.4第三天：分布式用下划线（）开头的变量名来表示该变量不被使用一一比如from。按照惯例仍会提供一些便于使用的API： Actors/cache/cache3.ex def start_link do igen_server.start_link((:local,:cache}，MoDULE,{HashDict.new,o}，[]) end def put(url,page)do :gen_server.cast(:cache,(:put,url,page)) end def get(url) do :gen_server,call(:cache,:get,ur)) end def size do :gen_server.cali(:cache,[:size)) end 123 这段代码使用了：gen_server.start_link（）替换spawn_link（），使用：genserver. cast（）发送一个不需要回复的消息，使用：genserver.call）发送一个需要回复的消息。接下来，用OTP创建一个管理者。 OTP管理者这是一个用OTP管理者行为来实现的缓存管理者： Actors/cache/cache3.ex defmodule CacheSupervisor do def init(_args) do workers = [worker(Cache, [])] supervise(workers, strategy: :one_for one) end end 进程启动时会调用init（)函数。其接受一个参数（本例中没有使用这个参数），创建一些工作进程并将其管理起来。本例中创建了一个Cache进程，并使用one-for-one重启策略来管理该进程。小乔爱问：什么是重启策略？ OTP管理者行为支持多种不同的重启策略，最常用的是 one-for-all 和 one-for-one。这些策略指的是管理多个工作进程的管理者如何重启崩溃的工作进程。如果一个工作进 124 第5章Actor 程崩溃，使用one-for-all策略的管理者将重启所有工作进程（包括那些没有崩渍的工作进程）。使用one-for-one策略的管理者仅重启已经崩溃的工作进程。还有许多其他的策略，不过这两种已经可以应对大部分场景了。按照惯例，提供易用的API： Actors/cache/cache3.ex defstart_linkdo :supervisor.start_link(_MoDULE_,[]) end 你可以自行验证一下缓存和管理者是否能正常工作，在昨天的学习中进行过类似的验证，此处不再赞述。小乔爱间： OTP还能做什么？正如以上的代码所示，OTP可以帮我们省去一些无聊的代码。此外它还提供了更多的好处，这些好处在之前的例子中不是那么明显。比起之前创建的简单版本，用OTP实现的服务器和管理者有着更多的功能，其中包括以下几点。更好的重启逻辑：之前我们自己实现的简单管理者使用非常草率的重启策略一如果工作线程崩溃，就将其重启。如果工作线程在启动时很快就崩溃，那么管理者会一直重启工作线程。而OTP提供的管理者可以设定最大重启频率，如果重启超过这个频率，管理者将会异常终止。调试与日志：通过调整OTP服务器的参数，可以开启调试和日志功能，这对开发很重要。代码热升级：OTP服务器不需要停止整个系统就可以进行升级。还有许多：发布管理、故障切换、自动扩容，等等。本书不会详细介绍这些特性。在大部分场景中可以直接使用这些特性，而不建议自己造轮子。节点每创建一个Erlang虚拟机实例，就相当于创建了一个节点。之前的例子都只创建了一个节点。现在来学习如何创建和连接多个节点。连接（connect）①节点 5.4第三天：分布式 125 连接两个节点时，必须先对这两个节点命名。启动Erlang虚拟机时可以使用-name或者-sname选项为节点命名。我的MacBookPro的IP是10.99.1.50。运行iex-sname nodel@1o.99.1.5o-=cookieyumyum（稍后会解释--cookie参数），可以查看节点名称： iex(nodel@1o.99.1.5o)1>Node.self："nodel@10.99.1.50" iex(nodel@1o.99.1.5o)2>Node.tist 使用Node，self（）可以查看节点名称，使用Node.list（）可以查看当前节点已知的其他节点列表。现在这个列表是空的，下面将为其赋值。如果使用iex--snamenode2@10.99.1.92-cookieyumyum在另一台计算机（10.99.1.92）上运行另一个Erlang虚拟机，用Node.connect（）可以连接该节点： iex(node1@10.99.1.5o)3>Node.connect(:"node2@1o.99.1.92") true iex(nodel@1o.99.1.5o)4>Node.list[："node2@1o.99.1.92"] 连接是双向的，第二台计算机也知道第一台的信息： iex(node2@1o.99.1.92)1>Node.list [:"nodel@10.99.1.50"] 小乔爱间：！如果只有一台计算机呢？如果你只有一台计算机，但又想进行集群试验，那有以下几种选择：口使用虚拟机；口使用AmazonEC2或者类似的云服务；口在一台计算机上运行多个节点。虽然这种方案与实际环境有一些偏差，却是目前最简单的方案。如果你对如何配置多机环境不太熟悉，这种方式可以帮你避免设置防火墙和配置网络等麻烦。远程执行已经建立了两个连接的节点，一个节点可以在另一个节点上执行代码： iex(nodel@1o.99.1.5o)5>whoami=fn()->Io.puts(Node.self)end#Function<20.80484245in:erl_eval.expr/5> ①之前我们看到过对进程的连接，其指的是link；此处的连接指的是connect，这两个概念不可混淆。一一译者注 126 第5章Actor iex(nodel@10.99.1.50)6>Node.spawn(:"node2@10.99.1.92",whoami) #PID<8242.50.0> node2@1o.99.1.92 这段看似简单的代码却异常强大一一个节点在另一个节点上执行代码，而且执行的结果还会返回给第一个节点。这是因为子进程会继承父进程的组长（groupleader），Io.puts（）会将输出发送给组长。其暗地里进行了很多处理！远程消息如你所料，一个actor可以向另一台计算机的actor发送消息。举例说明，下面的代码在一个节点上创建了一个Counter的实例（参见5.2节的“有状态的actor”部分）： iex(node2@10.99.1.92)1>pid=spawn(Counter,:loop,[421)#PID<0.51.0> iex(node2@1o.99.1.92)2>:global.register_name(:counter,pid):yes 创建好实例后，用：global.register_name（）进行注册，这类似于Process.register（），但它是在集群全局注册名字。现在就可以在另一个节点上使用：global.whereisname（)获取进程标识符，并发送消息： iex(nodel@10.99.1.50)1>Node.connect(:"node2@1o.99.1.92") true iex(nodel@10.99.1.50)2>pid=:global.whereis_name(:counter)#PID<7856.51.0> iex(nodel@10.99.1.50)3>send(pid,(:next))(:next} iex(node1@10.99.1.50)4>send(pid，{:next)):next} 显然，在第一个节点上的输出是： Current count:42 Current count: 43 重申一下：消息的运行结果会输出到产生消息的actor的父进程节点上。 1小乔爱问英我该如何管理集群？一个节点可以在另一个节点上远程执行代码，这是非常强大的一个功能。不过强大的功能都很危险。在设计集群管理策略时尤其需要考虑安全性。之前调用iex时使用的--cookie 参数就源出于此一个Erlang节点仅接收使用同样cookie的节点发送的消息。也有其他的方法用来保障Erlang集群的安全性，比如SSL隧道连接。安全性不是唯一的问题。上面的例子中使用IP地址作为节点名称的一部分，这在大部 5.4第三天：分布式 127 分场景下都适用（因为我并不知道你的网络配置，使用IP比较保险）。不过在产品环境中未必是最好的选择。集群设计中的种种权衡非常复杂，也超出了本书的范围。在产品环境中使用集群前，请务必阅读相关文档。分布式词频统计我们即将结束对actor模型和Elixir的学习，现在来尝试实现分布式的Wikipedia词频统计（前几章已经介绍过其背景）。分布式的解决方案与前几章的解决方案相比，相同的是可以借助多核的力量；不同的是它还可以利用多台计算机的力量，且能从崩溃中恢复。分布式解决方案的基本架构如图5-3所示。解析器已经被处理的页面累加器页面请求新的页面计数器计数结果图5-3分布式解决方案的基本架构分布式解决方案涉及到三类actor：一个解析器（Parser），多个计数器（Counter）和一个累加器（Accumulator）。解析器负责将一个Wikipediadump解析成若干个页面，计数器负责统计页面的词频，累加器负责统计多个页面的词频总数。处理的第一步是计数器向解析器请求一个页面。计数器收到页面后，统计页面的词频，并将结果传给累加器。累加器处理完成后，会告诉解析器该页面已经被处理。我们稍后会解释为什么要选择这样的处理流程，先来看看如何实现这个方案，从计数器的部分开始。计数器下面的Counter模块是一个简单的无状态的actor，从Parser接收页面，并将计数结果发送给 Accumulator: 128 第5章Actor Actors/word_count/lib/counter.ex Line 1 defmodule Counter do use GenServer.Behaviour def startlink do :gen_server.start_link(MoDULEnil,[J) 5 10 15 20 end def deliver_page(pid,ref,page)do :gen_server.cast(pid[:deliver_page,ref,page)) end def init(_args)do Parser.request_page(self()) :ok，niu) end def handle_cast(t:deliver_page,ref,page),state)do Parser.request_page(self()) words = String.split(page) counts = Enum.reduce(words,HashDict,new,fn(word, counts)-> Dict.update(counts, word, 1, &(&l + i)) end) Accumulator.deliver_counts(ref,counts) (:noreply, state) end 25end 这段代码遵循了OTP服务器的标准模式一一首先是供外部使用的API（startlink（）和 deliver_page（）），然后是初始化函数（init（）），最后是消息处理函数（handlecast（））。 Counter初始化时先调用Parser.request_page（）（第11行）。 Counter每接收到一个页面，首先会申请下一个页面（第16行，这样做是为了减少延迟）。然后统计当前页面的词频，构造字典counts来保存结果（第18~21行）。最后将ref（引用ref是和页面一起接收到的）和计数结果发送给Accumulator。利用CounterSupervisor可以创建和管理多个Counter： Actors/word_count/lib/counter.ex defmodule CounterSupervisor do use Supervisor.Behaviour def start_link(num_counters)do isupervisor.start_tink(MoDULE end ，numcounters) def init(num_counters)do workers = Enum.map(1..num_counters, fn(n) -> worker(Counter,[],id:"counter#(n") end) supervise(workers,strategy: :one_for_one) end end 5.4第三天：分布式 129 CounterSupervisor.init（）的参数是要创建的Counter的个数，也是workers列表的长度。注意，每个工作线程worker都需要一个唯一的id，可以用1．.num_counters构造id的值。累加器 Accumulator维护了两个状态：totals是保存累加结果的字典；processedpages是保存已经处理过的页面所对应的引用的集合。 Actors/word_count/lib/accumulator.ex Line1 defmodule Accumulator do useGenServer.Behaviour def start link do :gen_server.start_link(f:global,:wc_accumulator),(HashDict.new, HashSet.new), []) end def deliver_counts(ref,counts)do 10 15 20 MODULE :gen_server.cast(ft:global,:wc_accumulator),f:deliver_counts,ref,counts)) end defhandle_cast((:deliver_counts,ref,counts},{totals,processed_pages}))do ifSet.member?(processed_pages,ref)do[:noreply,[totals,processedpages}) else new_totals =Dict.merge(totals,counts,fn(_k,vl,v2) ->vl + v2 end) new_processed_pages=Set.put(processed_pages，ref) Parser.processed(ref) {:noreply,(new_totals,new_processed_pages}] end end end 这段代码以:global，wcaccumulator为参数调用：genserver.startlink（）（第5 行），为累加器创建了全局名称。可以直接使用全局名称来调用：gen_server.cast(）发送消息（第10行）。当Accumulator收到计数结果时，首先检查某一页面是否已经被处理过（稍后我们会看到 Accumulator可能收到两次同一页面的计数结果，并解释这个检查的重要性）。如果页面没有被处理过，则使用Dict.merge()将该页面的计数结果合并到totals中，并使用Set.put（）将该页面的引用合并到processed_pages，最后通知Parser该页面已经被处理。解析器与容错解析器是三种actor中最复杂的，我们将逐步进行介绍。首先，介绍其对外提供的API： Actors/word_count/lib/parser.ex defmodule Parser do use GenServer.Behaviour 130 第5章Actor def start_link(filename) do :gen_server.start_link(f:global,:wc_parser),MoDuLE,filename,[]) end def request_page(pid)do :gen_server.cast(f:global,:wc_parser],[:request_page,pid)) end def processed(ref) do :gen_server.cast(:global,:wc_parser),(:processed,refy) end end 与Accumulator相同，Parser也在初始化时注册了一个全局名称。它提供了两种操作一一第一种是request_page（），Counter调用这个函数来请求一个页面；第二种是processed（）， Accumulator调用这个函数来通知解析器某页面已经被处理了。接下来，介绍这两种操作的消息处理函数 Actors/word_count/lib/parser.ex def init(filename) do xml_parser = Pages.start_link(filename) (:ok，(ListDict.new,xml_parser)) end def handle_cast(f:request_page,pid),(pending,xml_parser))do new_pending=deliver_page(pidpending,Pages.next(xml_parser)) (:noreply，(new_pendingxml_parser)] end def handle_cast({:processed,ref),(pending,xml_parser))do new_pending =Dict.delete(pending,ref)[:noreply，(new_pending,xml_parser)) end Parser维护了两个状态：第一个是pending，这是一个ListDict，其元素是已经发往Counter 但没有被处理的页面的引用；第二个是xml_parser，这是一个actor，其使用Erlang的xmerl库来解析Wikipediadump（在此不详述其实现，详情可见本书配套代码）。对：processed消息的处理只需要从pending中删除已被处理的页面。对：request_page消息的处理需要从XML解析器中获取下一个可用的页面，并将页面传给deliver_page()： Actors/word_count/lib/parser.ex defpdeliver_page(pid,pending,page)whennil?(page)do if Enum.empty?(pending)do pending#什么也不做 http://www.erlang.org/doc/apps/xmerl/ else (ref,prev_page) = List.last(pending) Counter.deliver_page(pidref，prev_page) Dict.put(Dict.delete(pending,ref),ref,prev_page) end end defpdeliver_page(pid,pending,page)do ref =make_ref() Counter.deliver_page(pid,ref,page) Dict.put(pending.ref,page) end 5.4第三天：分布式 131 这里的deliverpage（）使用到了一个未介绍过的Elixir特性一一卫语句（guardclause），在本例中是第一个deliver_page()的when子句。卫语句是一个布尔表达式一一函数仅在表达式为真时有效。当page不为空时，首先使用makeref（）创建一个唯一的引用，并将页面传给请求页面的 counter，最后将页面添加到pending中。当page为空时，意味着XML解析器已经完成了对所有页面的解析，不再提供新的页面。此时只需将pending中最老的元素传给Counter，并从pending中将此页面移出再重新添加进来，以保证其是pending中最新的元素。 page为空的分支主要是为了确保pending中的页面最终都会被处理。将这些pending中的页面再次发给另一个counter有什么好处吗？和牌了这样的好处是提升了容错性。如果一个Counter崩溃、网络故障或者硬件故障，就需要将其处理的页面发给另一个counter。由于每个页面都带有唯一的引用，那就可以分辨哪些页面已经被处理过了，从而避免重复计数。现在启动一个集群来体验一下吧。在一台计算机上启动一个Parser和一个Accumulator，并在其他的一台或几台计算机上启动几个Counter。如果拔掉某个运行Counter的计算机的网线，或者干掉其Erlang虚拟机，其他正常的Counter将继续运行并接管那些运行在故障计算机上的页面。这是一个体现并发分布式程序的优点的绝佳例子。发生某个硬件故障时，串行的程序或多线程的程序都会崩溃，但这个分布式的程序将幸存下来。第三天总结我们完成了第三天的学习，同时也结束了对actor模型的学习。第三天我们学到了什么使用Elixir可以创建多节点的集群。一个节点上的actor可以向另一个节点上的actor发送消息， 132 第5章Actor 与向本节点的actor发送消息没有什么区别。使用Elixir可以创建一个分布在多台计算机上的系统，如果其中一台计算机崩溃，该系统可以从中恢复运行。第三天自习查找观看JoeArmstrong在LambdaJam上的演讲：SystemsThatRunForeverSelf-HealandScale。口什么是一个OTP应用程序？为什么把它理解成“组件”更加合适？口到目前为止，我们使用的actor的状态都会在它退出时丢失。Elixir是如何实现持久状态的？实践口对于本节中具有容错功能的词频统计程序，如果一个计数器或相应的计算机崩溃，程序可以继续运行下去。但如果一个解析器或一个累加器崩溃则不行。修改程序，使其在任一actor或任一计算机崩溃时都可以继续运行。 5.5复习 Smalltalk的设计者、面向对象编程之父AlanKay曾经这样描述面向对象的本质：很久以前，我在描述“面向对象编程”时使用了“对象”这个概念。很抱歉这个概念让许多人误入歧途，他们将学习的重心放在了“对象”这个次要的方面。真正主要的方面是“消息”………日文中有一个词ma，表示“间隔”，与其最为相近的英文或许是“interstitial”。创建一个规模宏大且可生长的系统的关键在于其模块之间应该如何交流，而不在于其内部的属性和行为应该如何表现。这段话也概括了使用actor模型进行编程的精髓一一我们可以认为actor模型是面向对象模型在并发编程领域的扩展。actor模型精心设计了消息传输和封装的机制，强调了面向对象的精髓，可以说actor模型非常“面向对象”。优点 actor有许多优良的特性，适用于解决多种并发问题。消息传输和封装行的。所以关于并发，只需要关注于多个actor之间的消息流即可。 ①http://c2.com/cgi/wiki?AlanKayOnMessaging 5.5复习 133 对开发人员来说这是个重大利好。每个actor可以被单独测试，而且当测试覆盖了某个actoi 的消息类型和消息顺序时，就可以确定这个actor非常可靠。如果发现了一个与并发相关的bug，也就知道重点应该放在actor之间的消息流上。容错使用actor模型的程序天生具有容错性。这不仅会让程序更加强壮，而且（通过“任其崩溃” 的哲学）会让代码更加简洁明了。分布式编程 actor模型支持共享内存模型，也支持分布式内存模型，这就带来了很多优点。首先，actor模型几乎可以解决任何规模的问题。我们不需要将问题局限于用一个系统解决。其次，actor模型可以解决地理分布式问题。对于不同部分需要部署在不同地理位置的软件， Actor模型是个极佳的选择。最后，分布式是软件具有容错能力的基石。缺点尽管使用actor模型的程序比使用线程与锁模型的程序更容易debug，但actor模型仍会碰到死锁这一类的共性问题，也会碰到一些actor模型独有的问题（例如信箱溢出）。类似于线程与锁模型，actor模型对并行也没有提供直接支持。需要通过并发的技术来构造并行的方案，这样就会引入不确定性。而且，由于多个actor并不共享状态，仅通过消息传递来进行交流，所以不太适合实施细粒度的并行。其他语言与许多伟大的思想一样，actor模型也由来悠久一一20世纪70年代CarlHewitt首次提出这个模型。Erlang无疑为布道actor做了最大的贡献。比如Erlang的创始人JoeArmstrong也是“任其崩溃” 哲学的先驱。大部分流行的编程语言都提供了一个actor库，特别是Akka库为Java和其他运行于JVM的语言提供了对actor模型的支持。如果想深入学习Akka，建议阅读本书的奖励章节，其中描述了如何用Scala进行actor编程。 http://akka.io ②http://media.pragprog.com/titles/pb7con/Bonus_Chapter.pdf 134 结语第5章 Actor actor模型是应用最广泛的编程模型之一不仅提供了并发支持，还支持分布式、错误检测和容错。当面对越来越大的分布式需求时，该模型是解决问题的绝佳选择。下一章我们将学习通信顺序进程（CommunicatingSequentialProcesses，CSP）。虽然CSP模型看上去类似于actor模型，但区别在于：actor模型的重点在于参与交流的实体，而CSP模型的重点在于用于交流的通道。因此使用CSP模型将是另一番体验。第6章通信顺序进程如果你和我一样是个车迷，很可能只会关注车辆本身，而忽略了它所要行驶的道路。大家都在噪噪不休地争论涡轮增压与自然吸气优敦劣，让中置发动机布局与前置发动机布局一较高下，却忘记了最重要的方面其实与车辆本身无关。你能去往何方、能多快到达自的地，首要的决定因素是道路网络而不是车辆本身。消息传递系统（message-passing system）与之类似，决定其特性和功能的首要因素并不是用于传递消息的代码或者消息的内容，而是消息的传输通道。本章我们所考察的模型表面上与actor模型相似，但由于其侧重点不同，所以有着很大的差别。 6.1万物皆通信如上一章所述，使用actor模型的程序是由独立的、并发执行的实体（称为actor，Elixir中称为进程）组成的，这些实体之间通过发送消息进行通信。每个actor都有一个信箱，用于保存已经收到但尚未被处理的消息。与actor模型类似，通信顺序进程（CommunicatingSequentialProcesse，CSP）模型也是由独立的、并发执行的实体所组成，实体之间也是通过发送消息进行通信。但两种模型的重要差别是： CSP模型不关注发送消息的实体，而是关注发送消息时使用的channel（通道）。channel是第一类对象，它不像进程那样与信箱是紧耦合的，而是可以单独创建和读写，并在进程之间传递。与函数式编程和actor模型类似，CSP模型也是正在复兴的古董。由于近来Go语言的兴起， CSP模型又流行起来。我们将通过core.async库来介绍CSP模型，这个库将Go的并发模型引人了Clojure。第一天，我们将学习构建core.async库的两大基石：channel和go块。第二天，使用这些知识构建一个有现实意义的例子。第三天，学习如何在ClojureScript中使用core.async来简化客户端编程。 ①http://golang.org ②http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html 136 第6章通信顺序进程 6.2第一天：channel和go块 core.async提供了两个主要的工具一一channel和go块。在大小有限的线程池中，go块充许多个并发任务复用线程资源。现在还是先来看看channel。使用core.async库在Clojure语言中，core，async库的资历较浅，且仍处于预发布阶段（因此需要留意可能发生的变化）。要使用这个库，你需要为项目添加依赖并导入core.async。由于 core.async库定义的一些函数名与Clojure核心库的函数名冲突，添加依赖和导入库往往较为繁复。为简单起见，你可以使用本书配套代码中的channel项目，它是这样导入core.async 库的： CSP/channels/src/channels/core.clj(nschannels.core (:require [clojure.core.async :as async refer:alt o 通过指定：refer：all，大多数core.async库的函数可以直接使用，但还有一部分（函数名与核心库函数名冲突的函数）必须通过使用async/前缀才能调用。切换到channel项目下，直接运行leinrepl，就可以运行一个REPL，其中已经加载了 core.async库的函数定义。 Channel 一个channel就是一个线程安全的队列一一任何任务只要持有channel的引用，就可以向一端添加消息，也可以从另一端删除消息。在actor模型中，消息是从指定的一个actor发往指定的另一个 actor的；与之不同，使用channel发送消息时发送者并不知道谁是接收者，反之亦然。通过chan函数可以创建新的channel： channels.core=>(def .c(chan))#channels.core/c 使用>！！可以向channel中写人消息，使用<！！可以从channel中读出消息： channels.core=>(thread (println"Read:"( channels.core=>(>!!c"Hello thread") Read: Hello thread from c nil 6.2第一天：channel和go块 137 这段代码使用了core.async提供的thread辅助宏，这个宏会将其中的代码运行在一个单独的线程上。这个线程将会输出从channel中读出的消息。不过首先它会阻塞，直到调用>！！向channel 中写入消息，然后我们才会看到输出。缓存区默认情况下，channel是同步的（或称无缓存的）直阻塞，直到另一个任务从channel中读出消息：个任务向channel写入消息的操作会一 channels.core=>(thread (>!!c"Hello") (println"Write completed")) # channels.core=> ( (def bc (chan 5))#'channels.core/bo channels.core=>(>!!bc o) nil channels.core=> (>!!bc 1) nil channels.core=> (close!bc) nil channels.core=> ( ( ((>!!(chan)niu) IllegalArgumentException Can't put nil on channel《... 下面的函数将运用我们已学的知识，不断地从channel中读出消息，直到channel被关闭。函数将以数组形式返回读到的所有内容： CsP/channels/src/channels/core.clj (defn readall!![ch](loop [coll []] 138 第6章：通信顺序进程 (if-let [x (!! ch x))(close!ch)) 来测试一下这几个函数： channels.core=> (def ch (chan 1o))#'channels.core/ch channels.core=> (writeall!! ch (range o 1o)) nit channels.core=> (readall!! ch)[0123456789] 你肯定料到了core.async会提供具有类似功能的辅助函数，这样我们就不用自已创建这些函数了： channels.core=> (def ch (chan 10))#"channels.core/ch channels.core=> (onto-chan ch (range o 1o)) # channels.core=>((def dc(chan(dropping-buffer5)))#'channels.core/dc channels.core=> (onto-chan dc (range o 1o)) # channels.core=>((def sc(chan(stiding-buffer5)))#channels.core/sc channels.core=> (onto-chan sc (range 1o)) # channels.core=>((def ch(chan)) #'channels.core/ch channels.core=>(go #_=>(let [x ( (println"Sum:"(+xy)))) #=> # channels,core=>(>!!ch 3) nil channels.core=> (>!! ch 4) nil sum：7 6.2第一天：channel和go块 141 这段代码首先创建了一个channelch。然后创建了一个go块，用来从ch中读取两个值，并输出两个值的和。虽然看上去go块从channel中读取数据时应当阻塞，实际上却发生了有趣的事情。这段代码并没有用<！！从channel中读取数据，而是使用了<！。单个叹号意味着本次读channel 是进行暂停操作，而不是进行阻塞操作。同理，！是！！的暂停版本如图6-1所示，go块将串行的代码转换成有3个状态的状态机。 ( ( (time (go-add 1o 1o)) "Elapsedtime:1.935msecs" 20 channels.core=> (time (go-add 1o 1ooo)) "Elapsed time: 5.311 msecs" 1010 channels.core=> (time (go-add 1o 100000)) "Elapsed time:734.91 msecs" 100010 可以看到，创建并运行100000个go块需要花费3/4秒。这意味着go块的性能比起Elixir的进程毫不逊色一一这个成绩非常优秀，因为Elixir运行在以并发性能为设计主旨的Erlang虚拟机中，而 Clojure却是运行在JVM中。 6.2第一天：channel和go块 143 我们已经学习了channel和go块这两种技术，现在可以将两者结合使用，构造出更复杂的 channel操作。在channel上进行操作如果你感觉channel与数组有些相像，那你并没有错。与数组类似，channel代表了一系列有序的值；我们可以将一些高级函数施加在channel中的全部元素上一一比如map函数、filter函数等；我们还可以将这些函数串联起来，构建复杂的操作。在channel上进行映射下面是channel版的map函数： CSP/channels/src/channels/core.clj(defn map-chan [f from] (let [to (chan)](go-loop (when-let [x (! to (f x)) (recur))(close! to)) to)) 这个函数接受一个函数f和一个源channelfrom。首先，这段代码创建了一个目标channelto to将作为函数的返回值。然后，使用go-loop创建一个go块，go-loop是一个辅助函数，等价于（go（oop：·.））。循环体中使用when-let从from中读出值并绑定到x上。如果x不为null，则 when-let中的代码会被执行，（f x)将被写入to中，并且循环会继续进行。如果x为null，to会被关闭。测试一下这个函数： channels.core=> (def ch (chan 1o))#"channels.core/ch o#'channels.core/mapped channels.core=> (onto-chan ch (range e 1o)) # channels.core=> ( (def ch (to-chan (range o 1o)))#"channels.core/ch ((([0481216] 144 第6章通信顺序进程上面这段代码使用了core.async提供的另一个辅助函数to-chan，其创建并返回一个 channel，这个channel中包含了输人数组中的所有元素，在数组中的元素用尽后这个channel会关闭。现在来做一个有趣的试验，以此为第一天的学习做个结尾。并发版本的埃氏筛我们现在来实现一个并发版本的埃氏筛。get-primes函数会返回一个channel，其中包含了 limit以内（含limit）的所有素数（从小到大排列）： CSP/Sieve/src/sieve/core.clj (defn factor? [x y](zero?(mody x))) (defn get-primes [limit](let [primes (chan) numbers (to-chan(range2limit)))(go-loop[ch numbers] (when-let [prime (! primes prime) (recur (remove< (partial factor?prime)ch))) (close! primes)) primes)）稍后将简要介绍这段代码的工作原理（建议你先自已整理一下思路一一所有必要的知识之前都已经介绍过了）。我们还是先来验证一下其正确性。下面的main函数会调用get-primes，并输出其返回的channel中的所有值： CSP/Sieve/src/sieve/core.clj(defn-main[limit] (let [primes (get-primes (edn/read-string limit)))(loop) (when-let[prime（。map<和map>分别适用于什么场景？口实现一个基于channel的并行map函数（类似于Clojure中的pmap函数，或者类似于在前面章节中用Elixir实现的并行map函数）。 6.3第二天：多个channel与1o 今天将学习如何使用core.async库，让异步IO的处理变得简洁易懂。在此之前，需要先了解一个之前没有提及的特性一一如何同时处理多个channel。处理多个channel 6.3第二天：多个channel与IO 147 到目前为止，我们在某个时间仅处理一个channel，但我们能做的并不仅限于此。使用alt！宏可以处理多个channel： channels.core=>(def chi (chan))#'channels.core/chl channels.core=>(def ch2(chan))#"channels.core/ch2 channels.core=> (go-loop [] (alt! # => #_=># => chl([x(println"Read"x"from channel1")) ch2([x)(printlnTwice"x"is"(*x2)))) (recur)) #= # channels.core=> (>!! chl "foo") Read foo from channel 1 nit channels,core=> (>!! ch2 21) Twice 21is 42 nit 这段代码中，首先创建了两个channel：ch1和ch2，然后创建了一个go块，其会不断循环并使用alt！从两个channel中读取数据。如果能从ch1中读取数据，那么将数据直接输出；如果能从 ch2中读取数据，那么将数据翻倍后再输出。从这段代码中很容易就能理解alt！宏的工作原理一一它接受成对的参数，每对的第一个参数是一个channel，第二个参数是一段代码，从channel中读出数据后将执行这段代码。在本例中，这段代码看上去像是一个匿名函数，从channel中读出的值被赋给x，并通过println输出。但它实质上并不是匿名函数一它没有使用fn构造匿名函数。这就是Clojure的宏系统施加的另一个魔法，比起使用匿名函数，alt!宏的这种用法显得更简洁高效。小乔爱间如果是向多个channel中写入数据呢？一类似于从多个channel读出数据，altl宏也可以我们刚才只是学习了alt!宏的皮毛一用于向多个channel写入数据，或者将读写混用。本书并不会涉及这种用法，如果读者想深入了解alt！，可以查看官方文档。超时 timeout函数返回一个channel，这个channel在指定的时间（以毫秒为单位）过后会被关闭： 6 148 第6章通信顺序进程 channels.core=>(time( (def ch (chan))#"channels.core/ch channels.core=> (let [t (timeout 1oooo)] #_=>(go（alt! ch ([x] (println"Read"x"from channel")) #_= t(println"Timed out")))) #三 # channels.core=> Timedout 设置超时并没有什么新鲜，但这种方法使得超时具象化了（用一个对象来代表超时操作）稍后将会看到这项改进是非常有用的。具象化的超时大部分系统是以请求为对象来设置超时时间的，比如Java的URLConnection类提供的 setReadTimeout（）方法。如果服务器在一定时间内没有响应，read（）会抛出异常IoException。这只适用于对单个请求设置超时时间，如果要为几个串行的请求设置一个总的超时时间，上述方法就不能解决问题，而具象化的超时却可以。只需要创建一个超时对象，并在串行的几个请求中都使用这个超时对象即可。为说明这一点，我们将昨天创建的素数筛稍微修改一下，使其不接受数值范围，而是接受个时间。素数筛将在规定时间内尽可能多地产生素数。先修改get-primes，使其不断产生素数： CSP/SieveTimeout/src/sieve/core.clj (defn get-primes [)(let [primes (chan) numbers(to-chan (iterate inc 2)))(go-loop [chnumbers] (when-let [prime (! primes prime) (recur(remove<(partiatfactor?prime)ch))) (close! primes)) primes)) 之前channel的初始值是由（range2limit）产生的，而这次是用无穷数组（iterateinc2）。下面的代码使用了get-primes： CSP/SieveTimeout/src/sieve/core.clj(defn-main [seconds] (let[primes(get-primes) 6.3第三天：多个channel与10 limit(timeout (*(edn/read-string seconds)1ooo)))(loop) (alt!!:priority true limit nil primes([prime](printlnprime)(recur)))))) 149 这段代码中使用了alt！！，如你所料，它是alt！的阻塞版本。这段代码中的alt！！将进行阻塞，直到产生了一个新的素数，或者到达设置的超时时间limit而返回nil。：prioritytrue选项确保了alt！！的子句（都可以执行时）是按代码顺序执行的（默认情况下，如果两个子句都可以执行，它们执行的顺序是不确定的），这样就尽量避免了由于产生素数的速度过快而导致超时的子句无法执行的情况。这个例子展示了如何自然地设置超时时间一一相比为每个请求设置超时时间，这种方式显得更加自然。下一节将使用超时机制和Clojure的宏系统来构建一个辅助工具，它适用于一个普遍的场景——轮询。异步轮询稍后我们将构建一个RSS阅读器。RSS阅读器需要轮询指定的新闻feed来检测是否有新的文章。本节我们将使用超时机制和Clojure的宏系统来构建一个辅助工具，它可以轻松高效地进行异步轮询。轮询函数要实现轮询功能，需要用到之前提到的timeout函数。下面这个函数接受两个参数：轮询周期（以秒为单位）和一个函数，这个函数每隔一个轮询周期会被调用一次： CSP/Polling/src/polling/core.clj (defn poul-fn[interval action](let[seconds(*interval1ooo)](gowhiletrue (action) ( Polling at:1388827086165 Polling at: 1388827096166 Polling at:1388827106168 不过这里有一个问题一一也许你看到poll-fn是在go块中对传人的函数进行调用的，因此就认为传入的函数中可以调用暂停函数。如果这样做，会发生以下异常： 6 150 第6章通信顺序进程 polling.core=> (def ch (to-chan (iterate inc o)))#'poliing.core/ch polling.core=> (poll-fn 1o #(printin"Read:" ( (poll 1e #_=> (println"polling at:"(System/currentTimeMillis)) #=> (println( polling.core=> Pollingat:1388829368011? Pollingat:1388829378018 1 由于宏是在编译时展开，因此传给poll的代码是内联的（inlined），会被直接替换到poll的 go块中，也就是说代码中可以包含暂停函数。使用宏的好处不只如此。我们不必再传入一个完整的函数，而是传入一个代码片段，这样就不用再借助匿名函数，进而代码看上去会更自然。事实上，我们创建了一种（不同于函数的）控制结构。通过展开poll可以检查它是否正确： polling.core=>(macroexpand-1 #=># =>#_=> "（potl1o 6.3第二天：多个channel与I0 (println"Polling at:"(System/currentTimeMiuiis))(printin((require[org.httpkit.ciientiashttp]) nil wordcount.core=>(defnhandle-response[responsel # (let [url (get-in response [:opts :urll) # =>#> status (:status response)) (println"Fetched:"url"with status:status))) #"wordcount.core/handle-response wordcount.core=>(http/get "http://paulbutcher.com/" handle-response) # wordcount.core=> Fetched:http://paulbutcher.com/ with status: 20o 现在的任务是对http/get进行封装，将http-kit集成到core.async中。这里将用到一个生的函数put！，它不必在go块中调用。它可以向channel写入数据，与之前不同，它只是发起写入而并不关心结果（既不会进行阻塞也不会进行暂停）： CSp/WordCount/src/wordcount/http.clj (defn http-get [url](let [ch (chan)] (http/get url (fn [response) (if (= 20o (:status response))(put! ch response) ch)) ①http://http-kit.org (do (report-error response) (close! ch))))) 6.3第二天：多个channel与I0 153 这段代码首先创建了一个channel，它将作为函数的返回值（你应该已经很熟悉这个模式了）；然后调用了http/get，并立刻返回。在未来某个时间，当GET操作完成时，回调函数将被调用。如果GET操作返回的状态是200（表示成功），回调函数会将GET操作的响应内容写入channel：如果状态不是200，回调函数会报告一个错误并关闭channel。下一节将创建轮询RSSfeed的函数。轮询feed 我们已经有了http-get和poll，如你所料，通过简单的代码就可以轮询RSSfeed： CSP/WordCount/src/wordcount/feed.clj(def poll-interval 60) ;Simple-minded feed-polling function ; WARNING:Don't use in production (use conditional get instead) (defn poll-feed [url](let [ch (chan)] (poll poll-interval (when-let【response((ns wordcount.feed) nil wordcount.feed=> (def feed (poll-feed"http://www.cbsnews.com/feeds/rss/main.rss"))#wordcount.feed/feed wordcount.feed=> (loop [] #=># =># => (when-let [url (! out link) out)) (recur(conjlinkslink)))))) 首先，这段代码创建了两个channel：in和out。in是由poll-feed函数返回的；feed中的新链接将被写人out。这段代码在go块中进行了一个循环，用于维护目前接收到的链接的集合 links，links的初始值是空集合#。每当从in中读出一个链接时，就需要检查links中是否已存在该链接。如果已经存在，就什么也不做；否则就将其写人out并添加到links中。在REPL中测试一下，这次不再会每隔60秒输出一堆链接，而是仅在检测到新链接时才会有输出。现在我们已经从feed中获取了新文章的链接，接下来就可以依次获取文章的内容并统计词数了。统计词数根据之前所学的知识，很容易就可以实现get-counts函数： CsP/WordCount/src/wordcount/core.clj (defn get-counts [urls](let [counts(chan)] (go(whiletrue (let [url (! counts [url c])))))) counts)) 155 这段代码接受一个channelurls，对于从中读出的每一个链接，使用http-get来获取文章的内容，统计其中的词数，并将结果写人返回的channel中。统计词数的结果是一个二元数组，其中第一个元素是文章的链接，第二个元素是文章的词数。万事俱备，只差将各个部分组装起来。组装下面这个main函数实现了完整的RSS词数统计功能： CSP/WordCount/src/wordcount/core.clj Line1(defn -main [feeds-file] 2 3 4 5 6 7 8 (with-open [rdr (io/reader feeds-file)](let [feed-urls (line-seq rdr) article-urls (doalt (map new-links feed-urls)) article-counts(doall(map get-counts article-urls)) counts (async/merge article-counts))(whiletrue (println ((macroexpand-1 '(alt!chl ([x) (printin x)) ch2 ([yl (println y)))) 对于展开后的代码，通过调整缩进并删除clojure.core前缀，可以方便阅读。alt！是如何不调用匿名函数而达到调用匿名函数的效果的？ 6.4第三天：客户端CSP ClojureScript（http://clojurescript.com）是Clojure的一个子集，ClojureScript并不将程序编译成 Java字节码，而编译成JavaScript。也就是说可以用Clojure为一个Web应用同时编写服务器端和客户端的代码。使用ClojureScript的主要原因之一是它支持core.async，这为我们带来了许多好处，其中最重要的就是它能将众多JavaScript程序员从“回调困境”中解救出来。并发是一种心境如果你熟悉客户端JavaScript编程，肯定会认为本节写错了一一浏览器使用的JavaScript引擎是单线程的，怎么会与core.async扯上关系？并发编程不是在多线程的场景下才有用吗？在没有真正多线程的场景中，通过go宏的控制反转，ClojureScript可以让客户端编程在表面上具有多线程功能。这是协作式多任务（cooperativemultitasking）的一种形式强制打断另一个任务。之后我们会看到，这为代码结构和清晰度带来了质的飞跃。业关于Web Worker 一个任务不会通过WebiWorkera，现代浏览器在一定形式上支持真正多线程的JavaScript。WebWorker 只涉及后台任务，而不能访问DOM。通过某些库，比如Servanth，ClojureSeript也可以使用WebWorker。 a.http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html b.https://github.com/MarcoPolo/servant 158 第6章通信顺序进程 Hello,ClojureScript ClojureScript与Clojure类似，但也存在一些差别一一本书会在相关部分介绍它们。 ClojureScript应用的编译过程通常是两阶段的。第一阶段，客户端的ClojureScript代码将被编译成一个JavaScript文件；第二阶段，服务器端的ClojureScript代码将被编译并创建一个服务器，这个服务器提供的页面会将该JavaScript文件的代码包装在

9 10 第4行中引用了ClojureScript生成的JavaScript脚本，它将操作第7行空白的

。下面是对应的ClojureScript代码： CSP/HelloClojureScript/sre-cljs/hello_clojurescript/core.cljs Line1 (ns hello-clojurescript.core (:require-macros[cljs.core.async.macros :refer [go]])(:require[goog.dom:as dom] [cljs.core.async :refer [充满整个窗口： CSP/Animation/resources/public/index.html Animation

我们要借助GoogleClosure库的图形功能在页面上绘图，GoogleClosure库对不同浏览器上绘图操作的细节进行了抽象。create-graphics函数接受一个DOM元素，返回一个图像接口，通过这个图像接口可以在DOM元素上绘图 CSP/Animation/src-cljs/animation/core.cljs(defn create-graphics [elem] (doto(graphics/createGraphics"100%""100%"）(.renderelem))) shrinking-circle函数接受一个图形接口和一个位置，并创建一个go块，其绘制以输人的位置为中心的圆，并实现动画： CSP/Animation/src-cljs/animation/core.cljs Line1(def stroke(graphics/stroke.1"#ffoooo")) (defn shrinking-circle [graphics × y](go (let [circle (.drawCircle graphics xy 1oe stroke niu)] 5 (loop[r 100] ( r o) 10 (recur(dec r))))(.dispose circle)))) 6.4第三天：客户端CSP 161 这段代码首先使用GoogleClosure库的drawcircle函数（第5行）来绘制圆；然后进入循环，每25ms调用一次setRadius函数（每秒40次）（第7行）；最后当半径衰减到o时，调用dispose 函数来删除圆（第11行）。我们还需要判断用户何时在页面上点击了鼠标。GoogleClosure库提供了isten函数，用于注册事件监听者。类似于昨天学习的http/get函数，listen接受一个回调函数，在指定事件发生时会调用该回调函数。与昨天类似，我们传入一个将事件写人channel的回调函数，来将回调函数转换成 core.async的形式: CSP/Animation/src-cljs/animation/core.cljs(defn get-eventsi [elem event-type](let [ch (chan)] (events/listen elem event-type #(put! ch %)) ch)) 还剩最后一点工作： CSP/Animation/src-cljs/animation/core.cljs(defn start [) (let [canvas(dom/getElement"canvas") graphics (create-graphics canvas) clicks(get-events canvas"click")] (go (while true (let [click (作为画布，构造一个图形接口在画布上绘画，并获得鼠标点击事件构成的channel；然后进人循环，等待发生一次鼠标点击，获取这次点击的坐标offsetx和 offsetY，并在这个坐标位置创建一个圆的动画。这个例子看上去很简单（实际上也是这样），但它将JavaScript的基于回调的代码转换成了 core，async的基于channel的代码，我们已经获得了巨大的成功一一找到了“回调困境”的解决方案。卵服回调 “回调困境”指的是由于JavaScript严重依赖回调方法而导致代码混乱的状况一一回调函数调 6 162 第6章通信顺序进程用的回调函数再调用另一个回调函数，还需要暂存不同的状态来进行回调之间的通信，下面将学习如何用本章介绍的异步编程模型来解决回调困境。实现一个向导器? 向导器是常用的界面模式，指导用户一步一步地进行操作。今天最后的任务就是运用所学来创建一个不使用回调函数的向导器： QQ8-Step2 Wizard localhost:30oo/index.htmt Date of Birth: 03/10/1968 Homepage:www.paulbutcher.com Next 图6-5向导器向导器由包含多个fieldset的表单构成： CSP/Wizard/resources/public/index.html

Step 1 2 Reader First Name: Last Name:

Step 2 Date of Birth:

Step3 o

①有趣的是，原文标题是“We'reOffto SeetheWizard”，这是绿野仙踪的一首插曲。“wizard”既有“巫师”的意思，也有“向导器”的意思。“ -译者注 6.4 第三天：客户端CSP 每个

代表向导器的一个步骤。先将所有的fieldset隐藏起来： CsP/Wizard/resources/public/styles.css label f display:block;width:8em;clear:left;float:left; text-align:right; margin-right:3pt; } input {display:block;} step{display:none;} 之后的程序会使用下面这些辅助函数，显示或隐藏相关的fieldset： CSP/Wizard/src-cljs/wizard/core.cljs(defn show [elem] (set!（.elem-style-display）"block"))(defn hide [elem] (set! (.- elem -style -display)"none")) (defn set-Vvalue [elem value](set! (.-value elem) value)) 这段代码使用了另一种形式的dotspecialform，用于访问对象深层的属性，比如：(set! (.: elem -style -display)"block") 会被转换成下面的JavaScript代码： elem.style.display ="block"; 下面的代码实现了向导器的控制流程： CSP/Wizard/src-cljs/wizard/core.cljs(defn start [) Line1 o6) (let [wizard (dom/getElement"wizard") 5 10 15 20 stepl(dom/getElement"stepi") step2(dom/getElement"step2") step3(dom/getElement"step3"） next-button(dom/getElement"next")(showstepl) (！，但并不支持阻塞函数<！！和>！！。这是为什么？口阅读take！的文档，通过这个函数，如何将基于channel的API转换为基于回调函数的API？这适用于什么场景？（提示：这个问题与上一个问题相关。）实践口用core.async编写一个简单的浏览器游戏，比如贪吃蛇、乒乓球或打砖块。口用JavaScript重写向导器的例子。其与ClojureScript版本相比有什么区别？ 6.5复习表面上看，actor模型和CSP模型非常相似一一它们均由独立的并发的执行单元构成，这些执行单元之间都使用消息来进行通信。但如本章所述，由于侧重点不同，这两种模型可谓是大相径庭。优点 6.5复习 165 与actor模型相比，CSP模型的最大的优点是灵活性。使用actor模型时，负责通信的媒介与执行单元是紧耦合的一一一每个actor都有一个信箱。而使用CSP模型时，channel是第一类对象，可以被独立地创建、写入数据、读出数据，也可以在不同的执行单元中传递。 Clojure语言的创始人RichHickey解释了他在CSP模型与actor模型中选择前者的原因：我个人对actor模型并不感兴趣。在actor模型中，生产者和消费者还是耦合在一起的。诚然，我们可以用actor模型实现消息通信用的队列（人们确实也经常这样做），但actor 模型本身就已经使用了队列，用它来实现基础的消息通信用的队列未免显得画蛇添足。2 从更务实的角度来说，现在的csP模型的实现，比如core.async库，使用了控制反转技术，不仅提高了异步程序的效率，还为原本使用回调函数来解决的应用领域提供了一种显著改进的编程模型。本章中我们学习了其中的两种模型：异步IO编程和异步UI编程，然而还有很多其他模型。缺点如果将本章与上一章相比，有两个主题没有被提及一一分布式和容错性。基于CSP模型的编程语言虽然也可以支持分布式和容错性，但与基于actor模型的编程语言不同，这两个主题并没有得到足够的重视和支持一也没有基于CSP模型实现的OTP。与使用线程与锁模型和actor模型一样，CSP模型也容易受到死锁影响，且没有提供直接的并行支持。使用CSP模型时，并行需要建立在并发的基础上，这也就引人了不确定性。其他语言与actor模型类似，CSP模型由TonyHoare于1970年代提出。近年来这两个模型一直在互相借鉴，共同进化。 20世纪80年代，编程语言occam使用CSP模型为基石。然而在当下，Go语言是使用CSP模型的最流行的语言。 core.async和Go语言都使用控制反转来实现异步任务，这一技术也被其他语言广泛使用，包括F#、C#、Nemerle和Scala http:/elojure.com/blog/2013/06/28/clojure-core-async-channels.html ②RichHickey在文章中主要阐述了设计core.async的目的，其中一个目的是提供消息通信用的队列。这段引文正是从提供消息通信用的队列这一角度来阐述选择CSP模型的原因。一—译者注 http://en.wikipedia.org/wiki/Occam_programming_language http://blogs.msdn.com/b/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx http://msdn.microsoft.com/en-us/library/hh191443.aspx https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro#async http://docs.scala-lang.org/sips/pending/async.html 166 结语第6章通信顺序进程 CSP模型和actor模型开发社区的侧重点不同，并各自发展，从而形成了两者之间的诸多差异。 actor模型的开发社区侧重于容错性和分布式，而CSP模型的开发社区侧重于效率和代码表达的流畅性。如何在这两种模型之间进行选择，很大程度上取决于你关注于哪个方面。 CSP模型是本书介绍的最后一种通用的编程模型。下一章我们将学习第一个专用的编程模型。第7章数据并行数据并行就像是八车道的高速公路。虽然每辆车的速度相对平缓，但由于多辆车可以同时行进，所以通过某一点的车流量还是很大的。到目前为止，我们讨论的每一项技术都可以用于解决多种编程问题。相比之下，数据并行只适用于很窄的范围。顾名思义，数据并行是并行编程技术，而不是并发编程技术（并发和并行是相关的，但又有所区别，参见1.1节）。 7.1隐藏在笔记本电脑中的超级计算机本章我们将学习如何利用隐藏在笔记本电脑中的超级计算机一一图形处理单元（GPU）。现代GPU是一个强力的数据并行处理器，其用于数学计算时性能超过了CPU，这种做法称为基于图形处理器的通用计算（General-PurposecomputingontheGPU），或GPGPU编程。过去数年间，有许多技术致力于将不同GPU的实现细节抽象出来。本书将使用开放计算语言（OpenCL）来编写GPGPU代码。第一天，我们将学习编写OpenCL内核的基础知识，以及用于编译和运行内核的主机程序。第二天，学习如何将内核映射到硬件上。第三天，学习OpenCL如何与开放图形库（OpenGL）2写就的图形代码进行交互。 7.2第一天：GPGPU编程今天我们将学习如何编写一个简单的将两个数组并行相乘的GPGPU程序，并测试这个程序的性能，来看看GPU与CPU相比性能会有多大提升。不过我们要先花点时间来探究一下为什么 GPU在进行数学运算时比较强力。 http://www.khronos.org/opencl/ ②http://www.opengl.org 168 3第7章数据并行图形处理与数据并行计算机图形学主要研究如何处理数据、如何处理大量数据以及如何快速处理大量数据。3D游戏的一个场景是由无数个小三角形构成的，每一个三角形都需要根据与视点相关的透视关系计算出其在屏幕上的位置，并进行裁剪、处理光照、修饰纹理等，这些操作每秒钟都要进行25次以上。虽然需要处理的数据量是巨大的，但其有一个非常好的特性：施加在数据上的操作都是相对简单的向量操作或矩阵操作。因此这种场景非常适合于数据并行一一多个计算资源会在不同的数据上并行地施加同样的操作。现代GPU是异常复杂但十分强力的并行处理器，其1秒钟可以处理几十亿个三角形。虽然设计GPU的主要目的是为了满足图形计算的需要，但是GPU也可用于更广的领域。数据并行可以通过多种方法来实现。我们要学习其中的两种：流水线和多ALU。流水线虽然看上去将两数相乘是一个原子操作，但如果从芯片上的门电路的角度来看，这个操作实际上是分儿步完成的。这些步骤通常被排列成流水线型，如图7-1所示。操作数1 操作数2 图7-1两个数乘法的操作流水线图7-1是一个有五个步骤的流水线，如果每一步骤需要1个时钟周期来完成，那将一组数（两个数）相乘就需要5个时钟周期。但如果有多组数要相乘，就可以通过让流水线饱和来获得更好的性能（假设内存子系统足够快，可以及时提供足够多的数），如图7-2所示。 aaza.ag - - a*bz>ag*bag*bs>a*b4ag*b3 - b6 b7 b8 bg- - a,*b,|a2*b2- - 图7-2多组数乘法的饱和的操作流水线如果需要将1000组数相乘，每组数需要5个时钟周期，看上去总共需要5000个时钟周期，而如图7-2所示，实际上只需要略多于1000个时钟周期即可完成。多ALU 7.2第一天：GPGPU编程 CPU中负责进行乘法之类运算的组件称为算术逻辑单元（ALU），如图7-3所示。操作数1 W 操作数2 结果图7-3ALU 169 只要搭配足够宽的内存总线，多个ALU就可以同时获取多个操作数，这样施加在大量数据上的运算就可以并行了，如图7-4所示。 ag a, a. as a. as az a4 ag a a a2 a13 a4 la15 Jai6 a b, D3 C b1ob11b12 bg 613614b15b16 .· b a bi a bn a2 bi2 c a C1 C12 图7-4利用多个ALU对大量数据进行并行操作 Ci NC Ca C2 C3 C4 Cg Co C-ChoCu e 3Ci4Ci5c6 GPU的内存总线通常有256位或更宽，也就是说一次可以获取8个或更多个32位的浮点数。混乱的局面为了获得更好的性能，现实中的GPU会综合使用流水线、多ALU以及许多本书尚未提及的技术。这就增加了进一步理解GPU的难度。更遗憾的是，不同的（即使是同一厂商生产的）GPU之间的共性是很少的。如果我们必须针对某个架构开发代码，GPGPU编程不是最佳选择。 170 第7章数据并行 OpenCL定义了一种类C语言，可以针对多种架构抽象地进行编程。不同的GPU厂商会提供各自的编译器和驱动程序，使代码可以被编译并在相应的硬件上运行。第一个OpenCL程序如果要利用OpenCL对数组相乘进行并行化，就需要先将工作划分成多个可以并行执行的工作项（work-item）。工作项在编写并行代码时，需要留意每个并行任务的颗粒度。通常，如果每个任务只进行非常少的工作，代码运行的效率会很低，其原因是线程创建和线程通信的代价会变得很高。相比之下，OpenCL的工作项通常会很小。如果要将两个有1024个元素的数组相乘，就可以创建1024个工作项。如图7-5所示。输人A· 输入B 工作项0 工作项1 工作项2 工作项1023 图7-5数组相乘的工作项输出我们的任务就是将问题拆分成尽可能小的工作项。OpenCL的编译器和运行时会根据硬件条件对工作项进行最优调度，保证硬件被尽可能高效地利用。 OpenCL调优如你所料，现实世界往往不是这么简单。对OpenCL程序进行调优，通常需要仔细考量可用的资源，并给编译器和运行时一些提示，帮助它们更好地调度工作项。有时为了性能甚至需要限制并行度。不过，过早地进行调优是编程之大忌。大部分情况下，只需要让并行最大化、让工作项最小化，仅在必要的时候才会考虑进行优化。内核 OpenCL的内核主要用于说明每个工作项是如何工作的。下面是数组相乘程序的内核： DataParallelism/MultiplyArrays/multiply_arrays.cl 7.2第一天：GPGPU编程 kernel void multiply_arrays(_global constfloat*inputA, global const float*inputB, globalfloat*output) int i = get_global_id(o); output[i] = inputA[i] * inputB[i]; 171 这个内核接受两个输入数组指针inputA和inputB，和一个输出数组指针output。它调用 get_global_id()来确定当前正在处理哪个工作项，并将inputA和inputB的对应元素相乘的结果写人output的对应元素。要创建一个完整的程序，就需要将这个内核嵌入到主机程序中，步骤如下： 1）创建上下文，内核和命令队列都将运行在这个上下文中；(2)编译内核； (3)创建输人数据的缓存区和输出数据的缓存区； (4)向命令队列中输入一个命令，让每一个工作项都运行一次内核程序；(5)获取结果。 OpenCL官方标准定义了C绑定（binding）和C++绑定。然而，大部分主流语言都提供了非官方的绑定，所以我们可以用自已喜欢的语言来编写主机程序。由于OpenCL官方标准使用了C语言，而且C语言能最好地描述底层的运行原理，因此我们一开始先选择C语言，第三天再学习用Java 编写主机程序。接下来的几节将会完成一个完整的OpenCL主机程序。为了在代码中更清楚地表达出底层的数据结构，我们将写一些奔放的不带错误处理的代码一一不过别担心，稍后会对这些代码进行修正。你还会发现在函数参数中使用了多个NULL一一同样别担心，在理解了整体结构后，我们会回头仔细学习这些API。创建上下文 OpenCL上下文表示了OpenCL内核运行的环境。要创建上下文，需要识别所使用的平台，以及平台上将运行内核的设备（稍后会详细讨论平台和设备）： DataParallelism/MultiplyArrays/multiply_arrays.c cl_platform_id platform; ciGetPlatformIDs(l,&platform，NULL); cl_device_id device; ciGetDeviceIDs(platform，CL_DEVICE_TYPE_GPU,1,&device,NULL); cl_context context = clCreateContext(NULL, 1, &device, NULL, NULL, NULL); 这段代码定义了一个简单的上下文，其仅包含一个GPU。首先调用clGetPlatformIDs（）来识别平台，然后将CLDEVICETYPEGPU传给clGetDeviceIDs（）来获取GPU的ID，最后将此ID 172 第7章·数据并行传给clCreateContext（）来创建上下文。创建命令队列已经创建了一个上下文，现在可以用它创建命令队列了： DataParallelism/MultiplyArrays/multiply_arrays.c cl command queue queue = clCreateCommandQueue(context, device, o,NULL); clCreateCommandQueue（)接受一个上下文和一个设备ID，并返回一个命令队列，命令将通过这个队列发送给该设备，编译内核接下来要将内核编译成可以在设备上运行的代码： DataParallelism/MultiplyArrays/multiply_arrays.c char* source=read_source("multiply_arrays.cl"); cl_program program =clCreateProgramwithSource(context,1, (const char**)&source, NULL, NULL); free(source); ciBuildProgram(program,o,NULL,NULL,NULL,NULL); cl_kernel kernel = clCreateKernei(program,"multiply_arrays",NULL); 这段代码首先将multiply_arrays.c中的内核源码读到一个字符串中（在本书配套代码中可以看到readsource（）的源码），然后将该字符串传给clCreateProgramWithSource（），之后使用clBuildProgram（）进行构建，最后使用clCreateKernel（）创建一个内核。创建缓存区内核使用的是缓存区中的数据，我们先来创建缓存区： DataParallelism/MultiplyArrays/multiply_arrays.c#define NUM ELEMENTS 1024 cl fIoat a[NUM ELEMENTS], b[NUM ELEMENTS]; random_fill(a,NUM_ELEMENTS); random_fill(b, NUM ELEMENTS); cl mem inputA= clCreateBuffer(context, CL MEM READ ONLY I CL MEM CoPY HOST PTR, sizeof(cl_float)*NUMELEMENTS,a,NULL); cl_mem inputB= clCreateBuffer(context,CL_MEM_READ_ONLYICL_MEM_COPY HOST_PTR, sizeof(cl_float)*NUM_ELEMENTS,b,NULL); cl_mem output = clCreateBuffer(context, CL_MEM_WRITE ONLY sizeof(cl_float) * NUM_ELEMENTS, NULL,NULL); 这段代码创建了两个数组a和b，并调用random_fill()向两个数组中灌入随机数： DataParallelism/MultiplyArrays/multiply_arrays.c void random fiil(cl float arrayll, size_t size) { for (int i =o; i< size; ++i) array[i] = (cl_float)rand() / RAND MAX; 7.2第一天：·GPGPU编程 173 从内核的角度来看，两个输人缓存区inputA和inputB都是只读的（CLMEMREADONLY）并从对应的数组中复制数据作为初始值（CLMEMCOPYHOSTPTR）。输出缓存区output是只写的（CLMEMWRITEONLY）执行工作项终于可以执行工作项来进行数组相乘了： DataParallelism/MultiplyArrays/multiply_arrays.c clSetKernelArg(kernel,o，sizeof(cl_mem)，&inputA); clSetKernelArg(kernel，1,sizeof(clmem)，&inputB); clSetKernelArg(kernet,2，sizeof(cl_mem)，output); size_t work_units=NUM_ELEMENTS; clEnqueueNDRangeKernel(queue,kernel,1,NULL,&work_units,NULL,o,NULL,NULL); 这段代码首先调用ciSetKernelArg（）来设置内核参数，然后调用clEnqueueNDRange Kernel（），将N维空间（NDRange）的工作项传给命令队列。本例中N=l（clEngueueND RangeKernel（）的第三个参数一稍后会看到N>1的例子），工作项的个数是1024。获取结果当内核运行结束，就可以获取结果了： DataParallelism/MultiplyArrays/multiply_arrays.c cl float results[NUM ELEMENTS]; ctEnqueueReadBuffer(queue,output,CL_TRUE,o,sizeof(cl_float)*NUMELEMENTS results,o,NULL,NULL); 这段代码创建了result数组，并调用cLEnqueueReadBuffer（）将output缓存区的内容复制到该数组中。清理主机程序最后的工作是清理现场： DataParallelism/MultiplyArrays/multiply_arrays.c clReleaseMemObject(inputA); clReleaseMemObject(inputB); clReleaseMemObject(output); clReleaseKernel(kernel); clReleaseProgram(program) clReleaseCommandQueue(queue); clReleaseContext(context); 174 第7章数据并行性能分析我们已经得到了一个内核，现在该来分析一下其性能了。这次需要使用OpenCL性能分析API： DataParallelism/MultiplyArraysProfiled/multiply_arrays.c Line1 cl_event timing_event; sizetwork_units=NUMELEMENTS; clEnqueueNDRangeKernel(queue,kernel,1,NuLL,&work_units, NULL, o, NULL, &timing_event); cl float results[NUM ELEMENTS]; clEnqueueReadBuffer(queueoutput,CLTRUE,o,sizeof(clfloat)*NUMELEMENTs results,o,NULL,NULL); cl_ulong starttime; 1o clGetEventProfilingInfo(timing_event,CL_PROFILING_COMMAND START, sizeof(cl_ulong), &starttime, NULL); cl_ulong endtime; clGetEventProfilingInfo(timing_event,CL_PRoFILING CoMMAND END, sizeof(cl_ulong),&endtime,NULL); 15printf("Elapsed (GPU):%lu nslnln",(unsigned long)(endtime-starttime)); clReleaseEvent(timing_event); 这段代码将事件timing_event传给clEnqueueNDRangeKernel（）（第3行）。当一个命令完成时，就可以调用clGetEventProfilingInfo（）来查看记录在这个事件中的时间信息（第1o行和第13行）。如果将NUM_ELEMENTS设置为100000，我的MacBookPro的GPU会花费43000纳秒。而如果使用简单循环在CPU中进行同样的操作： DataParallelism/MultiplyArraysProfiled/multiply_arrays.c for（inti=o;io;j/=2)f if (ij) scratchli] =min(scratch[i],scratch[i + jl); barrier(CLK LoCAL MEM_FENCE) ; 184 15 第7章数据并行 if (i=o) *result=scratch[o]; 上面的算法分为三个阶段： (1）从全局内存向局部内存（scratch）复制数组（第6行）；（2)进行化简操作（第8~12行）;(3）将结果复制到全局内存中（第14行）。化简操作是按照一个树形顺序进行的，这棵树非常像我们在介绍Clojure的reducer时见过的树（参见3.3节），如图7-7所示。图7-7化简操作的树形顺序每循环一次，有一半的工作项将失去活性一原因是只有i<的工作项才会进行操作（这就是为什么要假设数组的元素个数是2的乘方一一一这样就能一直对数组进行二分而不用担心边界情况）。当只剩下一个活动的工作项时退出循环。每个活动的工作项在每个循环中都会进行一次min（）操作，比较当前元素与另一半数组中的对应元素，并取较小者。当退出循环时，scratch数组的第一项就是化简操作的结果，工作组的第一个工作项负责将这个结果复制到result中。这个内核另一个有趣的地方是其使用了同步屏障（barrier）（第7行、第11行）来同步对局部内存的访问。同步屏障同步屏障（barrier）是一种同步手段，用来协调多个工作项对局部内存的使用。如果工作组中一个工作项执行了barrier（），那么该工作组中其他工作项必须都要执行相同的barrier（），才能从当前节点继续往下执行（这种同步方式也称作rendezvous，即会合）。在进行化简操作时，这样做有两个用途。 7.3第二天：多维空间与工作组 185 口在所有工作项从全局内存向局部内存复制数据的动作全部完成之前，确保任一工作项都不会开始进行化简操作，也确保了所有工作项都完成第n轮循环之前，任一工作项都不会开始第n+1轮循环。口OpenCL只提供了宽松的内存一致性。这类似于2.2节介绍的Java内存模型的内存可见性个工作项对局部内存进行的修改并不保证对另一个工作项可见，除非处于某些同步点，比如同步屏障。所以，在每次循环结束时执行同步屏障，可以保证第n轮循环的结果对第n+1 轮的所有工作项都可见。运行内核运行这个内核的方法与我们之前看到的类似一唯一的区别是如何创建局部缓存区： DataParallelism/FindMinimumOneWorkGroup/findminimum.c CHECK_STATUS(clSetKernelArg(kernel,2,sizeof(cl_float)*NUMVALUES,NULL)); 调用ciSetKernelArg（）时，将argsize设置为缓存区的大小，将argvalue设置为NULL，这样就创建了一个局部缓存区。现在已经可以用一个工作组进行化简操作了。不过工作组的大小是存在限制的（比如，我的 MacbookPro的GPU上不超过1024个元素）。下面再来看看如何使用多个工作组实现并行。使用多个工作组进行化简操作要使用多个工作组进行化简操作，只需要将输入数组进行切分并分别化简，如图7-8所示。图7-8使用多个工作组进行化简操作举例说明，如果每个工作组一次处理64个值，那一个长度为N的数组会被化简成一个长度为 N/64的数组。这个化简后的数组会再次进行化简，直到仅剩下一个值。要做到这一点，就需要对内核做一些修改，这样才能处理工作组（工作组代表问题的一个部分）。为此，OpenCL会用局部ID识别工作项，这个ID是工作项在对应工作组中的ID，如图7-9所示。 186 第7章数据并行全局IDO 工作组IDO 工作组IDI 局部大小一局部IDO 全局大小工作组ID2 图7-9 工作组中的局部ID 下面这个内核使用了局部ID： DataParallelism/FindMinimumMuitipleWorkGroups/find_minimum.cl kernel void find minimum(_global const float* values, global float* results, local float* scratch) { int i = get_local_id(o); int n = get_local_size(o); scratch[i] = values[get_global_id(o)]; barrier(CLK LOCAL MEM FENCE); for(intj=n/2;j>o;j/=2) if(i devices = platform.getDevices(CL DEVICE_TYPE_GPU); CLContext context = CLContext.create(platform, devices, null, drawable, nulu); CLCommandQueue queue= clCreateCommandQueue(context,devices.get(o),o,nult); CLProgramprogram clCreateProgramwithSource(context,loadSource("zoom.cl"),null); Util.checkcLError(clBuildProgram(program, devices.get(o),"",null)); CLKernel kernel = ciCreateKernel(program, "zoom", null); 可以看出，这段代码的方法名和参数都像极了C语言版本的代码。为了填平语言之间的差异比如Java中是没有指针的，还是需要修改少量代码。一般来说，是可以将C语言写成的OpenGL主机程序通过LWJGL翻译成Java版本的。用OpenGL显示网格我们并不打算用过多的篇幅来讨论OpenGL元素。不过确实需要花点时间，来解释本节的例子是如何显示用于表现水波纹的网格的，这样有利于阅读后面的OpenCL代码。 OpenGL的3D场景是由三角形构成的。在本例中，将三角形排列成如图7-10所示的网格。可以用两个部分来描述每个三角形的位置：一个顶点缓存区（vertexbuffer），其是顶点（在 3D空间中的位置）的集合；一个索引缓存区（indexbuffer），其定义了如何用顶点来绘制三角形。 @http://www.lwjgl.org 7.4第三天：OpenCL和OpenGL 6 (0.2.0) 3(0,1,0) o (0, 0,0) 图7-10 (1.2.0) 4 1:10(1, 0, 0) 8 22.0)(2.1,0)(2, 0, 0) 三角形排列成的网格全部在GPU上运行 189 在图7-10中，顶点0的位置是（0,0,0)，顶点1的位置是（1,0,0)，顶点2的位置是（2,0,0)，以此类推。对应的顶点缓存区是[0,0,0,1,0,0,2,0,0,0,1,0,1,1,0，]。对于索引缓存区，第一个三角形使用了顶点0、1、3；第二个三角形使用了顶点1、3、4；第三个使用了顶点1、2、4；以此类推。对应的索引缓存区定义了一个三角形带（triangle strip），其通过三个顶点定义了第一个三角形，之后的每个三角形只需要额外定义一个点即可，如图7-11 所示。图7-11三角形带本书配套代码中定义了一个Mesh类，用来生成顶点缓存区和索引缓存区的初始值。下面的代码使用这个类构造了一个64×64的网格，其x轴和y轴的范围都是从-1.0到1.0： DataParallism/Zoom/src/main/java/com/paulbutcher/Zoomjava Meshmesh=newMesh(2.0f,2.0f,64,64); 其z轴的值始终为0一一稍后涉及水波纹动画时会使用非0值。生成的数据会被复制到OpenGL缓存区中： DataParallelism/Zoom/src/main/java/com/paulbutcher/Zoom.java int vertexBuffer =glGenBuffers(); glBindBuffer(GL_ARRAY_BUFFER,vertexBuffer); glBufferData(GL_ARRAY_BUFFER,mesh.vertices,GL_DYNAMIC_DRAW); int indexBuffer =glGenBuffers(); glBindBuffer(GL_ELEMENTARRAY_BUFFER,indexBuffer); glBufferData(GL_ELEMENT_ARRAY_BUFFER,mesh.indices,GL_STATIC_DRAW); 190 第7章数据并行这段代码首先使用glGenBuffers（为每个缓存区分配ID，然后用glBindBuffer（）将其绑定到一个目标上，并用glBufferData（）为其设置初始值。索引缓存区使用了GL_STATICDRAW 标记，意味着它是不变的（静态的）；而顶点缓存区使用了GL_DYNAMIC_DRAW标记，意味着其会在动画帧之间发生改变。在实现水波纹的代码之前，先尝试一个简单的例子一一创建一个简单的内核，让其随着时间而放大网格的面积。从OpenCL内核访问OpenGL缓存区下面这个内核实现了放大动作： DataParallelism/Zoom/src/main/resources/zoom.cl kernel void zoom(_global float* vertices){ unsigned int id = get_global_id(o); vertices[id] *= 1.0l; 其参数是一个顶点缓存区，负责将该缓存区的每个元素都乘以1.01，每次调用该内核会将网格的面积放大1%。为了能将顶点缓存区传给内核，要创建一个OpenCL缓存区来引用这个顶点缓存区： DataParallelism/Zoom/src/main/java/com/paulbutcher/Zoom.java CLMem vertexBufferCL clCreateFromGLBuffer(context,CL MEM READ WRITE,vertexBuffer,nuil); 在负责绘制的主循环代码中可以使用这个缓存区对象： DataParallelism/Zoom/src/main/java/com/paulbutcher/Zoom.java while（!Display.isCloseRequested())( gICLear(GL_COLOR_BUFFER_BITIGL_DEPTHBUFFERBIT); glLoadIdentity(); glTranslatef(o.of,o.of,planeDistance); gIDrawElements(GL_TRIANGLE_STRIP,mesh.indexCount，GL_UNSIGNED_SHORT,o); Display.update(); utiu.checkcLError(clEnqueueAcquireGLobjects(queue,vertexBufferCL,null, null)); kernel.setArg(o,vertexBufferCL); clEnqueueNDRangeKernel(queue,kernel,1,null,workSize,null,null,nuli); Util.checkCLError(clEnqueueReleaseGLobjects(queue,vertexBufferCL,null,nuli)); clFinish(queue); 这段代码在OpenCL内核使用OpenGL缓存区前，首先调用了clEnqueueAcquireGLObjects（）进行申请。然后将这个缓存区作为内核的一个参数，并像以前一样调用了clEnqueueNDR 7.4第三天：OpenCL和OpenGL—一全部在GPU上运行 191 angeKernel（）。最后通过clEnqueueReleaseGLobjects（）来释放缓存区，并调用clFinish（）来等待发往命令队列的命令运行完成。运行这段代码，可以看到一个网格刚开始很小，但快速地被放大，最终成为一个充满整个屏幕的三角形。我们已经完成了一个简单的动画，其将OpenGL和OpenCL结合在一起。接下来可以实现更复杂的内核来仿真水波纹了。仿真水波纹现在要开始仿真水波纹的扩散效果了。每个波纹由两个参数来定义：一个扩散的中心点（网格中的2D点）和一个开始扩散时间。传给内核的参数包括一个指向OpenGL顶点缓存区的指针、一个含有扩散中心点的数组以及一个时间数组（时间单位是毫秒）： DataParallelism/Ripple/src/main/resources/ripple.cl Line1#defineAMPLITUDE0.1 -#defineFREQUENCY 10.0.#defineSPEED0.5 -#define WAVE PACKET 50.0-5#define DECAYRATE2.0 kernelvoidripple(globalfloat*vertices, global float* centers,_global long* times, int num_centers, longnow) 10 unsigned int id = get_global_id(o); unsigned int offset = id * 3; float x = vertices[offset]; float y = vertices[offset + 1]; 15float z =0.0; for (int i = o; i< num_centers; ++i) if (times[i] |= o){ float dx = × - centers[i * 2]; float dy = y - centers[i * 2 + 1]; 20 25 30 子 float d = sqrt(dx* dx + dy* dy); floatelapsed=(nowtimes[ij)/1ooo.o; float r = elapsed * SPEED; float delta = r - d; Z+=AMPLITUDE exp(-DECAYRATE*r*r) exp(-WAVE_PACKET*delta*delta) Cos(FREQUENCY * M_PI_F * delta); 中 vertices[offset + 2] = z; 192 第7章数据并行上面的代码先获取了当前工作项的顶点在x轴和y轴的位置（第13、14行）。循环（第17~30 行）是用于计算在z轴的位置，之后将这个位置写回顶点缓存区（第31行）。在循环中，依次检查了每一个开始扩散时间非0的水波纹。对于每一个这样的水波纹，首先计算当前工作项的顶点到水波纹中心的距离d（第21行），然后计算水波纹扩散的半径r（第23行），以及当前顶点到波纹的距离（第24行），如图7-12所示。水波纹中心当前顶点图7-12水波纹的参量综合r和8计算得到z： z= Ae-Dr -W8° cos(Fπ0) 其中，A、D、W、F是常量，分别表示波纹的幅度、幅度随着扩散的衰减程度、波纹的宽度和波纹的频率。最后还需要修改一下主机程序，创建缓存区： DataParallelism/Ripple/src/main/java/com/paulbutcher/Ripple.java int numCenters = 16; intcurrentCenter=o; centers.put(newfloat[numCenters*2]); centers.flip(); LongBuffer times =BufferUtils.createLongBuffer(numCenters); times.put(newlong[numCentersj); times.flip(); CLMemcentersBuffer ciCreateBuffer(context,CL_MEM_READ_ONLY I CL_MEM_COPY_HOST_PTR,centers,nult); CLMem timesBuffer: clCreateBuffer(context, CL_MEM_READ_ONLY I CL_MEM_CoPY_HOST_PTR, times, nulU); 7.4第三天：OpenCL和OpenGL- 并在点击鼠标时触发新的水波纹： DataParallelism/Ripple/src/main/java/com/paulbutcher/Ripple.java while(Mouse.next())( 一全部在GPU上运行 if(Mouse.getEventButtonState())t float x =((float)Mouse.getEventx()/Display-getwidth())*2-1; floaty=((float)Mouse.getEventY()/Display-getHeight())*2-1; FloatBuffer center = BufferUtils.createFloatBuffer(2); center.put(new float[) (x,y}); center.fiip(); clEnqueuewriteBuffer(queue,centersBuffer,o, currentCenter*2*FLOAT_SIzE,center,null,nuli); LongBuffer time=BufferUtils.createLongBuffer(1); time.put(System.currentTimeMillis()); time.flip(); clEnqueuewriteBuffer(queue,timesBuffer,o, currentCenter * LONG SIZE,time, nuli,nulu); currentCenter =(currentCenter + 1)% numCenters; 编译并运行这段代码，多次点击网格，将会看到如图7-13所示的景象。图7-13水波纹我们成功了一 193 在GPU上完成了一次物理仿真，通过并行计算不仅进行了仿真，还对结果进 194 第7章数据并行行了3D可视化。仿真和可视化需要的数据都在GPU上，不需要多余的数据复制。第三天总结我们完成了第三天的学习，同时也结束了用OpenCL在GPU上进行数据并行的讨论。第三天我们学到了什么在GPU上运行的OpenCL内核可以直接使用在同一个GPU上运行的OpenGL程序的缓存区。我们已经学习了以下内容：口在OpenCL中用clCreateFromGLBuffer（）为一个OpenGL缓存区创建引用；口将OpenGL缓存区作为参数传给内核前，使用clEnqueueAcquireGLobjects（）提出申请；口内核运行结束时，使用clEnqueueReleaseGLobjects（）释放缓存区。第三天自习查找口什么是图像对象（imageobject）？它和OpenCL的缓存区对象有什么区别？当不需要与 OpenGL交互时，图像对象是否适用？口什么是采样器对象（samplerobject）？它适用于解决什么样的问题？口什么是原子函数（atomicfunction）？什么场景下会用原子函数替代同步屏障？实践口在不使用原子函数的情况下，创建一个内核，其接受一个整数缓存区（整数范围为0～32），统计缓存区中每个整数的出现次数并形成统计直方图。如果将整数范围调整为0~1024，方案应如何修改？口使用原子函数创建内核再次解决上面的问题，并比较这两个方案。 7.5复习出于某些原因，在一些关于并行的主流讨论中数据并行常被忽略。不过通过本章的学习，我们已经了解到数据并行是一种非常强力的工具，可以大大改善代码的效率，所有程序员都应该将其收录到自己的工具箱中。优点数据并行非常适用于处理大量数值数据，尤其适合于科学计算、工程计算以及仿真领域，比如流体力学、有限元分析、N体模拟、模拟退火、蚁群优化、神经网络等。 7.5复习 195 GPU不仅是强大的数据并行处理器，在能耗方面也表现出众，比传统的CPU有更优秀的 GFLOPS/watt?指标。世界上最快的超级计算机都广泛使用GPU或专用数据并行协处理器?，其中能耗指标低是一个重要的原因。缺点数据并行编程，更准确地说是GPGPU编程，在其适用的领域内所向披靡。但它并不适用于所有问题领域。值得一提的是，虽然用数据并行可以解决一些非数值问题（比如自然语言处理）但这样做并不容易一一现今的工具集绝大多数关注的是数值处理。对OpenCL内核进行调优是一个技术活，理解了底层架构的细节才能有效地进行调优。如果要写出高效的跨平台的代码，就会变得异常复杂。在解决某些问题时，从主机往设备上复制数据会消耗大量的时间，这会减弱甚至抵消我们从并行计算中获得的收益。其他语言 GPGPU框架还包括CUDA、DirectCompute以及RenderScriptComputation。结语 GPGPU编程是小规模应用数据并行技术的例子一一所谓小规模，指的是程序运行在一台计算机上。下一章我们将学习Lambda架构，使用它可以大规模（跨越多台计算机）应用数据并行技术。 ①GFLOPS是十亿次浮点运算/秒（gigafloating-pointoperationspersecond）的缩写。GFLOPS/watt是用于衡量GPU效能比的单位。一译者注 ②http://www.top500.org/lists/2013/06/ ③http://www.nvidia.com/object/cudahome_new.html ④http://msdn.com/directx http://devetoper.android.com/guide/topics/renderscript/compute.html 第8章 Lambda架构如果需要将一大批货物从国家的一端运往另一端，18轮的大卡车是不二之选。如果仅运送一个快递包裹，大卡车就不太适用了，因此综合性的航运公司也会使用一些小货车进行本地的货物收发。 Lambda架构采用了类似的方法，既使用了可以进行大规模数据批处理的MapReduce技术，也使用了可以快速处理数据并及时反馈的流处理技术，这样的混搭能够为天数据问题提供扩展性、响应性和容错性都很优秀的解决方案。 8.1并行计算搞定大数据近年来，大数据时代的到来为数据处理领域带来了巨大的变化。不同于传统数据处理，大数据领域广泛使用了并行计算一一只要有足够的计算资源就可以处理TB级别的数据。Lambda架构是一种大数据处理技术，源于NathanMarz在BackType和Twitter的经验总结并由此推广开来。与上一章讨论的GPGPU编程类似，Lambda架构也使用了数据并行技术。与GPGPU编程不同， Lambda架构是站在大规模场景的角度来解决问题的，它可以将数据和计算分布到几十台或几百台机器构成的集群上进行。这种技术不但解决了之前因为规模庞大而无法解决的难题，还可以构建出对硬件错误和人为错误进行容错的系统。 Lambda架构包含了很多内容，本章只侧重于其并发和分布式特性（如需要深入学习，推荐阅读Nathan的著作BigData[MW14]）。对于Lambda架构中的诸多组件，本书将侧重介绍两个主要的：批处理层（BatchLayer）和加速层（SpeedLayer），如图8-1所示。批处理层使用MapReduce这类批处理技术从历史数据中对批处理视图进行预计算。这种计算效率很高但延迟也很高，所以又增加了一个加速层，使用流处理等低延迟技术从接收到的新数据中计算实时视图。合并这两种视图，就可以获得最终的计算结果。本书写到现在，Lambda架构是最复杂的专题。它以很多其他技术为基石，其中最重要的就是MapReduce。第一天，我们将只学习MapReduce技术，而忽略其使用的场景。第二天，首先学习传统数据系统中的问题，然后学习在Lambda架构的批处理层如何使用MapReduce技术解决这些问题。第三天，学习流处理技术，以及如何使用这项技术构造加速层，这样就可以一窥Lambda 架构的全貌了。原始数据批处理层加速层 8.2第一天：MapReduce 批处理视图结果实时视图图8-1批处理层和加速层 8.2第一天：MapReduce 197 MapReduce是一个多义的术语。其可以指代一类算法，这类算法分为两个步骤：对一个数据结构首先进行映射（map）操作，然后进行化简（reduce）操作。之前的词频统计的函数式版本正是这样的例子（frequencies就是用reduce函数实现的）。我们在3.3节中讨论过，将算法拆成映射和化简两步的一个好处是易于并行化。 MapReduce还可以指代一类系统一一这类系统使用了上面的算法，将计算过程高效地分布到一个集群上。这类系统不仅可以将数据和数据处理分布到集群的多台计算机上，还可以在一台或多台计算机崩溃时继续正常运转。当MapReduce指代一类系统时，可以说它是Google发明的。除了Google，最流行的MapReduce 框架是Hadoop 今天将结合前面的Wikipedia词频统计的例子，用Hadoop实现一个使用MapReduce的并行版本。Hadoop支持多种编程语言— 1V/小乔爱问：怎么用了这么个名称？一我们选用Java。对于“Lambda架构”这个名称有多种推测。我认为最好的解释来自于Lambda架构之 Nathan Marz Lambda架构源自于它与函数式编程的相似性。从本质上说，Lambda架构是将计算函数 ①http:/research.google.com/archive/mapreduce.html ②http://hadoop.apache.org 198 第8章Lambda架构施加于大量数据的一种通用方法。（原文：Thenameisduetothedeepsimilaritiesbetweenthe architecture and functional programming.At the most fundamental level, the Lambda Architecture is a general way to compute functions on all your data at once) a.http://www.manning-sandbox.com/message.jspa?messagelD=-126599 可行性开发和调试MapReduce程序的起点是在本地运行Hadoop。要在一个集群上运行Hadoop在过去是很痛苦的一一不是每位读者都有足够的闲置计算机来组建一个集群，而且就算能组建一个集群，安装、配置和维护Hadoop集群需要大量的时间和精力。幸运的是，云计算提供了按需使用、计时收费的虚拟机服务，从而大大改善了这一状况。而且许多云计算供应商直接提供了Hadoop集群的管理服务，大大简化了集群的配置和维护。我们将使用AmazonElasticMapReduce（EMR）服务来运行本章的例子の。之后都将在EMR 上进行集群的启动、停止、复制数据等操作，其背后的原理同样适用于所有Hadoop集群。为了运行本章的例子，需要注册一个AmazonAWS账号，并安装AWS和EMR命令行工具? 1小乔爱间：如何搞定Hadoop的版本？ Hadoop一直执着地使用一套混乱的版本号体系，本书撰写时其活跃的版本号就有 0.20.x、1.X、0.22.x、0.23.x、2.0.x、2.1.X和2.2.x。这些版本支持两套API，一套是日的 API（org.apache.hadoop.mapred包），另一套是“新”的API（org.apache.hadoop mapreduce包）。另外，不同的Hadoop发行版会打包Hadoop某个版本和一系列的第三方组件ab.c。本章的例子都会使用“新”的API，并在Amazon3.0.2AMI（Hadoop2.2.0°）上测试通过。 a.http://hortonworks.com b.http://www.cloudera.com c.http://www.mapr.com d.http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-plan-hadoop-version.html ①.http://aws.amazon.com/elasticmapreduce/ ②http://aws.amazon.com/cli/ ③http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-cli-reference.html Hadoop基础 8.2　第一天：MapReduce 199 Hadoop就是用来处理大量数据的工具。如果你的数据不是以吉字节或者更大的单位来度量，那就不适合使用Hadoop。Hadoop的效率源自于它将数据分块后分别交给多台计算机进行处理。我们很容易猜到，一个MapReduce任务由两种主要的组件构成：mapper和reducer。mapper 负责将某种输入格式（通常是文本）映射为许多键值对。reducer负责将这些键值对转换成最终的输出格式（通常也是一系列键值对）。：mapper和reducer可以分布在很多不同的计算机上（它们的数目不必相同），如图8-2所示。输入 Mapper Mapper Mapper Mapper 图8-2Hadoop数据流 Reducer Reducer ® Reducer 输出输人通常由一个或多个大文本文件构成。Hadoop对这些文件进行分片（每一片的大小是可配置的，通常为64MB），并将每个分片发送给一个mapper。mapper将输出一系列键值对，Hadoop 再将这些键值对发送给reducer。个mapper产生的键值对可以发送给多个reducer。键值对的键决定了哪个reducer会接受这个键值对一Hadoop确保具有相同键的键值对（无论是由哪个mapper产生的）都会发送给同一个 reducer处理。这个阶段通常被称为洗牌阶段（shufflephase） ①之前的章节将mapper和reducer分别译为“映射器”和“化简器”，本章中为了和Hadoop的类名对应，保留英文名称。译者注 200 第8章Lambda架构 Hadoop为每个键调用一次reducer，并传人所有与该键对应的值。reducer将这些值合并，再生成最终输出结果（通常是键值对，也可以不是）理论略显枯燥一一之前介绍过Wikipedia词频统计的例子，现在来实现它的Hadoop版本。词频统计的Hadoop版本为了让起步更平稳，我们先将需求简化为：统计几个文本文件中的词频（之后会将需求扩展到统计Wikipediadump的词频）。本例的mapper每次会处理一行文本，将其切分为单词，再用键值对来描述每个单词。键值对的键是单词本身，而值则是常数1。对于每个单词，本例的reducer会对相关的所有键值对的值进行求和，并生成一个结果键值对，该键值对的值是这个单词在整个输人中出现的次数。如图8-3 所示。 onepotato twopotato threepotato four fivepotato sixpotato sevenpotato more Mapper ("one",1)("potato",1)("two",1)("potato") ("one",1)("potato",6)("two",1)("three",1) ("five",1)("potato"1)("six",1) ("potato",1) 图8-3词频统计的Hadoop版本 Map Reduce 我们的Map继承了Hadoop的Mapper类，其接受四个类型参数：输人的键类型、输人的值类型、输出的键类型、输出的值类型： LambdaArchitecture/WordCount/src/main/java/com/paulbutcher/WordCount.java Linei pubuic static class Map extends Mapper{ private final static Intwritable one = new Intwritable(i); public void map(object key,Text value,Context context) 5 throws IoException,InterruptedExceptiont 10 string line = value.tostring(); Iterable words = new Words(line); for (string word: words) context.write(new Text(word),one); 8.2第一天：MapReduce 201 Hadoop表示输入和输出时需要使用自已的数据类型（不能直接使用String或者Integer）。 mapper要处理的是文本数据，而不是键值对，因此不需要输人的键类型（用object替代），而输人的值类型是Text。输出的键类型是Text，值类型是IntWritable。每处理一行输人文本都要调用一次map（）方法，对输人的行进行切分。首先将输人的行转换个单词生成相应的键值对，其键是单词本身，其值是常数1（第10行）。 Reducer 我们的Reduce继承了Hadoop的Reducer类，与Mapper类似，其参数也描述了输入和输出的键值类型（本例中键类型都是Text，值类型都是Intwritable）： LambdaArchitecture/WordCount/src/main/java/com/paulbutcher/WordCountjava public static class Reduce extends Reducer { public void reduce(Text key,IterableIntwritable> values, Context context) throws IoException,InterruptedException{ intsum=o; for (Intwritable val: values) sum+=val.get(); context.write(key,new Intwritable(sum)); 对于每个键，都会调用一次reduce（）方法，values是这个键对应的所有值的集合。reduce（）方法对这些值进行求和，并产生描述某个单词出现总数的键值对。现在已经得到了一个mapper和一个reducer，剩下的任务就是创建一个driver，这样Hadoop才知道如何让这几个部分运转起来。 Driver 我们的driver是一个Hadoop的Tool，实现了run（)方法： LambdaArchitecture/WordCount/src/main/java/com/paulbutcher/WordCount.java Line1 public class WordCount extends Configured implements Toot f public int run(string[) args) throws Exception f Configuration conf = getConf(); 5 Job job = Job.getInstance(conf,"wordcount"); job.setJarByClass(WordCount.class); 202 10 15 20 了第8章Lambda架构 job.setMapperClass(Map.class); job.setReducerClass(Reduce.class); job.setoutputKeyclass(Text.class): job.setoutputValueClass(Intwritable.class); FileInputFormat.addInputPath(job,newPath(args[o])); FileoutputFormat.setoutputPath(job,newPath(args[ij)); boolean success = job.waitForCompletion(true); return success ?:l; pubiic static void main(stringl args) throws Exception int res = ToolRunner.run(new Configuration(),new WordCount(), args); System.exit(res); 这段代码主要是公式化地告诉Hadoop我们要做什么。首先，第7行和第8行设置了mapper和 reducer的类，第9行和第10行设置了输出的键类型和值类型。这里不需要设置输入的键类型和值类型，因为默认情况下Hadoop认为我们处理的是文本文件。也不需要分别设置mapper输出的键/ 值类型和reducer输人的键/值类型，因为默认情况下Hadoop认为mapper的输出和reducer的输人具有相同的键/值类型然后，第11行和第12行告知Hadoop如何获得输人数据以及如何输出结果。最后，第13行启动任务并等待任务结束。现在已经完成了一个完整的Hadoop任务，可以输入一些数据运行一下了。在本地运行先来尝试在本地运行Hadoop任务。在本地运行时程序无法并行执行，也无法容错，不过可以用最小代价来验证一下程序是否运行正常，而不需要将程序部署到集群上再进行验证。我们需要一些文本作为输人数据。input文件夹中有两个文本文件，包括即将进行分析的文本： LambdaArchitecture/WordCount/input/file1.txt one potato two potato three potato four LambdaArchitecture/WordCount/input/file2.txt five potato six potato seven potato more 虽然输入数据很短，显然不够吉字节级别，不过足够用来检验代码正确性。要对这两个文本文件进行词频统计，可以用mvnpackage命令进行编译，再调用下面的命令在本地启动 Hadoop实例： $ hadoop jar target/wordcount-1.o-jar-with-dependencies.jar input output 当Hadoop运行完成，就可以看到一个新文件夹output，其包括两个文件一一SuccEss和 8.2第天：MapReduce 203 part-r-00000。_sucCEss是一个空文件，只是告诉我们任务运行成功。part-r-0000o的内容如下： five1 four 1 more1 one1 potato6 seven1 six1 three 1 two 1 我们已经在小数据规模的情况下，在本地验证了任务的正确性，现在需要在真正的集群上运行这个任务，并处理更多的输人。 1小乔爱问：结果一定是排序好的吗？你也许注意到了输出的结果是按键的字符序进行排序的。Hadoop在键值对传给reducer 前会对键进行排序，这在一些场景下会有帮助。但需要小心。虽然键值对传给reducer前会对键进行排序，但稍后将学习到，默认情况下reducer之间是没有顺序的。partitioner组件可以用于控制这一行为，但本书不再详述。在AmazonEMR上运行要在AmazonElasticMapReduce上运行一个Hadoop任务的步骤比较复杂。本书不会深入讨论 EMR，而仅介绍一些必要的细节。输入和输出 EMR默认都是对AmazonS3进行输人和输出。包含代码的JAR包以及日志文件也会存储在 S3上。首先，创建一个包含若干文本文件的S3bucket。由于Wikipediadump是XML文件而不是文本文件，所以不太适用。本章的配套代码中有一个项目ExtractwikiText，可以从Wikipediadump 中提取需要的文本。然后，将这些文本上传到S3bucket中。代码编译生成的JAR包需要上传到另一个S3bucket中。 ①http://aws.amazon.com/s3/ 204 第8章Lambda架构向S3上传大文件如果在上传大文件时，你的宽带像我的一样不够“宽”，可以考虑创建一个临时的Amazon EC2实例，利用这个实例下载Wikipediadump、提取文本并将文本上传到S3上。毫无疑问， EC2和S3之间有足够的带宽创建一个集群创建EMR的集群有许多方法一一本书使用的是命令行工具elastic-mapreduce： $ elastic-mapreduce --create --name wordcount --num-instances ll ↓--master-instance-type ml.large --slave-instance-type ml.large\--ami-version 3.o.2-jar s3://pb7con-lambda/wordcount.jar1 -args3://pb7con-wikipedia/text--args3://pb7con-wikipedia/counts Createdjobflowj-2LSRGPBSR79ZV 上面的命令创建了一个名为wordcount的集群，其含有11个实例（1主10备），每个实例都是 m1.large类型，并运行在3.0.2AMI上。最后的几个参数分别是JAR包在S3上的位置、输人数据在S3上的位置和输出数据在S3上的位置。监控创建集群时命令行返回了一个jobflow的ID，我们可以用这个ID建立SSH连接，连接到刚才创建的集群： $elastic-mapreduce--jobflowj-2LSRGPBSR79ZV-ssh 现在已经处于主实例上的命令行中，通过查看日志文件可以对任务的进度进行监控： $tait-f/mnt/var/log/hadoop/steps/i/syslog INFo org.apache.hadoop.mapreduce.Job (main):map 0% reduce 0% INFo org.apache.hadoop.mapreduce.Job (main):map 1%reduce 0% INFo org.apache.hadoop.mapreduce.Job (main):map 2% reduce 0% oooo INFo org.apache.hadoop.mapreduce.Job(main):map 4%reduce0% 检查结果在我的测试中，对Wikipedia进行词频统计需要1小时多一点。运行完成后，可以在相应的S3 bucket中看到很多文件： part-r-ooooo part-r-00001 part-r-00002 ①http://aws.amazon.com/ec2/instance-types/ part-r-00028 8.2　第一天：MapReduce 205 这些文件作为一个整体包含了所有结果。在每个结果分块中，结果是排序的，但整体上不是排序的（参见“小乔爱问：结果一定是排序好的吗？”）。现在已经可以统计文本文件中的词频了，不过最好能直接统计Wikipediadump的词频。下面来看看怎么做。处理XML XML文件其实只是对结构有要求的文本文件，所以我们很容易想到用处理文本文件的方式来处理XML文件。但这是行不通的，原因是Hadoop默认根据换行符对文件进行分片，而这可能会错误地切分XML标签。虽然Hadoop默认没有提供针对XML的分片器，但利用另一个Apache项目Mahout提供的 XmlInputFormat可以达到目的。为了使用XmlInputFormat，需要对driver进行一些修改： LambdaArchitecture/WordCountXmi/src/main/java/com/paulbutcher/WordCount.java Lineipubuic int run(stringll args)throws Exception Configuration conf = getConf(); conf.set("xmlinput.start"，""); Job job =Job.getInstance(conf,"wordcount"); job.setJarByClass(WordCount.class); job.setInputFormatclass(XmlInputFormat.class); job.setMapperClass(Map.class); 10 15 job.setCombinerClass(Reduce.class); job.setReducerClass(Reduce.class); job.setoutputKeyclass(Text.class); job.setoutputValueClass(Intwritable.class); FileInputFormat.addInputPath(job,new Path(args[o])); FileoutputFormat.setoutputPath(job,newPath(args[ij)); boolean success = job.waitForCompletion(true); return success ? : 1; 在这段代码中，使用setInputFormatclass（）（第8行）将XmlInputFormat设置为分片器并且配置xmlinput.start和xmlinput.end（第3行和第4行）来告诉分片器我们关注的是哪个标签。仔细查看xmlinput.start的值，你可能会觉得有点奇怪一一这个值为标签中可以设置属性，所以不能设置xmlinput.start为，而需要设置成 (.*)$"，Pattern.DoTALL); pubiic void map(object key,Text value,Context context) throws IoException, InterruptedException string text=value.tostring(); Matchermatcher=textPattern.matcher(text); if(matcher.find()){ Iterable words =newWords(matcher.group(i)); for (String word: words) context.write(new Text(word),one); 每个分片由匹配xmlinput，start和xmlinput，end标签之间的文本（包含被匹配的标签）构成。在进行统计之前，这段代码还用了一点正则表达式的技巧来去除标签（防止 text这个词的计数不准)。你也许已经注意到driver中使用了setCombinerClass（）（第10行）来设置combiner。combiner 是一种优化手段，使键值对可以在发往reducer前进行合并（如图8-4所示）。我进行了一下测试，程序的运行时间从1个多小时下降到45分钟。 ("one") onepotato twopotato threepotato four fivepotato sixpotato sevenpotato more ("potato",1)("two",1)("potato",1) ("five",n)("potato",) C"'six",1)("potato",) ("one",)("potato"3)("two",1)("three",1) ("one",1)("potato",6)("two",1)("three",1) ("five",("potato"3)("six",) ("seven",1) 图8-4使用combiner Map Combine Reduce 8.2第一天：MapReduce 207 在我们的场景中，reducer起的作用和combiner一样，但在其他场景中可能就需要单独的 combiner。当设置了一个combiner时，Hadoop并不能保证一定会使用它，所以必须确定我们的算法不依赖于是否调用combiner，也不依赖于调用了多少次combiner。小乔爱间 Hadoop只有速度优势吗？一个通常的误解是：Hadoop的优势只有速度提升比起使用一台计算机，Hadoop可以在多台计算机上更快地处理海量的数据，这的确是个诱人的优势。但它还有其他优势。口当涉及数百台计算机构成的集群时，系统崩溃不再是一个“极少发生的风险”，而是一种“很有可能发生的必然”。如果一台计算机的崩溃就会引发整个系统崩溃，那么这个系统基本上没有实用价值。因此，Hadoop天生就具有处理错误和从错误中恢复的能力。口与上一条相关，我们不仅要考虑将节点崩溃时正在处理的任务重新执行，还需要考虑当存储发生故障时如何保证数据不丢失。Hadoop默认使用Hadoop分布式文件系统（HDFS），这个有容错能力的分布式文件系统可以在多个节点之间允余数据。口涉及吉字节级别以上的数据时，就不能将所有中间数据或结果全部存放在内存中。 Hadoop在处理过程中将键值对存储在HDFS中，这样就可以不受内存限制，完成数据量非常大的任务。综上所述，这些优点都是革命性的。本书只在本章中使用了完整的Wikipediadump作为词频统计的输入数据，这并不是巧合一MapReduce是本书介绍的唯一能处理这个量级数据的技术。第一天总结第一天的学习结束了。第二天我们将学习如何用Hadoop实现Lambda架构的批处理层。第一天我们学到了什么将一个问题拆分成一个映射操作和一个化简操作，使其更容易被并行化。MapReduce，在本章中使用的这个术语特指一个使用多台计算机的、由映射操作和化简操作构成的、高效且容错的分布式系统。Hadoop就是一个MapReduce系统，其可以做到：口将输人分配给多个mapper，每个mapper都会产生一些键值对；口这些键值对会被发送给reducer，产生最终的输出（通常也是一系列键值对）；口每个reducer对应的键是不同的，因此具有相同键的键值对都会发送给同一个reducer进行处理。 8 208 第8章Lambda架构第一天自习查找口阅读HadoopstreamingAPI的文档，通过Hadoopstreaming可以使用其他语言创建 MapReduce任务，比如Ruby、Python或Perl。口阅读HadooppipesAPI的文档，通过Hadooppipes可以用C++创建MapReduce任务。口有很多基于HadoopJavaAPI的库，利用它们可以很容易地创建复杂的MapReduce任务。比如Cascading、Cascalog和Scalding。实践口在词频统计程序运行时，尝试于掉集群中的一台计算机（不要干掉主节点一一Hadoop不能处理主节点的崩溃。检查整个过程中的日志，看看Hadoop如何重试故障节点上的任务。检查最终结果，其正确性不应受到故障的影响。口现在的词频统计程序能很好地完成本职工作，但如果想知道“Wikipedia最常用的100个词是什么？”，就需要改进一下程序。利用二级排序（SecondarySort）可以获取全局排序的结果（网络上有许多文章介绍如何实现。口Topten模式是解决“Wikipedia最常用的词”这个问题的另一种方法。利用这个模式尝试解决一下。口有些问题无法用单个MapReduce任务来解决一一经常需要串联多个任务，前一个任务的输出是后一个任务的输人。以PageRank算法为例，创建一个Hadoop程序来计算每个Wikipedia 页面的pagerank。多少个选代后结果才能达到稳定？ 8.3第二天：批处理层昨天学习了如何用Hadoop在一个集群中进行并行计算。MapReduce适用于解决各种各样的问题，今天我们将学习在Lambda架构中如何使用MapReduce。不过，在正式学习之前先来了解一下Lambda架构要解决的主要问题一一传统数据系统有什么缺陷？传统数据系统的缺陷数据系统不是一个新概念一一从计算机发明之初，数据库就一直负责存储和处理数据。传统数据库适用于一台计算机，但随着处理的数据量越来越大，数据库就必须使用多台计算机。扩展性利用某些技术（比如复制、分片等）可以将传统数据库扩展到多台计算机上，但随着计算机数量和查询数量的增加，应用这种方案会变得越来越困难。超过一定程度，增加计算机资源将无法继续改善性能。维护成本 8.3第二天：批处理层 209 维护一个跨多台计算机的数据库的成本是比较高的。如果要求维护时不能停机，那么维护将变得更加困难一一比如对数据库进行重新分片。随着数据量和查询数量的增加，容错、备份、确保数据一致性等工作的难度都会呈几何级数增长。复杂度复制和分片通常要求应用层面提供一些支持一应用需要知道将查询发给哪一台计算机，以及应该更新哪一个数据分片（每个更新所对应的分片通常不一样，规则也比较复杂）。程序员习惯使用的许多特性（例如对事务的支持）在数据库分片后都无法使用。也就是说程序员必须显式处理失败的事务并进行重试。这些都增加了使用传统数据库的复杂度，也增加了出错的可能。人为错误讨论容错性时很容易被忽略的就是人为错误。许多数据故障不是由于存储故障引起的，而是由于管理员或开发人员的人为错误引起的。如果运气比较好，这类错误可以被快速定位，并通过还原备份来恢复，但不是所有错误都可以轻易解决。设想一下，如果有一个隐藏了几周的数据错误突然引发了大面积的崩溃，我们又该如何修复数据库呢？有时，我们可以分析错误的影响范围，并写一个临时的脚本来修复数据库。有时，我们可以通过重放数据库日志（假设数据库日志记录了所有必要的信息）来回滚这个错误。有时，我们只能承认运气不佳。每次都依赖运气可不是一个好的长久之计。报表与分析传统数据库擅长于运营支持，即处理日常的业务数据。如果要处理历史数据，比如生成报表或进行数据分析，传统数据库的效率就比较低了。典型的解决方案是在独立的数据仓库中用另一种格式来维护历史数据。数据从业务数据库向数据仓库的迁移过程就是著名的萃取（extract）、转置（transform）、加载（load）（简称ETL）。这种方案不仅复杂，而且需要准确预测将来我们需要什么信息。有时会碰到这种情况：由于缺乏必要的信息或者信息格式不对，无法生成所需报表或进行某些分析。现在学习Lambda架构如何解决这些问题。Lambda架构不仅能处理现代应用中的大量数据，而且其使用也比较简单，可以从技术性故障和人为故障中恢复，并维护完整的历史数据，这样就可以在未来生成任何想要的报表，进行任何想要的分析。永恒的真相我们可以将信息分为两类一一原始数据及（源于原始数据的）衍生信息。 8 210 第8章Lambda架构以Wikipedia的页面为例，Wikipedia的页面是被持续更新的，也就是说今天看到的某个页面和昨天看到的同一个页面的内容可能是不同的。但是在Wikipedia的结构中，页面并不是原始数据一一个页面是由许多贡献者的若干次编辑记录构成的。这些编辑记录才是原始数据，而页面是其衍生信息。另外，虽然页面每天都在变，但编辑记录是不变的。一旦贡献者进行了一次编辑，这个编辑记录就不会改变了。后续的编辑记录可能影响或回滚本条编辑产生的效果，也会影响到页面的内容，但编辑记录本身是不变的。在任何数据系统中信息都可以这样分类。银行账户的余额是衍生信息，而账户的收入和支出是原始数据；Facebook的friendgraph是衍生信息，而添加好友和删除好友的事件是原始数据。与 Wikipedia的编辑记录类似，收入记录、支出记录、添加好友事件、删除好友事件都是不变的。原始数据是永恒的真相，也是Lambda架构的基础。下一节我们将学习其如何利用原始数据来解决传统数据系统碰到的问题。 V小乔爱间：原始数据真的都是不变的？乍看上去，有一些原始数据不大可能是永远不变的。比如用户的家庭住址？如果用户搬家了呢？这类数据可以是不变的一我们只需要添加一个时间戳。以前我们的记录是Charlotte livesat22AcaciaAvenue，而添加时间戳后的记录是OnMarch1，1982，Charlottelivedat22 AcaciaAvenue。这样，无论将来发生什么，原始数据仍然是不变的。数据还是原始的好建议大家现在集中注意力。如前所述，不变性和并行计算是天作之合。美好的设想现在来做一个简短的设想。假如有一个无限快的计算机，可以在瞬间处理TB级别的数据。那么只需要保存原始数据而不需要保存衍生信息，因为在需要的时候可以由原始数据推导出衍生信息。在这种情况下，由于数据是不变的，存储数据的成本大幅下降，就大大降低了传统数据库系统的复杂度。存储介质只需要让我们附加新的数据即可。由于数据被存储后就不可变了，那就不再需要那些精密的锁机制和事务机制了。 8.3第二天：批处理层 211 更进一步，当数据不可变时，多个线程可以并行地访问数据，而不用担心相互之间的作用。我们可以对数据进行复制，再对副本进行操作，而不用担心数据过期，所以在集群中分布地处理数据就变得非常容易。小乔爱间：删除数据该怎么处理？有些情况下，我们有足够的理由删除原始数据。原因可能是数据已经不再使用了，也可能是审计或安全的因素（比如，数据保护法规可能要求数据存在一段时间后不再继续保存）。这并不意味着我们之前说错了。尽管可以选择遗忘那些要被删除的原始数据，它们仍然是不变的。当然，设想终归是设想，不过见识了MapReduce的威力之后，你会惊访于我们是如此接近理想。 888888 设想（几乎）变为现实如果能够准确预测出未来会对原始数据进行怎样的查询，就可以预计算出一个批处理视图，这个视图包含这些查询将要返回的衍生信息，或者那些可以计算出这些衍生信息的数据。Lambda 架构的批处理层就是用来计算这些批处理视图的批处理视图可以包含衍生信息，比如：假设要用一系列编辑记录来构建Wikipedia的页面批处理视图将只包含从页面的编辑记录中计算得来的页面内容。批处理视图也可以包含可以计算出衍生信息的数据，这类情况会稍微复杂一些，这也是今天的讨论重点。我们将用Hadoop来构造批处理视图，通过批处理视图可以查询某个Wikipedia贡献者在某一段时间内进行了多少次编辑。 Wikipedia贡献者我们理想中的查询应该是这样的：“FredBloggs在2012年6月5日下午3:15到2012年6月7日上午10:45之间进行了多少次编辑？”为了达到这个目的，就需要维护每个编辑记录的编辑时间并进行索引。如果这种查询是必要的，那我们的成本会比较高，不过实际上不需要如此细粒度的查询一一按天来维护数据已经绰绰有余了。所以批处理视图就会按天进行统计，如图8-5所示。如果只需要查询几天的状况，那现在已经满足要求了，但如果要查询几个月的状况，就需要合并许多值（如果需要一年的数据，就需要统计365天的贡献次数）。如果能同时按天和按月维护 212 第8章Lambda架构数据，就可以减少计算工作量，如图8-6所示。 Fred的贡献 2012-02-2615:04:16 2012-02-2616:23:43 2012-02-2618:59:03 2012-02-2712:56:32 2012-02-2817:09:12 2012-02-2818:54:28 2012-03-0212:00:36 2012-03-0510:34:19 Fred的贡献次数 2012-02-26:3 2012-02-27:1 >2012-02-28:2 2012-03-02:1 2012-03-05:1 图8-5按天统计的批处理视图 Fred的贡献 2012-02-2615:04:16 2012-02-2616:23:43 2012-02-2618:59:03 2012-02-2712:56:32 2012-02-28 17:09:12 2012-02-2818:54:28 2012-03-0212:00:36 2012-03-0510:34:19 Fred的贡献次数 2012-02-26:3 2012-02-27:1 2012-02-28:2 2012-02:6 2012-03-02:1 2012-03-05:1 2012-03:2 图8-6按天和按月统计的批处理视图计算一年中某用户的贡献数时，计算次数从365次降到了12次。通过增加或删减以天为单位的数据，就可以处理开始时间或结束时间不是整月的查询时间区段，如图8-7所示。 .... 按月统计的数据查询时间区段按天统计的数据无减图8-7查询某用户在一个时间区段内的贡献数贡献者日志加遗憾的是，我们无法获得Wikipedia贡献者的feed。我们希望feed是如下格式的： 2012-09-01T14:18:13Z 123456789 1234 Fred Bloggs 2012-09-01T14:18:15Z12345679054321JohnDoe 2012-09-01T14:18:16z1234567916789PaulButcher 第一列是时间戳，第二列是贡献记录的标识符，第三列是贡献者的用户ID，第四列是贡献者的用户名。们需要其中的enwiki-latest-stub-meta-history)。 8.3第二天：批处理层 213 本章的配套代码中有一个项目ExtractWikiContributors，其可以将一个dump转化为上述feed格式的日志文件。下一节我们将创建一个Hadoop任务，接受这些日志文件并生成批处理视图需要的数据。计算贡献数这个Hadoop任务仍然包括一个mapper和一个reducer。mapper非常简单，只是解析贡献者日志中的一行，并产生一个键值对，其键是贡献者的用户ID，其值是贡献记录的时间戳： LambdaArchitecture/WikiContributorsBatch/src/main/java/com/paulbutcher/WikipediaContributors.java public static class Map extends Mapper { public void map(object key,Text value,Context context) throws IoException,InterruptedException Contribution contribution =new Contribution(value.tostring()); context.write(new Intwritable(contribution.contributorId), new Longwritable(contribution.timestamp)); 其中大部分工作都由Contribution类完成： LambdaArchitecture/WikiContributorsBatch/src/main/java/com/paulbutcher/Contribution.java Line1 ciassContribution static final Pattern pattern=Pattern.compile("^(["lls]*)(lld*)(lld*)(.*)$"); static final DateTimeFormatter isoFormat =IsoDateTimeFormat.dateTimeNoMillis(); 5 10 15 public long timestamp; public int id; pubiicint contributorId; public String username; public Contribution(string line) ( Matcher matcher = pattern.matcher(line); if(matcher.find()){ timestamp = isoFormat.parseDateTime(matcher.group(1)).getMillis(); id=Integer.parseInt(matcher.group(2)); contributorId = Integer.parseInt(matcher.group(3)); username = matcher.group(4); http://dumps.wikimedia.org/enwiki 8 214 第8章Lambda架构有很多种方法可以解析日志文件的一行一本例使用的是正则表达式（第2行）。如果其匹配，则使用Joda-Time库的ISoDateTimeFormat来解析时间戳，并将时间转换为长整数（第13行），这个长整数是自1970年1月1日到该时间所经过的毫秒数。贡献记录的ID和贡献者的用户ID是整数，这一行剩余的部分是贡献者的用户名。 reducer则会负责更多的工作： Linei pubiic static class Reduce extendsReducerf static DateTimeFormatter dayFormat =IsoDateTimeFormat.yearMonthDay(): static DateTimeFormatter monthFormat = ISoDateTimeFormat.yearMonth(); public void reduce(Intwritable key,Iterable values, Context context)throws IoException,InterruptedException HashMap days = new HashMap(); HashMap months = new HashMap(); for (Longwritable value: values) { 10 DateTime timestamp = new DateTime(value.get()); DateTime day =timestamp.withTimeAtstartofDay(); DateTime month = day.withDayofMonth(1); incrementCount(days,day); 15 20 incrementCount(months,month); for (Entry entry: days.entrySet()) context.write(key,formatEntry(entry,dayFormat)); for (Entry entry:months.entrySet()) context.write(key,formatEntry(entry,monthFormat)); 这段代码首先为每个贡献者建立两个HashMap：days（第8行）和months（第9行）。然后遍历与这个贡献者相关的时间戳（values是时间戳列表），并用Joda-Time库的辅助方法 withTimeAtStartofDay（）和withDayofMonth（）将时间戳转化为当天的午夜时间和当月第一天的午夜时间（分别是第12行和第13行）。接下来可以用一个简单的辅助方法对days和months的相关元素进行递增： LambdaArchitecture/WikiContributorsBatch/src/main/java/com/paulbutcher/WikipediaContributors.java private void incrementCount(HashMap counts, DateTime key){ Integer currentCount = counts.get(key); if (currentCount == null) counts.put(key,1); else counts.put(key,currentCount + 1); ①http://www.joda.org/joda-time/ 8.3第二天：批处理层 215 最后当两个HashMap构建完成，遍历这两个map就可以生成（至少有一条贡献记录的贡献者）每天和每月的贡献数（第17到20行）。这里有一点需要说明，Hadoop任务的输出是键值对的集合，但本例中需要输出三个值一一贡献者的用户ID、日期（某月或某天）和一个统计值。可以通过定义一个复合值来达到自的，键值对的键是贡献者的用户ID，而值是日期和统计值构成的复合值。不过由于本例非常简单，可以简单地用一个字符串作为值，这个字符串是通过formatEntry（）定义的： LambdaArchitecture/WikiContributorsBatch/src/main/java/com/paulbutcher/WikipediaContributors.java privateText formatEntry(Entry entry DateTimeFormatter formatter) return newText(formatter.print(entry.getKey())+"/t"+entry.getValue()) 下面是这个任务的一部分输出： 4632001-11-241 463 2002-02-14 1 463 2001-11-26 6 4632001-10-011 4632002-021 4632001-101 4632001-117 这就是我们想要的结果，但输出是一堆文本文件，不是很方便。下一节我们将学习服务层，其可以对批处理层的输出进行索引和合并。小乔爱问：是否可以增量地生成批处理视图？到目前为止我们每次都是重新生成整个批处理视图。这是可行的，但也做了一些不必要的工作一为什么不用上次更新后的新数据增量地更新批处理视图呢？没有什么能阻止我们这么做，而且这是一个非常有效的优化手段。不过需要提醒的是，我们不能严重依赖于增量更新Lambda架构的威力大部分来自于我们可以在必要时进行重建。所以只要值得优化就可以去实现一个增量算法，不过增量算法永远不能代替重建视图。完成拼图批处理层不能单独构成端到端的应用。所以还需要完成Lambda框架的另一部分一一服务层。服务层我们需要对生成的批处理视图进行索引，这样就可以对索引进行查询了。另外，还需要一个 8 216 第8章Lambda架构地方来存放程序逻辑（说明一个查询该如何合并批处理视图的逻辑）。这就是服务层的任务，如图8-8所示。批处理视图批处理视图园 0 批处理视图数据库查询 Web服务器结果图8-8批处理视图和服务层由于服务层与本书主题关联度不大，对服务层的实现还是留作家庭作业。在此只介绍其中的一部分数据库。虽然我们可以利用传统数据库来构建服务层，不过其访问数据库的模式与传统应用不同。服务层不需要进行随机写一一只需要在更新批处理视图时批量更新数据库即可。有一类数据库为了这种访问模式而进行了优化，其中最有名的是ElephantDB和Voldemort? 涅檗至此，利用批处理层和服务层，我们得到了一个数据系统，可以用于解决今天一开始提出的问题，如图8-9所示。批处理层会不断循环运行，从原始数据重新生成批处理视图。每一个批处理完成时，服务层都会更新数据库。由于只处理不可变的原始数据，批处理层可以轻松地被并行化。原始数据可以分布到一个多机集群，在可接受的时间内就可以处理TB级别的数据。原始数据的不变性也使得系统可以承受住技术性故障和人为故障。一方面，原始数据更容易进行备份；另一方面，如果存在bug，最坏的情况就是批处理视图是暂时错误的- @https://github.com/nathanmarz/elephantdb ②http://www.project-voldemort.com/voldemort/ 一只需要修复该bug并重新计算批处理视图即可。原始数据批处理层 8.3第二天：批处理层批处理视图批处理视图服务层 . 批处理视图图8-9数据系统 217 而且，由于保存了所有原始数据，就可以在将来生成任何想要的报表或进行任何分析。不过存在着一个严重的问题一一延迟。如果批处理层需要一个小时的运行时间，那批处理视图就比最新的数据至少延迟1小时。明天我们会学习加速层，来解决这个问题。第二天总结第二天的学习结束了。第三天我们将学习加速层，并完成整个Lambda架构。第二天我们学到了什么信息可以分为原始数据和衍生信息。原始数据是永恒的真相，而且是不变的。基于这个特性，利用Lambda架构的批处理层，可以创建具有以下特性的系统：口高度并行化，可以处理TB级别的数据；口简单，容易创建且不易出错；口对技术性故障和人为故障进行容错；口支持对日常数据的操作，也支持对历史数据生成报表和进行分析。批处理层最大的缺点在于其有延迟，Lambda架构利用加速层来解决这一问题。第二天自习查找口本章中介绍的方法并不是利用Hadoop建立数据系统的唯一方法一一其他的方法有HBase、 218 第8章Lambda架构 Pig和Hive。这三种方法更类似于传统数据系统。选择其中一种，与Lambda架构的批处理层进行比较。每种方法分别适合什么场景？实践口创建一个服务层，来完善今天所学习的系统。这个服务层能够接受批处理层的输出，保存到数据库中，并可以查询一段时间内某用户的贡献数。可以使用传统数据库或 ElephantDB来建立服务层。口扩展上面的例子，增量生成批处理视图一一为了达到目的，Hadoop集群需要访问服务层的数据库。这个方案效率如何？花费的代价是否值得？增量生成批处理视图适用于何种应用？不适用于何种应用？第三天：加速层 8.41 在昨天的学习中，我们了解到Lambda架构的批处理层能解决传统数据系统碰到的若干问题但代价是较高的延迟。加速层就是用来解决这个问题的。图8-10展示了加速层与批处理层如何协同工作。批处理视图原始数据添加新数据批处理层加速层批处理视图实时视图实时视图图8-10Lambda架构合并有新数据产生时，一方面将其添加到原始数据中，这样批处理层就可以进行处理；另一方面将其传给加速层。加速层会生成实时视图，实时视图会和批处理视图合并来满足对最新数据的查询。 8.4第三天：加速层 219 实时视图仅包含最后一次生成批处理视图后产生的原始数据所对应的衍生信息，当这部分数据被批处理层处理后，该实时视图将被弃用。现在我们用Storm来生成加速层。设计加速层不同的应用对实时性的要求不同一一有一些要求新数据在秒级别可用，有一些要求新数据在毫秒级别可用。无论你的应用有什么性能要求，只使用批处理层很可能无法满足。由于加速层要求使用增量算法，因此比起构建批处理层，构建加速层本质上要更困难。这意味着加速层不能只处理原始数据，也就享受不到原始数据的完美特性了。我们必须重新面对传统数据库的特性：随机写、复杂的锁机制和事务机制等。从好的方面来看，加速层只需要处理一部分数据，就是那部分还未被批处理层处理的数据（通常是几个小时的数据）。一旦批处理层赶上进度，旧的数据就会从加速层移除。同步还是异步？最容易想到的构建加速层的方法就是模仿传统的同步数据库。其实可以将传统数据库看作是 Lambda架构的一种退化特例（不使用批处理层），如图8-11所示。客户端客户端数据库 ·· 客户端图8-11传统数据库在这种模型中，客户端直接和数据库通信，并在数据库进行更新操作时进行阻塞。这种模型非常合理，在某些场景下这是唯一能满足特定需求的方法。不过在另一些场景中，异步架构更合 @http://storm.incubator.apache.org 220 第8章 Lambda架构适一些，如图8-12所示。客户端客户端.· 客户端队列流处理器图8-12传统数据库的异步架构数据库在这种模型中，客户端将更新操作添加到队列中（可以用Kafka或Kestrel?等实现队列），这一步骤是无阻塞的。流处理器将串行地处理这些更新操作并对数据库进行更新。用队列将客户端和数据库进行解耦，会使更新操作之间的交互变得更加复杂。不过，根据应用的特性，如果可以接受异步的方案，也会获得非常显著的好处：口客户端不会阻塞，所以少量的客户端就可以处理大量的数据，从而提高了吞吐量；口业务压力激增会导致客户端或数据库超载，也会导致同步系统超时或丢失一些更新。而异步系统则不同，只需要将未处理的更新操作保持在队列中，在业务压力恢复稳定后可逐渐赶上进度；口稍后我们将了解到：流处理器可以被并行化，也可以在多台计算机上进行分布式计算，既改善了性能又可以容错。出于上述原因，再加上同步的加速层实现起来很是无趣，并且本书应关注于并行和并发，因此本书将不会深人讨论同步方案。在实现异步方案之前，需要先来学习如何让数据过期。如何让数据过期假设批处理层需要两个小时处理数据，那很容易就会认为加速层需要保留这两个小时以内的数据。实际上加速层需要保留两倍的数据，如图8-13所示。假设第N－1次批处理刚刚结束，第N次批处理正要开始。如果每次批处理需要运行两个小时， http://kafka.apache.org ②http://robey.github.io/kestrel/ 8.4第三天：加速层 221 这意味着批处理视图会落后两个小时。因此加速层需要保持这落后的两个小时的数据，还要保持批处理层运行的这两个小时中所有的新数据，总共需要保持四个小时的数据。时间第N-1次批处理第N次批处理当前数据加速层第N次批处理本过期数据批处理层已处理的数据批处理层正在处理的数据批处理层未处理的数据第N+1次当前数据批处理加速层图8-13在加速层中让数据过期当第N次批处理结束时，需要让最早两个小时的数据过期，但仍保存其后两个小时的数据。有多种方法可以达到目的，不过最容易的就是同时维护两个加速层，并交替使用它们，如图8-14 所示。时间加速层A（正在使用）加速层B 加速层B（正在使用）图8-14交替使用加速层当前数据本当前数据加速层A 当一次批处理完成时，批处理视图中的新数据就变得可用，就可以将当前用于处理请求的加速层切换到另一个加速层上。切换后闲置的加速层会清理其数据库，并在新的批处理开始时重新建立新的视图。 8 222 第8章Lambda架构这种做法的好处是，一方面不需要费心识别加速层的数据库中哪些数据需要被过期清理，另一方面由于每次切换后加速层都是从一个空数据库开始运行，因此达到了更好的性能和可靠性。当然为此付出的代价是必须要维护两份加速层的数据并且消耗两份计算资源，不过考虑到加速层仅仅处理总数据量中很小的二部分，因此付出的代价相对不那么大。 Storm系统剩下的时间我们来学习用Storm系统实现异步的加速层。Storm是个很大的话题，本书只能浅尝辑止一如需深人了解请参见Storm文档?。 Hadoop主要负责批处理，Storm主要负责实时处理一一其能方便地使用多台计算机进行分布式计算，以改善性能和容错性。 Spout、Bolt和Topology Storm系统处理的是元组（tuple）的流。Storm的元组类似于之前我们在第5章看到的actor模型的元组，但不同于Elixir的元组，Storm元组的元素是有名字的。元组由spout（出水管）组件创建，并由bolt（螺栓）组件进行处理，bolt也会输出元组。用流将spout和bolt连接在一起，就形成了topology（拓扑结构）。图8-15所示的是一个简单的topology，由一个spout生成元组并由一系列bolt构成的流水线进行处理。 Spout Bolt Bolt 一个简单的topology 图8-15 Bolt topology也可以很复杂一一bolt可以消费多个流，而一个流也可以被多个bolt消费，构成一个有向无环图（或称DAG），如图8-16所示。图8-16 一个复杂的topology http://storm.incubator.apache.org/documentation/Home.html 8.4第三天：加速层 223 不过就算是最简单的那种流水线式的topology，也要比看上去的复杂很多，因为spout和bolt 都是并行化和分布式的。 worker spout和bolt不仅相互之间是并行的，而且其内部也都是并行的一每一个个体内部都是由很多worker实现的。如图8-17所示，这个简单的流水线式topology中，每个spout和bolt内部都有3 个worker。图8-17spout和bolt的worker 如图8-17所示，流水线上每个节点的worker都可以向下游节点中任意一个worker发送元组。在稍后讨论到数据流分发（StreamGrouping）时我们会学习如何控制使用哪一个worker来接收元组。 worker还是分布式的一一如果使用有4个节点的集群，那spout的worker可能运行在节点1、节点2和节点3上，第一个bolt的worker可能运行在节点2和节点4上（其中两个在节点2，一个在节点 4上。 Storm的优美之处在于我们不需要特别关注于分布式一一只需要定义好topology，Storm就会向节点分配好worker，并确保发送的元组可以送达。容错性将一个spout或bolt的多个worker分布在多台计算机上的主要原因是容错性。如果集群中的某一台计算机发生故障，topology可以将元组分发给仍存活的计算机，这样topology就可以继续运行。一如果某一个元组没能完成，Storm会将其依赖的spout元组置 Storm会监视元组之间的依赖一为失败并进行重试。这也就是说Storm默认使用的是“至少会执行一次”的处理策略。应用必须知道这个事实：元组可能会被重试，直到其结果正确。听够了理论，我们来实践一下，为之前的Wikipedia贡献统计程序用Storm实现一个简单的加速层。 224 1/ 第8章Lambda架构小乔爱问如果我的应用不能进行重试呢？ Storm默认的策略是“至少会执行一次”，这一策略适用于大部分应用，但有一些应用需要更强的约束，即“只会执行一次”。 Storm通过TridentAPIa可以支持“只会执行一次的策略，本书将不会介绍相关内容。 a.http://storm.incubator.apache.org/documentation/Trident-tutorial.html 用Storm统计贡献图8-18所示的是一种加速层的topology。读取日志解析日志图8-18加速层的topology 更新数据库首先使用一个spout来读取贡献者的日志，并将其转换成一个元组流。然后由一个bolt来处理元组流，对日志条目进行解析，并输出一个解析后的流。最后再由另一个bolt处理这个流，并对保存实时视图的数据库进行更新。不过出于以下原因，我们会构建一个不太一样的topology：首先，我们并不直接访问Wikipedia 贡献者的日志；其次，我们并不想关心更新数据库的细节（我们关心的是并行和并发）。图8-19 是我们设计的topology。模拟日志解析日志记录贡献图8-19改进后的加速层的topology 记录内存中的实时视图。这个方案不适用于产品环境，但非常适用于学习Storm。模拟贡献日志下面的代码实现了一个spout，它会随机产生日志来模拟feed： 8.4第三天：加速层 225 LambdaArchitecture/WikiContributorsSpeed/src/main/java/com/paulbutcher/RandomContributorSpout.java Line1 public class RandomContributorSpout extends BaseRichspout f private static final Random rand = new Random(); private static final DateTimeFormatter isoFormat = 5 1o 15 20 25 ISoDateTimeFormat.dateTimeNoMillis(); private SpoutoutputCollector collector; private int contributionId = 1oooo; public void open(Map conf, TopologyContext context, SpoutoutputCoulector collector){ this.collector = collector; public void declareOutputFields(OutputFieldsDeclarer declarer) declarer.declare(newFields("line")); pubilic void nextTuple() Utils.sleep(rand.nextInt(1oo)); ++contributionId: string line= isoFormat.print(DateTime,now()) + rand.nextInt(1o0oo)+""+"dummyusername"; collector.emit(new Values(line)); + contributionId + 这段代码创建了一个spout，其继承了BaseRichSpout（第1行）。Storm会在初始化时调用 open（)方法（第10行）：在open方法中只是保存了Spoutoutputcollector的引用，以便之后将输出发给SpoutoutputCollector。Storm在初始化时还会调用declareoutputFields（）方法（第16行），以便了解spout会产生的元组的结构一一本例中，元组只有一个名为line的字段。 nextTuple（）（第20行）承担了大部分工作。这个函数首先会随机睡眠100多毫秒，然后创建一个字符串，它的格式如8.3节的“贡献者日志”部分所述，最后调用collector.emit（)来输出字符串。产生的日志会被传给解析器bolt（将在下一节中介绍）。解析日志解析器bolt接受代表日志行的元组，并进行解析，再输出含有四个字段的元组，每个字段代表了日志行的一部分： LambdaArchitecture/WikiContributorsSpeed/src/main/java/com/paulbutcher/ContributionParser.java Line1class ContributionParser extends BaseBasicBolt ( public void declareoutputFields(OutputFieldsDeclarer declarer) declarer.declare(newFields("timestamp"，"id"，"contributorId","username")); 4 226 6 8 9 10 第8章Lambda架构 public void execute(Tuple tuple,BasicoutputCollector collector){ Contribution contribution = new Contribution(tuple.getstring(o)); contribution.contributorId,contribution.username)); 这段代码创建一个了bolt，其继承了BaseBasicBolt（第1行）。与创建spout时一样，还需要实现declareoutputFields（）方法（第2行），以便让Storm了解到bolt输出元组的结构一一本例中，输出元组包含4个字段，分别是timestamp、id、contributorId和username。这次承担了大部分工作的是execute（）（第5行）。本例与批处理层一样，使用了Contri bution类来解析日志行，再调用contributor.emit（）来输出元组。解析得到的元组会被传给另一个bolt，以记录每个贡献者的贡献数，下一节我们会学习这个bolt。记录贡献数最后一个bolt维护了一个记录着每个贡献者的贡献记录的简单内存数据库（其实是一个map，其键是贡献者ID，其值是贡献时间戳的集合）： LambdaArchitecture/WikiContributorsSpeed/src/main/java/com/paulbutcher/ContributionRecord.java Line1 class ContributionRecord extends BaseBasicBolt f private static final HashMap> timestamps new HashMap>(); public void declareOutputFields(OutputFieldsDeclarer declarer){ public void execute(Tuple tuple, BasicoutputCollector collector) f addTimestamp(tuple.getInteger(2),tuple.getLong(0)); 10 15 中 private void addTimestamp(int contributorId, long timestamp) { if (contributorTimestamps==null)f contributorTimestamps=newHashSet(); timestamps.put(contributorId,contributorTimestamps); contributorTimestamps.add(timestamp); 本例中并不产生任何输出，所以declareoutputFields（）函数是空的（第s行）。execute（）（第7行）方法只是从输人中提取相关信息，并传给addTimestamp（）函数，addTimestamp（）负责向贡献者相应的集合中添加时间戳。现在来创建一个topology，将已有的spout和bolt集成起来。 11/小乔爱间：为什么要记录时间戳的集合？ 8.4第三天：加速层 227 在8.3节中我们看到批处理视图仅记录了每天和每月的贡献记录数。那么在实时视图中为什么要记录完整的时间戳呢？如之前讨论过的，实时视图只需要记录几个小时的数据，所以记录和查询完整的时间戳的代价相对较低。但更重要的原因是：向集合中增加记录的操作是幂等的。之前学习过，Storm默认的策略是“至少会执行一次”，那么元组可能会被重试。所谓幂等操作，就是无论操作执行多少次结果都是一样的，这正可以用于处理元组被重试的情况。构建topology 我们对contributionRecord可能会有些担心一已经知道bolt会包括多个worker，那么如何来保证一个贡献者只会对应一个时间戳集合呢？要解决这个问题就需要先了解如何构建 topology。 Line1publicclassWikiContributorsTopology public static void main(stringll args)throws Exception S 10 15 20 TopologyBuilderbuilder=newTopologyBuilder(); builder.setSpout("contribution spout",new RandomContributorSpout(),4); builder.setBoit("contributionparser",new ContributionParser(),4) shuffleGrouping("contribution_spout"); builder.setBolt("contribution_recorder",new ContributionRecord(),4) fieldsGrouping("contribution_parser",new Fields("contributorId")); Localclustercluster=newLocalcluster(); Config conf =new Config(); cluster.submitTopology("wiki-contributors",conf,builder.createTopology()); Thread.sleep(1oooo); cluster.shutdown(); 首先，这段代码创建一个TopologyBuilder（第5行），并调用setSpout（）（第7行）来添加个spout实例。其第二个参数是一个并行度的参考（hint），这只是个参考而不是强制命令，但 8 228 第8章Lambda架构如果要详细了解如何控制Storm的并行，推荐阅读“WhatMakesaRunningTopology：Worker Processes,ExecutorsandTasks 接下来，这段代码调用setBolt（）（第9行）来添加ContributionParser的实例。最后，这段代码调用shuffleGrouping（），其参数与设置spout时的字符串一样，这样Storm就知道这个bolt 需要从spout中读取输人。这里我们还需要学习数据流分发。数据流分发 Storm的数据流分发策略主要解决了哪一个worker接受哪一个元组的问题。解析器bolt所使用的随机分发（shufflegrouping）策略是最简单的一一只是简单地将元组随机分发给某一个 worker。记录贡献数的bolt使用的是按字段分发（fieldsgrouping）策略（第12行），这个策略保证某些字段（本例中是contributorId字段）的值相同的元组会被分发给同一个worker。回到上一节开始的问题，我们也是通过这个策略来确保一个贡献者只对应一个时间戳集合的。本地集群设置Storm集群并不复杂，但这超出了本书的范围。更悲剧的是，由于这是一门新技术，还没有可以直接利用的现成的Storm集群服务。所以需要创建了一个Localcluster（第17行）在本地运行我们的topology。本例中我们让topology运行了1o秒后调用cluster.shutdown（）来关闭它。然而在产品环境中，当批处理层赶上了进度，已经不再需要当前的实时视图时，就需要用其他方法来关闭topology。第三天总结我们完成了第三天的学习，也完成了对Lambda架构的加速层的讨论。第三天我们学到了什么加速层创建的实时视图包含了最后一次生成批处理视图后产生的数据，这样就完善了 Lambda架构。加速层可以是同步的或异步的一一Storm是一种构建异步加速层的方法。口Storm实时地处理元组流。元组由spout创建、由bolt处理、由topology调度。口spout和bolt都包含多个worker，这些worker并行执行，且分布在集群的多个节点上。 http://storm.incubator.apache.org/documentation/Understanding-the-parallelism-of-a-Storm-topology.html 第三天自习查找 8.5复习 229 口Trident是建立在Storm基础上的高级API。类似于Storm的“至少会执行一次”的默认策略， Trident提供了“只会执行一次”的策略。Trident适用于什么场景？Storm的低级API适用于什么场景？口除了随机分发和按字段分发，Storm还提供了哪些数据流分发策略？实践口创建一个真正的Storm集群，并将今天本地运行的例子部署在上面。口创建一个bolt和一个topology，bolt负责维护每分钟的贡献总数，topology负责将 ContributionParser的输出分发给ContributionRecord和我们创建的bolt。口今天的例子使用了BaseBasicBolt，它会自动地对元组进行确认。请改用BaseRichBolt 你需要显式对元组进行确认。创建一个bolt，如何在确认之前处理多个元组？ 8.5复习 Lambda架构将我们已经学过的一些内容融合在了一起：口原始数据是永恒的真相，这让我们想到Clojure分离标识与状态的做法；口Hadoop并行化解决问题的方法是先将问题切分并映射到一个数据结构上，再进行化简操作。这非常类似于并行函数编程的做法口类似于actor模型，Lambda架构将处理过程分布到集群上，这样既改进了性能，又可以对硬件故障进行容错；口Storm的元组流类似于actor模型和CSP模型的消息机制。优点 Lambda架构主要用于解决大规模数据的问题一一这些问题是传统数据处理架构难以应对的。Lambda架构非常适合于报表和分析一一以前我们会使用数据仓库来进行这类工作。缺点 Lambda架构最大的优点一一擅长处理大规模数据这也正是它的缺点。除非你的数据达到数太字节甚至更多，否则其成本（计算成本和智力成本）将高于收益。替代方案 Lambda架构并没有与MapReduce绑定一一批处理层可以用其他的分布式批处理系统来实现。 230 第8章Lambda架构基于这一点，ApacheSpark就是一个很有意思的方案。Spark是一个集群计算框架，它实现了DAG执行引擎，可以使用很多比MapReduce用起来更自然的算法（尤其是图算法）。它也提供了与流相关的API?，这意味着批处理层和加速层都可以用Spark实现。结语由于包含前几章介绍过的很多技术，Lambda架构很适合用来作为本书压轴的主题。用Lambda，最后一章，我们将重新审视过去7周的内容，以及本书已经涉及的几大主题。@http://spark.apache.org ②http://spark.apache.org/streaming/ 第9章圆满结束恭喜你完成了七周的学习！从由数据并行GPU提供的细粒度并行，到大规模的MapReduce集群，我们讨论的主题涉及方方面面。一路走来，我们不仅学习了如何用并行和并发来挖掘现代多核CPU的潜力，而且学到了许多比传统串行代码更优秀的特性。口我们学习了Elixir、Hadoop和Storm，这几种系统都可以部署在多机集群上进行分布式计算，从而创建出可以对硬件故障进行容错的解决方案。口通过core.async，学习了如何利用并发来解决事件处理时会碰到的“回调困境”。口在函数式编程的章节中，学习了如何让并发方案比等价的串行方案更简洁易读。现在来看看这预示着怎样的未来。 9.1君欲何往二十几年前，我曾预言并行技术和分布式编程将成为主流，如今的现实表明我不是个成功的预言家。尽管如此现在我仍然相信并行和并发预示着编程的未来。未来是“不变”的在我看来，有一个话题散发着耀眼的光芒一一和过去相比，不变性在代码中的应用会越来越广泛。与不变性关系最大的是函数式编程一一在函数式编程中，避免使用可变状态会使得并行和并发更为简单。不过为了获得不变性，不一定非要使用函数式编程。在过去的几周中我们已经学过：口虽然Clojure不是一门纯粹的函数式语言，但其核心数据结构是持久且不变的（参见4.2节的“持久数据结构”部分）。持久数据结构可以将标识与状态分离，这样Clojure就可以支持可变引用，并且避免使用可变状态带来的问题；口虽然Lambda架构的底层代码通常不是函数式代码，不过其核心思想的确是不变性批 9 232 第9章圆满结束处理层规定其原始数据是永恒真实的（不可变的），所以我们可以将数据安全地分布到集群中，对数据进行并行处理，且能对技术故障和人为故障进行容错；口运行在Erlang虚拟机上的Elixir有着卓越性能和可靠性，虽然它不是一门纯粹的函数式语言，但其优异表现的关键是它不适用可变变量；口基于actor模型或CSP模型的应用所发送的消息是不可变的；口在使用线程与锁模型时，不变性也非常有用一一不可变的数据越多，需要使用的锁就越少，我们就越不用担心内存可见性带来的问题。显而易见，虽然我们可能不使用函数式语言，但所涉及的框架和代码越来越多地受到函数式规则的影响。这是个好消息一一不仅让我们更容易地使用并行和并发，也让代码变得更加简洁易懂且可靠。未来是分布式的并行和并发目前的复兴主要是由多核危机引发的。CPU的发展趋势并不是大幅提升单核性能，而是增加CPU的核数。好消息是利用过去几周所学到的知识我们可以挖掘出多核的潜力。但我们还面临着另一个危机一一内存带宽。自前，双核、4核或8核的计算机尚可利用共享内存高效地通信，但如果涉及16核、32核甚至64核呢？如果CPU的核数继续按照这个速度增长，共享内存就会成为瓶颈，分布式内存就成为我们不可不考虑的选择。未来的计算机可能仍然是个小盒子，但从程序员的角度来看，其更像一个计算机集群。我认为，基于消息传递的技术，例如actor模型和CSP模型，随着时间发展会变得愈加重要。你背定猜到了，过去的七周内我们没有穷尽并行和并发的每一种可能。那我们遗漏了些什么呢？ 9.2未尽之路撰写本书时，最艰难的就是对内容进行取舍。下面简要介绍一些我们尚未涉及的技术，以及一些自学的资料。 Fork/Join模型和Work-Stealing算法 Fork/Join是随着Cilk语言流行起来的并行方法，Cilk是C/C++的一个并行变种。不过现在许多语言环境，包括Java?，都实现了Fork/Join。Fork/Join模型非常适用于分治算法，我们在3.3节 ①http://www.cilkplus.org ②http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html 9.2未尽之路 233 的“分而治之”部分学习过分治算法（实际上Clojure的reducer内部就使用了Fork/Join模型）。实现Fork/Join，通常会用到work-stealing算法在线程池中共享任务。work-stealing非常类似于 Clojure中的go块（参见6.2节的“go块”部分）。数据流我们在3.4节中接触过数据流，这个主题值得更深入的讨论。本书之所以未作深人讨论的主要原因是，没有找到一门合适的、通用的数据流语言。较为合适的语言是多重编程范式语言Oz（Mozart编程系统的一部分）。本书不深入讨论并不意味着数据流不重要一一恰恰相反，硬件设计中大量使用了基于数据流的并行技术一一VHDL和Verilog都是数据流语言。反应型编程与数据流密切相关的是反应型编程（reactiveprogramming）。反应型程序可以自动传播变化。反应型程序之所以引人关注，归功于MicrosoftRx（ReactiveExtensions）库和其他的库。反应型编程与之前我们学习的几种技术有相似之处，包括Storm的topology，还有actor模型和 CSP模型这类基于消息传递的技术。函数式反应型编程函数式反应型编程（FunctionalReactiveProgramming，FRP）是反应型编程的一种，通过对时间进行建模来扩展函数式编程。EIm实现了并发版本的FRP，其运行在浏览器中。与 core.async类似，在处理事件时其提供了一种方法来避免“回调困境”。Elm是本系列丛书的下一本书（SevenMoreLanguagesinSevenWeeks[TDMD14]）中将要涉及的编程语言之一。网格计算网格计算是一种松耦合地建立分布式集群的方法。网格的元素通常是异构且地理分布的，甚至加入网格和退出网格都可能是自发的。 ①http://mozart.github.io ②http://en.wikipedia.org/wiki/VHDL ③http://en.wikipedia.org/wiki/Verilog@https://rx.codeplex.com https://github.com/Netflix/RxJava http://elm-lang.org 9 234 第9章圆满结束最著名的网格计算项目是SETI@Home，任何人都可以通过它参与到许多项目的计算中。元组空间元组空间（tuplespace）是分布式联想记忆（distributedassociativememory）的一种形式，可用于实现进程之间的通信。元组空间首次在Linda协作语言中被引人（这恰巧是20世纪90年代初我的博士论文选题），现在也有一些正在开发中的基于元组空间模型的系统③① 9.3 越过山丘我是一个汽车迷，所以每一章开头使用的比喻几乎都与汽车相关。与汽车类似，编程遇到的问题会呈现不同的类型和不同的规模。无论我们处理的问题相当于二辆轻量级定制赛车、一辆量产家用轿车，或者一辆重型卡车，我都可以自信地说，并行和并发都将变得越来越重要。无论你是否会直接使用这些并发模型，我真诚地希望过去七周所学的知识能帮助你更有信心地迎接未来的项目。祝驾驶（线程）安全。 ①http://setiathome.ssl.berkeley.edu ②http:/en.wikipedia.org/wiki/Linda_(coordination_language) http://river.apache.org/ ④https:/github.com/vjoel/tupelo 参考书目 [Arml3] Joe Armstrong. Programming Erlang: Software for a Concurrent World. The Pragmatic Bookshelf,Raleigh,NCandDallas,TX,Second,2013. BrianGoetz.JavaConcurrency in Practice.Addison-Wesley,Reading,MA,2006 [Goe06][HB12] Stuart Halloway and Aaron Bedra. Programming Clojure. The Pragmatic Bookshelf, Raleigh NC and Dallas, TX, Second, 2012. [MD14] Jack Moffitt and Fred Daoud. Seven Web Frameworks in Seven Weeks:Adventures in Better Web Apps.The Pragmatic Bookshelf, Raleigh, NC and Dallas, TX, 2014. [MW14] Nathan Marz and James Warren. Big Data: Principles and Best Practices of Scalable Realtime Data Systems.Manning Publications Co., Greenwich,CT,2o14. [RW12] Eric Redmond and Jim R. Wilson. Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement. The Pragmatic Bookshelf, Raleigh, NC and Dallas, TX, 2012. [Tat10] Bruce A. Tate. Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programm- ing Languages.The Pragmatic Bookshelf, Raleigh, NCand Dallas, TX, 2010. [TDMD14] Bruce A. Tate, Fred Daoud, Jack Moffitt, and Ian Dees. Seven More Languages in Seven Weeks.ThePragmaticBookshelf, Raleigh,NC andDallas,TX,2014. [Tho14] David Thomas. Programming Elixir: Functional |> Concurrent |> Pragmatic|> Fun.The PragmaticBookshelf, Raleigh,NC andDallas,TX,2014. “基于锁和线程的并发模型是目前最常用的一种并发模型，但是并发编程模型不仅仅只有这一种，本书几乎涵盖了目前所有的并发编程模型。了解和熟悉各种并发编程模型，在解决并发问题时会有更多思路。” 方腾飞，并发编程网站长 “当看到这本书的目录时，我就为之一振。它涉及了当今所有的主流并发编程模型（当然也包括Go语言及其实现的CSP模型）。而在品读之后，我更是有一些激动。其中的大部分章节都深入浅出地描述了某一个并发编程模型的概念、特点、机理以及适用领域。加之有大量相应实现语言的示例呈现，更是让这些模型活灵活现、极易理解。另外，各章之间的衔接会使你更容易把这些知识融会贯通。总之，并发编程乃现代编程技能的必备，而这本书则为并发编程的首选佳作。” 郝林（@特价萝卜），《Go并发编程实战》作者 “几十年来，专业的程序员一直在用线程与锁模型来进行并行和并发，但这仅仅是《七周七并发模型》介绍的众多模型之一。当今主流语言都竞相支持不同的并发模型，例如CSP模型、数据并行、函数式编程和Clojure的 unifiedsuccessionmodel。如果你想紧跟时代，我推荐阅读本书。” StuartHalloway，Cognitect联合创始人 “随着计算机拥有越来越多的核，理解并发技术变得愈发重要。本书介绍了为什么函数式编程会与并发有关、如何利用actor模型编写分布式软件、怎样利用GPU实现并行处理以及大数据的相关内容。通过阅读本书，你可以充实自己的知识库，为未来数年做好准备。” JoséValim，Plataformatec联合创始人 “这是个变革的时代，每个程序员都应学会并发编程的思维方式。如果你问我“应当如何适应这个并发的时代”，我会推荐阅读本书，因为我从中受益良多。” AndrewHaley，RedHat公司首席Uava工程师 “随着阿姆达尔定律开始取代摩尔定律的地位，面向并发编程也逐渐开始取代面向对象编程的地位。本书的问世恰逢其时。Paul在书中详尽介绍了最重要的几种并发模型，足以帮助读者选择最适合的并发模型。如果开发与多核相关的软件，我推荐必读本书。” FrancescoCesarini，ErlangSolutions创始人、技术总监 “我与Paul有过多次合作，我确信他是编程语言设计和结构方面的权威。并发是现代软件工程上非常重要但又容易被误读的主题，本书清晰阐述了这个主题。 BenMedlock，SwiftKey联合创始人、CTO The Pragmatic Programmers 图灵社区：iTuring.cn 热线：010)51095186转600 计算机/程序设计分类建议人民邮电出版社网址：www.ptpress.com.cn TURING 来社区领银子 0m ISBN978-7-115-38606-9 8 58606 ISBN978-7-115-38606-9 定价：49.00元