Imutabilidade de String

Desde a versão 1.5 do Java SE, a classe tornou-se imutável. Cada vez que um valor é atribuido a um objeto String a máquina virtual cria um objeto novo, contudo a referência é mantida. Em situações de concatenação de Strings ou de atribuição, a Máquina Virtual cria um objeto novo, o que é muito custoso. Inicialmente, fiquei triste por ser assim. Entretando, duas novas foram criadas para armazenar Strings de uma maneira mutável.

A StringBuilder e StringBuffer. Este é similar ao primeiro, contudo é Thread-Safe e obviamente mais lento devido ao controle de sincronização.

O código em http://phpfi.com/331387, foi feito para comparar desempenho entre StringBuilder e String.

Abaixo, a saída do programa em ms:
Tempo para atribuicao em String: 16
Tempo para concatenaco em String: 660531
Tempo para atribuicao em StringBuilder: 31
Tempo para concatenao em StringBuilder: 32

Incrível!!
Atribuição em String é mais veloz. Mas a concatenação é extremamente lenta.

Porque?
Seja String str += new String("aaa");

Ele cria uma objeto com "aaa" e cria mais com o valor antigo de str. Para fazer uma concatenação foram criados dois objetos.

Gostaria muito de ver a implementação destas classes.

Espero que tenham gostado e aguardem o próximo tópico. Como Java cria objetos.

Oops...intern não é tão bom assim

A um tempo atrás Fábio Marcon Pallini, vulgo dolly da IBm, se propôs a fazer um código que testasse a eficiência de comparação de Strings entre três métodos do Java.
- java.lang.String.intern(void)::String
- java.lang.Object.equals(Object)::boolean
- java.lang.Object.compareTo(Object)::int

O código encontra-se neste link:
http://phpfi.com/331388

Foi usado como arquivo de entrada a bíblia que está em http://www.gutenberg.org/ebooks/10
1.34 Mb .zip

O resultado foi surpreendente:
Texto lido. 392429 palavras carregadas.
Fazendo comparacao com a palavra: God.
Inicio das comparacoes:

.intern() == : 329 milissegundos.

.equals(String) : 15 milissegundos.

.compareTo(String) == 0 : 0 milissegundos

Incrível e triste ao mesmo tempo.
O intern() foi o pior resultado. O James Gosling disse o contrário.
Contudo, eu vejo que esse método joga a String para o pool, e realmente é mais barato comparar referência de memória do que byte a byte da String, contudo, a comparação que ocorre no pool é que deve deixar lento. Talvez, seja isto que ele quis dizer.

Agradecimentos a Fábio Marcon Pallini.