Java—Principes et différences entre StringBuffer et StringBuilder

J'étais à la recherche d'un emploi récemment et l'examinateur m'a posé une question simple : « Quelles sont les différences entre StringBuffer et StringBuilder, et quels sont leurs scénarios d'application ? tout le monde peut apprendre à l'avenir et aussi être un bon exemple.

En fait, il suffit de chercher sur Google et vous aurez la réponse : les méthodes et fonctions de StringBuffer et StringBuilder sont complètement équivalentes, mais la plupart des méthodes de StringBuffer sont modifiées avec le mot-clé synchronisé, elles sont donc thread- safe , et StringBuilder n'a pas cette modification et peut être considéré comme non sécurisé pour les threads.

Afin de mieux comprendre la réponse ci-dessus, il est plus pratique de regarder directement l'implémentation du code source de StringBuffer et StringBuilder. En tant que programmeur, "en cas de doute, regardez le code source" est la bonne solution. façon. Je peux dire de manière responsable, bien sûr, il y a des conditions !

Dans l'implémentation de jdk, StringBuffer et StringBuilder héritent de AbstractStringBuilder. Vous pouvez avoir une idée approximative de la sécurité et de la non-sécurité du multi-threading en voyant le groupe de synchronisation devant les méthodes. dans StringBuffer.

Voici une discussion informelle sur le principe d'implémentation de AbstractStringBuilder : nous savons que l'utilisation de StringBuffer n'est rien de plus que d'améliorer l'efficacité de la connexion par chaîne en Java, car si la connexion par chaîne est utilisée directement, jvm créera plusieurs chaînes. objets, donc cela provoque des frais généraux. AbstractStringBuilder utilise un tableau de caractères pour enregistrer la chaîne qui doit être ajoutée. Le tableau de caractères a une taille initiale. Lorsque la longueur de la chaîne ajoutée dépasse la capacité actuelle du tableau de caractères, le tableau de caractères est étendu de manière dynamique, c'est-à-dire qu'une période plus grande est réappliquée. .espace mémoire, puis copiez le tableau de caractères actuel vers un nouvel emplacement. Étant donné que la surcharge de mémoire et de copie est relativement élevée, chaque fois que vous réappliquez de l'espace mémoire, vous devez demander un espace mémoire plus grand que l'espace mémoire. espace mémoire actuellement requis. Ici, c'est 2 fois.

Ensuite, amusons-nous !

Certaines informations sont sorties dans Google :

[
StringBuffer a démarré à partir du JDK 1.0
StringBuilder a démarré à partir du JDK 1.5

À partir du JDK 1.5 Initialement, l'opération de connexion ( ) avec des variables de chaîne est implémentée en interne par la JVM à l'aide de
StringBuilder, alors qu'auparavant cette opération était implémentée à l'aide de StringBuffer.
】

Regardons son processus d'exécution à travers un programme simple :

Listing 1 Buffer.java

public class Buffer {
public static void main(String[] args) {
String s1 = "aaaaa";
String s2 = "bbbbb";
String r = null;
int i = 3694;
r = s1 + i + s2;
 
for(int j=0;i<10;j++){
r+="23124";
}
}
}

Utilisez la commande javap -c Buffer pour afficher son implémentation du bytecode :

Listing 2 Buffer class bytecode

Convertir le listing 1 et correspondant au listing 2 , l'instruction ldc dans le bytecode du Listing 2 charge la chaîne "aaaaa" du pool de constantes vers le haut de la pile, istore_1 stocke "aaaaa" dans la variable 1, et comme ci-dessous, sipush charge une chaîne courte La constante entière La valeur (-32768~32767) est poussée vers le haut de la pile, voici la constante "3694". Pour plus de jeux d'instructions Java, veuillez consulter un autre article "Jeu d'instructions Java".

Voyons directement que 13, 13~17 crée un nouvel objet StringBuffer et appelons sa méthode d'initialisation, 20~21 pousse d'abord la variable 1 vers le haut de la pile via aload_1, comme mentionné précédemment, la variable 1 est mise en haut de la pile se trouve la constante de chaîne "aaaaa", puis appelle la méthode append de StringBuffer via l'instruction invocationvirtual pour assembler "aaaaa", et il en va de même pour les 24 à 30 secondes suivantes. Enfin, en 33, la fonction toString de StringBuffer est appelée pour obtenir le résultat String et stockée dans la variable 3 via astore.

En voyant cela, certaines personnes pourraient dire : "Puisque la JVM utilise StringBuffer en interne pour connecter des chaînes, nous n'avons pas besoin d'utiliser StringBuffer nous-mêmes, utilisez-le simplement" "C'est tout !". Vraiment? Bien sûr que non. Comme le dit le proverbe, "Il y a une raison d'exister". Continuons à regarder le bytecode correspondant à la boucle suivante.

37~42 sont toutes des préparations avant d'entrer dans la boucle for. 37 et 38 doivent définir j à 1. 44 compare ici j avec 10 via if_icmpge. Si j est supérieur à 10, passez directement à 73, cela. autrement dit, l'instruction return quitte la fonction ; sinon, elle entre dans la boucle, qui est le bytecode de 47~66. Ici, il suffit de regarder 47 à 51 pour savoir pourquoi nous devons utiliser StringBuffer pour gérer la connexion de chaîne dans le code, car chaque fois que l'opération " " est effectuée, la JVM doit créer un nouvel objet StringBuffer pour gérer la chaîne. connexion. Cette surcharge sera élevée lorsque de nombreuses opérations de concaténation de chaînes sont impliquées.

Pour plus d'articles sur les principes et les différences de Java-StringBuffer et StringBuilder, veuillez prêter attention au site Web PHP chinois !