访问器方法的性能和优化 [英] Accessor Method Performance and Optimization
问题描述
通常，我会碰到重复使用/滥用 Getter 方法以获得某些值或将其作为方法参数传递的代码，例如：
公共类测试{
public void someMethod（）{
if（person.getName（）！= null&& person.getName（ ）.equalsIgnoreCase（ Einstein））{
method1（person.getName（））;
}
method2（person.getName（））;
method3（person.getName（））;
method4（person.getName（））;
}
}
我通常将其编写如下：
公共类测试{
public void someMethod（）{
字符串名称= person.getName（）;
if（name！= null&& name.equalsIgnoreCase（ Einstein））{
method1（name）;
}
method2（name）;
method3（name）;
method4（name）;
}
在我看来，将吸气剂分配给变量并使用它，因为Getters是Java方法并使用堆栈框架。这样编码是否真的有相当大的优势？
}
您最近简要介绍了您的意见 。
性能：
这可能是微观优化，在1999年至2001年使用1.2之前的JVM进行处理，即使这样，除非有一些严重的数字表明，否则我还会质疑它。
现代JIT实现会告诉您今天，您的观点不合适了。
现代编译器实现会进行各种优化，从而使这种思考变得浪费。 Java时间。 JIT只是使它更加令人担忧。
逻辑：
<在并发情况下，您的两个代码块在逻辑上并不等效，如果您想查看更改，则进行本地复制将防止这种情况。根据您要执行的操作，一种或另一种方法可能会创建非常细微的不确定性错误，而这些错误很难用更复杂的代码来确定。
特别是返回的内容是可变的，与 String 是不可变的。然后，甚至本地副本也可能会发生变化，除非您进行了深层克隆，否则很快就很容易出错。
关注自己 >正确地进行操作，然后测量并优化重要的内容，只要它不会使代码的可维护性降低。
JVM将内联对 final 实例成员的所有调用，如果方法调用中除 final ，因此它知道可以内联
为此，
person.getName（）！=空&& person.getName（）。equalsIgnoreCase（ Einstein）
更正确地表示为
person！=空&& Einstein .equalsIgnoreCase（person.getName（））
因为没有机会 NullPointerException
重构：
现代的IDE重构工具也消除了有关必须在很多地方更改代码的任何争论。
Often, I come across code where the Getter method is repeatedly used/abused to get some value or pass it as a method parameter, for ex:
public class Test {
public void someMethod() {
if(person.getName() != null && person.getName().equalsIgnoreCase("Einstein")) {
method1(person.getName());
}
method2(person.getName());
method3(person.getName());
method4(person.getName());
}
}
I usually code it, as below:
public class Test {
public void someMethod() {
String name = person.getName();
if(name != null && name.equalsIgnoreCase("Einstein")) {
method1(name);
}
method2(name);
method3(name);
method4(name);
}
In my opinion, there is considerable memory/performance advantage in assigning the getter to a variable and using it, as Getters are Java methods and use stack frames. Is there really a considerable advantage in coding that way? }
Have you profiled your opinion lately.
Performance:
This might have been a micro-optimization that was something to be concerned with in 1999-2001 in a pre-1.2 JVM and even then I would have questioned it unless some serious numbers showed otherwise.
Modern JIT implementations would tell you that today that your opinion is out of place.
Modern compiler implementations do all kinds of optimizations that make thinking about things like this a waste of time in Java. The JIT just makes it even more of a waste of concern.
Logic:
In a concurrent situation, your two code blocks are not logically equivalent, if you want to see changes, making the local copy will prevent that. Depending on what you want to do, one or the other approaches could create very subtle non-deterministic bugs that would be very hard to pin down in more complicated code.
Especially if what was return was something mutable unlike a String which is immutable. Then even the local copy could be changing, unless you did a deep clone, and that gets really easy to get wrong really quickly.
Concern yourself with doing it correctly, then measure and then optimize what is important as long as it doesn't make the code less maintainable.
The JVM will inline any calls to final instance members and remove the method call if there is nothing in the method call other than the return this.name; It knows that there is not logic in the accessor method and it knows the reference is final so it knows it can inline the value because it will not be changing.
To that end
person.getName() != null && person.getName().equalsIgnoreCase("Einstein")
is expressed more correctly as
person != null && "Einstein".equalsIgnoreCase(person.getName())
because there is no chance of having a NullPointerException
Refactoring:
Modern IDE refactoring tools remove any arguments about having to change code in a bunch of places as well.
这篇关于访问器方法的性能和优化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
