blocks|key|553281|text|val表示不可变，var表示可变。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|553282|Full+discussion.|553283|entityMap|0|LINK|mutability|MUTABLE|url|http://javaforyou.wordpress.com/2009/07/02/val-versus-var-in-scala/^0|0|3|9|3|0|0|G|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@]|D|@$9|V|A|W|1|X]]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

<code>val</code> means immutable and <code>var</code> means mutable.

<a href="http://javaforyou.wordpress.com/2009/07/02/val-versus-var-in-scala/" rel="noreferrer">Full discussion.</a>

blocks|key|553304|text|val是最终的，也就是说，无法设置。想想java中的final吧。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|553305|entityMap^0|0|3|Q|5|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

<code>val</code> is final, that is, cannot be set. Think <code>final</code> in java.

blocks|key|1843083|text|不同之处在于var可以重新分配，而val不能。可变性，或者任何实际分配的东西，都是一个次要问题：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1843084|import+collection.immutable
import+collection.mutable
var+m+=+immutable.Set("London",+"Paris")
m+=+immutable.Set("New+York")+//Reassignment+-+I+have+change+the+"value"+at+m.|code-block|syntax|javascript|1843085|鉴于：|1843086|val+n+=+immutable.Set("London",+"Paris")
n+=+immutable.Set("New+York")+//Will+not+compile+as+n+is+a+val.|1843087|因此：|1843088|val+n+=+mutable.Set("London",+"Paris")
n+=+mutable.Set("New+York")+//Will+not+compile,+even+though+the+type+of+n+is+mutable.|1843089|如果您正在构建一个数据结构，并且它的所有字段都是val，那么该数据结构就是不可变的，因为它的状态不能改变。|1843090|entityMap^0|6|3|H|3|0|0|0|0|0|0|O|3|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|14|8|@]|D|@]|E|$]]|$1|Q|3|R|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|V|$]]

The difference is that a <code>var</code> can be re-assigned to whereas a <code>val</code> cannot. The mutability, or otherwise of whatever is actually assigned, is a side issue:

<pre><code>import collection.immutable
import collection.mutable
var m = immutable.Set("London", "Paris")
m = immutable.Set("New York") //Reassignment - I have change the "value" at m.
</code></pre>

Whereas:

<pre><code>val n = immutable.Set("London", "Paris")
n = immutable.Set("New York") //Will not compile as n is a val.
</code></pre>

And hence:

<pre><code>val n = mutable.Set("London", "Paris")
n = mutable.Set("New York") //Will not compile, even though the type of n is mutable.
</code></pre>

If you are building a data structure and all of its fields are <code>val</code>s, then that data structure is therefore immutable, as its state cannot change.

blocks|key|1961173|text|"val表示不可变，var表示可变。“|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1961174|套用一下，"val表示值，var表示变量“。|1961175|这一区别在计算中非常重要(因为这两个概念定义了编程的本质)，而OO几乎完全模糊了这一点，因为在OO中，唯一的公理是“一切都是对象”。因此，现在的许多程序员往往不理解/欣赏/认可，因为他们已经被洗脑成了“以面向对象的方式思考”。通常会导致变量/可变对象像在任何地方一样被使用，而值/不可变对象可能/通常会更好。|1961176|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

"val means immutable and var means mutable."

To paraphrase, "val means value and var means variable".

A distinction that happens to be extremely important in computing (because those two concepts define the very essence of what programming is all about), and that OO has managed to blur almost completely, because in OO, the only axiom is that "everything is an object". And that as a consequence, lots of programmers these days tend not to understand/appreciate/recognize, because they have been brainwashed into "thinking the OO way" exclusively. Often leading to variable/mutable objects being used like everywhere, when value/immutable objects might/would often have been better.

