tobilko20 июн 2015 в 19:09

Обработка строк в Java. Часть I: String, StringBuffer, StringBuilder

8 мин

475K

Java *

Туториал

Из песочницы

+11

Комментарии 68

leventov 20 июн 2015 в 19:30

Это перевод? Отметьте, откуда

tobilko 20 июн 2015 в 19:33

это мой оригинальный текст

pleha 21 июн 2015 в 17:36

Мне всегда было интересно хоть кто-то нашел применение StringBuffer. Не очень понятно в каком случае он может пригодиться. Попеременно дописывать какие-то строки и потом их куда-то выводить. Получается в такой строке порядок должен быть не очень важен. Могу подумать только о логировании и чем-то подобном, но для этого есть масса других средств.

vladimir_dolzhenko 21 июн 2015 в 17:55

именно StringBuffer? или в целом подход StringBuilder/StringBuffer?

leventov 21 июн 2015 в 18:33

Конечно, именно StringBuffer. StringBuilder-то один из самых часто используемых классов в стандартной библиотеке.

vladimir_dolzhenko 21 июн 2015 в 19:07

У меня только одно объяснение: по историческим причинам и в силу того, что java дает обратную совместимость

 * @since       1.5
 */
public final class StringBuilder

 * @since   JDK1.0
 */
 public final class StringBuffer

hmpd 20 июн 2015 в 20:25

String second = new String(habr); // аналогично second = habr;

Разве аналогично?
1. String second = new String(habr) — создается новый объект second с тем же содержимым, что и в объекте habr. При этом second и habr ссылаются на разные объекты.
2. String second = habr — копируется ссылка на объект habr, то есть second и habr ссылаются на один объект.
Верно?

tobilko 20 июн 2015 в 20:48

Опечатался, спасибо. Все верно отметили.
Хотелось бы дополнить и сказать, что все ссылки на string объекты хранится в String Pool и перед созданием строки с помощью литерала проверяется нет ли эквивалентной строки в пуле, если нет — добавляется, иначе просто получаем ссылку на уже готовый объект. В случаи с new, новый объект создаться в любом случаи, независимо от пула.

hmpd 20 июн 2015 в 20:53

Вам спасибо за статью! Давайте продолжение.

(Чисто языковой комментарий: слово «что», конечно, заменяет слово «который», но не без потерь: оно не передает род заменяемого слова, поэтому текст воспринимается хуже. Пример:
«если длина строки, что хранится...» — к чему здесь относится «что»: к длине или к строке? Конкретно в этом случае подойдет причастие:
«длина строки, хранящаяся...» или
«длина строки, хранящейся...»)

tobilko 20 июн 2015 в 21:25

спасибо, исправил :)

apangin 20 июн 2015 в 20:29

А теперь запустите тот же тест с -XX:BiasedLockingStartupDelay=0:

StringBuffer: 5590ms.
StringBuilder: 5493ms.

И чего в итоге померили?

Также изменения коснулись hashCode (новый алгоритм hashing)

Оппа! Как такое может быть, если алгоритм хеширования для String строго прописан в спецификации?

apangin 20 июн 2015 в 20:55

А при добавлении третьей строчки у меня вообще весело получается:

    test(new StringBuffer("")); // StringBuffer: 5020ms.
    test(new StringBuilder("")); // StringBuilder: 14041ms.
    test(new StringBuilder("")); // StringBuilder: 10716ms.

vladimir_dolzhenko 21 июн 2015 в 16:42

Учитывая цикл 1e9 итераций и что StringBuilder/StringBuffer расширяются — может произойти GC, наверняка может случится и JIT — словом, что именно происходило в фоне — неизвестно, так, что можно гадать на кофейной гуще, что же именно мерялось.

tobilko 20 июн 2015 в 20:59

Алгоритм действительно не изменился (где-то прочитал, но не проверял тогда), спасибо.

uthark 21 июн 2015 в 03:16

