Esküszöm, nem értem, mit akarsz mondani Superhun válaszára.
De pár tény:
1) A JVM k*rva okos és tele van optimalizációval. Memória allokációnak alig van költsége, persze sok kis objektum lassíthatja a GC-t. Megoldás: arra az objektumra ne veszítsük el a referenciát, amit újra fogunk használni. Ennek megkönnyítésére szoktak memory poolokat implementálni Javában úgy, ahogy C++-ban is. De ezeket elég speckó esetekben szokták használni, amikor a sebesség van mindenek felett.
2) literálokra referencia mindig ugyanarra a memóriaterületre mutat. for() { String s = "nyorr"; } nem fog új objektumot létrehozni minden egyes iterációban
3) Olyan mikro-optimalizációról beszélünk, aminél egy adatbázis lekérdezés nagyságrendekkel lassabb: semmi értelme gondolkodni rajta
Ciklusban String összefűzést StringBuilderrel, mert azt a compiler tudtommal nem ismeri fel, ellenben a "egy" + "ketto" + $valami.toString; kóddal, amit StringBuilderre cserél (vagy StringBuffer, most hirtelen nem emlékszem, melyik a thread-safe)
Nem látom értelmét String helyett StringBufferben tárolni a stringet.
Szerk.:
Közben rájöttem, mit akartál mondani, de elég veszélyes. Ha Stringbuilderben tárolod a stringeket, akkor a StringBuilder mutable, és olyan helyen is megváltoztathatod a String értékét, ahol nem akarod. pl.:
StringBuilder strTime = getTimeInString();
page1.setLastVisited(strTime);
majd később:
StringBuilder strTime = getTimeInString();
page2.setLastVisited(strTime);
no shit, lastVisited szintén frissült page1-re, mert ugyanaz az objektum. Nem hiába találták ki, hogy a String immutable.