blocks|key|1961530|text|正如许多人所说的那样，分配给val的对象是不可替换的，而分配给var的对象是可以替换的。然而，所述对象可以修改其内部状态。例如：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1961531|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)+//+Doesn't+work,+because+I+can't+replace+the+object+created+on+the+line+above+with+this+new+one.
++++x.value+=+new+A(6)+//+Doesn't+work,+because+I+can't+replace+the+object+assigned+to+B.value+for+a+new+one.
++++x.value.value+=+6+//+Works,+because+A.value+can+receive+a+new+object.
++}
}|code-block|syntax|javascript|1961532|因此，即使我们不能更改分配给x的对象，我们也可以更改该对象的状态。然而，在它的根部，有一个var。|1961533|现在，由于许多原因，不变性是一件好事。首先，如果一个对象没有改变内部状态，你就不必担心代码的其他部分会不会改变它。例如：|1961534|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")|1961535|这在多线程系统中变得尤为重要。在多线程系统中，可能会发生以下情况：|1961536|x+=+new+B(1)
f(x)
if+(x.value.value+==+1)+{
++print(x.value.value)+//+Can+be+different+than+1!
}|1961537|如果您只使用val，并且只使用不可变的数据结构(即避免使用数组、scala.collection.mutable中的所有内容等)，那么您可以放心，这种情况不会发生。也就是说，除非有一些代码，甚至可能是一个框架，否则会使用反射技巧--不幸的是，反射可能会改变“不可变”的值。|1961538|这是一个原因，但还有另一个原因。当您使用var时，您可能会出于多种目的重用相同的var。这有一些问题：|1961539|1961540|阅读代码的人将更难知道代码的某个部分中变量的值是什么。|unordered-list-item|1961541|您可能会忘记重新初始化某些代码路径中的变量，最终会在代码下游传递错误的值。|1961542|1961543|简而言之，使用val更安全，代码更具可读性。|1961544|然后，我们可以走另一个方向。如果val更好，那为什么还要有var呢？嗯，有些语言确实采用了这种方法，但在某些情况下，可变性可以极大地提高性能。|1961545|例如，取一个不可变的Queue。当你在其中enqueue或dequeue对象时，你会得到一个新的Queue对象。那么，您将如何处理其中的所有项呢？|1961546|我将通过一个示例进行说明。假设你有一个数字队列，你想用它们组成一个数字。例如，如果我有一个2，1，3的队列，按照这个顺序，我想取回数字213。让我们首先用mutable.Queue来解决这个问题|1961547|def+toNum(q:+scala.collection.mutable.Queue[Int])+=+{
++var+num+=+0
++while+(!q.isEmpty)+{
++++num+*=+10
++++num+%2B=+q.dequeue
++}
++num
}|1961548|这段代码快速且易于理解。它的主要缺点是传递的队列是由toNum修改的，因此您必须事先对其进行复制。这就是不变性使你摆脱的那种对象管理。|1961549|现在，让我们将其转换为immutable.Queue|1961550|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+%2B+digit)
++++}
++}
++recurse(q,+0)
}|1961551|因为我不能重用一些变量来跟踪我的num，就像前面的例子一样，我需要求助于递归。在这种情况下，它是尾递归，具有相当好的性能。但情况并不总是这样:有时就是没有好的(可读的，简单的)尾递归解决方案。|1961552|但是请注意，我可以重写该代码以同时使用immutable.Queue和var！例如：|1961553|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+%2B=+digit
++++qr+=+newQ
++}
++num
}|1961554|这段代码仍然是高效的，不需要递归，而且在调用toNum之前，您不需要担心是否必须复制队列。自然，我避免将变量重用于其他目的，并且此函数外部的代码都看不到它们，因此我不需要担心它们的值从一行更改到下一行--除非我显式地这样做。|1961555|Scala选择让程序员这样做，如果程序员认为这是最好的解决方案。其他语言已经选择使这类代码变得困难。Scala+(以及任何具有广泛可变性的语言)付出的代价是，编译器在优化代码方面没有足够的回旋余地。Java的解决方案是基于运行时配置文件优化代码。我们可以继续讨论每一方的利弊。|1961556|就我个人而言，我认为Scala目前取得了正确的平衡。到目前为止，它并不完美。我认为Clojure和Haskell都有一些非常有趣的概念没有被Scala采用，但是Scala也有自己的优势。让我们看看未来会发生什么。|1961557|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Clojure|1|http://en.wikipedia.org/wiki/Haskell_%2528programming_language%2529^0|E|3|V|3|0|0|E|1|19|3|0|0|0|0|0|6|3|W|O|0|K|3|14|3|0|0|0|0|0|7|3|0|G|3|T|3|0|A|5|L|7|T|7|1C|5|0|25|D|0|0|Q|5|0|B|F|0|0|G|3|0|J|F|Z|3|0|0|M|5|0|0|15|7|0|1D|7|1|0^^$0|@$1|2|3|4|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|2C|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|2D|8|@$9|2E|A|2F|B|C]|$9|2G|A|2H|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|2I|8|@]|D|@]|E|$]]|$1|O|3|P|5|H|7|2J|8|@]|D|@]|E|$I|J]]|$1|Q|3|R|5|6|7|2K|8|@]|D|@]|E|$]]|$1|S|3|T|5|H|7|2L|8|@]|D|@]|E|$I|J]]|$1|U|3|V|5|6|7|2M|8|@$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|2R|8|@$9|2S|A|2T|B|C]|$9|2U|A|2V|B|C]]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]|$1|Z|3|10|5|11|7|2X|8|@]|D|@]|E|$]]|$1|12|3|13|5|11|7|2Y|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|2Z|8|@]|D|@]|E|$]]|$1|15|3|16|5|6|7|30|8|@$9|31|A|32|B|C]]|D|@]|E|$]]|$1|17|3|18|5|6|7|33|8|@$9|34|A|35|B|C]|$9|36|A|37|B|C]]|D|@]|E|$]]|$1|19|3|1A|5|6|7|38|8|@$9|39|A|3A|B|C]|$9|3B|A|3C|B|C]|$9|3D|A|3E|B|C]|$9|3F|A|3G|B|C]]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|3H|8|@$9|3I|A|3J|B|C]]|D|@]|E|$]]|$1|1D|3|1E|5|H|7|3K|8|@]|D|@]|E|$I|J]]|$1|1F|3|1G|5|6|7|3L|8|@$9|3M|A|3N|B|C]]|D|@]|E|$]]|$1|1H|3|1I|5|6|7|3O|8|@$9|3P|A|3Q|B|C]]|D|@]|E|$]]|$1|1J|3|1K|5|H|7|3R|8|@]|D|@]|E|$I|J]]|$1|1L|3|1M|5|6|7|3S|8|@$9|3T|A|3U|B|C]]|D|@]|E|$]]|$1|1N|3|1O|5|6|7|3V|8|@$9|3W|A|3X|B|C]|$9|3Y|A|3Z|B|C]]|D|@]|E|$]]|$1|1P|3|1Q|5|H|7|40|8|@]|D|@]|E|$I|J]]|$1|1R|3|1S|5|6|7|41|8|@$9|42|A|43|B|C]]|D|@]|E|$]]|$1|1T|3|1U|5|6|7|44|8|@]|D|@]|E|$]]|$1|1V|3|1W|5|6|7|45|8|@]|D|@$9|46|A|47|1|48]|$9|49|A|4A|1|4B]]|E|$]]|$1|1X|3|-4|5|6|7|4C|8|@]|D|@]|E|$]]]|1Y|$1Z|$5|20|21|22|E|$23|24]]|25|$5|20|21|22|E|$23|26]]]]

