Az üres utasításblokkba csak be kell írni egy NOP-ot és megkommentezni, hogy ezért van ott :-)
A finalize-ra nem nagyon van jó megoldás. Mármint ha nincs a programban leak és mindent szépen lezárogat időben "kézzel" (lásd try finally AutoCloseable minta), akkor az jó. De ha valami lib elfelejt néhányat lezárni, és elkezdenek ezek a heapen kallódni az már nem jó.
De az ilyen helyzet még menthető volna például kézzel periódikusan triggerelt GC-vel. Példaul ha lefuttatom "kézzel" a GC-t pl óránként! Nem, nem, nem! A GC-t nem futtathatod kézzel, majd a VM eldönti, hogy mikor jó neki!
Van System.gc hívás, de nincs rá garancia, hogy valóban le is fut! Például ha csak egyszer hívod meg, akkor többnyire nem lesz teljes GC! Tehát a finalizálandó objektumod megúszhatja ha valami öregebb generációban csücsül.
Igazából a JVM memória és egyéb resource foglalását elég nehéz kézbentartani. A "kedvencem" a natív memóriát foglaló (direkt) ByteBuffer ojjektum. Ennek szabályos API-ja nincs is a tárterület felszabadítására, csak Unsafe-en keresztül lehet elérni, hogy szabadítsa fel a memóriát. Egyébként lényegében finalize-ban van csak felszabadítva. Ebből az következik, hogy ha nem csinálod meg kézzel a finalize-t az összes ilyen ojjektumodra, akkor nem tudsz egy pontos képet se kapni arról, hogy éppen mennyi memóriád van szabad, mert az csak GC után derülne ki, azt meg nem tudod kikényszeríteni.
Jó nagy káosz ez a GC, kár hogy nem nagyon van jobb.
Ami nagyon jó a GC-ben, hogy memória töredezés viszont nincsen benne. Ugye amiben van memória töredezés, abban nagyon nehéz olyat állítani, hogy ez a program márpedig működni fog két évig megállás nélkül. Lényegében csak menedzselt memóriájú nyelvvel, illetve teljesen statikusan foglalós C-vel lehet ezt könnyű szívvel igazoltan kijelenteni.
2 éves futásidő már nem rossz egy processztől, gratulálok hozzá!