В каком контексте значение класса String является неизменяемым в отличии от StringBuilder?

Question

[MishaXXL]

Почему нужно было помимо класса Stringсоздавать дополнительные классы по типу StringBuilder?

Из учебника.

Класс String аналогичен классу StringBuilder за исключением того, что он является неизменяемым.

1. По поводу изменения
В данном примере строка s спокойно изменяется путем конкатенации, что аналогично sb.append

2. Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

3. Почему s.equals(sb) равно false, если мы сравниваем только значения, а не ссылки
Значения у нас типа String, длина строк и символы одинаковые.

public class MyClass {
    public static void main(String args[]) {
        String s = "Hello";
        s += " Java!";
        
        String s2 = new String("Hello Java!");
        
        StringBuilder sb = new StringBuilder("Hello");
        sb.append(" Java!");
        
        System.out.println(s.equals(s2));
        System.out.println(s.equals(sb));
    }
}

Наткнулся на код из статьи и не понял для чего тут используют StringBuilderс append, а не просто Stringс конкатенацией, ведь после всё равно превращают его в String.
Для чего здесь эти манипуляции с классами String и почему здесь не обошлись без StringBuilder?

StringBuilder requestBuilder = new StringBuilder();
String line;
while (!(line = br.readLine()).isBlank()) {
   requestBuilder.append(line + "\r\n");
}
String request = requestBuilder.toString();
String[] requestsLines = request.split("\r\n");

Ссылка на статью
https://dev.to/mateuszjarzyna/build-your-own-http-...

Comments

[Everything_is_bad]

и что в учебниках даже это не объясняют? и в гугле про не это не написано?

[Ivan Ustûžanin]

ЕМНИП, любые изменяющие операции над String приводят к созданию нового объекта, т.к. строка immutable

например, str += "append" это копирование имеющегося контента в str и "append" в новую строку, что для малых строк не так принципиально, однако делает эту операцию внезапно O(n), т.е. линейной, от содержимого строки, что становится заметным при использовании в циклах и при больших размерах строк

Answer 1

[Dmitry Roo]

Почему нужно было помимо класса String создавать дополнительные классы по типу StringBuilder?

Потому, что String - иммутабельный класс. Чтобы конструировать строки как раз добавлены StringBuffer (в версии 1.0) и StringBuilder (в 1.5).

В данном примере строка s спокойно изменяется путем конкатенации, что аналогично sb.append

В итоге у вас каждый раз создается новый объект. Не всегда это бывает уместно.

2. Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Потому, что это нарушает принцип единой ответственности. Так же можно заметить, что мысль не стоит на месте и со временем появляются новые методы для конструирования строк.

3. Почему s.equals(sb) равно false, если мы сравниваем только значения, а не ссылки

Потому, что вы сравниваете разные объекты. StringBuilder - это не String.

Answer 2

[Дмитрий Кинаш]

1. Нет! Строки неизменяемые. Конкатенация строк - это операция по созданию нового объекта с новой ссылкой.

2. String это базовый тип для Java, а StringBuilder добавили только в 5-ю версию. Апгрейд существующего класса не стали делать по соображениям совместимости и чтобы не поломать String Pool, который для билдера не имеет смысла.

3. Потому что это разные типы!!! Хотите, чтобы String и StringBuilder сравнивались по содержимому? Делайте дочерние классы, в которых переопределяйте сравнение, а потом экземпляры своих классов присвойте переменным типов String и StringBuilder - магия, сравнение заработало!

Answer 3

[mayton2019]

Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Главный поинт при создании immutable String - безопасность кода. Когда компиллятор точно
знает что value строки не изменится - то он может доказать много кейсов и гарантировать что
разделяемая память не будет сломана. Особенно это важно для мультипоточки. Когда
разные потоки владеют строкой и здесь сам вопрос доказательства вдруг становится очень важным.

Язык С++ например такой защитой не обладает и для него строка как фундаментальный тип
может иногда мутировать. Тоесть если вы старались писать правильно то она конечно не мутирует.
Но в этом есть большая разница между C++ и Java. На уровне платформы гарантировано отсуствие
какого-то класса ошибок.

