Az objektum altal "kozvetlenul" elfoglalt memoria talan a kisebb problema ezekben az esetekben (nyilvan nem orom, de lenyelheto beka a gyakorlatban). Inkabb az a necces, amikor az objektum valamilyen eroforrast kezel (legyen ez tranzakcio, socket, lock, file, nagyobb buffer). Es ebbol a szempontbol nagyon nem mindegy, hogy az adott eroforras mikor lesz elengedve. Ha nem a using-ot hasznalod, akkor pl. a lock biztosan megmarad a kovetkezo gc-ig, de lehet, hogy meg azutan is, ugyanis semmi nem garantalja egy gc rendszerben, hogy az osszes elerhetetlen objektum felszabaditasra kerul!!! Pl. donthet ugy az algoritmus, hogy mivel mar sok munkat vegzett, es hogy ne alljon tul sokaig a program (pl. gui vagy real-time alkalmazasok eseten ez lehet problemas), ezert benthagy egy kis szemetet a kovetkezo gc-re. Ha az eroforras egy listening socket, amit te mar elengedtel, es rogton utana szeretnel egy ujat letrehozni, akkor a bind() el fog hasalni, mivel a regi socket meg nincs bezarva. Ez konkretan helytelen viselkedes es csak a using tud segiteni rajtad.
Horribile dictu: ha tenyleg vannak real-time kriteriumok a rendszerben (tehat nem futhat gc bizonyos muveletek vegrehajtasa kozben), akkor szokas a gc-t idolegesen letiltani. Ilyenkor kis figyelmetlenseggel es a using hanyagolasaval azert mar lehet dead-lock-ot is csinalni! Ha becsuletesen hasznalod a using-ot, akkor ez a gond nem all, mert a Dispose() meg fog hivodni meg letiltott gc mellett is.
Asszem a gc-rendszerekben egyebkent is a destruktorok irogatasa nem eppen good practice. Helyette az IDisposable megvalositasa preferaltabb. Viszont onnantol kezdve tenyleg a programozon all, hogy explicite using-on keresztul kell az osszes objektumot hasznalnia, ha korrekt viselkedest akar es nem szeretne szivni a fentiekkel.