一想到這兩個的區(qū)別，大多數(shù)人第一反應(yīng)就是，var 修飾的變量可改變，val 修飾的變量不可改變；但真的如此嗎？事實上，var 修飾的對象引用可以改變，val 修飾的則不可改變，但對象的狀態(tài)卻是可以改變的。例如：

class A(n: Int) {
  var value = n
}

class B(n: Int) {
  val value = new A(n)
}

object Test {
  def main(args: Array[String]) {
    val x = new B(5)
    x = new B(6) // 錯誤，因為 x 為 val 修飾的，引用不可改變
    x.value = new A(6) // 錯誤，因為 x.value 為 val 修飾的，引用不可改變
    x.value.value = 6 // 正確，x.value.value 為var 修飾的，可以重新賦值
  }
}

對于變量的不變性有很許多的好處。

一是，如果一個對象不想改變其內(nèi)部的狀態(tài)，那么由于不變性，我們不用擔(dān)心程序的其他部分會改變對象的狀態(tài)；例如

x = new B(0)
f(x)
if (x.value.value == 0)
  println("f didn't do anything to x")
else
  println("f did something to x")

這對于多線程（多進(jìn)程）的系統(tǒng)來說尤其重要。在一個多線程系統(tǒng)中，以下可能發(fā)生：

x = new B(1)
f(x)
if (x.value.value == 1) {
  print(x.value.value) // Can be different than 1!
}

如果你只使用 val ，并且只使用不可變的數(shù)據(jù)結(jié)構(gòu)（即是，避免使用 arrays ，scala.collection.mutable 內(nèi)的任何東西，等等），你可以放心，這是不會發(fā)生的；除非有一些代碼，例如一個框架，進(jìn)行反射——反射可以改變不可變的值。

二是，當(dāng)用 var 修飾的時候，你可能在多個地方重用 var 修飾的變量，這樣會產(chǎn)生下面的問題：

• 對于閱讀代碼的人來說，在代碼的確定部分中知道變量的值是比較困難的；
• 你可能會在使用代碼前初始化代碼，這樣會導(dǎo)致錯誤；

因此，簡單地說，使用 val 是安全和增強代碼可讀性的。

既然 val 有這么多的好處，那為什么還要使用（或者說存在） var ； 的確，有些編程語言只存在 val的情況 ，但是有些情況下，使用可變性可以大幅度提高程序的執(zhí)行效率。

例如，對于一個不可變的 Queue ，當(dāng)每次對隊列進(jìn)行 enqueue 和 dequeue 操作時，將會得到一個新的 Queue 對象，那么 ，如何處理所有的項目呢？

下面我們通過例子進(jìn)行解釋。假設(shè)一個 Int 類型的隊列，對隊列內(nèi)的所有數(shù)字進(jìn)行組合；例如隊列的元素有 1，2，3，那么組合后的數(shù)字就是 123。下面是第一種解決方案：采用的是 mutable.Queue

def toNum(q: scala.collection.mutable.Queue[Int]) = {
  var num = 0
  while (!q.isEmpty) {
    num *= 10
    num += q.dequeue
  }
  num
}

上面的代碼易于閱讀和理解，但存在一個主要的問題是，會改變源數(shù)據(jù)，因此在調(diào)用 toNum 方法前必須對源數(shù)據(jù)進(jìn)行拷貝，避免對源數(shù)據(jù)產(chǎn)生污染。這時一種對對象進(jìn)行不變性管理的方法。

接下來采用 immutable.Queue :

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  def recurse(qr: scala.collection.immutable.Queue[Int], num: Int): Int = {
    if (qr.isEmpty)
      num
    else {
      val (digit, newQ) = qr.dequeue
      recurse(newQ, num * 10 + digit)
    }
  }
  recurse(q, 0)
}

因為 num 不能被重新分配值，就像在前面的例子中一樣，因此需要使用遞歸。這是一個尾部遞歸，它的性能很好。但情況并非總是如此：有時根本就沒有好的(可讀的、簡單的)尾遞歸解決方案。

下面采用 immutable.Queue 和 mutable.Queue 對代碼進(jìn)行重寫：

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  var qr = q
  var num = 0
  while (!qr.isEmpty) {
    val (digit, newQ) = qr.dequeue
    num *= 10
    num += digit
    qr = newQ
  }
  num
}

這段代碼非常有效，不需要遞歸，也無需擔(dān)心是否需要在調(diào)用toNum之前復(fù)制隊列。自然地，我避免了由于其他用途而對變量進(jìn)行重用，由于在這個函數(shù)之外沒有任何代碼可以看到（修改）它們，所以我不需要擔(dān)心它們的值在代碼的其他地方會發(fā)生——除非我明確地這么做。

如果程序員認(rèn)為某種解決方案是最好的解決方案，那么 Scala 就允許程序員這么做。其他變成語言則沒有這么大的靈活性。Scala (以及任何具有廣泛可變性的語言)的代價是，編譯器在優(yōu)化代碼方面沒有足夠的靈活性。Java的提供解決方案是基于運行時來優(yōu)化代碼。