Comment utiliser correctement StringBuilder de Java dans des scénarios hautes performances

Utilisation correcte de StringBuilder dans des scénarios hautes performances

À propos de StringBuilder, la plupart des étudiants se souviennent simplement que vous devez utiliser StringBuilder pour l'épissage de chaînes, n'utilisez pas + et n'utilisez pas StringBuffer, puis la performance C'est la meilleure, vraiment ?

Certains étudiants ont également entendu trois expériences spécieuses :

1 Après la compilation et l'optimisation de Java, + a le même effet que StringBuilder

#. 🎜🎜#2. StringBuilder n'est pas thread-safe Par souci de "sécurité", il est préférable d'utiliser StringBuffer

3. .

1. La longueur initiale est si importante qu'elle mérite d'être mentionnée quatre fois.

StringBuilder a un char[] à l'intérieur, et constant append() est le processus de remplissage constant de char[].

new StringBuilder() La longueur par défaut de char[] est de 16. Alors, que dois-je faire si je souhaite ajouter le 17ème caractère ?

Utilisez System.arraycopy pour doubler la capacité ! ! ! !

De cette façon, il y a le coût de la copie du tableau, et deuxièmement, le char[] original est également gaspillé et sera GCed. Comme vous pouvez l'imaginer, une chaîne de 129 caractères a été copiée et supprimée quatre fois, 16, 32, 64 et 128, et un total de 496 caractères ont été alloués au tableau. Dans un scénario hautes performances, cela représente presque. insupportable.

Alors, combien il est important de fixer raisonnablement une valeur initiale.

Mais que se passe-t-il si je n'arrive vraiment pas à bien estimer ? Il vaut mieux surestimer. Tant que la ficelle est supérieure à 16 au final, même si c'est un peu gaspillé, c'est mieux que de doubler la capacité.

2. La classe StringBundler de Liferay

La classe StringBundler de Liferay fournit une autre idée pour le réglage de la longueur. Lorsqu'append(), elle ne se précipite pas vers char[] Au lieu de mettre des éléments dedans, prenez d'abord un String[] et stockez-les tous. À la fin, additionnez les longueurs de toutes les chaînes pour construire un StringBuilder de longueur raisonnable.

3. Cependant, doublez le char[]

gaspillé dans la dernière étape, StringBuilder.toString()

#🎜 🎜#// Créez une copie, ne partagez pas le tableau

return new String(value, 0, count);

Le constructeur de String utilisera System.arraycopy ()Copiez le caractère entrant [] pour garantir la sécurité et l'immuabilité. Si l'histoire se termine ainsi, le char[] dans StringBuilder sera toujours sacrifié en vain.

Afin de ne pas gaspiller ces char[], une solution consiste à utiliser diverses technologies noires telles que Unsafe pour contourner le constructeur et attribuer directement une valeur à l'attribut char[] de String, mais peu de gens fais ça.

Une autre méthode plus fiable consiste à réutiliser StringBuilder. La réutilisation résout également le problème précédent de réglage de la longueur, car même si l'estimation n'est pas précise au début, elle suffira après quelques expansions supplémentaires.

4. Réutiliser StringBuilder

Cette méthode provient de la classe BigDecimal du JDK (il est normal de voir à quel point le code du JDK est important). n'a qu'une seule fonction

public StringBuilder getStringBuilder() {

sb.setLength(0);

return sb;
}
# La fonction 🎜🎜#
StringBuilder.setLength() réinitialise uniquement son pointeur de comptage, tandis que char[] continuera à être réutilisé, et toString() transmettra également le pointeur de comptage actuel en tant que paramètre au constructeur String, donc là il n'y a pas besoin de s'inquiéter du transfert d'anciens contenus qui dépassent la taille du nouveau contenu. On peut voir que StringBuilder est entièrement réutilisable.

Afin d'éviter les conflits de concurrence, ce Holder est généralement défini sur ThreadLocal. Pour les méthodes d'écriture standards, voir les commentaires de BigDecimal ou StringBuilderHolder.

5. ＋ avec StringBuilder

String s = « bonjour » + user.getName();

L'effet de cette phrase après la compilation javac est en effet équivalent à l'utilisation de StringBuilder, mais la longueur n'est pas définie.

String s = new StringBuilder().append(“hello”).append(user.getName());

Cependant, Si cela ressemble à ceci :

String s = “hello ”;

// séparé par quelques autres instructions

s = s ＋ user.getName(); # 🎜🎜#

Chaque instruction générera un nouveau StringBuilder. Il y a deux StringBuilders ici, et les performances sont complètement différentes. Si s+=i; est dans le corps de la boucle, ce sera encore plus ridicule.

Selon R University, les ingénieurs JVM qui travaillent dur sont en phase d'optimisation en cours, selon +XX:+OptimizeStringConcat (ouvert par défaut après JDK7u40), le adjacent (sans instructions de contrôle entre les deux) Synthèse StringBuilder On s'efforcera également de deviner la longueur.

Donc, par mesure de sécurité, continuez à utiliser StringBuilder et définissez vous-même la longueur.

6. StringBuffer et StringBuilder

StringBuffer et StringBuilder héritent tous deux de AbstractStringBuilder. La seule différence est que les fonctions StringBuffer ont le mot-clé synchronisé.

Ces étudiants qui disent que StringBuffer est « sûr », avez-vous déjà vu plusieurs fils de discussion ajouter à tour de rôle un StringBuffer ? ? ?

7. Remettez toujours la concaténation des chaînes de journaux à slf4j??

logger.info("Hello {}", user.getName()) ;# 🎜🎜#

Pour les journaux que vous ne savez pas s'il faut sortir, laisser à slf4j le soin de les assembler uniquement lorsqu'ils ont vraiment besoin d'être sortis peut en effet réduire les coûts.

Mais pour les journaux qui doivent être générés, il est plus rapide d'utiliser StringBuilder pour les assembler vous-même. Parce qu'en regardant l'implémentation de slf4j, il s'agit en fait simplement d'un indexof("{}") constant, d'un subString() constant et d'une utilisation continue de StringBuilder pour l'assembler. Il n'y a pas de solution miracle.

PS. Le StringBuilder dans slf4j réserve 50 caractères en dehors du message d'origine. Si les paramètres variables totalisent plus de 50 caractères, ils doivent quand même être copiés et développés... et le StringBuilder n'est pas réutilisé.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!