Вдобавок к вышеперечисленному, хочу добавить, что одним из важных аспектов, почему String объявлен как final — это безопасность. Например, когда загружаем класс, то имя класса передается в виде строки. Если бы строки были не финальные, то вредоносный код мог бы изменить имя класса и, таким образом, загрузить неправильный класс. Например, вместо java.io.FileReader был бы загружен com.malicious.FileRemover. Также можно было бы сломать контракт equals/hashCode.

Для обхода всех этих проблем, возможно, был бы введен класс java.lang.SafeString, который бы помог предотвратить эти проблемы, но попутно создал бы новых (например, конвертацию из SafeString в String и обратно, замусоривание API). Но так как это один из базовых классов, то было принято решение сделать класс String финальным.

НЛО прилетело и опубликовало эту надпись здесь

vladimir_dolzhenko 21 июн 2015 в 16:13

Просто оставлю это здесь

НЛО прилетело и опубликовало эту надпись здесь

vladimir_dolzhenko 21 июн 2015 в 20:27

Это ни в коем случае не камень в ваш огород, просто логическое продолжение замечания, учитывая то, что этого доклада в комментариях еще не было

tagir_valeev 23 июн 2015 в 06:49

Метод substring напротив был добрым до 1.7.0_06, если им правильно пользоваться =)

НЛО прилетело и опубликовало эту надпись здесь

tagir_valeev 23 июн 2015 в 07:26

При правильном использовании substring мог даже сэкономить память: можно было на один char[]-массив повесить тыщу строк, снижая оверхед на заголовки каждого массива. К примеру, вы загружаете из базы readonly-словарь, который всё равно будете держать всегда целиком в памяти. Можно было конкатенировать все строки и разбить по substring.

ASuprun 21 июн 2015 в 08:15

Маленькое уточнение по поводу оператора "+". Как с казано в документации к Oracle JDK 6, 7 и 8, реализация этого оператора сделана с использованием StringBuilder:

The Java language provides special support for the string concatenation operator ( + ), and for conversion of other objects to strings. String concatenation is implemented through the StringBuilder(or StringBuffer) class and its append method. String conversions are implemented through the method toString, defined by Object and inherited by all classes in Java.

(ссылка на v8)

Что также отражено в спецификации:

An implementation may choose to perform conversion and concatenation in one step to avoid creating and then discarding an intermediate String object. To increase the performance of repeated string concatenation, a Java compiler may use the StringBuffer class or a similar technique to reduce the number of intermediate String objects that are created by evaluation of an expression.

For primitive types, an implementation may also optimize away the creation of a wrapper object by converting directly from a primitive type to a string.

(ссылка)

Эта тема также поднималась на StackOverflow и там был детально описан процесс конкатенации (ссылка).

23derevo 21 июн 2015 в 12:05

Как сказано в документации к Oracle JDK 6, 7 и 8

это не документация к Oracle JDK. Это javadoc, то есть, документация к стандарту Java SE (6, 7, 8).

tobilko 21 июн 2015 в 12:11

String habr = new StringBuilder(String.valueOf("habra")).append("habr").toString();

это уточнения было в статьи

vladimir_dolzhenko 21 июн 2015 в 16:09

Объясните — откуда взялось это убожество String.valueOf?

public String s(String v, String f){
    return v + f;
}

