Java final修饰符 [英] Java final modifier

问题描述

有人告诉我，我误解了 final 的影响。 最终关键字有什么影响？

I was told that, I misunderstand effects of final. What are the effects of final keyword?

以下简要概述了我的想法，我知道：

Here is short overview of what I think, I know:

Java最终修饰符（又称聚合关系）

原始变量：只能设置一次。 （内存和性能
增益）

对象变量：可能会被修改，最终适用于对象
引用。

字段：只能设置一次。

方法：无法覆盖，隐藏。

类：无法扩展。

垃圾收集：将强制Java代际垃圾收集
mark-sweep进行双重扫描。

Java final modifier (aka aggregation relation)

primitive variables: can be set only once. (memory and performance gain)
objects variables: may be modified, final applies to object reference.
fields: can be set only once.
methods: can't be overridden, hidden.
classes: can't be extended.
garbage collection: will force Java generational garbage collection mark-sweep to double sweep.

可以和Cant的

• 可以使克隆失败（这两者都很好）


• 可以使不可变原语aka const


• 可以使空白不可变 - 在创建时初始化也是只读


• 可以使对象变得非常不可变


• 可以使范围/可见性不可变


• 可以使方法调用开销变小（因为它不需要虚拟表）


• 可以将方法参数用作final（即使你是


• 可以使对象线程安全（如果对象被定义为final，它不会使方法参数最终）


• 可以进行模拟测试（不是你可以做任何事情 - 你可以说错误是有意的）


• 不能交朋友（可与其他朋友互动，不可变休息）


• 
  
• 不能使数组元素成为不可变的，也就是说不可变的


• 无法创建对象的新实例（这既好又坏）


• 无法进行序列化工作



Can's and Cant's

• Can make clone fail (this is both good and bad)
• Can make immutable primitives aka const
• Can make blank immutable - initialized at creation aka readonly
• Can make objects shallowly immutable
• Can make scope / visibility immutable
• Can make method invocation overhead smaller (because it does not need virtual table)
• Can make method arguments used as final (even if thy are not)
• Can make objects threadsafe (if object is defined as final, it wont make method arguments final)
• Can make mock tests (not that you could do anything about it - you can say bugs are intended)
• Can't make friends (mutable with other friends and immutable for rest)
• Can't make mutable that is changed to be immutable later (but can with factory pattern like fix)
• Can't make array elements immutable aka deeply immutable
• Can't make new instances of object (this is both good and bad)
• Can't make serialization work

final 没有其他选择，但有包装+私人和枚举。

There are no alternatives to final, but there is wrapper + private and enums.

推荐答案

依次回答每一点：




原始变量：可以设置只有一次。 （内存和性能增益）

primitive variables: can be set only once. (memory and performance gain)

是的，但没有内存增益，也没有性能提升。 （你假设的性能增益来自设置一次......不是来自最终。）

Yes, but no memory gain, and no performance gain. (Your supposed performance gain comes from setting only once ... not from final.)




对象变量：可以修改，最终适用于对象引用。

objects variables: may be modified, final applies to object reference.

是。 （但是，这个描述忽略了这与Java语言的其余部分处理对象/引用二元性的方式完全一致。例如，当对象作为参数传递并作为结果返回时。）

Yes. (However, this description miss the point that this is entirely consistent with the way that the rest of the Java language deals with the object / reference duality. For instance, when objects are passed as parameters and returned as results.)




字段：只能设置一次。

fields: can be set only once.

真正的答案是：与变量相同。

The real answer is: same as for variables.




方法：无法覆盖，隐藏。

methods: can't be overridden, hidden.

是的。但是请注意，这里发生的是 final 关键字在不同的语法环境中使用，意味着与 final 表示字段/变量。

Yes. But also note that what is going on here is that the final keyword is being used in a different syntactic context to mean something different to final for an field / variable.




类：无法扩展。

classes: can't be extended.

是的。但另请参阅上面的注释。

Yes. But also see note above.




垃圾收集：将强制Java世代垃圾收集标记扫描进行双重扫描。

garbage collection: will force Java generational garbage collection mark-sweep to double sweep.

这是无稽之谈。 final 关键字与垃圾收集没有任何关联无论。你最终可能会混淆 final ...它们是无关的。

This is nonsense. The final keyword has no relevance whatsoever to garbage collection. You might be confusing final with finalization ... they are unrelated.

但即使是终结者也不会强迫额外的扫描。发生的事情是，需要完成的对象在一侧设置，直到主GC完成。然后GC在对象上运行finalize方法并设置其标志......并继续。 GC下次运行时，该对象被视为普通对象：

But even finalizers don't force an extra sweep. What happens is that an object that needs finalization is set on one side until the main GC finishes. The GC then runs the finalize method on the object and sets its flag ... and continues. The next time the GC runs, the object is treated as a normal object:



• 如果可以访问它，则标记并复制


• 如果无法访问则不会标记。



（您的特征描述 - Java代垃圾收集垃圾收集器可以是标记扫描或世代（复制的子类）。它不能同时存在.Java通常使用世代集合，只能回归标记 - 在紧急情况下消失;即当空间不足或低暂停收集器无法跟上时。）

