Dans une application Web de production, mes collègues programmeurs ont utilisé StringBuffer partout. Maintenant, je m'occupe du développement et des corrections d'applications. Après avoir lu StringBuilder et StringBuffer, j'ai décidé de remplacer tout le code StringBuffer par StringBuilder car nous n'avons pas besoin de la sécurité des threads dans nos beans de données.
Par exemple: (Dans chaque bean de données, je peux voir l'utilisation de StringBuffer)
@Override
public String toString() {
StringBuffer sb = new StringBuffer();// replace it from StringBuilder
sb.append(" ABCD : ").append(abcd);
sb.append(", EFGH : ").append(efgh);
sb.append(", IJKL : ").append(ijkl);
}
Nous créons des beans de données séparés pour chaque session / demande. Une session est utilisée par un seul utilisateur, aucun autre utilisateur ne peut y accéder.
Dois-je considérer d'autres points avant de migrer?
S'il existe un seul thread (aucun thread en attente / aucun nouveau thread ne recherchera le verrouillage d'objet), il fonctionne de la même manière avec StringBuffer ou StringBuilder. Je sais que dans le cas de StringBuffer, il faut du temps pour prendre le verrou d'objet, mais je veux savoir s'il y a une différence de performances entre eux, sauf le maintien / relâchement du verrou d'objet.
StringBuffer
. Je n'ai jamais vu de code comme ça, mais je suis presque sûr que c'est une mauvaise conception d'un point de vue multithreading. Puisque je pense que synchroniser le fil le long de l' StringBuffer
interface est une mauvaise idée, je pense que cette classe ne devrait pas exister et que l'on devrait toujours l'utiliser StringBuilder
. Comme d'autres l'ont déjà mentionné, StringBuffer
existe pour des raisons historiques.
sb
une variable locale comme dans votre exemple, la sécurité des threads n'a pas d'importance du tout. Même si mille threads entraient simultanément dans la méthode, chacun aurait sa propre pile d'appels avec ses propres variables locales. Les StringBuilders n'interfèrent jamais les uns avec les autres.