Dotaz: Java zvětšení pole pomocí znovuvytvoření

[jafaa]

Potřeboval bych v javě zvětšit pole. Asi jediná možná cesta je znovuvytvořit ho, tzn. mojepole = new int[velikost]; Takhle to funguje, ale mám pocit že tím se neuvolní místo v paměti po starém poli. Jestli je to tak, jak mám to místo uvolnit?

---

---

Odpovědi

[Jan Trávníček]

Java používá garbage collector, díky tomu se sama stará o uvolnění paměti - nic není potřeba uvolňovat. Zvětšení pole v javě můžeš jedině přes inicializaci jiného a překopírování obsahu (třída Arrays poskytuje metody na kopírování). Pokud by si vyžadoval dynamickou velikost pole zkusil bych ArrayList nebo něco obdobného.

[kuka]

Jen doplnim, ze zminene metody v Arrays jsou az od verze 1.6, (nejen) ve starsich lze pouzit System.arraycopy().

[Jan Trávníček]

Staré pole se uvolní automaticky po té, co na něj nebude ukazovat žádný odkaz – v Javě se o uvolňování paměti stará garbage collector. Jinak pokud potřebujete měnit velikost, použijte raději nějakou kolekci. Používat pole a měnit jeho velikost může být dobré jedině v případě, kdy je to kritická část kódu, kterou potřebujete optimalizovat – a k tomu je zase potřeba Javu znát docela dobře. Pokud potřebujete výsledek předat někam, kde se očekává pole, převeďte kolekci na pole až těsně před použitím pomocí toArray().

[podlesh]

Jenom bych doplnil, že tazatel chce ukládat inty, takže používání standardních kolekcí (= boxing) přináší overhead (především paměťový). U malého objemu dat je to celkem jedno, ale u větších už je rozdíl znát a vyplatí se používat pole primitivních typů.

I tak ale není nutné psát si to ručně, existují knihovny jako PCJ (mám dobré zkušenosti), GNU Trove (nemám zkušenosti) a řada dalších (nechce se mi hledat, google pomůže).

[Filip Jirsák]

Přehlédl jsem, že jde o pole intů. Ale i tak, to co píšete už je optimalizace – a je lépe nejprve použít kolekce a teprve když se ukáže, že je tam výkonový nebo paměťový problém, řešit optimalizaci, než to psát rovnou „optimalizovaně“, nadělat chyby v kopírování polí, napsat to kopírování neefektivně a nakonec zjistit, že s tou optimalizací je to horší, než bez ní. Tedy nic proti optimalizacím, jenom je potřeba si uvědomit, že takové kopírování pole může ve skutečnosti výkon i paměťovou náročnost zhoršit. Ostatně, pro velký objem dat se zase bude spíš než pole hodit něco z java.nio.

[happy barney]

používanie javy všeobecne prináša pamäťový overhead

[maertien]

Diky Garbage Collector neni treba se uniku pameti obavat.

[Filip Jirsák]

To bych netvrdil, i s garbage collectorem je možné vyrobit únik paměti. Není nutné explicitně uvolňovat paměť, ta se uvolní po té, co se daný objekt přestane používat (přestane na něj existovat ukazatel). Pořád ale můžete vyrobit únik paměti tak, že budete držet ukazatel na nějaký objekt, který už nepotřebujete.

[happy barney]

pozor, javovský gc pracuje len "niekedy v budúcnosti". Extrémna situácia: medzi dvoma spusteniami gc sa vyčerpá toľko pamäte, že gc jej nebude mať dosť na svoj vlastný beh

[Filip Jirsák]

Ze skutečnosti, že o tom nic nevíte, nemusíte hned vyvozovat závěr, že to určitě funguje špatně. Funkce alokátoru paměti nezávisí na tom, zda požadavky na alokaci paměti a její vrácení dostává explicitně od programátora, nebo se o ně stará nějaká softwarová komponenta.

[podlesh]

Myslím že diskuse by se měla zamknout, jediné co zde přibude je flamewar.

[cronin]

To len hadas, alebo pises o nejakej prototypovej implementacii GC s cias ked JDK 1.0 bola horucou novinkou? Sucasne Javovske garbage collectory su uz uplne, ale uplne inde.