【51CTO精選譯文】前日，Akka 0.6發(fā)布了。Akka是一個(gè)基于Actor的框架，提供Scala API和Java API，目標(biāo)是“通過Actor實(shí)現(xiàn)更簡(jiǎn)單的伸縮性，容錯(cuò)力，并發(fā)以及遠(yuǎn)程操作”。

本篇文章的主題是Actor。對(duì)于不太了解Actor的讀者們，可以先參考一下老趙的這篇《Actor模型的本質(zhì)》。簡(jiǎn)單的說，Actor是一種天生為并行編程而存在的模型，在很多編程語(yǔ)言中都采用了這種模型，比如C#，Erlang以及Scala。本文是Code-o-matic博主Dimitris Andreou針對(duì)Scala的Actor模型展開的思考。

51CTO編輯推薦：Erlang的Actor回顧 順暢的使用C# Actor

有人在Scala郵件列表的討論中建議直接對(duì)比actors和鎖的使用。下文是我的討論，前面部分只是作為一種回應(yīng)，而最后我總結(jié)了不少當(dāng)前對(duì)于actor編程模型的關(guān)注點(diǎn)和問題。

將actors和底層并發(fā)編程（比如鎖）做對(duì)比具有誤導(dǎo)性。它不是這樣一種情況：存在一些actors，它們之后是巨大的空白，然后是一些鎖——然后我們不得不做出一些極端的選擇。兩者之間涉及更多的東西。例如，一臺(tái)虛擬機(jī)中，在阻塞隊(duì)列（或者，不久之后將成為的傳輸隊(duì)列）的頂端實(shí)現(xiàn)消息傳遞是非常煩瑣的。目前已經(jīng)有executor框架，以及fork/join框架來(lái)提供線程池或者細(xì)粒度（fine-grained）的并行（parallelism）機(jī)制。（51CTO編輯推薦閱讀：Java 7的細(xì)顆粒并行化）

我要說的是，actors提供了一種簡(jiǎn)單化的、比直接使用底層工具更簡(jiǎn)潔優(yōu)雅的編程模型。在其內(nèi)核中，典型的actors是一種伴隨阻塞隊(duì)列（郵箱）的運(yùn)行接口，而反應(yīng)程序是事件的監(jiān)聽者。正如Haller/Odersky論文中指出的那樣，actors的優(yōu)勢(shì)在于它們能夠?qū)⒒诰€程和基于事件的模型統(tǒng)計(jì)起來(lái)——人們也可以在相同的架構(gòu)下使用這兩種模型，或者對(duì)它們進(jìn)行組合。這種編程模型目前正處于起步階段，還需要編程人員去探索以找到最佳的使用案例，并充分的理解它。頗為重要的是，你有必要準(zhǔn)備一本“Effective Actors”這種類型的書。Actors編程很容易誤入歧途，尤其是對(duì)于那些試圖進(jìn)行類MPI編程卻被搞得暈頭轉(zhuǎn)向的初學(xué)者而言更是如此。死鎖仍然存在（actors可能會(huì)永久等待一個(gè)不會(huì)到達(dá)的消息），競(jìng)爭(zhēng)條件也可能出現(xiàn)（actors可能在真正的響應(yīng)到達(dá)之前放棄等待），它不會(huì)像常規(guī)并發(fā)編程那樣，其可疑之處不會(huì)奇跡般的消失。（注明：根據(jù)JCiP命名規(guī)則（51CTO編輯注：JCiP即Java Concurrency in Practice，實(shí)用Java并發(fā)），我將最后一種情況歸為競(jìng)爭(zhēng)條件或許是一個(gè)錯(cuò)誤，因?yàn)樗袷且环N數(shù)據(jù)競(jìng)爭(zhēng)）

此外，簡(jiǎn)化編程也必須付出代價(jià)，探討其對(duì)性能的影響變得不再像以前那么容易，至少對(duì)我而言如此。例如：假定scala actors依賴于ForkJoinScheduler(也就是使用fork/join架構(gòu))， 此處源自ForkJoinPool中的javadocs的引用將會(huì)很有意思：

ForkJoinPool在創(chuàng)建時(shí)會(huì)被指定一個(gè)并行等級(jí)（目標(biāo)池的大小），該等級(jí)通過動(dòng)態(tài)添加、掛起、恢復(fù)線程的方法來(lái)維持，即使一些任務(wù)正在等待其它任務(wù)也是如此。然而，在阻塞式IO或者非托管的異步系統(tǒng)中，這種調(diào)整沒有被實(shí)現(xiàn)。

這就產(chǎn)生一些很明顯、但我卻很難告訴你答案的問題：

1. actors使用（阻塞式）IO會(huì)對(duì)性能產(chǎn)生什么影響？（我還沒有看到提供給actors用戶的類似警告）

2. 既然我們根據(jù)javadoc已經(jīng)知道任務(wù)不會(huì)被加入，而receive()的阻塞式系統(tǒng)調(diào)用會(huì)陷入非托管的同步系統(tǒng)中，那么這對(duì)我們而言又意味著什么呢？

#t#因此，簡(jiǎn)單化也似乎意味著以隱藏可能的重大優(yōu)化作為代價(jià)，就像一個(gè)需要阻塞以加入子任務(wù)的線程一樣，在其等待期間繼續(xù)運(yùn)行以及執(zhí)行其它任務(wù)。

我不能確定最終的結(jié)論是什么。若順利的話，3-4年內(nèi)社區(qū)在這一方面的編程經(jīng)驗(yàn)將會(huì)大大增加，我們將了解如何才能更好的使用這種很炫的工具，也將會(huì)知道什么時(shí)候改使用底層的并發(fā)服務(wù)程序。就我個(gè)人而言，截至目前為止，盡管我很希望使用actors，但底層工具的運(yùn)用讓我如魚得水，因?yàn)槲铱梢愿菀追治鑫业拇a的性能特征。很希望有人能夠?qū)懸槐緝?yōu)秀的Scala actors書籍——雖然目前并發(fā)的書也不錯(cuò)，但因?yàn)镾cala還很新，所以這些數(shù)據(jù)關(guān)于actors的往往只有一章。讀者若想了解除基礎(chǔ)知識(shí)之外的東西，這些書籍所涵蓋的內(nèi)容還遠(yuǎn)遠(yuǎn)不夠。

【51CTO.com譯稿，非經(jīng)授權(quán)請(qǐng)勿轉(zhuǎn)載。合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com，且不得修改原文內(nèi)容。】

原文：Thoughts on Actors  作者：Dimitris Andreou