in class String I often see member variables copied to local variables.In java.nio.Buffer I don't see that (e.g. for "position" in nextPutIndex(int nb))
关于这个问题,各个地方的说法不一。
具R大说,现在的jvm已经足够智能,这种优化不需要手动来做了。
in class String I often see member variables copied to local variables.In java.nio.Buffer I don't see that (e.g. for "position" in nextPutIndex(int nb)).Now I'm wondering. From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile variables in a cache for each thread, so e.g. even in CPU register for few ones. From this knowing, I don't understand, why doing the local caching manually in String (and many other classes), instead trusting on the JVM.
原文是:
It's ultimately due to the fundamental mismatch between memory models and OOP :-) Just about every method in all of j.u.c adopts the policy of reading fields as locals whenever a value is used more than once. This way you are sure which value applies when. This is not often pretty, but is easier to visually verify. The surprising case is doing this even for "final" fields. This is because JVMs are not always smart enough to exploit the fine points of the JMM and not reload read final values, as they would otherwise need to do across the volatile accesses entailed in locking. Some JVMs are smarter than they used to be about this, but still not always smart enough.
总结:在性能核心部分,是有效果的(所以j.u.c和Netty大量这样搞)。 juc那么写是因为一开始就那么写(考虑到当时的jvm的现代化),而且单纯来看,local variable跟 get filed 是有性能差异,是否jvm能优化,在于是否同一个方法中重复使用了该字段,而且该jvm不会重复去reload。 讲的是其他引用类型,那写需要用 ALOAD_x 从LVT加载的引用类型。基本类型,又是final,在compile阶段就优化掉了。而且普遍来看,除非是为了追求“极致性能”,否则不建议这么做。