Scala 类定义对永久代空间的影响
Scala 类库中使用的标准模式是在类和特征中定义类。父类对象的大多数操作都会导致这些内部类的对象被创建。每个内部类对于每个对象都是不同的。
例如 请参阅 scala.io.Source 和 LineIterator 的源代码。我认为这是标准库中最简单的一个。
正如下面的文件所示，这是两个不同的类别。
val s1:Source = ...
val s2:Source = ...
s1.getLines.getClass != s2.getLines.getClass //true if s1 != s2
意味着创建了两个类。
由于整个集合库使用相同的模式，对于长时间运行的进程来说，对永久代空间有什么影响？
A standard pattern used in Scala class library is definition of classes within classes and traits. And most of the operations of objects of parent classes result in objects of those inner classes being created. Each inner class is different for each object.
e.g.
See source for scala.io.Source and LineIterator. I think this is the simplest one in standard library.
As documents suggest below are two different classes.
val s1:Source = ...
val s2:Source = ...
s1.getLines.getClass != s2.getLines.getClass //true if s1 != s2
Meaning two classes are created.
As the whole collection library is using the same pattern, what are the effects on permgen space for long running processes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定您如何得出结论：如果
s1 != s2，则s1.getLines.getClass != s2.getLines.getClass。如果我使用Source.fromFile创建BufferedSource的两个实例，那么两者都将返回同一类scala.io.BufferedSource$BufferedLineIterator的实例当我调用 getLines 时。确实，Scala 创建了很多类，但这是在编译时而不是运行时完成的，因此对于长时间运行的进程来说，perm gen 不应该成为更多问题。
I'm not sure how you concluded that if
s1 != s2, thens1.getLines.getClass != s2.getLines.getClass. If I create two instances ofBufferedSourceusingSource.fromFile, then both will return an instance of the same classscala.io.BufferedSource$BufferedLineIteratorwhen I callgetLines.It's true that Scala creates a lot of classes, but this is done at compile-time, not runtime, so perm gen should not be more of a issue for long-running processes.