As so many others have said, the object assigned to a <code>val</code> cannot be replaced, and the object assigned to a <code>var</code> can. However, said object can have its internal state modified. For example:

<pre><code>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) // Doesn't work, because I can't replace the object created on the line above with this new one.
 x.value = new A(6) // Doesn't work, because I can't replace the object assigned to B.value for a new one.
 x.value.value = 6 // Works, because A.value can receive a new object.
 }
}
</code></pre>

So, even though we can't change the object assigned to <code>x</code>, we could change the state of that object. At the root of it, however, there was a <code>var</code>.

Now, immutability is a good thing for many reasons. First, if an object doesn't change internal state, you don't have to worry if some other part of your code is changing it. For example:

<pre><code>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")
</code></pre>

This becomes particularly important with multithreaded systems. In a multithreaded system, the following can happen:

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

If you use <code>val</code> exclusively, and only use immutable data structures (that is, avoid arrays, everything in <code>scala.collection.mutable</code>, etc.), you can rest assured this won't happen. That is, unless there's some code, perhaps even a framework, doing reflection tricks -- reflection can change "immutable" values, unfortunately.

That's one reason, but there is another reason for it. When you use <code>var</code>, you can be tempted into reusing the same <code>var</code> for multiple purposes. This has some problems:

<ul>
<li>It will be more difficult for people reading the code to know what is the value of a variable in a certain part of the code.</li>
<li>You may forget to re-initialize the variable in some code path, and end up passing wrong values downstream in the code.</li>
</ul>

Simply put, using <code>val</code> is safer and leads to more readable code.

We can, then, go the other direction. If <code>val</code> is that better, why have <code>var</code> at all? Well, some languages did take that route, but there are situations in which mutability improves performance, a lot.

For example, take an immutable <code>Queue</code>. When you either <code>enqueue</code> or <code>dequeue</code> things in it, you get a new <code>Queue</code> object. How then, would you go about processing all items in it?

I'll go through that with an example. Let's say you have a queue of digits, and you want to compose a number out of them. For example, if I have a queue with 2, 1, 3, in that order, I want to get back the number 213. Let's first solve it with a <code>mutable.Queue</code>:

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

