Final 成员变量有助于更好的 GC？
这个问题是这个问题的延续，但要求更具体的场景。
假设我们有以下类：
public class Person {
private Foot left, right;
public Person(Foot left, Foot right) {
this.left = left;
this.right = right;
}
}
我想知道如果我们将下面的类变成以下内容，是否能够从 GC 的角度进行优化：
public class Person {
private final Foot left, right;
public Person(Foot left, Foot right) {
this.left = left;
this.right = right;
}
}
如果我正在查看这个类，我可以立即看出左变量和右变量永远不能提前设置为 null。这意味着 GC 唯一需要收集此类的左右对象（并减少对其的引用）的时间是当对父 Person 类的引用达到零时。它还应该意味着它可能能够在收集左右脚对象的同时收集人；还可以减少运行次数并提高速度。
因此，在这个例子中，将私有成员变量标记为final是否意味着代码将导致垃圾回收的微小加速（或者它可能被用作加速点）？
This question is a continuation of this one but asking for a more specific scenario.
Lets say we have the following class:
public class Person {
private Foot left, right;
public Person(Foot left, Foot right) {
this.left = left;
this.right = right;
}
}
I was wondering if the following class would be able to be optimised from the GC's perspective if we turned it into the following:
public class Person {
private final Foot left, right;
public Person(Foot left, Foot right) {
this.left = left;
this.right = right;
}
}
If I was looking at this class I can immediately tell that the left and right variables can never be set to null early. That means that the only time the GC will need to collect the left and right objects (and decrease the references to it) for this class will be when the references to the parent Person class reach zero. It should also mean that it might be able to collect person at the same time as it collects left and right Foot objects; also resulting in less runs and a speedup.
Therefore, in this example, does marking the private member variables final mean that the code will result even a minor speedup in garbage collection (or could it possibly be used as a speedup point)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对字段的分配不会触发任何垃圾收集器工作或引用计数调整，因为 Java GC 不使用引用计数 (*)。所以答案是，将一个字段声明为
final不会对垃圾收集器的性能产生任何影响。 （收集器的跟踪阶段必须检查该字段是否为final。可以想象，将字段声明为
final可以帮助JIT编译器的数据流内存获取的分析和优化但是，使用它作为将字段更改为final的理由是一个坏主意，如果您打算这样做，那么出于正确性原因（即为了正确性）而这样做。确保并发环境下的施工安全）或者出于风格原因（即，为了使代码更易于理解和维护）（*没有主流 Java 实现依赖引用计数来实现内存管理。理论上，有人可能实现这样的 JVM。使用引用计数，但传统观点认为引用计数效率极低……更不用说并发性、收集周期等方面的问题了。）
Assignment to fields does not trigger any garbage collector work or reference count adjustment because Java GCs don't use reference counting (*). So the answer is that declaring a field as
finalwill make no difference to garbage collector performance. (The tracing phase of the collector has to examine the field whether or not it isfinal.It is conceivable that declaring a field to be
finalcould help the JIT compiler's data flow analysis and optimization of memory fetches. However, it would be a bad idea to use that as a justification for changing fields tofinal. If you are going to do it, do it for correctness reasons (i.e. to make construction safe in a concurrent context) or for stylistic reasons (i.e. to make the code easier to understand and maintain).(* No mainstream Java implementation relies on reference counting to implement memory management. It is theoretically possible that someone might implement a JVM that used reference counting, but conventional wisdom is that reference counting is horribly inefficient ... not to mention problematic for concurrency, collecting cycles, and so on.)
GC 优化不可能的唯一原因，是因为 JVM 规范允许更改final< /code> 字段。
final字段在对象构造过程中具有特殊的语义，这对于构造过程在 Java 内存模型中正常工作非常重要。但你可以打破规则并使用反射来改变它。在这种情况下，您不能依赖final字段的语义（关于 java 内存模型）罢工：对不起，大家，我不知道我在说什么。 final 与 GC 无关。即使final根本不可改变，GC也无法获得该事实的任何有用信息
The only reason that GC optimization is not possible, is because JVM spec does allow changingfinalfield.finalfields has special semantic during the object construction process which is important for the construction process to work properly regarding the java memory model. But you can break the rules and use reflection to change it. In this case you can not rely on the semantic offinalfield (regarding the java memory model)the strike: Sorry guys, i don't know what i was talking about. final is irrelevant for GC. even if final is not changeable at all, GC can not get any useful information of that fact
Java 垃圾收集不通过引用计数来工作。它的工作原理是检查对象的可达性。
Java garbage collection doesn't work by reference counting. It works by examining objects for reachability.