Java8 min de leitura

Java Internals: O Custo Cognitivo da Imutabilidade de Strings

Foto de Guilherme Gomes
Guilherme Gomes

Java Internals: O Custo Cognitivo da Imutabilidade de Strings

Imutabilidade de String - JVM

Introdução

Você já fez code review e encontrou algo assim?

public static String stopIt(String str) {
    str.replace(str, "stop"); // parece certo...
    return str;               // mas retorna "start"
}

A primeira reação costuma ser: "como esse dev não sabia que String é imutável?"

A resposta honesta é: ele provavelmente sabia. O problema não é falta de conhecimento - é o que podemos chamar de custo cognitivo da semântica verbal.

O Problema: a Semântica dos Verbos

Verbos como replace, trim, toUpperCase e toLowerCase carregam uma carga semântica de ação direta. O cérebro os processa como modificadores - da mesma forma que list.add() ou map.put() realmente alteram o estado do objeto.

Essa é a armadilha. Não é que o desenvolvedor esqueceu a imutabilidade. É que a leitura fluida do código ativa um padrão cognitivo diferente da realidade da JVM.

Veja a diferença de comportamento com coleções mutáveis:

// List é mutável - add() modifica o estado diretamente
List<String> list = new ArrayList<>();
list.add("item"); // funciona como esperado
System.out.println(list); // [item]

// String é imutável - replace() não modifica nada
String texto = "start";
texto.replace("start", "stop"); // resultado descartado silenciosamente
System.out.println(texto); // "start"

O compilador não avisa. O IDE pode (e deve) alertar, mas em projetos com muitos warnings suprimidos, esse erro passa despercebido facilmente.

O que Acontece na JVM

Quando uma String é criada, seu conteúdo é alocado no String Constant Pool (SCP) - uma área especial da heap gerenciada pela JVM. Uma vez lá, o conteúdo é imutável e fixo.

Quando você chama str.replace(str, "stop"), a JVM:

  1. Lê o conteúdo original de str no SCP
  2. Cria um novo objeto String com o valor "stop"
  3. Retorna a referência para esse novo objeto
  4. Descarta a referência se você não a capturar

O objeto original não é tocado. A variável str continua apontando para "start".

SCP (String Constant Pool)
┌──────────────┐     ┌──────────────┐
│   "start"    │     │    "stop"    │
│  (imutável)  │     │ (nova inst.) │
└──────┬───────┘     └──────┬───────┘
       │                    │
       str             ← referência descartada se não capturada

A Solução: Captura Explícita da Nova Referência

Métodos de manipulação de String não são mutators (modificadores de estado). São fábricas de novos objetos. Para que a alteração persista, a nova referência precisa ser explicitamente capturada:

// ✗ Errado - resultado descartado
public static String stopIt(String str) {
    str.replace(str, "stop");
    return str; // retorna "start"
}

// ✓ Correto - nova instância capturada
public static String stopIt(String str) {
    return str.replace(str, "stop"); // retorna "stop"
}

O mesmo padrão se aplica a toda a API de String:

String nome = "  guilherme  ";

// ✗ Errado
nome.trim();
nome.toUpperCase();

// ✓ Correto
nome = nome.trim().toUpperCase();
System.out.println(nome); // "GUILHERME"

Por que a Imutabilidade Existe

A imutabilidade das Strings não é uma limitação - é uma decisão arquitetural deliberada que viabiliza otimizações críticas na JVM:

1. String Constant Pool e Compartilhamento de Referências

O SCP permite que literais idênticos compartilhem a mesma referência em memória:

String a = "Java";
String b = "Java";

System.out.println(a == b); // true - mesma referência no SCP

Se Strings fossem mutáveis, compartilhar referências seria perigoso: alterar a afetaria b.

2. Thread Safety Nativa

Strings são inerentemente thread-safe. Não há necessidade de synchronized, volatile ou locks para compartilhar uma String entre threads, porque nenhuma thread pode modificar seu conteúdo.

// Seguro compartilhar entre threads sem qualquer sincronização
String endpoint = "https://getcaramelo.dev/v1/posts";

ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor();
for (int i = 0; i < 100; i++) {
    pool.submit(() -> fetch(endpoint)); // endpoint é imutável, sem risco
}

3. String Deduplication (G1GC)

O G1 Garbage Collector possui uma otimização chamada String Deduplication: ele identifica objetos String com conteúdo idêntico em diferentes regiões da heap e consolida suas referências para apontar ao mesmo char[] interno. Isso só é possível porque o conteúdo é imutável - a JVM tem a garantia de que ninguém vai alterá-lo por baixo dos panos.

4. HashCode Cacheado

O hashCode() de uma String é computado uma vez e armazenado internamente. Como o conteúdo nunca muda, o cache é sempre válido - o que torna operações com HashMap<String, ?> mais eficientes do que com objetos mutáveis equivalentes.

Quando Você Precisa de Mutabilidade: StringBuilder

Toda vez que você precisa construir uma String em múltiplos passos, o StringBuilder entra em cena - mas usá-lo em todos os casos é um exagero que pode custar em legibilidade sem ganho real de performance.

