Путаница с равным методом

Question

Всякий раз, когда я использую метод equals () с двумя разными объектами StringBuffer, я получаю результат как false, но когда я использую метод equals () с двумя разными объектами String, я получаю результат как true. Почему?

    String s=new String("434");
    String s1=new String("434");

    System.out.println(s.equals(s1));//true

   StringBuffer s=new StringBuffer("434");
   StringBuffer s1=new StringBuffer("434");

   System.out.println(s.equals(s1));//false

Answer 1

StringBuffer не переопределяет equals (). Также вызывается Object.equals (), который сравнивает идентификатор объекта (адрес памяти). String переопределяет equals и сравнивает содержимое.

Answer 2

StringBuffer не переопределяет Object # equals () , поэтому вы испытываете проверки на основе ссылочной идентичности , а не значение проверки на основе. Поскольку эти экземпляры StringBuilder различны, каждый из них имеет разные области памяти, базовая реализация Object # equals () всегда будет возвращать false.

Вот определение для Java 6:

public boolean equals(Object obj) {
  return (this == obj);
}

Видите проблему?

Answer 3

По крайней мере, в моей версии JDK (Sun 1.6) StringBuffer не реализует метод equals (). Это означает, что он наследует метод equals () объекта, который совпадает с ==

Если вы действительно хотите проверить два StringBuffers на равенство, вы можете вызвать x.toString (). equals (y.toString ())

Answer 4

Если вы хотите сравнить представления String двух объектов StringBuffer, то вам нужно сделать следующее:

StringBuffer sb1 = new StringBuffer("434");
StringBuffer sb2 = new StringBuffer("434");
if (sb1.toString().equals(sb2.toString())) {
  // whatever you want to do if they're equal
} else {
  // whatever you want to do if they're not
}

В противном случае вы сравниваете равенство двух объектов объекта StringBuffer , а не их содержимого - другими словами, выполнение Object # equals (), а не (несуществующего) StringBuffer # equals ().

Answer 5

equals возвращает true только для объектов StringBuffer, когда два объекта совпадают. Чтобы сравнить StringBuffers так, как вы хотите, используйте это:

System.out.println(s.toString().equals(s1.toString());

Answer 6

String s.equals будет использовать таблицу строк для сравнения фактических строк, где в качестве StringBuffer sb.equals будет просто использовать реализацию по умолчанию метода equals и просто сравнивать указатели объектов.

Answer 7

StringBuffer не имеет своей собственной реализации метода equals, он наследует метод equals () от класса объекта, поэтому значения хеш-значений сравниваются, а не сравниваются с фактическим содержимым в stringBuffer. Следовательно, мы должны явно привести его к строковому объекту, который обеспечивает реализацию метода equals ().

Answer 8

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

Напротив, переменная типа StringBuffer инкапсулирует не только последовательность символов, но также identity для экземпляра конкретного . Если две переменные ссылаются на один и тот же экземпляр, изменение экземпляра, на который ссылается одна переменная, повлияет на экземпляр, на который ссылается другая (поскольку это один и тот же экземпляр). Если они ссылаются на разные экземпляры, изменения в экземпляре, на который ссылается один, не влияют на экземпляр, на который ссылается другой. Решение не использовать Java StringBuffer override equals не было результатом лени, а скорее основывалось на том факте, что объекты StringBuffer имеют значимая идентичность и непересекающиеся экземпляры всегда имеют разные идентичности.