StringBuilder - это попытка улучшить перформанс для кумулятивных строк. Тоесть например
если вы формируете текстовый файл-отчет в памяти то вы будете постоянно делать конкатенации
строк. Это конкатенации вызовут аллокацию-уничтожение памяти. (в скобочках помним
что строка - не мутабельная поэтому изенить ее можно только создав новую копию с добавлением
чего-то нового. Причем с учетом роста самой строки , драматично будет расти эффект нагрузки на память.

Специально для уменьшения этой проблемы (реаллокации и копирования) был создан StringBuilder.
Это вообще не строка а как-бы мутирующий буфер куда можно добавлять в хвост строки. И в конце
когда все готово - из буфера берется иммутабельная строка и на этом работа билдера закончена.

Immutable строки - это гениальное изобретение. Оно реализовано во многих языках и платформах
и оно практически спасает разработчика бизнес-приложений от трудно уловимых ошибок.

Comments

[MishaXXL]

Если я правильно понял, то Stringэто массив символов с ограниченной длинной, чтобы экономить память и при каждой конкатенации мы создаем новый массив.
А StringBuilderэто массив без ограничения по длине и по этому он более ресурсоемкий?

[mayton2019]

MishaXXL, нет. И String и StringBuilder могут создать строку ~ до 2 млрд символов. Максимальный
размер int аргумента для аллоцируемого массива символов.

Просто append в StringBuilder - это легкая операция а "+" для двух строк - тяжелая потому что
создает в памяти третью строку которая по сумме равна двум слагаемым.

Answer 4

[Сергей Горностаев]

Во-первых, при конкатенации строк создаётся новая строка. Выполните в цикле миллион конкатенаций, получите миллион ненужных объектов, сожрете память, нагрузите сборщик мусора, программа начнёт тормозить, и ваш наниматель вас уволит. Во-вторых, строки - один из самых часто используемых классов в java-программах, поэтому очень важно, чтобы операции с ними были быстрыми, и именно неизменяемость строк позволила их очень сильно оптимизировать.

Послушайте, если осилите.

Comments

[MishaXXL]

Спасибо, подскажи пожалуйста
В примере со статьи

StringBuilder requestBuilder = new StringBuilder();
String line;
while (!(line = br.readLine()).isBlank()) {
   requestBuilder.append(line + "\r\n");
}
String request = requestBuilder.toString();
String[] requestsLines = request.split("\r\n");

В данном месте все приводится к строке потому что она занимает меньше памяти и ресурсов?
String request = requestBuilder.toString();

И после этого будет правильно еще добавить?
requestBuilder = null;

Что бы сборщик мусора сразу явно очистил память

[Сергей Горностаев]

MishaXXL, потому что сам по себе стрингбилдер бесполезен, всë работает со строками. Занулять переменные бесполезно. Иногда может быть полезно занулять поля, но это зависит от кода.

[MishaXXL]

Сергей Горностаев, тысяча извинений, для уточнения, подскажите такой момент
Нужно использовать StringBuilder в случае, когда нам неизвестно финальное значение строки, а при окончании ее составления, передавать его значение методом toString() обычному объекту строки?
И это переопределение из StringBuilderв Stringтолько из-за того, что через String str проще выводить значение через str, чем каждый раз делать StringBuilder.toString()?
Плюс мы не сможем из StringBuilderсделать массив в отличии от String, верно?

При работе с итерацией, где мы сделаем 20 раз

String str = "string";
for(int i = 0; i < 20; i++)
   str += текст из 300 букв

В таком случае мы же не можем навредить памяти, речь шла, если мы работаем с очень большим текстом и или в итерациях более 100?
Как то, что это дурной тон, я понял, но в цифрах это же смертельно только с большими текстами или тысячными итерациями?

[Сергей Горностаев]

MishaXXL,

Нужно использовать StringBuilder в случае, когда нам неизвестно финальное значение строки, а при окончании ее составления, передавать его значение методом toString() обычному объекту строки?

Да, если вам надо собрать строку, используете StringBuilder.

И это переопределение из StringBuilderв Stringтолько из-за того, что через String str проще выводить значение через str, чем каждый раз делать StringBuilder.toString()?

Не только. Ещё потому, например, что StringBuilder не является потокобезопасным и нельзя использовать в конкурентной среде без синхронизации.

Плюс мы не сможем из StringBuilderсделать массив в отличии от String, верно?

Не верно. Ни что не мешает сделать StringBuilder[] builders = new StringBuilder[42]

В таком случае мы же не можем навредить памяти, речь шла, если мы работаем с очень большим текстом и или в итерациях более 100?

В приведённом коде вы создали 20 лишних строк. Если это консольная программа, то вообще не проблема. Если это web-сервис, который может вызываться кем попало сколько угодно раз, то у вас нет гарантий, что его не вызовут миллион раз в секунду, создав 20 миллионов строк.

[MishaXXL]

Сергей Горностаев, спасибо!

StringBuilder не является потокобезопасным и нельзя использовать в конкурентной среде без синхронизации.

Можете пожалуйста привести примеры, что за конкурентная среда, если мы завершили сбор нашей строки, то что нам мешает оставить ее в StringBuilder, если тот же Stringтак же не защищен от изменений путем конкатенации?

[Сергей Горностаев]

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

[MishaXXL]

Сергей Горностаев, я тысячекратно извиняюсь, не сочтите за дерзость.

Подскажите пожалуйста хороший материал про Buffer
До этого вы давали ссылку на доклад о String, который внес некую дополнительную ясность к вашим словам (хотя из понятного была только первая половина доклада, до второй я видимо еще мал).

Решив обработать запрос на сервере, столкнулся с проблемой понимания буфера на низком уровне

Когда я какой-то магией получил данные в буфер, было всё в порядке

BufferedReader buffer = new BufferedReader(new InputStreamReader(client.getInputStream()));

После я решил, что наверно набором данных типа буфер просто манипулировать
Например, получить из байт, которые хранятся в нашем буфере, как полученные данные
В строку

Но следующие строки кода из статьи меня вогнали в ступор
Со стрингбилдером мы разобрались, это уже свой парень
Но почему я просто не могу из переменной bufferполучить данные в виде строки, например, buffer.toString();

К чему эта сложность с циклом, да еще чтением и проверкой
while (!(line = buffer.readLine()).isBlank())

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

StringBuilder requestBuilder = new StringBuilder();
String line;
while (!(line = buffer.readLine()).isBlank()) {
    requestBuilder.append(line + "\r\n");
}

В попытках найти ответ, попалась статья
https://javarush.com/quests/lectures/jru.module1.l...

Где буферу нужно всегда определять длину

ByteBuffer byteBuffer = ByteBuffer.allocate((int) channel.size());

А длина, как я понял

FileChannel channel = randomAccessFile.getChannel();

Получается при чтении файла, который содержит информацию, сколько ячеек памяти занимает файл
Как и наши запросы, перед отправкой, как я понял, так же сервер получает данные о том, сколько ячеек памяти нужно выделить под буфер для загрузки файла на сервер

Но дальше обработка буфера происходит уже другим образом
Уже не readLine(), а hasRemaining()
Причем так же непонятно, каким образом у нас цикл сам завершится без каких-либо сторонних флагов

while (byteBuffer.hasRemaining()) {
       builder.append((char) byteBuffer.get());
}

В итоге я немного запутался и поиск статей на эту тему ситуации не прояснил.
Хотя первоначальная задача казалось элементарной, просто прочитать http запрос и обработать его.

Помогите пожалуйста с разьяснением ситуации.

[Сергей Горностаев]

MishaXXL, я учился по учебникам и официальной документации, чего и всем желаю.

[MishaXXL]

Сергей Горностаев, подскажи пожалуйста хороший актуальный учебник, чтобы из основ Java плавно закончить полным пониманием работы Web серверов.

[Сергей Горностаев]

MishaXXL, это наверняка будет не один учебник. По одной только Java стоит прочитать минимум 3-4. Подсказать мне сложно, сам я учился больше 20 лет назад, причём переходил в Java из C.

Answer 5

[My1Name]

Массив — структура данных хранящая набор значений, в простейшем случае фиксированой длины. Массивы не всегда удобно использовать, поэтому ряд языков программирования поддерживают динамические массивы и, Java один из таких языков. ⇨ Данные типа String - это массив char-ов в таких языках как Pascal, C, C++, Java и др.. В Java все строковые литералы помещаются в специальный объект (класс) под который выделяется память, а уже адрес этого объекта помещается в переменную, под которую тоже выделяется память. Java коллекции расширяют возможности работы с массивами и это пожалуй ответ на все ваши вопросы.
https://javarush.com/quests/lectures/questsyntaxpr...

Например, если вы заполните HashSet<String> то сможете проверить наличие определенного String-а в массиве строк, заменив s.equals(sb) на list.contains(sb) Такой код будет работать в оперативной памяти используя hashcode (32 битный идентификатор объекта). Это работает быстро и эффективно, так как числовые значения гораздо легче и быстрей сравнить. Однако, каждая строка будет представлять собой отдельный объект и занимать свою ячейку в памяти.

При конкатенации происходит приблизительно то же самое: Создаётся массив, где каждая строка - это отдельный объект (массив) разного размера. В момент конкатенации создаётся новый объект типа String с размером == сумма двух String и + 2 объекта "склеивания". А если у нас таких операций (итераций) много, то велика вероятность получить outofmemoryerror прежде чем GC (сборщик мусора) успеет собрать все созданные объекты.

В отличие от языков C/C++ в Java нет доступа к памяти. Программист не может удалить "cell memory" хранящую ссылку на объект и в этом нет необходимости. Эту работу выполняет Garbage collectors (GC) а вся работа с памятью происходит только через Java-машину (JVM).

С целью экономии памяти, начиная с версии JDK 5 для работы со String-ами в Java имеется StringBuilder. Таким образом у нас всегда один объект, который пропорционально заполненяет StringBuffer, подобно HashSet<String> но с одной ("резиновой") ячейкой в памяти.
https://docs.oracle.com/javase/8/docs/api/java/lan...

Comments

[My1Name]

p.s. если вы работаете с текстовым документом ~2-3Мб (толстенькая книга), нужно изрядно "поизвращаться" при написании программы, чтоб поймать outofmemoryerror на современном ПК, используя простой оператор сложения + или сложения с присваиванием +=