new
erzeugt, oder mittels StringBuilder zusammengefügt wurde. Dann nämlich ist der String nicht aus dem Javainternen-Cache abrufbar. Das hat zur Folge, dass zum Beispiel bei der Verwendung von equals der tatsächliche Inhalt der Zeichenketten verglichen werden muss, was unperformanter ist, als der einfache Referenzvergleich, der sonst als erstes von der equals-Methode ausgeführt wird. Zur Verdeutlichung: das folgende Beispiel ergibt false"foo" == new StringBuilder().append("f").append("oo").toString()
Dieses hier hingegen ist true
"foo" == new StringBuilder().append("f").append("oo").toString().intern()
Wird ein neu gebauter String später häufig verglichen, so kann es sich lohnen die intern-Methode zu verwenden, um unnötige operationen beim Stringvergleich zu vermeiden.
Interessant ist übrigens, dass das Java-Framework selbst ebenfalls davon gebrauch macht, um den Vergleich mit equals gleich ganz zu vermeiden. In der Klasse java.lang.Class findet sich zum Beispiel folgende Methode, die aber nur deshalb sicher funktioniert, weil die getName-Methode der Klasse java.lang.Field garantiert, immer einen interned-String zurückzugeben.
// Helpers for fetchers of one field, method, or constructor private Field searchFields(Field[] fields, String name) { String internedName = name.intern(); for (int i = 0; i < fields.length; i++) { if (fields[i].getName() == internedName) { return getReflectionFactory().copyField(fields[i]); } } return null; }
*Update 19.5.11*
Links: mindprod, enicholas
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.