Aumento do consumo de memória devido ao comportamento do String Constant Pool após a atualização do Java 17 para o Java 21

TL;DR: Isso será corrigido no Java 21.0.7(*) e foi corrigido no Java 22.0.2 e Java 23 e posteriores.

O problema é que a inicialização com string vazia que você vincula não é realmente usada, pois esses campos são sobrescritos com o resultado de chamadas StringBuffer.toString()(Java 17)/ StringBuilder.toString()(Java 21) no applyPatternmétodo que é chamado dos DecimalFormatconstrutores. O problema é que o toString()método de StringBuffer/ StringBuildermudou significativamente com o que é retornado se o buffer estiver vazio.

No Java 17 (17.0.14) ele faz:

@Override
@IntrinsicCandidate
public synchronized String toString() {
    if (toStringCache == null) {
        return toStringCache =
                isLatin1() ? StringLatin1.newString(value, 0, count)
                           : StringUTF16.newString(value, 0, count);
    }
    return new String(toStringCache);
}

(Embora, curiosamente, se você tivesse chamado toString()duas vezes sem modificação, ele retornaria uma nova instância).

Isso requer StringLatin1.newStringum buffer vazio, que retorna a mesma string vazia todas as vezes:

public static String newString(byte[] val, int index, int len) {
    if (len == 0) {
        return "";
    }
    return new String(Arrays.copyOfRange(val, index, index + len),
                      LATIN1);
}

No Java 21 (ou pelo menos, depois do Java 17), a implementação mudou para StringBuilder, e no Java 21 (21.0.6) o toString()of StringBuilderfaz:

@Override
@IntrinsicCandidate
public String toString() {
    // Create a copy, don't share the array
    return new String(this);
}

Que retorna uma nova instância toda vez (embora eu não tenha verificado se há uma intrínseca e, se houver, se ela pode fazer outra coisa).

Isso foi abordado em versões posteriores do Java. No Java 24 (24.0.0), StringBuilder.toString()faz:

@Override
@IntrinsicCandidate
public String toString() {
    if (length() == 0) {
        return "";
    }
    // Create a copy, don't share the array
    return new String(this, null);
}

Esta é a correção de bug JDK-8325730 para Java 23 e retroportada para Java 22.0.2 e Java 21.0.7(*) (que ainda não foi lançada). Este problema desencadeou discussão adicional, veja JDK-8332282 e JDK-8138614 , como StringBuilder.toString()explicitamente diz:

Um novo Stringobjeto é alocado e inicializado para conter a sequência de caracteres atualmente representada por este objeto.

E a correção não está realmente em conformidade, pois não retorna uma nova instância para um buffer de string vazio. A documentação mudará no Java 25 para não exigir mais uma nova instância.

Pelo que posso perceber em uma rápida olhada, antes do Java 15, o comportamento era semelhante ao do Java 21 (retornando novas instâncias vazias).

Por exemplo, o Java 8 (8.0.442) faz isso em StringBuffer.toString():

@Override
public synchronized String toString() {
    if (toStringCache == null) {
        toStringCache = Arrays.copyOfRange(value, 0, count);
    }
    return new String(toStringCache, true);
}

E embora a implementação do Java 11 StringBuffer.toString()fosse a mesma do Java 17, no Java 11 (11.0.26), StringLatin1.newStringsempre retornava uma nova cópia:

public static String newString(byte[] val, int index, int len) {
    return new String(Arrays.copyOfRange(val, index, index + len),
                      LATIN1);
}

^{*: O problema de backport JDK-8331299 lista a versão de correção como 21.0.7-oracle, então não tenho certeza se essa correção também será aplicada no OpenJDK ou apenas nas compilações do Oracle.}

Também encontrei esse problema após o Java 19, depois de analisar o problema, descobri que, a partir do Java 19, a classe DecimalFormat começou a usar um CompactNumberFormat interno, mesmo se você não estiver usando formatação compacta diretamente. Internamente, o CompactNumberFormat aloca um monte de matrizes para diferentes padrões de formatação, e a maioria dessas matrizes é preenchida com strings vazias como marcadores de posição. Essas strings vazias permanecerão por enquanto sua instância DecimalFormat existir, e se você estiver usando instâncias estáticas como em seu exemplo, elas essencialmente existirão durante o tempo de vida do seu aplicativo.

No Java 17 e versões anteriores, esse comportamento não existia, então as strings vazias extras simplesmente não eram alocadas.

Para resolver isso, evite usar DecimalFormat estático, a menos que seja absolutamente necessário.

Em vez de usar:

static DecimalFormat df = new DecimalFormat("#.##");

mude para

DecimalFormat df = new DecimalFormat("#.##");

ou melhor ainda:

NumberFormat nf = NumberFormat.getNumberInstance();
nf.setMaximumFractionDigits(2);