и его bytecode

 public java.lang.String s(java.lang.String, java.lang.String);
    descriptor: (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=3
         0: new           #2                  // class java/lang/StringBuilder
         3: dup
         4: invokespecial #3                  // Method java/lang/StringBuilder."<init>":()V
         7: aload_1
         8: invokevirtual #4                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        11: aload_2
        12: invokevirtual #4                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        15: invokevirtual #5                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        18: areturn
      LineNumberTable:
        line 3: 0

т.е + это синтетический сахар, а на деле

public String s(String v, String f){
    return new StringBuilder().append(v).append(f).toString();
}

и никаких String.valueOf — не вводите людей в заблуждение.

И вы уверены, что в следующем методе используется конкатенация?

public String q(){
return "ha" + "br";
}

Данный строковый литерал может быть вычислен уже на стадии компиляции и javac подставляет уже результат

Constant pool:
   #2 = String             #20            // habr

 public java.lang.String q();
    descriptor: ()Ljava/lang/String;
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: ldc           #2                  // String habr
         2: areturn
      LineNumberTable:
        line 3: 0

Что может привести к неожиданным результатам:
К примеру, вы используете константу из сторонней библиотеки, которая скажем возвращает ее версию в виде строки, н-р «v1». Если вы обновите эту библиотеку (которая возвращает «v2») без пересборки класса, который ее использует — результат будет по прежнему «v1» ибо именно это значение было подставлено на стадии компиляции.

Hack, который позволяет обходить данные грабли — использование метода intern — как например тут. По сути строковый литерал уже находится в пуле строк и никакого выигрыша/проигрыша нет, кроме того, что теперь javac не может (по крайней мере пока) вычислить значение на стадии компиляции и уже будет честно загружать класс и его константу.

tobilko 21 июн 2015 в 20:01

String habrahabr = new StringBuilder()).append(habra).append(habr).toString();

вы правы, исправил

23derevo 21 июн 2015 в 20:01

поддерживаю. Проверить очень легко: скомпирировать конкатенацию, а потом декомпилировать.
Даже в байткод руками лазать не надо :)

vladimir_dolzhenko 21 июн 2015 в 20:05

скомпирировать… декомпилировать.

Настоящим пацанам нужна только консолька, vi, javac да javap для этого

vladimir_dolzhenko 21 июн 2015 в 08:18

Напишем небольшой тест для сравнения скорости работы этих двух классов

Возьми вольтметр и измерь!

tobilko 21 июн 2015 в 10:47

предложите свой вариант

23derevo 21 июн 2015 в 12:08

Прежде, чем писать любые перфомансные тесты и юзать всякие System.currentTimeMillis(), мы с vladimir_dolzhenko настоятельно рекомендуем Вам ознакомиться вот с этой лекцией:

tobilko 21 июн 2015 в 12:21

спасибо, посмотрю, перепишу тест :)

vladimir_dolzhenko 21 июн 2015 в 13:20

Всецело согласен с Лешей 23derevo, но стоит добавить, что одной лекцией не стоит ограничится, чтобы понять как же измерять и пользоваться jmh, но вектор правильный.

Стоит обратить внимание, что в java есть такая вещь как Escape Analysys, которая делает много волшебных вещей, н-р, стирание блокировок, если экземпляр никуда не утекает.

Т.е в однопоточном случае разница между StringBuilder и StringBuffer будет в пределах погрешности измерений (после того, как JIT свернет). Это следует учитывать, когда будете писать jmh-тест.

apangin 21 июн 2015 в 19:46

Используйте метод concat, если слияние нужно провести только один раз, для остальных случаев рекомендовано использовать или оператор "+" или StringBuffer / StringBuilder.

Никогда не используйте concat. Обычный "+" или StringBuilder всегда будет эффективней, даже всего для двух строк. Просто потому, что JVM оптимизирует "+" специальным образом (это JVM intrinsic), а concat — нет (это обычный Java метод).

vladimir_dolzhenko 21 июн 2015 в 19:49

Можно подробнее про JVM intrinsic используемый в +?

Как бы байткод всегда показывает цепочку new StringBuilder().append()...toString() и не знал, что intrinsic может действовать над цепочкой

apangin 21 июн 2015 в 21:57

Именно так. HotSpot JVM распознаёт паттерн new StringBuilder().append()...toString() (или то же самое со StringBuffer), и компилирует это как одно целое. Регулируется опцией -XX:+OptimizeStringConcat, по умолчанию включено.

vladimir_dolzhenko 21 июн 2015 в 21:58

Спасибо большое!

23derevo 14 июл 2015 в 09:57

