吸气剂是否对Java性能不利？

Question

Given the following two code options, is there any performance benefit (over a very large scale or a long period of time) of the second over the first?

Option 1

private Map<Long, Animal> animals = ...;
public Map<Long, Animal> getAnimals() {
    return animals;
}

public void useAnimals() {
    for (int i=0; i < SOME_LARGE_NUMBER; i++) {
        Animal animal = getAnimals().get(id);
    }
    // Many many calls to getAnimals() are made...
}

Option 2 - no getter

private Map<Long, Animal> animals = ...;

public void useAnimals() {
    for (int i=0; i < SOME_NUMBER; i++) {
        Animal animal = animals.get(id);
    }
    // No method calls made
}

If it is bad for performance, why, and how should I determine whether it is worth mitigating?

And, would storing the result of getAnimals() as a local provide a benefit...

• if SOME_NUMBER is hundreds or thousands?
• if SOME_NUMBER is only in the order of magnitude of 10?

---

Note : I previously said "encapsulation". I changed it to "getter" because the purpose is actually not that the field can't be modified but that it can't be reassigned. The encapsulation is simply to remove responsibility for assignment from subclasses.

Answer 1

Most likely JVM will inline getAnimals() invocation in tight loop effectively falling back to Option 1 . So don't bother, this is really a micro (nano?) optimization.

Another thing is migrating from field access to local variable. This sounds good since instead of traversing through this reference every time you always have a reference on the stack (two memory accesses vs. one). However I believe (correct me if I'm wrong) that since animals is private and non- volatile again JVM will perform this optimization for you at runtime.

Answer 2

The second snippet is more encapsulated than the first one. The first one gives access to the internal map to anyone, whereas the second keeps it encapsulated in the class.

Both will lead to comparable performance.

EDIT: since you change the question, I'll also change the answer.

If you go through a getter, and the getter is not final, it means that subclasses may return another map than the one you hold in the class. Choose whether you want your method to operate on the subclass's map or on the class's map. Both could be acceptable, depending on the context.

Anyway, suppose your subclass always makes a defensive copy of the map, you'll end up having many copies if you don't cache the result of the getter in a local variable of useAnimals . It might be required to always work on the latest value of the subclass's map, but I doubt it's the case.

If there is no subclass, or the subclass doesn't override the method, or override it by always returning the same map, both will lead to comparable performance and you shouldn't care about it.

Answer 3

Have you profiled this to see if it matter, for a modern JIT I would guess it would get optomized away, especially if animals was marked final but there is nothing stopping you from testing this yourself.

Either way, I am 100% this would NEVER be your bottle neck in an application.

Answer 4

Well, I don't think that JVM will inline the function call. So probably it may affect performance. The better way is to create local variable and assign class field animals to it.