Не так давно в своей карьере я тоже выучил наизусть версию самой старой мантры из книги для интервью разработчиков Java.
Что-то вроде:
== сравнивает ссылки на объекты, а .equals() сравнивает все, что определено в переопределенном методе класса, для которого он вызывается.
Если переопределение не указано, по умолчанию используется Object.equals().
Такие посты, как этот и тот, придавали некоторую уверенность в том, что я говорил.
Несколько лет спустя, когда я готовился к своей первой сертификации по Oracle Java, я узнал об этом предмете гораздо подробнее и смог подробно рассказать о нем и по-настоящему проявить себя в этой части процесса собеседования или просто использовать его в качестве случайного подобрать линию.
Интересно, что около 20% людей, у которых я сейчас беру интервью, по-прежнему либо не полностью правильно отвечают на этот вопрос, либо просто не могут вдаваться в подробности той роли, на которую они претендуют.
Задавать этот вопрос в процессе собеседования — клише, но это сэкономит вам время, если вы сделаете это тактично и достаточно рано, например, во время телефонного скрининга.
Несколько лет спустя я работал в магазине Java в Лиссабоне под названием Linkare, где мне выпала честь прикоснуться к совершенно уникальной кодовой базе под названием e-lab.
К моему удивлению, я увидел, что некоторые сравнения строк выполняются с помощью ==, а не .equals(). Назовите это отсутствием опыта, запуском счастливого фиксера, наивностью ради себя или старой доброй самонадеянностью. Я начал вносить поправки в эту кодовую базу только для того, чтобы увидеть, как наш технический директор откатил их.
Оглядываясь назад, я должен был догадаться, что кто-то, кто основал компанию с духом Java Excellence, не просто забыл бы переопределить метод equals. Двойная ретроспектива: даже спрашивать было бы менее высокомерно, чем работать с поиском и заменой.
Несколько дней спустя, во время того, что всегда было похоже на семейный обед, 30 или около того разработчиков Linkare собрались вместе на очень непринужденный, веселый обед, где я наконец получил возможность услышать очень подробное объяснение того, почему мой код меняется. не был принят.
Оказывается, конкретный проект выполнялся как драйвер Java, поддерживающий очень тесную, контролируемую и предсказуемую связь с неким кодом C более низкого уровня, который обрабатывал состояние и обновления некоторых механических битов, которые, в свою очередь, служили удаленными лабораторными экспериментами.
Поскольку в JVM ВСЕ ее IO были предсказаны и ограничены, код был совершенно функциональным и правильным, чтобы использовать == для достижения полного уровня производительности, который в противном случае был бы рассеян через немного более длительное время. стек вызовов для вызова метода equals.
Этот метод работает из-за особого способа обработки строк в пулах в Java. Вы можете прочитать больше об этом здесь, но, по сути, создание строк настолько распространено, что реализация их с помощью приспособленческого шаблона означала, что JVM может сбрасывать множество крошечных битов памяти на протяжении всего жизненного цикла работающего приложения.
Теперь у меня есть более интересная история, которую я могу рассказать, когда меня спросят: «В чем разница между == и .equals()?»