vladimir_dolzhenko, apangin, lany —
зацените шипилёвский JEP в тему: openjdk.java.net/jeps/8085796

tagir_valeev 14 июл 2015 в 10:03

Ага, я ниже в комментарии писал про это =)

23derevo 14 июл 2015 в 10:08

ага, каюсь, пропустил :)

23derevo 21 июн 2015 в 20:16

в теории ведь никто не мешает concat реализовать как JVM intrinsic?

vladimir_dolzhenko 21 июн 2015 в 20:42

Представляешь как было бы… фантастично-феерично иметь pluggable intrinsic?

23derevo 21 июн 2015 в 20:57

а чего там представлять? Есть такая штука — OpenJDK. Она некоторыми и используется именно так, как ты хочешь: Taobao JVM (слайды 34-37)

vladimir_dolzhenko 21 июн 2015 в 21:06

Все клева конечно, только доклад 2011.
Почему-то на ум приходит академическая разработка RedHat под названием Shenandoah — вызов Zing VM и С4 — но только больше о них ничего не слышно.

23derevo 21 июн 2015 в 21:13

погоди, тут другой случай :)

Как я понял — это просто кастомизированная OpenJDK (classlib, jvm), работающая внутри Taobao. Они делают определенные изменения и оптимизации, заточенные под их конкретные юзкейсы (ворклоады, железо, сценарии и т.п.). И как я понимаю, именно поэтому они не всегда коммитят назад в OpenJDK — их изменения не всем подойдут.

vladimir_dolzhenko 21 июн 2015 в 21:50

Я вообще о том, что ежели продукт пошел — то должны быть упоминания и развитие, кроме данного доклада.

Но все равно было бы варенье-с-маслом видеть pluggable intrinsic в java-по-умолчанию

23derevo 21 июн 2015 в 23:23

Ну вот смотри, у нас в Одноклассниках тоже есть свои сборки OpenJDK патченные — и classlib и JVM. Мы об этом упоминаем периодически, но чтобы прямо кричать об этом на каждом углу…

Многие, кстати, патчат. Например, тот же гугл. Посмотри доклады Jeremy Manson с JVMLS 2013 и JVMLS 2014. И тоже об этом мало в интернете есть. Потому что это больше не инфоповод и не рокит саенс.

tagir_valeev 23 июн 2015 в 06:24

В теории — да. На практике вряд ли его напишут, потому что его мало используют. Практический выход никакой, зато трудозатраты на написание низкоуровневого кода и новое место для багов. Многие куда более полезные интринсики (например, Array.get) и то отсутствуют.

tagir_valeev 23 июн 2015 в 06:32

На самом деле дело ещё в том, что по факту внутренняя реализация оператора "+" не специфицирована строго. Спецификация не требует, чтобы это обязательно был StringBuilder. Вон Алексей колбасит новую реализацию на invokedynamic. Если что-то получится, может работать ещё быстрее.

String.concat может быть полезен, если ожидается много пустых строк на входе. Тогда он просто вернёт непустую строку, не создавая новых объектов вообще. Это будет быстрее, чем "+", даже с учётом интринсиков: спецификация обязывает "+" возвращать новый объект (если это не compile-time constant).

tagir_valeev 23 июн 2015 в 06:39

Мне, кстати, не очень понятно, почему операторы "+" и "+=" названы «перегруженными». Можно ли считать, что оператор деления "/" «перегружен», потому что он ведёт себя по-разному для целых чисел и для дробных? По-моему, слово «перегружен» здесь неуместно вообще. Обычно его используют для пользовательской перегрузки в тех языках, где она поддерживается (в Java — нет). А так это просто «оператор конкатенации строк».

tobilko 29 июн 2015 в 14:40

Оператор "+" «перегружен» для строк, потому что главное его назначение это сложения для числовых примитивных типов данных.

23derevo 29 июн 2015 в 14:54

А на каком основании вы полагаете, что одно применение «главнее», чем другое?

tobilko 29 июн 2015 в 15:26

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

