Einhvern tíman las ég að maður gæti hjálpað ruslasafnaranum með því að nulla object eftir að búið væri að nota þau í Java. Hef ekki séð neina sönnun á því samt.

Í C# er hægt að kalla á System.GC.Collect() til að neyða ruslasafnarann að hreinsa upp minni, en það er mælt með því að fara virkilega varlega í slíkar æfingar.

Góð grein og bara ein spurning.

Hefur Java sýndarvélin ekki screen buffer sem myndi skrifa út hvern streng fyrir sig í dæmi 2 hjá þér í staðinn fyrir að skeyta öllum strengjum saman í einn og skrifa hann svo út?

Mjög áhugaverð grein hjá þér Massi. Svona pælingar eru skemmtilegar og er eitthvað sem maður mætti gera meira af að fara eftir.

Ég hlakka til að lesa næstu greinar frá þér í þessum flokki.

Góð point. Þetta er eitthvað sem maður þarf að hugsa meira um.

Java þýðandinn breytir sjálfkrafa strengjasummum í StringBuffer. Ef útgáfan þín af javac gerir það ekki þá er að öllum líkindum rofi fyrir það.

Prófaðu að þýða eftirfarandi forrit:

public class Prufa
{
public void main(String[] args)
{
System.out.println(“a”+“b”+“c”);
}
}

Notaðu svo decompiler (til dæmis DJ) til að þýða .class fælinn aftur yfir á java kóða. Þá færðu eftirfarandi:

public class Prufa
{
public void main(String[] args)
{
System.out.println(new StringBuffer(“a”).append(“b”).append(“c”).toStrin g());
}
}

Þannig að það er ekki að sjá að það sé neinn munur á bætiskóðanum hvort sem maður notar String eða StringBuffer.

ÞÚ REIKNAR ÞETTA EKKI ALVEG NÁKVÆMLEGA ÞVÍ ´MEÐ MÍNUM ÚTREIKNINGUM=423(87%64/55) +98** /87# -12/12% 634)))** 12+161012-GAGNFORITINU =4512&340 MEÐ SINFONÍUUSAR REGLUNAR */* 56 ER =38% AF 12,23“”

Nokkrar athugasemdir við þennan þráð.
>Í Java er hlut (Object) hent við lok hverrar blokkar sem aðgang hefur í hlutinn…

Ef þú ert að tala um blokk í java skilningi (milli tveggja slaufusviga) þá er þetta ekki rétt. Hlutum er einungis hent úr minni af ruslasöfnunarþræði ef engin tilvísun finnst í hlutinn. Ruslasöfnunarþræðir keyra að jafnaði einungis ef að minnishaugar eru fullir. Þ.a. ef þú tiltekur lágmarksstærð 512mb af minni þegar þú ræsir java forrit (-Xs512m), en notar hámark 20mb, þá er ruslasöfnun aldrei gerð. (Nema þú kallir sjálfur á System.gc()). Hinsvegar er breytum hent úr minni við lok blokkar, en það er önnur saga.

>Dæmi 1: Léleg forritun – Hér eru búin til hundrað þúsund strengjabreytur og þeim hent aftur jafn óðum.
for(int i=99999; i>0; i–){
String str = “massi”;
System.out.println(str);
}

Hmm, það er örrugglega perraskapur að pota í þessa athugasemd og dæmi - en fjöldi breyta er ekki vandamálið hér, heldur fjöldi hluta sem eru búnir til. Þannig að flytja skilgreiniguna á breytunni út fyrir lykkjuna breytir engu ef þú heldur áfram að búa til hlutina inni í lykkjunni, þú ert með jafnmargar gildisveitingar og frumstillingar á hlutum í báðum dæmunum. (Hinsvegar notar dæmið statiskan streng, sem þýðandinn setur í töflu yfir statisk gögn í klasanum, ergo einungis 1 hlutur er búinn til. Til að gera dæmið betra mætti breyta [str = “massi”] í [str = new(“massi”)] sem myndi frumstilla 1 nýjan hlut í hverri umferð í lykkjunni. Síðan mætti flytja þá línu upp fyrir lykkjunna í seinna dæminu til að sýna betri forritun. (Það að gera new(“einhver strengur”) er hinsvegar að jafnaði ekki góð forritun þar það kemur í veg fyrir áðurnefnda samnýtingu á strengjum sem þýðandin framkvæmir)).

>Einhvern tíman las ég að maður gæti hjálpað ruslasafnaranum með því að nulla object…
Já það getur gert það (en, frekari perraskapur, maður nullar ekki object því hlutir geta ekki tekið neitt null gildi, maður nullar breytur (þ.e.a.s. veitir þeim null gildið)).
Ruslasöfnun í Java byggist á að finna hluti sem hafa engar tilvísanir í sig. Hver breyta sem hefur gildi (er sem sagt ekki með null gildi) hefur tilvísun í einhvern hlut. Ef breytan x er member í hlut A sem hefur langan líftíma, þá mun hlutur B sem x vísar í, vera til í minni a.m.k. allan líftíma A (hversu lengi er háð því hvort einhverjir aðrir vísi í hlutinn og keyrslu á ruslasöfnun). Ef hluturinn B sem x vísar í er einungis notaður í skammastund (t.d. byte[] sem notað við innlestur á skrá) þá getur borgað sig að setja x=null eftir innlesturinn til að halda hlutnum ekki að óþarfi í minni.

Hinsvegar er eftifarandi blokk dæmi um óþarfa null gildisveitingu:
… einhver kóði
if (eitthvað skilyrði) {
byte[] x = new byte[1000000];
.. einhver vinnsla með x
x = null;
}
… áframhaldandi kóði

Þar sem breytan x á sér einungis lífdaga innan if blokkarinnar þá bætir x=null engu við, því það næsta sem gerist er að blokkin klárast og öllum staðværum breytum í henni er hent.

Því má segja að þetta snúist allt um líftímann á breytum annarsvegar og notagildi þeirra hinsvegar. Þ.e.a.s. ef breyta lifir mun lengur en hún er notuð, þá getur borgað sig að setja null gildi í hana til að losa tilvísanir í undirliggjandi hluti. Það má síðan færa rök fyrir því að það sé vond forritun að láta breytur lifa mun lengur en notagildi þeirra, en það er önnur umræða.

Í lokinn, smá niðurlag við umræðuna um strengjavinnslu. Þýðandin reynir að besta alla notkun á ‘+’ virkjanum í strengavinnslu, sem sagt a + b + c…, með því að umbreyta þessu í StringBuffer. Slíkt er tiltölulega einfalt þar sem þessi virki hefur enga hliðarverkun. Hinsvegar verður hann alltaf í meiri erfiðleikum með ‘+=’ þar sem þar er kominn gildisveiting. Ég hef ekki skoðað það en myndi gera ráð fyrir að hann reyni ekki einusinni að besta slíka vinnslu. Menn geta sem sagt notað ‘+’ virkjan án þess að spá í String vs. StringBuffer, en verða að gæta sín í öðrum tilfellum (og aðsjálfsögðu engu að tapa við notkun á StringBuffer, nema stundum lesanleika).

slartibartfast