(Your characterization - "Java generational garbage collection mark-sweep" is garbled. A garbage collector can be either "mark-sweep" OR "generational" (a subclass of "copying"). It can't be both. Java normally uses generational collection, and only falls back to mark-sweep in emergencies; i.e. when running out of space or when a low pause collector cannot keep up.)




可以使克隆失败（这既好又坏）

Can make clone fail (this is both good and bad)

我不这么认为。




可以使不可变原语aka const

Can make immutable primitives aka const

是。




可以使空白不可变 - 在创建时初始化也称为readonly

Can make blank immutable - initialized at creation aka readonly

是的......虽然我从未听过之前使用的空白不可变一词。

Yes ... though I've never heard the term "blank immutable" used before.




可以使对象变得浅不可变




对象可变性是关于可观察状态是否可能发生变化。因此，声明属性 final 可能会也可能不会使对象表现为不可变的。除了浅不可变的概念之外没有明确定义，尤其是因为没有对类语义的深入了解，就无法映射浅的概念。

Object mutability is about whether observable state may change. As such, declaring attributes final may or may not make the object behave as immutable. Besides the notion of "shallowly immutable" is not well defined, not least because the notion of what "shallow" is cannot be mapped without deep knowledge of the class semantics.

（很明显，变量/字段的可变性在JLS的上下文中是一个定义明确的概念。它只是从JLS的角度来看未定义的对象可变性的概念。）

(To be clear, the mutability of variables / fields is a well defined concept in the context of the JLS. It is just the concept of mutability of objects that is undefined from the perspective of the JLS.)




可以使范围/可见性不可变

Can make scope / visibility immutable

术语错误。可变性是关于对象状态的。可见性和范围不是。

Terminology error. Mutability is about object state. Visibility and scope are not.




可以减少方法调用开销（因为它不需要虚拟表）

Can make method invocation overhead smaller (because it does not need virtual table)

实际上，这是无关紧要的。如果它们没有被应用程序实际使用的任何类重写，那么现代JIT编译器也会对非final方法执行此优化。 （聪明的事情发生......）

In practice, this is irrelevant. A modern JIT compiler does this optimization for non-final methods too, if they are not overridden by any class that the application actually uses. (Clever stuff happens ...)




可以将方法参数用作final（即使你不是）

Can make method arguments used as final (even if thy are not)

嗯？我无法解析这句话。

Huh? I cannot parse this sentence.




可以使对象线程安全

Can make objects threadsafe

在某些情况下是。




（如果对象被定义为final，它不会使方法参数最终）

(if object is defined as final, it wont make method arguments final)

是的，如果你的意思是 class 是最终的。对象不是最终的。

Yes, if you mean if class is final. Objects are not final.




可以进行模拟测试（不是你可以对它做任何事情 - 你可以说错误是有意的）

Can make mock tests (not that you could do anything about it - you can say bugs are intended)

不解析。




可以'交朋友（可与其他朋友互动，不可变休息）

Can't make friends (mutable with other friends and immutable for rest)

Java没有朋友。




不能使以后更改为不可变的mutable（但可以使用像修复一样的工厂模式）

Can't make mutable that is changed to be immutable later (but can with factory pattern like fix)

对于第一个， final 字段无法从mutable切换到immutable。

Yes to the first, a final field can't be switched from mutable to immutable.

目前还不清楚你的意思是第二部分。确实，您可以使用工厂（或构建器）模式来构造不可变对象。但是，如果对象字段使用 final ，则该对象不会是可变的。

It is unclear what you mean by the second part. It is true that you can use a factory (or builder) pattern to construct immutable objects. However, if you use final for the object fields at no point will the object be mutable.

或者，你可以实现使用非final字段来表示不可变状态的不可变对象，你可以设计API以便你可以翻转开关来制作以前可变的对象从现在开始是不可变的。但是如果你采用这种方法，你需要对同步更加小心......如果你的对象需要是线程安全的。

Alternatively, you can implement immutable objects that use non-final fields to represent immutable state, and you can design the API so that you can "flip a switch" to make a previously mutable object immutable from now onwards. But if you take this approach, you need to be a lot more careful with synchronization ... if your objects need to be thread-safe.




不能使数组元素不可变又名不可变

Can't make array elements immutable aka deeply immutable

是的，但是你的术语被打破了;请参阅上面关于浅层可变性的评论。

Yes, but your terminology is broken; see comment above about "shallow mutability".




无法创建对象的新实例（这既好又坏）

Can't make new instances of object (this is both good and bad)

不。没有什么可以阻止你用最终字段或最终类或最终方法创建一个对象的新实例。

No. There's nothing stopping you making a new instance of an object with final fields or a final class or final methods.




无法进行序列化工作

Can't make serialization work

不。序列化工作。 （当然，使用自定义 readObject 方法对 final 字段进行反序列化会出现问题...尽管您可以使用它们来解决它们反射黑客。）

No. Serialization works. (Granted, deserialization of final fields using a custom readObject method presents problems ... though you can work around them using reflection hacks.)




没有替代品，

There are no alternatives to final,

正确。




但有包装+私人

but there is wrapper + private

是的，模数（严格地说）非最终字段的非同步getter可能是非线程安全的...... 即使它在对象构造期间被初始化然后从不已更改！

Yes, modulo that (strictly speaking) an unsynchronized getter for a non-final field may be non-thread-safe ... even if it is initialized during object construction and then never changed!




和枚举。

and enums.

解决另一个问题。并且枚举可以是可变的。

Solves a different problem. And enums can be mutable.

这篇关于Java final修饰符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！