Как использование оператора == повышает производительность по сравнению с оператором equals?

Если каждый класс может гарантировать, что a.equals(b) тогда и только тогда, когда a==b , это означает, что он вводит косвенное требование о том, что не может быть объектов, ссылающихся на 2 разных пространства памяти, и при этом хранить одни и те же данные, то есть память. растрата . Если они содержат одни и те же данные, они являются одним и тем же объектом. То есть они указывают на одно и то же место в памяти.

Да, именно на это и претендует автор.

Если вы можете (для данного класса это будет невозможно для всех, в частности, это не может работать для изменяемых классов) вызовите == (который является единственным кодом операции JVM) вместо equals (который является динамически отправляемым вызовом метода), это экономит (некоторые) накладные расходы.

Это работает, например, для enums.

И даже если бы кто-то вызвал метод equals (что было бы хорошей практикой защитного программирования, вы не хотите привыкать использовать == для объектов ИМХО), этот метод можно было бы реализовать как простой == (вместо того, чтобы искать при потенциально сложном состоянии объекта).

Между прочим, даже для «обычных» методов equals (таких как String) в их реализации, вероятно, будет хорошей идеей сначала проверить идентичность объекта, а затем быстро просмотреть состояние объекта (что и делает String#equals, когда вы узнали).

Цитата означает, что неизменяемый класс может выбрать интерн его экземпляры. Это легко реализовать с помощью Interner, например:

public class MyImmutableClass {
    private static final Interner<MyImmutableClass> INTERN_POOL = Interners.newWeakInterner();
    private final String foo;
    private final int bar;

    private MyImmutableClass(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }

    public static MyImmutableClass of(String foo, int bar) {
        return INTERN_POOL.intern(new MyImmutableClass(foo, bar));
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(foo, bar);
    }

    @Override
    public boolean equals(Object o) {
        if (o == this)
            return true;        // fast path for interned instances
        if (o instanceof MyImmutableClass) {
            MyImmutableClass rhs = (MyImmutableClass) o;
            return Objects.equal(foo, rhs.foo)
                    && bar == rhs.bar;
        }
        return false;
    }
}

Здесь конструктор делается закрытым: все экземпляры должны проходить через метод фабрики MyImmutableClass.of(), который использует Interner, чтобы гарантировать, что если новый экземпляр является equals() по отношению к существующему экземпляру, вместо него будет возвращен существующий экземпляр.

Интернирование может использоваться только для неизменяемых объектов, под которыми я подразумеваю объекты, чье наблюдаемое состояние (т. е. поведение всех доступных извне методов, в частности equals() и hashCode()) не изменяется для объектов. жизни. Если вы интернируете изменяемые объекты, поведение будет неправильным при изменении экземпляра.

Как уже говорили многие другие люди, вы должны тщательно выбирать, какие объекты интернировать, даже если они неизменяемы. Делайте это только в том случае, если набор интернированных значений мал по сравнению с количеством дубликатов, которые у вас могут быть. Например, не стоит интернировать Integer вообще, потому что существует более 4 миллиардов возможных значений. Но стоит интернировать наиболее часто используемые Integer значения, и на самом деле Integer.valueOf() интернирует значения между -128 и 127. С другой стороны, перечисления отлично подходят для интернирования (а они интернированы по определению), потому что множество возможных значения небольшие.

В целом для большинства классов вам придется выполнять анализ кучи, например, с помощью jhat (или, чтобы подключить мой собственный проект, fastthat), чтобы решить, достаточно ли дубликатов для интернирования. В других случаях просто будьте проще и не стажируйтесь.

Если вы можете гарантировать, что не существует двух экземпляров объекта с эквивалентными семантическими значениями (т. е. если x и y относятся к разным экземплярам [x != y], то x.equals(y) == false для всех x и y), то это означает, что вы можете сравнивать две ссылки. ' объекты на равенство, просто проверяя, ссылаются ли они на один и тот же экземпляр, что и делает ==.

Реализация ==, по сути, просто сравнивает два целых числа (адреса памяти) и, как правило, будет быстрее, чем практически все нетривиальные реализации .equals().

Стоит отметить, что это не переход, который может быть выполнен для Strings, так как вы не можете гарантировать, что любые два экземпляра String не эквивалентны, например:

String x = new String("hello");
String y = new String("hello");

Поскольку x != y && x.equals(y) недостаточно просто выполнить x == y для проверки на равенство.

Чтобы ответить на ваши вопросы...

Что он имеет в виду под улучшением производительности здесь [String]? Как это улучшает производительность.

Это НЕ пример того, о чем говорит Блох. Блох говорит о классах, управляемых экземпляром, а String таким классом не является!

Прав ли я в этом выводе?

Да это верно. Класс, управляемый экземплярами, экземпляры которого являются неизменяемыми, может гарантировать, что "одинаковые" объекты всегда будут равны в соответствии с оператором ==.

Однако некоторые наблюдения:

• Это относится только к неизменяемым объектам. Или точнее к объектам, где мутация не влияет на семантику равенства.

• Это относится только к классам, полностью контролируемым экземпляром.

• Контроль экземпляра может быть дорогим. Рассмотрим форму (частичного) управления экземпляром, предоставляемую методом intern класса String и пулом строк.

  • Пул строк фактически представляет собой хеш-таблицу слабых ссылок на объекты String. Это занимает дополнительную память.

  • Каждый раз, когда вы интернируете String, он вычисляет хэш-код строки и проверяет хэш-таблицу, чтобы узнать, не была ли уже интернирована аналогичная строка.

  • Каждый раз, когда выполняется полный сборщик мусора, слабые ссылки в пуле строк приводят к дополнительной работе по «отслеживанию» для сборщика мусора, а затем, возможно, к дополнительной работе, если сборщик мусора решит сломать ссылки.

  Обычно вы получаете аналогичные накладные расходы, когда реализуете свои собственные классы, управляемые экземпляром. При анализе затрат и результатов эти накладные расходы учитываются в сравнении с преимуществами более быстрого сравнения экземпляров.

Я думаю, это означает следующее:

Если вам нужно проверить две сложные структуры на равенство, вам обычно нужно выполнить много тестов, чтобы убедиться, что они одинаковы.

Но если из-за какой-то хитрости языка вы знали, что две сложные, но одинаковые структуры не могут существовать одновременно, то вместо проверки равенства путем их побитового сравнения вы можете просто проверить, что они находятся в одном и том же месте в памяти, и вернуть false, если они не.

Если кто-то может создавать объекты, вы не можете гарантировать, что два одинаковых объекта не могут быть созданы, но являются разными экземплярами... но если вы контролируете создание объектов и создаете только отдельные объекты, вам не нужно сложное равенство тесты.

В тех случаях, когда сложные значения инкапсулируются с помощью ссылок на неизменяемые объекты, при сравнении двух ссылок обычно могут возникнуть три сценария:

• Это ссылки на один и тот же объект (очень быстро)

• Это ссылки на разные объекты, которые инкапсулируют разные значения (часто быстрые, но иногда медленные).

• Это ссылки на разные объекты, которые инкапсулируют одно и то же значение (обычно всегда медленное).

Если объекты чаще всего будут обнаруживаться равными, чем нет, то минимизация частоты случая 3 может иметь существенное значение. не бывает очень часто.

Если убедиться, что для любого заданного значения никогда не будет более одного объекта, который содержит это значение, код, который наблюдает, что две ссылки идентифицируют разные объекты, может сделать вывод, что они инкапсулируют разные значения, без необходимости фактически проверять рассматриваемые значения. Однако ценность этого часто несколько ограничена. Если рассматриваемые объекты являются большими, сложными, вложенными коллекциями, которые иногда будут очень похожими, можно заставить каждую коллекцию вычислить и кэшировать 128-битный хеш ее содержимого; две коллекции с разным содержимым вряд ли будут иметь совпадающие хеш-значения, а коллекции с разными хеш-значениями могут быть быстро распознаны как неравные. С другой стороны, наличие ссылок, которые инкапсулируют одно и то же содержимое, обычно идентифицируются с одним и тем же объектом, даже если существует несколько ссылок на идентичные коллекции, может повысить производительность всегда плохих "равных" значений. кейс.

Подход, который можно было бы использовать, если вы не хотите использовать отдельную промежуточную коллекцию, состоял бы в том, чтобы каждый объект сохранял порядковый номер long, чтобы всегда можно было определить, какой из двух в остальном идентичных объектов был создан первым, вместе со ссылкой к самому старому объекту, который, как известно, содержит то же самое содержимое. Чтобы сравнить две ссылки, начните с определения самого старого объекта, который, как известно, эквивалентен каждой из них. Если самый старый объект, который, как известно, соответствует первому, не совпадает с самым старым объектом, который, как известно, соответствует второму, сравните содержимое объектов. Если они совпадают, один будет новее другого, и этот объект может рассматривать другой как «самый старый объект, который, как известно, соответствует».