Сравнение содержимого StringBuffer с равными

] Вы сравниваете ссылки на объекты StringBuffer, а не на реальные строки внутри StringBuffer.[

][]System.out.println(sb1.toString().equals(sb2.toString()))[] вернет true, и я предполагаю, что это то, чего вы ожидали или хотели достичь.[

] оба сравнивают две ссылки на объекты (sb1 - одна, а sb2 - вторая), таким образом, обе они разные.[

] Если вы пытаетесь сравнить содержимое - используйте метод [] compareTo(. ...)[] в классе []String[] - то есть - сначала получим []String[] содержимое []StringBuffer[] с помощью метода []toString()[] ([]. toString().compareTo[]).[

]Ps. начиная с JDK 5, существует еще один гораздо более быстрый класс, который ведет себя точно так же, как []StringBuffer[] - это []StringBuilder[][], а также[], но он не является потокобезопасным. [

StringBuffer sb1 = new StringBuffer("Java"); 
StringBuffer sb2 = new StringBuffer("Java"); 

System.out.println(sb1.toString().compareTo(sb2.toString())); 

][]StringBuffer[] похоже не имеет собственного метода []равно[], так что мое первое предположение было бы, что []StringBuffer[] наследует []равно[] метод []Object[], который сравнивает с использованием []sb1 == sb2[]. Таким образом, оба метода дают один и тот же результат.[

Интересно, почему StringBuffer не отменяет метод равно. Вероятно, потому, что содержимое объекта получено методом toString() и имеет желаемый метод.

Простой ответ заключается в том, что StringBuffer (и StringBuilder ) не отменяют базовую семантику Object.equals () . Таким образом, равно в StringBuffer будет просто сравнивать ссылки на объекты.

Фактически, String , StringBuffer , StringBuilder и CharBuffer реализуют интерфейс CharSequence и javadoc для этого интерфейса говорит следующее:

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

Также обратите внимание, что javadocs для StringBuffer (и StringBuilder ) явно заявляет следующее:

Примечание API:

StringBuffer реализует Comparable но не отменяет равно . Таким образом, естественный порядок StringBuffer несовместим с равным .Следует проявлять осторожность, если объекты StringBuffer используются как ключи в SortedMap или элементы в SortedSet .

Но почему?

В основе этого лежит тот факт, что String является неизменяемым, а StringBuffer / StringBuilder - изменяемым.

• Если два объекта String имеют одинаковые символы, они всегда будут иметь одинаковые символы. Поэтому естественно рассматривать их как равные ... и это то, что делает String :: equals (Object) .

• Если два объекта StringBuffer могут иметь одинаковые символы сейчас и разные символы через мгновение ... из-за операции изменения, выполняемой другим потоком. Реализация equals (Object) для StringBuffer , чувствительного к (изменяющемуся) содержимому, будет проблематичной. Например:

   if (buf1.equals (buf2)) {
   // Сделайте что-нибудь с одним из объектов StringBuffer. 
  } 
   

  имеет потенциальную гонку условие. Другой пример - использование экземпляров StringBuffer в качестве ключей в HashTable или HashMap .

В любом случае, очень давно было принято намеренное дизайнерское решение, согласно которому StringBuffer и StringBuilder не отменят Object :: equals Методы и Object :: hashCode .