Java 最终修饰符 [英] Java final modifier
问题描述
有人告诉我，我误解了 final 的效果.final 关键字的作用是什么?
这是我的想法的简短概述，我知道:
<块引用>Java final 修饰符(又名聚合关系)
原始变量:只能设置一次.(内存和性能增益)
objects变量:可以修改，final适用于对象参考.
字段:只能设置一次.
方法:不能被覆盖、隐藏.
类:无法扩展.
垃圾收集:将强制 Java 分代垃圾收集标记扫描到双扫描.
罐头和罐头
- 会使克隆失败(这有好有坏)
- 可以制作不可变的原语，也就是 const
- 可以使空白不可变 - 在创建时初始化又名只读
- 可以使对象浅不可变
- 可以使范围/可见性不可变
- 可以使方法调用开销更小(因为它不需要虚拟表)
- 可以将方法参数用作 final(即使不是)
- 可以使对象成为线程安全的(如果对象被定义为final，它不会使方法参数成为final)
- 可以进行模拟测试(不是说您对此无能为力-您可以说是有意为之)
- 无法交朋友(与其他朋友可变，休息不变)
- 不能使以后变为不可变的可变(但可以使用工厂模式，如修复)
- 不能使数组元素不可变，也就是深度不可变
- 无法创建对象的新实例(这既好又坏)
- 无法使序列化工作
final 没有替代品，但有包装器 + 私有和枚举.
依次回答你的每一点:
<块引用>原始变量:只能设置一次.(内存和性能增益)
是的，但没有内存增益，也没有性能增益.(您假设的性能提升来自仅设置一次......而不是来自 final.)
objects 变量:可以修改，final 适用于对象引用.
是的.(但是，这个描述忽略了这一点，即这与 Java 语言的其余部分处理对象/引用二元性的方式完全一致.例如，当对象作为参数传递并作为结果返回时.)
<块引用>字段:只能设置一次.
真正的答案是:与变量相同.
<块引用>方法:不能被覆盖、隐藏.
是的.但也要注意，这里发生的事情是 final 关键字在不同的句法上下文中使用，以表示与字段/变量的 final 不同的含义.><块引用>
类:不能扩展.
是的.但也请参阅上面的注释.
<块引用>垃圾收集:将强制 Java 分代垃圾收集标记-扫描双重扫描.
这是无稽之谈.final 关键字与垃圾收集无关任何.您可能会将 final 与 finalization 混淆……它们是无关的.
但即使是终结器也不会强制执行额外的扫描.发生的情况是需要终结的对象被设置在一侧，直到主 GC 完成.GC 然后在对象上运行 finalize 方法并设置它的标志......并继续.下次 GC 运行时，该对象将被视为普通对象:
- 如果可以访问，则标记并复制它
- 如果无法访问，则不会对其进行标记.
(你的特征——Java 分代垃圾收集标记-扫描"是乱码.垃圾收集器可以是标记-扫描"或分代"(复制"的一个子类).不能两者兼而有之.Java 通常使用分代收集，只有在紧急情况下才会回退到标记清除；即当空间用完或低暂停收集器跟不上时.)
<块引用>可以使克隆失败(这有好有坏)
我不这么认为.
<块引用>可以制作不可变的原语，也就是 const
是的.
<块引用>可以使空白不可变 - 在创建时初始化又名只读
是的……虽然我以前从未听说过空白不可变"这个词.
<块引用>可以使对象浅不可变
对象可变性是关于可观察状态是否可以改变.因此，声明属性 final 可能会也可能不会使对象表现为不可变的.此外，浅不可变"的概念没有得到很好的定义，尤其是因为如果没有对类语义的深入了解，就无法映射浅"的概念.
(需要明确的是，变量/字段的可变性在 JLS 的上下文中是一个定义明确的概念.从 JLS 的角度来看，它只是未定义的对象可变性的概念.)
<块引用>可以使范围/可见性不可变
术语错误.可变性与对象状态有关.可见性和范围不是.
<块引用>可以使方法调用开销更小(因为不需要虚表)
在实践中，这无关紧要.如果非最终方法没有被应用程序实际使用的任何类覆盖，现代 JIT 编译器也会对非最终方法进行这种优化.(聪明的事情发生了......)
<块引用>可以使方法参数用作最终的(即使不是)
嗯?我无法解析这句话.
<块引用>可以使对象线程安全
在某些情况下是的.
<块引用>(如果对象被定义为final，它不会使方法参数成为final)
是的，如果您的意思是 class 是最终的.对象不是最终的.
<块引用>可以进行模拟测试(不是说您对此无能为力-您可以说是有意为之)
不解析.
<块引用>无法交朋友(与其他朋友可变，休息不可变)
Java 没有朋友".
<块引用>不能使以后变为不可变的可变(但可以使用工厂模式如修复)
对第一个来说是的，final 字段不能从可变转换为不可变.
不清楚你说的第二部分是什么意思.确实可以使用工厂(或构建器)模式来构造不可变对象.但是，如果您对对象字段使用 final ，则该对象在任何时候都不会是可变的.
或者，您可以实现使用非 final 字段来表示不可变状态的不可变对象，并且您可以设计 API 以便您可以翻转开关"使以前的可变对象从现在开始不可变.但是如果你采用这种方法，你需要更加小心同步......如果你的对象需要是线程安全的.
<块引用>不能使数组元素不可变，也就是深度不可变
是的，但是您的术语已损坏；请参阅上面关于浅可变性"的评论.
<块引用>不能创建对象的新实例(这有好有坏)
没有.没有什么能阻止您使用 final 字段或 final 类或 final 方法创建对象的新实例.
<块引用>无法使序列化工作
没有.序列化工作.(当然，使用自定义 readObject 方法对 final 字段进行反序列化存在问题……尽管您可以使用反射技巧来解决这些问题.)
除了final之外别无选择，
正确.
<块引用>但是有包装器+私有
是的，模(严格来说)非最终字段的非同步 getter 可能是非线程安全的......
<块引用>和枚举.
解决一个不同的问题.而 enums 可以是可变的.
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 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.
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
There are no alternatives to final, but there is wrapper + private and enums.
Answering each of your points in turn:
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.
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.
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.
garbage collection: will force Java generational garbage collection mark-sweep to double sweep.
This is nonsense. The final keyword has no relevance whatsoever to garbage collection. You might be confusing final with finalization ... they are unrelated.
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:
- if it is reachable it is marked and copied
- if it is not reachable it is not marked.
(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)
I don't think so.
Can make immutable primitives aka const
Yes.
Can make blank immutable - initialized at creation aka readonly
Yes ... though I've never heard the term "blank immutable" used before.
Can make objects shallowly immutable
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.
(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)
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 ...)
Can make method arguments used as final (even if thy are not)
Huh? I cannot parse this sentence.
Can make objects threadsafe
In certain situations yes.
(if object is defined as final, it wont make method arguments final)
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)
Doesn't parse.
Can't make friends (mutable with other friends and immutable for rest)
Java doesn't have "friends".
Can't make mutable that is changed to be immutable later (but can with factory pattern like fix)
Yes to the first, a final field can't be switched from mutable to immutable.
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.
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
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,
Correct.
but there is wrapper + private
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 最终修饰符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
