成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Inside Scala：王在祥的Scala學習筆記

作者：王在祥
開發 后端
本文是王在祥先生的Scala學習博文系列。在這個系列中，王在祥先生分篇講述了Scala中的一些有意思的語言特性，如curry，case類，模式匹配等等。

編者注：本系列來自王在祥先生的博客，主要是分篇總結了對于Scala一些語言特性的心得，為了便于與大家分享而在此轉載。這個系列適合對Scala以及函數式語言有一定了解的開發者閱讀。

51CTO編輯推薦：Scala編程語言專題

Inside Scala - 1：Partially applied functions

Partially applied function（不完全應用的函數）是scala中的一種curry機制，本文將通過一個簡單的實例來描述在scala中 partially applied function的內部機制。

 

  1. // Test3.scala  
  2. package test  
  3.  
  4. object Test3 {  
  5.  
  6.   def sum(x:Int, y:Int, z:Int) = x + y + z  
  7.     
  8.   def main(args: Array[String]) {  
  9.     val sum1 = sum _  
  10.     val sum2 = sum(1, _:Int, 3)  
  11.     println(sum1(1,2,3))  
  12.     println(sum2(2))  
  13.     List(1,2,3,4).foreach(println);  
  14.     List(1,2,3,4).foreach(println _)  
  15.   }  
  16.  
  17. }  
  18.  

 

在這個代碼中 sum _ 表示了一個 新的類型為 （Int,Int,Int)=>Int 的函數，實際上，Scala 會生成一個新的匿名函數（是一個函數對象，Function3），這個函數對象的apply方法會調用 sum 這個對象方法（在這里，是方法，而不是一個函數）。
sum2 是一個 Int => Int的函數（對象），這個函數的apply方法會調用 sum 對象方法。
后面的兩行代碼都需要訪問 println， println是在在Predef對象中定義的方法，在scala中，實際上都會生成一個臨時的函數對象，來包裝對 println 方法的調用。如果研究一下scala生成的代碼，那么可以發現，目前生成的代碼中， 對 println, println _生成的代碼是重復的，這也說明，目前，所有的你匿名函數基本上沒有進行重復性檢查。（這可能導致編譯生成的的類更大）。

從這里可以得知，雖然，在語法層面，方法（所有的def出來的東西）與函數看起來是一致的，但實際上，二者在底層有區別，方法仍然是不可以直接定位、傳值的，他不是一個對象。而僅僅是JVM底層可訪問的一個實體。而函數則是虛擬機層面的一個對象。任何從方法到函數的轉換，Scala會自動生成一個匿名的函數對象，來進行相應的轉換。

所以， List(1,2,3,4).foreach(println) 在底層執行時，并不是獲得了一個println的引用（實際上，根本不存在println這個可訪問的對象），而是scala自動產生一個匿名的函數，這個函數會調用println。

當然，將一個函數傳遞時，Scala是不會再做不必要的包裝的，而是直接傳遞這個函數對象了。

#p#

Inside Scala - 2: Curry Functions

Curry，在函數式語言中是很常見的，在scala中，對其有特別的支持。

package test

 

  1. object TestCurry {  
  2.  
  3.   def sum(x:Int)(y:Int)(z:Int) = x + y + z  
  4.  
  5.   def main(args: Array[String]){  
  6.  
  7.     val sum1: (Int => Int => Int) = sum(1)  
  8.     val sum12: Int => Int = sum(1)(2)  
  9.     val sum123 = sum(1)(2)(3)  
  10.     println(sum1(2)(3))  
  11.     println(sum12(3))  
  12.     println(sum123)  
  13.  
  14.   }  
  15.  
  16. }  
  17.  

 

在這個例子中， sum 被設計成為一個curried函數，（多級函數？），研究一個函數的實現是很有意思的：

如果看生成的 sum 函數代碼，那么，它與 如下編寫的
def sum(x:Int, y:Int: z:Int) = x + y + z 是一致的。
而且，如果，你調用sum(1)(2)(3)，實際上，scala也并不會產生3次函數調用，而是一次 sum(1,2,3)

