访问器方法性能和优化

我经常遇到代码Getter方法被重复使用/滥用来获取某些值或将其作为方法参数传递，例如：

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());
   }
}

我通常编码如下：

public class Test {
   public void someMethod() {
      String name = person.getName();
      if(name != null && name.equalsIgnoreCase("Einstein")) {
           method1(name);
      }
      method2(name);
      method3(name);
      method4(name);
   }

在我看来，将 getter 分配给变量并使用它会带来相当大的内存/性能优势，因为 Getter 是 Java 方法并使用堆栈帧。以这种方式编码真的有很大的优势吗？ }

你profiled your opinion最近。

表现：

这可能是 1999-2001 年 1.2 之前的 JVM 中需要关注的微观优化，即使在那时我也会质疑它，除非有一些严肃的数字表明情况并非如此。

现代 JIT 实现会告诉您，今天您的opinion不合适。

现代编译器实现会进行各种优化，这使得在 Java 中思考此类问题是浪费时间。 JIT 只会让担忧变得更加浪费。

Logic:

在并发情况下，您的两个代码块在逻辑上并不等效，如果您想查看更改，则制作本地副本将阻止这种情况。根据您想要做什么，一种或另一种方法可能会产生非常微妙的非确定性错误，这些错误在更复杂的代码中很难确定。

特别是如果返回的是可变的东西，不像String这是不可变的。然后，即使是本地副本也可能会发生变化，除非您进行了深度克隆，而且这很容易很快出错。

关心自己与做它正确地, then 衡量并优化重要的内容只要它不会降低代码的可维护性。

JVM 将内联任何调用final实例成员并删除方法调用（如果方法调用中除了return this.name;它知道访问器方法中没有逻辑，并且它知道引用是final所以它知道它可以内联该值，因为它不会改变。

为此

person.getName() != null && person.getName().equalsIgnoreCase("Einstein") 

更正确地表达为

person != null && "Einstein".equalsIgnoreCase(person.getName())

因为没有机会拥有NullPointerException

重构：

现代 IDE 重构工具也消除了有关必须在很多地方更改代码的争论。