This code is fast and easy to understand. Its main drawback is that the queue that is passed is modified by <code>toNum</code>, so you have to make a copy of it beforehand. That's the kind of object management that immutability makes you free from.

Now, let's covert it to an <code>immutable.Queue</code>:

<pre><code>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)
}
</code></pre>

Because I can't reuse some variable to keep track of my <code>num</code>, like in the previous example, I need to resort to recursion. In this case, it is a tail-recursion, which has pretty good performance. But that is not always the case: sometimes there is just no good (readable, simple) tail recursion solution.

Note, however, that I can rewrite that code to use an <code>immutable.Queue</code> and a <code>var</code> at the same time! For example:

<pre><code>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
}
</code></pre>

This code is still efficient, does not require recursion, and you don't need to worry whether you have to make a copy of your queue or not before calling <code>toNum</code>. Naturally, I avoided reusing variables for other purposes, and no code outside this function sees them, so I don't need to worry about their values changing from one line to the next -- except when I explicitly do so.

Scala opted to let the programmer do that, if the programmer deemed it to be the best solution. Other languages have chosen to make such code difficult. The price Scala (and any language with widespread mutability) pays is that the compiler doesn't have as much leeway in optimizing the code as it could otherwise. Java's answer to that is optimizing the code based on the run-time profile. We could go on and on about pros and cons to each side.

Personally, I think Scala strikes the right balance, for now. It is not perfect, by far. I think both <a href="http://en.wikipedia.org/wiki/Clojure" rel="noreferrer">Clojure</a> and <a href="http://en.wikipedia.org/wiki/Haskell_%28programming_language%29" rel="noreferrer">Haskell</a> have very interesting notions not adopted by Scala, but Scala has its own strengths as well. We'll see what comes up on the future.

blocks|key|1961600|text|var+val表示不可变，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1961601|表示可变|blockquote|1961602|1961603|1961604|您可以将val视为java编程语言final键世界或c%2B%2B语言const键世界。|offset|length|style|CODE|1961605|entityMap^0|0|0|0|0|4|3|H|5|V|5|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]|$I|X|J|Y|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|N|$]]

<blockquote>
 val means immutable and var means mutable
</blockquote>

you can think <code>val</code> as java programming language <code>final</code> key world or c++ language <code>const</code> key world。

blocks|key|1961669|text|简而言之：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1961670|var+=+variable|offset|length|style|BOLD|1961671|val+=v变量%2B+final|1961672|entityMap^0|0|0|3|6|3|0|0|3|5|1|D|2|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@$D|S|E|T|F|G]|$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$]]

In simple terms:

var = variable

val = variable + final

blocks|key|1843324|text|从C%2B%2B的角度来看，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1843325|val+x:+T|code-block|syntax|javascript|1843326|类似于指向非常数数据的常量指针。|1843327|T*+const+x;|1843328|而|1843329|var+x:+T+|1843330|类似于非常数数据的非常数指针。|1843331|T*+x;|1843332|相对于var，支持val增加了代码库的不变性，这可以促进其正确性、并发性和可理解性。|offset|length|style|CODE|1843333|要理解常量指针指向非常数数据的含义，请考虑以下Scala代码片段：|1843334|val+m+=+scala.collection.mutable.Map(1+->+"picard")
m+//+res0:+scala.collection.mutable.Map[Int,String]+=+HashMap(1+->+picard)|1843335|这里的“指针”val+m是常量，所以我们不能重新赋值给它来指向其他类似的东西|1843336|m+=+n+//+error:+reassignment+to+val|1843337|但是，我们确实可以像这样更改m所指向的非常数数据本身|1843338|m.put(2,+"worf")
m+//+res1:+scala.collection.mutable.Map[Int,String]+=+HashMap(1+->+picard,+2+->+worf)|1843339|entityMap^0|0|0|0|0|0|0|0|0|3|3|9|3|0|0|0|7|5|0|0|E|1|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1D|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1E|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1F|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1G|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1H|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1I|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1J|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1K|8|@$U|1L|V|1M|W|X]|$U|1N|V|1O|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1P|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|1Q|8|@]|9|@]|A|$E|F]]|$1|12|3|13|5|6|7|1R|8|@$U|1S|V|1T|W|X]]|9|@]|A|$]]|$1|14|3|15|5|D|7|1U|8|@]|9|@]|A|$E|F]]|$1|16|3|17|5|6|7|1V|8|@$U|1W|V|1X|W|X]]|9|@]|A|$]]|$1|18|3|19|5|D|7|1Y|8|@]|9|@]|A|$E|F]]|$1|1A|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|1B|$]]