也就是說，如果你沒有進行 sum(1), sum(1)(2)等調用，那么實際上，上述的代碼中根本不會生成額外的函數處理代碼。但是，如果我們需要進行一些常用的curry操作時，scala為我們提供了額外的語法級的便利。

#p#

Inside Scala - 3: How Trait works

Scala中Trait應該是一個非常強大，但又有些復雜的概念，至少與我，我對trait總是有一些不太明了的地方，求人不如求己，對這些疑問還是自己動手探真的比較好。

還是從一個簡單的實例著手。

package test

 

  1. import java.awt.Point  
  2.  
  3. object TestTrait {  
  4.  
  5.   trait Rectangular {  
  6.     def topLeft: Point  
  7.     def bottomRight: Point  
  8.       
  9.     def left = topLeft.x  
  10.     def top = topLeft.y  
  11.     def right = bottomRight.x  
  12.     def bottom = bottomRight.y  
  13.     def width = right - left  
  14.     def height = bottom - top  
  15.   }  
  16.     
  17.   class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular {  
  18.     override def toString = "I am a rectangle" 
  19.   }  
  20.  
  21. }  
  22.  

 

對這段代碼，我想問如下的幾個問題：
Rectangle是如何繼承 Rectangular的行為，如 left, right, width, height的？
Rectangular 對應于Java的接口，那么，相關的實現代碼又是如何保存的？
其實，這兩個問題是相關的。研究這個問題的最直接的辦法莫過于直接分析scalac編譯后的結果。
這個類編譯后包括：
TestTrait.class 這個類
TestTrait$.class 其實就是 object TestTrait這個對象的類。一個object實際上從屬于一個類，scala是對其加后綴$
在這個例子中，TestTrait這個對象實際上并未定義新的屬性和方法，因此，并沒有包含什么內容
TestTrait$Rectangular.class
對應于代碼中的Rectangular這個trait，這實際上是一個接口類。對應的就是這個trait中定義的全部方法。包括topLeft, bottomRight以及后續的實現方法left, width等的接口定義
 

  1. public interface test.TestTrait$Rectangular extends scala.ScalaObject{  
  2.  
  3. public abstract int height();  
  4. public abstract int width();  
  5. public abstract int bottom();  
  6. public abstract int right();  
  7. public abstract int top();  
  8. public abstract int left();  
  9. public abstract java.awt.Point bottomRight();  
  10. public abstract java.awt.Point topLeft();  
  11.  
  12. }  

