blocks|key|579587|text|根据定义，Case类是不可变的。toString返回的任何值本身也是不可变的。因此，通过使用一个惰性val从本质上“缓存”这个值是有意义的。另一方面，所提供的toString实现除了所有case类提供的默认toString之外，并没有做更多的事情。如果一个普通的case类toString在下面使用了一个惰性val，我不会感到惊讶。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|579588|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Case classes are, by definition, immutable. Any value returned by toString will itself be immutable, too. Thus it makes sense to essentially "cache" this value by utilizing a lazy val. On the other hand, the provided toString implementation does little more than the default toString provided by all case classes. I would not be surprised if a vanilla case class toString used a lazy val underneath.

blocks|key|4362830|text|在第一个代码片段中，当%7Cif+toString方法被调用时，position将只按需计算一次。在第二个代码片段中，toString主体将在每次调用该方法时重新计算。由于x和y不能更改，因此它是没有意义的，应该存储toString值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4362831|entityMap^0|F|8|U|8|1L|8|2C|1|2E|1|2Y|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|G|$]]

In the first snippet <code>position</code> will be calculated just once, on demand, [when|if] <code>toString</code> method is called. In the second snippet, <code>toString</code> body will be re-evaluated every time the method is called. Given that <code>x</code> and <code>y</code> cannot be changed, it's senseless, and <code>toString</code> value should be stored.

blocks|key|890756|text|在我看来，这是一个微优化。JVM有足够的能力处理这样的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|890757|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Looks like a micro-optimization to me. JVM is able enough to take care of such cases.

blocks|key|4362888|text|关于惰性函数，需要注意的一点是，虽然它们只计算一次，但对它们的每次访问都受到双重检查的锁定包装器的保护。这是必要的，以防止两个不同的线程试图在同一时间初始化该值，并产生滑稽的结果。现在，双重检查锁定非常有效(因为它实际上可以在JVM中工作)，并且在大多数情况下不需要获取锁，但是比简单的值访问有更多的开销。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4362889|另外(也是有些明显的)，通过缓存对象的字符串表示，您显式地牺牲了CPU周期，以换取内存使用量的可能大幅增加。"def“版本中的字符串可以被垃圾收集，而"lazy+val”版本中的字符串将不会被垃圾收集。|4362890|最后，与性能问题一样，如果没有基于事实的基准测试，基于理论的假设几乎没有任何意义。如果不进行性能分析，您将永远无法确定，因此不妨尝试一下并查看。|4362891|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|$]]

One thing to note about lazy vals is that, while they are only calculated once, every access to them is protected by a double-checked locking wrapper. This is necessary to prevent two different threads from attempting to initialize the value at the same time with hilarious results. Now double-checked locking is pretty efficient (now that it actually works in the JVM), and won't require lock acquisition in most cases, but there is more overhead than a simple value access.

Additionally (and somewhat obviously), by caching the string representation of your object, you are explicitly trading off CPU cycles for possibly large increases in memory usage. The strings in the "def" version can be garbage-collected, while those in the "lazy val" version will not be. 

Finally, as is always the case with performance questions, theory-based hypotheses mean nearly nothing without fact-based benchmarking. You'll never know for sure without profiling, so might as well try it and see.

blocks|key|2896069|text|可以用lazy+val直接覆盖toString。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2896070|scala>+case+class+Cell(x:+Int,+y:+Int)+{
+++++%7C+++override+lazy+val+toString+=+{println("here");+"(%25s,+%25s)".format(x,+y)}
+++++%7C+}
defined+class+Cell

scala>+{val+c+=+Cell(1,+2);+(c.toString,+c.toString)}
here
res0:+(String,+String)+=+((1,+2),(1,+2))|code-block|syntax|javascript|2896071|请注意，def不能覆盖val+--您只能使子类中的成员更稳定。|2896072|entityMap^0|3|8|F|8|0|0|4|3|B|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|N|$]]

<code>toString</code> can be directly overriden with a <code>lazy val</code>.

<pre><code>scala&gt; case class Cell(x: Int, y: Int) {
 | override lazy val toString = {println("here"); "(%s, %s)".format(x, y)}
 | }
defined class Cell

scala&gt; {val c = Cell(1, 2); (c.toString, c.toString)}
here
res0: (String, String) = ((1, 2),(1, 2))
</code></pre>

Note that a <code>def</code> may not override a <code>val</code> -- you can only make members more stable in the sub class.

I encountered the following code in JAXMag's Scala special issue:

<pre><code>package com.weiglewilczek.gameoflife

case class Cell(x: Int, y: Int) {
 override def toString = position
 private lazy val position = "(%s, %s)".format(x, y)
}
</code></pre>

Does the use of <code>lazy val</code> in the above code provide considerably more performance than the following code?

<pre><code>package com.weiglewilczek.gameoflife

case class Cell(x: Int, y: Int) {
 override def toString = "(%s, %s)".format(x, y)
}
</code></pre>

Or is it just a case of unnecessary optimization?

Use of lazy val for caching string representation

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我在JAXMag的Scala特刊中遇到了以下代码：package com.weiglewilczek.gameoflifecase class Cell(x: Int, y: Int) {  override def toString = position  private lazy val position = "(...

问使用lazy val缓存字符串表示
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用lazy val缓存字符串表示EN