если ошибаюсь, с радостью узнаю истину :)

23derevo 29 июн 2015 в 16:17

а как эта ваша реплика связана с моим вопросом? :)

tobilko 29 июн 2015 в 16:45

с этой реплики следует, что операции с примитивными типами «главнее» за операции с объектами, имхо

23derevo 29 июн 2015 в 18:20

вот-вот :) и «имхо» здесь ключевое слово.

tagir_valeev 29 июн 2015 в 17:43

В языке Java некоторые объекты обрабатываются специальным образом на уровне синтаксиса или имеют специальное значение. К примеру, после слова throw может идти только объект класса Throwable или его наследник. Вот и String имеет специальное значение не только как часть библиотеки, но и как часть самого языка.

Кстати, вот вам такой код:

Integer a = 1;
Integer b = 2;
Integer c = a + b;
Integer d = a - b;

Здесь мы применяем плюс и минус к объектам. Значит ли это по вашему, что и тут эти операторы «перегружены»?

23derevo 29 июн 2015 в 18:20

тот же пример хотел скинуть, но ты меня опередил :)

tobilko 29 июн 2015 в 18:21

нет, здесь операторы не перегружены, потому что операции совершаются над примитивными типами, а не над объектами, в которые «завернуты» эти типы:

        Integer a = Integer.valueOf(1);
        Integer b = Integer.valueOf(2);
        Integer с = Integer.valueOf(a.intValue() + b.intValue());
        Integer d = Integer.valueOf(a.intValue() - b.intValue());

vladimir_dolzhenko 29 июн 2015 в 19:40

Что-то вы не последовательны — значит как строки складывать — так + перегружен, а как Integer/Long/Double и т.п — так не перегружен.

Откуда же тогда берется эта магия с unboxing?

tobilko 29 июн 2015 в 18:29

И да, я понимаю, что объекты некоторых классов имеет «особый статус» и их обработка оговорена в спецификации.

vladimir_dolzhenko 29 июн 2015 в 19:34

С моей точки зрения многие люди часто путают Java и C++ — как-то generics vs templates или перегрузку операторов с особыми случаями синтаксиса.

В этом смысле и string + string и number + number в каком-то смысле «перегружены», что для данных классов на уровне языка определен расширенный синтаксис (или если угодно синтаксический сахар). В самом деле, в java же невозможно задать некоторый свой класс my.package.Vector(x,y) и определить для него + как операцию сложения векторов на уровне синтаксиса, тогда как в C++ / groovy / др это можно сделать легко — и это неловкое чувство, что some animals are more equal.

tobilko 29 июн 2015 в 20:58

lany, vladimir_dolzhenko, 23derevo, спасибо за помощь, разобрался, почитал спецификацию.

Не понимаю людей, которые яро минусуют посты, где обсуждаются вопросы по теме. Я пытаюсь разобраться, докопаться до истины, высказывая свои мысли. Это ни в коем случаи не камень в огород знаний собеседников.

tagir_valeev 23 июн 2015 в 06:44

А StringJoiner в Java-8 адски медленный. В девятке разогнали.

НЛО прилетело и опубликовало эту надпись здесь

tagir_valeev 24 июн 2015 в 15:20

А что там описывать? В восьмёрке под капотом обычный StringBuilder. В девятке элементы складывают в массив и подсчитывают суммарную длину, а итоговую строку создают через приватный конструктор (SharedSecrets, всё такое). В итоге массив char[] создаётся ровно один раз вместо того, чтобы его пересоздавать и копировать, когда он кончается (а в конце ещё раз пересоздавать и копировать, потому что его длина почти наверняка не совпадает с длиной результирующей строки). Я сам хотел подобную оптимизацию предложить, но потом догадался в девятке посмотреть. В общем-то на целую статью этот рассказ вроде не тянет.

НЛО прилетело и опубликовало эту надпись здесь

Зарегистрируйтесь на Хабре, чтобы оставить комментарий