O Cenário Crítico: Concatenação em Loops

O uso do operador + dentro de um loop é o principal caso onde o StringBuilder deve ser preferido explicitamente. Cada iteração com + pode criar um novo objeto String intermediário na heap, gerando lixo que o GC precisará processar. Em volumes altos, isso resulta em complexidade de tempo O(n²):

// ✗ Ineficiente - potencialmente O(n²)
// cada iteração cria um objeto String descartável
String resultado = "";
for (String parte : partes) {
    resultado += parte;
}

// ✓ Eficiente - O(n)
// uma única instância de buffer, append in-place
StringBuilder sb = new StringBuilder();
for (String parte : partes) {
    sb.append(parte);
}
String resultado = sb.toString();

O mesmo vale para construção condicional ao longo de múltiplos passos de lógica:

// ✓ StringBuilder faz sentido aqui - construção incremental e condicional
StringBuilder query = new StringBuilder("SELECT * FROM users WHERE 1=1");
if (filtroNome != null)   query.append(" AND nome = '").append(filtroNome).append("'");
if (filtroAtivo != null)  query.append(" AND ativo = ").append(filtroAtivo);
if (limite > 0)           query.append(" LIMIT ").append(limite);
return query.toString();

Onde o + Vence: Concatenação Simples

Para concatenações diretas em uma única instrução, o compilador e a JVM já fazem o trabalho por você - e fazem bem.

No JDK 8, o compilador transformava internamente "A" + "B" + "C" em uma implementação de StringBuilder no bytecode. A partir do JDK 9, o JEP 280 introduziu a Indify String Concatenation: a instrução invokedynamic delega a operação à JVM de forma dinâmica, permitindo otimizações que nem aparecem no bytecode e que evoluem com as versões do Java sem recompilação.

Na prática, benchmarks em máquinas modernas mostram que a concatenação via + em casos simples pode ser mais rápida do que o uso explícito de StringBuilder:

// ✓ Deixa o compilador/JVM otimizar - é a escolha certa aqui
String mensagem = "Olá, " + nome + "! Bem-vindo ao " + plataforma + ".";

// ✗ Desnecessariamente verbose - sem ganho de performance
String mensagem = new StringBuilder()
    .append("Olá, ").append(nome)
    .append("! Bem-vindo ao ").append(plataforma).append(".")
    .toString();

Alternativas Modernas para Legibilidade

Quando o objetivo é legibilidade na construção de texto dinâmico - XML, JSON, SQL, templates - existem alternativas mais expressivas que o StringBuilder:

Text Blocks (JDK 15+) para strings multilinhas fixas:

String json = """
        {
            "nome": "%s",
            "ativo": %b
        }
        """.formatted(nome, ativo);

String.formatted() como alternativa legível ao String.format() - mesmo resultado, sintaxe mais fluida:

// String.format() - clássico
String msg = String.format("Usuário %s criado em %s", nome, data);

// String.formatted() - mais idiomático desde o Java 15
String msg = "Usuário %s criado em %s".formatted(nome, data);

⚠️ Evite String.format() e String.formatted() dentro de loops de alta frequência. Ambos são consideravelmente mais lentos que StringBuilder ou concatenação simples por envolverem parsing de formato a cada chamada.

Guia de Decisão Rápido

Cenário Use
Concatenar poucas variáveis em uma linha + ou String.formatted()
Construir String dentro de loop StringBuilder
Construção incremental com condicionais StringBuilder
Template multiline com valores fixos Text Block
Template multiline com interpolação Text Block + .formatted()
Alta frequência em loop crítico StringBuilder (evite format)

Revisitando o Código Original

Com tudo isso em mente, o erro inicial fica mais claro:

// ✗ Versão com o erro
public static String stopIt(String str) {
    str.replace(str, "stop"); // cria "stop" na heap, referência perdida
    return str;               // str ainda aponta para "start" no SCP
}

// ✓ Versão correta
public static String stopIt(String str) {
    return str.replace(str, "stop"); // captura e retorna a nova referência
}

O erro não é conceitual - é de leitura. replace soa como uma operação in-place. Para quem lê rápido (e revisores de PR leem rápido), o olho passa e o cérebro valida. Saber disso é o que separa um bom code reviewer de um revisor médio.

Conclusão

Imutabilidade de Strings em Java não é um detalhe trivial de documentação. É uma decisão que impacta gerenciamento de memória, segurança em concorrência e performance do GC. O custo cognitivo existe - e conhecê-lo te torna mais atento tanto ao escrever quanto ao revisar código.

Na próxima vez que você ver um verbo como replace, trim ou toUpperCase em uma revisão, a pergunta certa é simples: o resultado foi capturado?

Este artigo faz parte da série Objects · Immutability · Switch · Pattern Matching do getcaramelo.dev.

Tem dúvidas ou quer aprofundar algum ponto? Me encontra no LinkedIn ou no GitHub.

Gostou do conteúdo? Me segue no @getcaramelo.dev

← Voltar aos Artigos