Рассмотрим этот метод (только для иллюстрации):
boolean isSmallNumber(String s) {
return (n in ["one", "two", "three", "four"]);
}
Это, конечно, не Java, но это может быть на вашем любимом альтернативном языке, который поддерживает литералы коллекции, такие как Groovy или Kotlin. Выражение лаконично и, подобно строковым литералам, компилятору разрешено помещать литерал коллекции в некоторую статическую область хранения (возможно, даже "intern()"
).
Теперь введите Java 9:
boolean isSmallNumber(String s) {
return Set.of("one", "two", "three", "four").contains(s);
}
Это также красноречиво, но, к сожалению, каждый раз, когда вы его вызываете, он выделяет новый набор в кучу, а затем сразу же делает его доступным для сбора мусора.
Вы можете, конечно, определить константу коллекции:
private static final Set<String> SMALL_NUMBERS = Set.of(...);
Но тогда это определение может быть в тысячах строк от определения метода в большом классе, и вы, возможно, не сможете думать о хорошем описательном имени для него, тогда как литерал может быть более ясным (в этом гипотетическом случае).
Итак, если я использую Set.of(...)
внутри метода, компилятор JIT оптимизирует создание нового объекта каждый раз при вызове метода?