TestTrait$Rectangular$class.class
這個類實際上是trait邏輯的實現類。由于JVM中，接口是不支持任何的實現代碼的，因此，scala將相關的邏輯代碼編譯在這個類中

 

  1. public abstract class test.TestTrait$Rectangular$class extends java.lang.Object{  
  2.  
  3. public static void $init$(test.TestTrait$Rectangular); // 在這個例子中，沒有trait的初始化相關操作  
  4.   Code:  
  5.    0:   return 
  6.  
  7. public static int height(test.TestTrait$Rectangular);   // 對應于height = bottom - top這個操作的實現  
  8.   Code:  
  9.    0:   aload_0  
  10.    1:   invokeinterface #17,  1; //InterfaceMethod test/TestTrait$Rectangular.bottom:()I  
  11.    6:   aload_0  
  12.    7:   invokeinterface #20,  1; //InterfaceMethod test/TestTrait$Rectangular.top:()I  
  13.    12:  isub  
  14.    13:  ireturn  
  15.  

 

更多的方法并不在此羅列。
首先，這個實現類是抽象的，它不需要被實例化。
所有的trait方法，其實接收一個額外的參數，即 this 對象。對對象的任何的訪問，如bottom等操作，實際上是直接調用對象的相應操作。
所有的trait方法，都是static的。
TestTrait$Rectangle.class
這個就是Rectangle這個類的代碼了。

 

  1. // 首先，實現類以implements的方式繼承了trait所定義的接口。  
  2. public class test.TestTrait$Rectangle extends java.lang.Object implements test.TestTrait$Rectangular,scala.ScalaObject{  
  3.  
  4. // 類的val屬性直接對應于一個同名的private字段和相應的讀取方法。  
  5. private final java.awt.Point bottomRight;  
  6.  
  7. private final java.awt.Point topLeft;  
  8.  
  9. // scala對象比較特殊的是，相應字段的初始化比調用父類構造函數來得更早。也就是說，在Class(arg)中的參數是最早被初始化的。  
  10. // 在構造函數后，可以看到，會調用trait的初始化代碼。當然，在我們的這個例子中，trait沒有任何的初始化行為。  
  11. public test.TestTrait$Rectangle(java.awt.Point, java.awt.Point);  
  12.   Code:  
  13.    0:   aload_0  
  14.    1:   aload_1  
  15.    2:   putfield        #13; //Field topLeft:Ljava/awt/Point;  
  16.    5:   aload_0  
  17.    6:   aload_2  
  18.    7:   putfield        #15; //Field bottomRight:Ljava/awt/Point;  
  19.    10:  aload_0  
  20.    11:  invokespecial   #20; //Method java/lang/Object."":()V  
  21.    14:  aload_0  
  22.    15:  invokestatic    #26; //Method test/TestTrait$Rectangular$class.$init$:(Ltest/TestTrait$Rectangular;)V  
  23.    18:  return 
  24.  
  25. // height這個函數是從trait中繼承的，在這里，繼承體現為對trait實現類的一個調用，同時，將對象本身作為this傳遞給該函數  
  26. public int height();  
  27.   Code:  
  28.    0:   aload_0  
  29.    1:   invokestatic    #39; //Method test/TestTrait$Rectangular$class.height:(Ltest/TestTrait$Rectangular;)I  
  30.    4:   ireturn  
  31.  

 

這里不再羅列其他的函數實現，其基本與height函數是相一致的。

理解了以上的邏輯，trait是如何實現將接口和接口實現溶于一體的，應該就非常的清楚了。我以前一直在納悶一個問題：接口中不能夠包含實現代碼，那么，難道每次編譯繼承trait的類時，這寫實現的代碼是怎么在子類中繼承的呢？難道是編譯器將這個邏輯復制了一份？如果這樣，不僅生成的代碼量很大，而且，還有一個問題，那就是，在編譯時需要有trait的源代碼才行。經過上面的剖析，我們終于知道scala其實有更***的解決之道的：那就是一個trait輔助類。

#p#

Inside Scala - 4: Trait Stacks

這個例子摘自 Programming In Scala 這本書第12.5節。本文將從另外一個角度來分析 Stackable Trait的內部原理。

package test

 

  1. import scala.collection.mutable.ArrayBuffer  
  2.  
  3. object Test7 {  
  4.  
  5.   abstract class IntQueue {  
  6.     def put(x:Int)  
  7.     def get(): Int  
  8.   }  
  9.     
  10.   class BasicIntQueue extends IntQueue {  
  11.     private val buf = new ArrayBuffer[Int]  
  12.     def put(x:Int) { buf += x }  
  13.     def get() = buf.remove(0)  
  14.   }  
  15.  
  16.   trait Doubling extends IntQueue {  
  17.     abstract override def put(x:Int) { super.put(2*x) }  
  18.   }  
  19.  
  20.   def main(args: Array[String]) {  
  21.     val queue: IntQueue = new BasicIntQueue with Doubling  
  22.     queue.put(1)  
  23.     queue.put(5)  
  24.     println( queue.get )  
  25.     println( queue.get )  
  26.   }  
  27.  
  28. }  
  29.  

 

我們來看這一行代碼 val queue = new BasicIntQue with Doubling，Scala針對這一行代碼干了很多很多的工作，并不是一個簡單的操作那么簡單
Scala需要新生成一個類型，在我的環境中，這個類叫做：Test7$$anon$1，看看這個代碼：
// 新的類以BasicIntQueue為父類，同時實現了Doubling這個trait定義的接口
 

  1. public final class test.Test7$$anon$1 extends test.Test7$BasicIntQueue implements test.Test7$Doubling{  
  2.  
  3. public test.Test7$$anon$1();  
  4.   Code:  
  5.    0:   aload_0  
  6.    1:   invokespecial   #10; //Method test/Test7$BasicIntQueue."":()V // 父類初始化  
  7.    4:   aload_0  
  8.    5:   invokestatic    #16; //Method test/Test7$Doubling$class.$init$:(Ltest/Test7$Doubling;)V // trait輔助類初始化  
  9.    8:   return 
  10.  
  11. public void put(int);  
  12.   Code:  
  13.    0:   aload_0  
  14.    1:   iload_1  
  15.    2:   invokestatic    #21; //Method test/Test7$Doubling$class.put:(Ltest/Test7$Doubling;I)V // 這個類使用的是Doubling提供的版本  
  16.    5:   return 
  17.  
  18. public final void test$Test7$Doubling$$super$put(int); // Doubling所需要的super的版本  
  19.   Code:  
  20.    0:   aload_0  
  21.    1:   iload_1  
  22.    2:   invokespecial   #29; //Method test/Test7$BasicIntQueue.put:(I)V  
  23.    5:   return 
  24.  
  25. }  
  26.  

我們來分析一下Doubling這個trait的實現
 

  1. public interface test.Test7$Doubling extends scala.ScalaObject{  
  2.  
  3. public abstract void put(int);  // 這個是trait中實現的方法  
  4.  
  5. public abstract void test$Test7$Doubling$$super$put(int); // 這個是這個trait 額外依賴的方法  
  6.  
  7. }  
  8.  
  9. // Doubling這個trait的輔助類  
  10. public abstract class test.Test7$Doubling$class extends java.lang.Object{  
  11. public static void $init$(test.Test7$Doubling);  
  12.   Code:  
  13.    0:   return 
  14.  
  15. public static void put(test.Test7$Doubling, int);  
  16.   Code:  
  17.    0:   aload_0  
  18.    1:   iconst_2  
  19.    2:   iload_1  
  20.    3:   imul  
  21.    4:   invokeinterface #17,  2; //InterfaceMethod test/Test7$Doubling.test$Test7$Doubling$$super$put:(I)V  
  22. // 這也是 Doubling這個接口中需要 super.init這個方法的原因。  
  23.    9:   return 
  24.  
  25. }  
  26.  

由此可見，編譯器在處理 val queue: IntQueue = new BasicIntQueue with Doubling這一行代碼時，需要確定類、Trait的先后順序。這也是理解Trait的最為復雜的一環。后續，我將就這個問題進行分析。

#p#

Inside Scala - 5: Trait Stacks

繼續上一個案例，現在我們將Trait的鏈搞得更長一些：

 

  1. trait Incrementing extends IntQueue {  
  2. abstract override def put(x: Int) { super.put(x + 1) }  
  3. }  
  4. trait Filtering extends IntQueue {  
  5. abstract override def put(x: Int) {  
  6. if (x >= 0) super.put(x)  
  7. }  
  8. }  
  9.  
  10. val queue: IntQueue = new BasicIntQueue with Incrementing with Filtering  
  11.  

 

新的類如何呢？當我們調用 queue的 put方法時，這個的先后順序究竟如何呢？還是看看生成的代碼：
 

  1. public final class test.Test7$$anon$1 extends test.Test7$BasicIntQueue implements test.Test7$Incrementing,test.Test7$Filtering{  
  2.  
  3. // 初始化的順序：先父類、再Incremeting、再Filtering，這個順序與源代碼的順序是一致的。  
  4. public test.Test7$$anon$1();  
  5.   Code:  
  6.    0:   aload_0  
  7.    1:   invokespecial   #10; //Method test/Test7$BasicIntQueue."":()V  
  8.    4:   aload_0  
  9.    5:   invokestatic    #16; //Method test/Test7$Incrementing$class.$init$:(Ltest/Test7$Incrementing;)V  
  10.    8:   aload_0  
  11.    9:   invokestatic    #21; //Method test/Test7$Filtering$class.$init$:(Ltest/Test7$Filtering;)V  
  12.    12:  return 
  13.  
  14. // put 方法實際使用的是 Filtering這個Trait的put  
  15. public void put(int);  
  16.   Code:  
  17.    0:   aload_0  
  18.    1:   iload_1  
  19.    2:   invokestatic    #34; //Method test/Test7$Filtering$class.put:(Ltest/Test7$Filtering;I)V  
  20.    5:   return 
  21.  
  22. // Filtering Trait的父實現是Incremeting trait  
  23. public final void test$Test7$Filtering$$super$put(int);  
  24.   Code:  
  25.    0:   aload_0  
  26.    1:   iload_1  
  27.    2:   invokestatic    #38; //Method test/Test7$Incrementing$class.put:(Ltest/Test7$Incrementing;I)V  
  28.    5:   return 
  29.  
  30. // incrementing的父實現是父類的實現。  
  31. public final void test$Test7$Incrementing$$super$put(int);  
  32.   Code:  
  33.    0:   aload_0  
  34.    1:   iload_1  
  35.    2:   invokespecial   #26; //Method test/Test7$BasicIntQueue.put:(I)V  
  36.    5:   return 
  37.  
  38. }  
  39.  

 

因此，要理解這個過程，可以這么來分析：val queue: IntQueue = new BasicIntQueue with Incrementing with Filtering
首先初始化的是BasicIntQueue
在這個基礎上疊加 Incrementing，super.put引用的是BasicIntQueue的put方法
再在疊加后的基礎上疊加 Filtering，super.put引用的是 Incrementing的put方法
疊加后的結果就是***的版本。put引用的是Filtering的put方法
因此，初始化的順序是從左至右，而方法的可見性則是從右至左（可以理解為上面的疊加關系，疊加之后，上面的trait具有更大的優先可見性。

#p#

Inside Scala - 6：Case Class 與 模式匹配

本文將嘗試對Case Class是如何參與模式匹配的進行剖析。文中的代碼還是來自 Programming In Scala一書。

  1. abstract class Expr;  
  2. case class Var(name: String) extends Expr;  
  3. case class Number(num: Double) extends Expr;  
  4. case class UnOp(operator: String, arg: Expr) extends Expr;  
  5. case class BinOp(operator:String, left: Expr, right: Expr) extends Expr; 

這里我們先來看一個最為簡單的模式匹配
 

  1. some match {  
  2.   case Var(name) => println("a var with name:" + name)  
  3. } 


這幾行的代碼編譯后等效于：

  1. if(some instanceof Var)  
  2. {  
  3.     Var temp21 = (Var)some;  
  4.     String name = temp21.name();  
  5.     if(true)  
  6.     {  
  7.         name = temp22;  
  8.         Predef$.MODULE$.println((new StringBuilder()).append("a var with name:").append(name).toString());  
  9.     } else 
  10.     {  
  11.         throw new MatchError(some.toString());  
  12.     }  
  13. } else 
  14. {  
  15.     throw new MatchError(some.toString());  
  16. } 


如果從生成的代碼的角度上來看，Scala生成的代碼質量并不高，其中的 if(true) else 的那個部分就有明顯的廢代碼。（不過，這個對運行效率的影響到時幾乎可以忽略，只是編譯后的字節碼倒是沒理由的多了幾分）。
上面的這個模式匹配僅僅是匹配一個類型。因此，其對應的java原語就是 instanceof 檢測。

讓我們更進一步， 看看如下的例子：
 

  1. some match {  
  2.   case Var("x") => println("a var with name:x")  
  3. } 

這個模式匹配不僅匹配類型，還要匹配構造器中的name屬性為 "x"常量。這里我就不在福州 Scala生成的字節碼了，而是簡單的翻譯一下：
if( some instanceof Var)  -- 類型檢查
var.name() == "x"             -- 檢查 對象的 name 屬性是否等于 "x",編譯器非常清楚的指導 Case Class的每一個構造參數所對應的字段名稱。

更進一步，讓我們看看一個更復雜的模式匹配：嵌套的對象。
 

  1. some match {  
  2.   case BinOp("+", Var("x"), UnOp("-", Number(num))) => println("x - " + num)  
  3. } 

這個邏輯其實也是上面的一個嵌套：
some instanceof BinOp
some.operator == "+"  編譯器進行了特殊的null檢測，以防止這個操作出現NPE
some.left instanceof Var
some.left.name == "x"
some.right instanceof UnOp
some.right.operator == "-"
some.right.arg instanceof Number
......
實際上，Scala的模式匹配確實為我們干了很多很多的事情，這也使得在很多的情況下，使用scala的模式匹配為我們提供了一個非常安全的（不用擔心大量的Null檢查），以及非常復雜的匹配操作。當然，與更復雜的模式匹配相比（譬如，規則引擎其實也是一個模式匹配的引擎），Scala的模式匹配還是相對比較簡單的。

這里簡單的補充一下 Scala中的幾種模式：
1、通配符模式。 也就是說使用 case _ => 來匹配所有的東西。或者，case Var(_) 來對局部進行通配。
2、常量匹配。譬如上述的Var("x"） ,其中，"x"就是一個常量。常量除了文字常量外，還可以使用以大寫字母開頭的scala變量，或者`varname`形式的引用。
3、變量匹配。一個變量匹配實際上匹配任何的類型，并同時賦予其一個變量名。
4、構造函數匹配。匹配一個給定的類型，并且嵌套的對其參數進行匹配。參數可以是通配符模式、常量、變量或者子構造函數匹配
5、對于List類型， _*可以匹配剩余的全部元素。
6、Tuple匹配。(a,b,c)
7、類型匹配。對于java對象，由于并不適合Scala的Case Class模型，因此，可以使用類型進行匹配。在這種情況下，與構造子匹配是不同的。

再摘一段我以前編寫的使用scala來編寫應用程序的邏輯代碼，讓我們看看模式匹配在商業應用中的使用：

  1. _req.transType match {  
  2.       case RechargeEcp | RechargeGnete | FreezeToAvailable => // 充值類交易  
  3.         assert(_req.amount > 0, "金額不正確")  
  4.       case DirectPay | AvailableToFreeze =>    // 支付、凍結類交易  
  5.         assert(_req.amount < 0, "金額不正確")  
  6.       case _ =>      
  7.         assert(false, "無效交易類型")  
  8.     }  
  9.       
  10.     val _account = queryEwAccount(_req.userId)  
  11.     assert(_account != null, "用戶尚未開通電子錢包")  
  12.       
  13.     var _accAvail, _accFreeze: EWSubAccount = null 
  14.     var _total: BigDecimal = _req.amount  
  15.     _account.subAccounts.find(_.subTypeCode==Available) match {  
  16.       case Some(x) =>  _accAvail = x;    _total += x.balance  
  17.       case None =>  
  18.     }  
  19.     _account.subAccounts.find(_.subTypeCode==Freeze) match {  
  20.       case Some(x) =>  _accFreeze = x;    _total += x.balance  
  21.       case None=>  
  22.     }  

這個僅僅是一個很簡單的應用，試想使用Java的if/else或者switch來進行相同的代碼，你不妨看看代碼量會增加多少？可讀性又會如何呢？

#p#

Scala Actor是一種借鑒于Erlang的進程消息機制的并發編程模式，由于Java中不存在Erlang的進程的概念，因此，Scala的Actor在隔離性上是不如Erlang的，譬如，在Erlang中，可以有效的終止一個進程，不僅僅無需擔心死鎖（根本沒有鎖），也可以馬上釋放掉改進程的內存，這種隔離性在某種程度上是更接近于操作系統的進程的。在Java的世界里暫時沒有等效的替代品。

（題外話，最近在我們的Open Service Platform中集成了一個類似于操作系統定時調度的機制，可以定時執行一些任務，但是***，我們仍然決定將部分非交易相關的定時任務，主要是一些日志分析類、管理性批量處理等定時任務放到操作系統上進行調度，畢竟操作系統提供了一個更好的虛擬機，在OSGi層面仍然是有限的隔離，哪一天JVM能夠提供像操作系統的隔離特性，那么，操作系統就真的不重要了）。

本文將對actor的機制進行簡單的分析，以幫助加強對actor的理解。

  1. package learn.actor  
  2.  
  3. object Test1 extends Application {  
  4.  
  5.   import scala.actors.Actor._  
  6.  
  7.   val actor1 = actor {  
  8.  
  9.     println("i am in " + Thread.currentThread)  
  10.  
  11.     while(true) {  
  12.  
  13.       receive {  
  14.  
  15.         case msg => println("recieve msg:" + msg + " In " + Thread.currentThread);  
  16.  
  17.       }  
  18.  
  19.     }  
  20.  
  21.   }  
  22.  
  23.    
  24.  
  25.   val actor2 = actor {  
  26.  
  27.     println("i am in " + Thread.currentThread)  
  28.  
  29.     while(true) {  
  30.  
  31.       receive {  
  32.  
  33.         case msg: String => println("recieve msg:" + msg.toUpperCase + " In " + Thread.currentThread);  
  34.  
  35.       }  
  36.  
  37.     }  
  38.  
  39.   }  
  40.  
  41.    
  42.  
  43.   actor1 ! "Hello World" 
  44.  
  45.   actor2 ! "Hello World" 
  46.  
  47.   actor1 ! "ok" 
  48.  
  49.   actor2 ! "ok" 
  50.  
  51.    
  52.  
  53. }  
  54.  

運行的結果是：

  1. i am in Thread[pool-1-thread-1,5,main]  
  2. i am in Thread[pool-1-thread-2,5,main]  
  3. recieve msg:HELLO WORLD In Thread[pool-1-thread-2,5,main]  
  4. recieve msg:Hello World In Thread[pool-1-thread-1,5,main]  
  5. recieve msg:OK In Thread[pool-1-thread-2,5,main]  
  6. recieve msg:ok In Thread[pool-1-thread-1,5,main] 

從這個例子來看，actor1和actor2實際上是兩個獨立的Java線程，任何線程可以將消息以 ! 的方式發給給這個線程進行處理。由于采用消息的方式來進行通信，因此，線程與線程之間無需采用Java的notify/wait機制，而后者是建立在鎖的基礎之上的。有關于這一點，我不在本文只進行深入的分析了。（有必要的話，我會再寫一個帖子來說明）。

那么 Scala Actor 的底層基礎是什么呢？與Java的notify/wait就完全沒有關系嗎？我們將重點分析actor的三個方法：!, receive, react

1、Scala Actor的send（外部調用者發送一個消息給當前actor）和receive（當前actor接收一個消息），這兩個操作是同步的(synchronized)，也就是說，不可同時進入。（客觀的說，這一塊應該有很大的優化空間，應該采用樂觀鎖的機制，可能會有更好的效率，一來，send/receive操作本身都是很快速的操作，即便在出現沖突的情況下，使用樂觀鎖也可以降低線程切換引起的開銷，而且，在大部分情況下，send操作與receive操作引發沖突的可能性并不是很大的。也就是說，在很大的程度上，send和receive還可以有更好的并行性，不知道后續的scala版本是否會進行優化。）

2、執行send操作時，如果當前actor正在等待這個消息（指actor自身已經在receive、react并且期待這個消息的情況下），那么原來的等待將會馬上執行，否則，消息會進入到actor的郵箱，等待下次receive/react的處理。這種模式相較于全部放入郵箱更加有效。它避免了一次在郵箱上的同步等待。

3、當執行receive操作時，actor會檢查對象的郵箱，如果有匹配的消息的話，則會馬上返回該消息進行處理，否則會處在等待狀態（當前線程阻塞，采用的是wait原語）當匹配的消息到達時，也是采用notify原語通知等待線程繼續actor的處理的。

4、react與receive不同的是，react從不返回。這個在Java的編程世界里，好像還沒有看到類似的東西，該如何理解它呢：

react(f: ParticialFunction[Any,Unit]) 首先檢查actor的郵箱，如果有符合f的消息，則馬上提取該消息，并且在一個ExecutionPool中調度執行f。（因此，f的執行肯定不在請求react這個線程中執行的。當前的調用react的線程，將產生一個 SuspendActorException，從而中斷一般的執行過程。（也就是說文檔中說的不返回的概念）

如果當前郵箱中沒有消息，react將登記一個Continuation對象，將等待的消息（一個等待給定消息的函數）、獲得消息后需要繼續進行的處理在actor中進行登記，而后，當前線程會產生一個SuspendActorException,中斷處理（從而是將當前線程歸還到線程池）。

當消息到達（通過send)時，send將檢查等待消息的Continuation，如過匹配的話，則會在線程池中的選擇一個線程來執行f函數。在f處理完成一個消息后，一般的，它會再次調用 react來處理下一個消息，將再次重復這個過程。

應該說，scala的這個設計是非常精巧，也非常有效的，但這對Java開發程序員來說，就意味著一個新的挑戰：看上去的一個函數體，實際上其中的代碼不僅是執行不連續的（如closure可能會延遲、重復多次的被調用），甚至可能是在不同的線程中被執行的。

從這個概念上來看，scala的actor并不對應于Java的線程，相反，可以理解為一個行為執行者，是一個有上下文的非操作系統線程，語義其實更接近于現實的一個載體。這個與Erlang的進程還是有很明顯的語義上的區別的。從上述的分析中，或許如果切換到樂觀鎖的機制，Scala的并發效率還能有更進一步的提升。

 

 

 

責任編輯：yangsai 來源： Wang Zai Xiang
Inside Scala
相關推薦

2009-07-22 07:43:00

Scala閉包

2009-07-21 16:58:31

Scala變量范圍

2009-07-08 12:43:59

Scala ServlScala語言

2010-09-14 15:34:41

Scala

2009-07-08 15:35:18

Case類Scala

2009-07-22 07:57:00

ScalaCurry化函數

2020-10-31 17:33:18

Scala語言函數

2009-07-22 07:47:00

Scala客戶代碼

2009-07-22 09:22:20

Scala工廠對象

2009-08-03 11:07:18

Scala Actor

2009-09-28 11:01:39

從Java走進Scal

2009-07-22 08:57:49

Scalafinal

2009-08-21 16:17:25

ScalaTwitter API

2009-07-22 09:02:45

Scala組合繼承

2009-12-09 09:15:47

從Java走進ScalTwitter API

2009-10-19 11:26:08

Scala循環數組

2009-07-20 16:56:51

Scala類的定義

2009-07-22 07:53:00

Scala無參數方法

2009-09-09 10:50:55

Scala例子Scala與Java

2009-06-17 11:44:22

Scala控制結構
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 一级片免费在线观看 | 国产精品美女久久久久久不卡 | 国产目拍亚洲精品99久久精品 | 精品亚洲一区二区 | 一区二区亚洲 | 成人午夜网 | 国产一区二区在线免费观看 | 成人福利在线 | 色狠狠一区 | 日韩一级免费看 | 国产精品毛片久久久久久久 | 免费国产一区二区 | 91久久综合| 97精品视频在线 | 成人免费淫片aa视频免费 | 国产剧情一区 | av黄色免费| 国产一区二区免费 | 在线国产一区二区 | 九九伊人sl水蜜桃色推荐 | 日韩中文字幕在线视频观看 | 狠狠狠色丁香婷婷综合久久五月 | 亚洲精品中文字幕在线观看 | 亚洲精品免费看 | 亚洲欧美激情四射 | 欧美成人激情 | 有码在线 | 在线观看中文字幕dvd播放 | 夜夜草视频 | 久久6| 狠狠爱免费视频 | 国产一区不卡 | 亚洲国产成人精品久久 | 看特级黄色片 | 国产在线中文字幕 | 欧美综合自拍 | 国产美女在线免费观看 | 久久一级 | 日本精品一区二区三区视频 | 精品视频一区二区三区在线观看 | 日韩和的一区二在线 |