Thinking in terms of C++, 

<pre><code>val x: T
</code></pre>

is analogous to constant pointer to non-constant data

<pre><code>T* const x;
</code></pre>

while 

<pre><code>var x: T 
</code></pre>

is analogous to non-constant pointer to non-constant data 

<pre><code>T* x;
</code></pre>

Favoring <code>val</code> over <code>var</code> increases immutability of the codebase which can facilitate its correctness, concurrency and understandability.

To understand the meaning of having a constant pointer to non-constant data consider the following Scala snippet:

<pre><code>val m = scala.collection.mutable.Map(1 -&gt; "picard")
m // res0: scala.collection.mutable.Map[Int,String] = HashMap(1 -&gt; picard)
</code></pre>

Here the "pointer" <code>val m</code> is constant so we cannot re-assign it to point to something else like so

<pre><code>m = n // error: reassignment to val
</code></pre>

however we can indeed change the non-constant data itself that <code>m</code> points to like so

<pre><code>m.put(2, "worf")
m // res1: scala.collection.mutable.Map[Int,String] = HashMap(1 -&gt; picard, 2 -&gt; worf)
</code></pre>

blocks|key|1845898|text|它就像它的名字一样简单。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1845899|1845900|变量表示它可以变化|blockquote|1845901|1845902|val表示不变的|1845903|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|M|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

It's as simple as it name.
<blockquote>
var means it can vary
val means invariable
</blockquote>

blocks|key|1843397|text|Val+-value是类型化的存储常量。一旦创建，它的值就不能被重新赋值。可以使用关键字val定义新值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1843398|例如：val+x:+Int+=5|1843399|在这里，type是可选的，因为scala可以从赋值中推断出来。|1843400|Var+-变量是类型化的存储单元，只要保留了内存空间，就可以再次赋值。|1843401|例如：变量x:+Int+=5|1843402|存储在这两个存储单元中的数据一旦不再需要，JVM就会自动释放这些数据。|1843403|在scala中，由于稳定性的原因，值优先于变量，这给代码带来了好处，特别是在并发和多线程代码中。|1843404|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

Val - values are typed storage constants. Once created its value cant be re-assigned. a new value can be defined with keyword val.

eg. val x: Int = 5

Here type is optional as scala can infer it from the assigned value.

Var - variables are typed storage units which can be assigned values again as long as memory space is reserved. 

eg. var x: Int = 5

Data stored in both the storage units are automatically de-allocated by JVM once these are no longer needed.

In scala values are preferred over variables due to stability these brings to the code particularly in concurrent and multithreaded code.

blocks|key|553920|text|尽管许多人已经回答了Val和var之间的区别。但需要注意的一点是，val与final关键字并不完全相同。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|553921|我们可以使用递归来改变val的值，但是我们永远不能改变final的值。Final比Val更恒定。|553922|def+factorial(num:+Int):+Int+=+{
+if(num+==+0)+1
+else+factorial(num+-+1)+*+num
}|code-block|syntax|javascript|553923|默认情况下，方法参数是val，并且在每次调用时，值都会被更改。|553924|entityMap^0|A|3|E|3|X|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|Z|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|P|$]]

Though many have already answered the difference between Val and var.
But one point to notice is that val is not exactly like final keyword.

We can change the value of val using recursion but we can never change value of final. Final is more constant than Val.

<pre><code>def factorial(num: Int): Int = {
 if(num == 0) 1
 else factorial(num - 1) * num
}
</code></pre>

Method parameters are by default val and at every call value is being changed.

blocks|key|553947|text|Val表示其最终，不能被重新分配|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|553948|然而，Var可以在以后的中被重新分配。|553949|entityMap^0|0|3|6|2|0|3|3|0^^$0|@$1|2|3|4|5|6|7|K|8|@$9|L|A|M|B|C]|$9|N|A|O|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|P|8|@$9|Q|A|R|B|C]]|E|@]|F|$]]|$1|I|3|-4|5|6|7|S|8|@]|E|@]|F|$]]]|J|$]]

<code>Val</code> means its final, cannot be reassigned

Whereas, <code>Var</code> can be reassigned later.

What is the difference between a <code>var</code> and <code>val</code> definition in Scala and why does the language need both? Why would you choose a <code>val</code> over a <code>var</code> and vice versa?

What is the difference between a var and val definition in Scala?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

Scala语言中的var和val定义有什么不同?为什么语言需要两者？为什么要选择val而不是var，反之亦然？

问Scala中的var和val定义有什么不同？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Scala中的var和val定义有什么不同？EN