StringBuffer

JavaBaby Membro desde: 07/11/2008 08:16:29 Mensagens: 88 Offline

schuelter wrote:para ajudar na explicação. String é um tipo de dado IMUTÁVEL. ou seja, ele NUNCA muda. Para vc concatenar uma String a VM tem que criar uma segunda String para criar uma terceira(o resultado). Vamos ver um código para vc entender melhor
String s = "Java"; //Aqui ele cria uma String normal. IMUTAVEL s += "Free"; // Aqui é ciado uma String "Free". deposi disso é criado // uma terceira String com o valor "JavaFree". Tudo isso // A vm faz pra vc StringBuffer sb = new StringBuffer(); //MUTAVEL sb.append("Java");//apenas concatena o valor sb.append("Free");// aqui tb apenas conc

Usar StringBuffer é beeem mais rápido para concatenar grandes quantidades de String. faça um teste. coloque um for de 1milhão concatenando String com += e depois faça o mesmo usando StringBuffer

Mesmo assim:
nesse Exemplo com String seriam criados 3 Objetos String.
E no StringBuffer tambêm...
O proprio Objeto String Buffer, e os Dois argumentos que são Objetos String tambêm... ("Java") e ("Free")
Qual é a explicação para isso ?

velo wrote:Para um loop de 5000000

A diferença, na minha opinião, não justifica a criação do StringBuilder, q 6 axam?

A pergunta é... por que não justifica? A classe é idêntica, o código será idêntico e mais rápido. Além disso, são raríssimas as vezes que você vai precisar da sincronização do string buffer.
Na verdade, é justamente ao contrário. São poucas situações que justificam a criação de um StringBuffer.

Outra coisa, a diferença foi tão pequena porque você está rodando com uma única thread. A VM é esperta o suficiente para saber disso e eliminar boa parte do overhead de código envolvido na sincronização nesse caso, já que ela sabe que não haverá concorrência.

This message was edited 1 time. Last update was at 19/09/2009 10:30:45

m4rkk wrote:Mesmo assim:
nesse Exemplo com String seriam criados 3 Objetos String.
E no StringBuffer tambêm...
O proprio Objeto String Buffer, e os Dois argumentos que são Objetos String tambêm... ("Java") e ("Free")
Qual é a explicação para isso ?

A diferença é que o custo de criação das strings literais é ínfimo, enquanto o custo de criação das strings em tempo de execução é alto.
Strings literais podem ser criadas e cacheadas em tempo de compilação.

Além do mais, a maior parte das situações em que faremos concatenações assim é de valores já alocados em memória, ou lidos de alguma fonte.
Aí formataremos uma nova String. Por isso o exemplo também não reflete uma situação real.

Mas claro, para um caso tão minusculo como o do exemplo, você dificilmente veria alguma diferença significativa de performance.
Agora, ponha concatenações num loop, e você observa rapidinho.

É issso aeeee!

Boa tarde galera,

Primeiramente eu queria parabenizá-los, pois este tópico está show de bola!!
Deu para entender direitinho o comportamento, os exemplos estão bem claros!

Tenho uma dúvida e gostaria de saber também a opinião de vocês.
No meu caso, em um programa que tenho que mexer, tem uma String que é concatenada umas 4 vezes, à grosso modo, é algo mais ou menos assim (bem a grosso modo, porque é bem pior que isso):

Criei um StringBuffer (no meu caso estou usando Buffer, pois este programa é executado N vezes em paralelo) e coloquei estas informações com o método append.
Até aí tudo bem, mas em determinados momentos, eu preciso repassar o StringBuffer criado como parâmetro em alguns método, e acabo jogando um .toString() nele.

Neste caso, voltei a criar uma String na memória (além do StringBuffer já criado), com as mesmas características que vocês já falaram aqui (imutável, etc.)?
Alguém tem alguma sugestão ou comentário? No caso, eu repasso esse StringBuffer mais de uma vez, então passo a ter 2 Strings (com o mesmo valor) em memória?

Obs: os métodos são de JARs próprios da ferramenta que utilizo para programar, não há possibilidade de modificá-los...

Obrigado a todos, abs!!

Notícias, artigos e o maior fórum brasileiro sobre Java