Java Объясните: почему String неизменяемый делает StringBuffer более эффективным - PullRequest
2 голосов
/ 28 марта 2012

Я прочитал в книге на Java, где написано:

Поскольку String является неизменным, использование StringBuffer более эффективно.

Я понимаю, что String экземпляры являются неизменными.

Я также понимаю, что StringBuffer делает обработку строк более эффективной, чем обычно.

Но что я не могу понять, так это то, что связывает эти два понятия, то есть, как String неизменность помогает StringBuffer?

Спасибо:)

Ответы [ 5 ]

8 голосов
/ 28 марта 2012

Поскольку строки неизменяемы, для манипулирования строками, например для объединения строк, необходимо создавать новые объекты String, поскольку очевидно, что вы не можете изменить состояние существующих объектов String. Принимая во внимание, что с помощью StringBuffer или StringBuilder вы создаете один объект и просто меняете его состояние. Например, если вы выполняете какую-либо важную конкатенацию строк в цикле for, создание этого объекта может быть очень дорогим.

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

Также обратите внимание, что вы должны использовать StringBuilder преимущественно вместо StringBuffer, если вашему приложению не требуется доступ к объекту в нескольких потоках и он не возражает против дополнительных затрат, которые это несет.

2 голосов
/ 28 марта 2012

То, что он хотел сказать, так это то, что поскольку String является неизменным, поэтому лучше использовать StringBuffer (или StringBuilder) для манипулирования String, поскольку вы не создаете новый объект каждый раз, когда меняете базовую строку.

1 голос
/ 28 марта 2012

Но я не могу понять, что связывает эти два понятия, т. Е. Как неизменяемость String помогает StringBuffer?

Это не так. Я думаю, что вы просто неверно истолковываете приведенное вами предложение.

"Поскольку строка является неизменной, использование StringBuffer более эффективно."

Это говорит о том, что StringBuffer является относительно более эффективным вариантом (для определенных задач). Другими словами: «Поскольку String является неизменным, использование StringBuffer более эффективно [чем использование String для определенных задач].».

Это НЕ говорит, что StringBuffer быстрее в абсолютном выражении, чем это было бы, если бы String не был неизменным. Конечно, это не то, как я читаю цитату ... и это тоже не верное утверждение.

1 голос
/ 28 марта 2012

Все остальные посты однозначно отвечают на вопрос. Я бы добавил, что вы всегда должны выбирать StringBuilder вместо StringBuffer. StringBuffer имеет встроенную синхронизацию потоков, что приводит к огромным накладным расходам на блокировку, которые вам почти никогда не понадобятся. StringBuilder не имеет этого, и поэтому быстрее.

На самом деле, даже если вам нужна безопасность потоков, вот несколько очень веских причин не использовать StringBuffer.

0 голосов
/ 28 марта 2012

Понятие неизменяемости может быть легко объяснено на этом примере

String s1 = "Hello";
String s2 = "Hi";
String s3 = "Hello";

if (s1 == s2){ System.out.println("s1==s2");}
if (s1 == s3){ System.out.println("s1==s3");}

s1 = "Hi";

if (s1 == s2){ System.out.println("s1==s2");}
if (s1 == s3){ System.out.println("s1==s3");}

Если вы выполните этот фрагмент кода, вы получите s1==s3 и s1==s2. Что объясняет этот пример?

Когда вы создали s1, компилятор создал строку «Hello» в своей таблице строк (я не помню его точное имя). Когда вы создали s2, он создает новый объект «Привет». Теперь, когда вы создали s3, компилятор знает, что в его таблице строк уже есть объект «Hello», так почему бы просто не обратиться к s3. Так что s1 = s3 (тиски памяти). То же самое произошло, когда вы присвоили значение «hi» s1, компилятор мог видеть, что «hi» уже находится в памяти, на которую указывает s3, поэтому он также указал на s1.

В случае StringBuffer, Compiler выделяет память для объекта, которым вы можете манипулировать, скорее, «пулом», как в случае String.

...