To nezaručení je často špatně chápáno. Java (a obecně žádný jazyk s GC, ani ten používající GC s refcountingem, pokud dojde k cyklům, tak refcounting nefunguje) nezaručuje, kdy budou finalizéry vykonány, protože z pohledu programu se GC nespouští deterministicky a objekty k uvolnění nevybírá deterministicky; GC se spouští, když samo uzná za vhodné, a vybírá objekty, které uzná za vhodné, takže třeba když máte spoustu volné paměti, tak se nespouští vůbec, a když jí máte méně, ale pořád dost, tak uvolňuje jen velké objekty. Problém je také, že zdroje uvolňované finalizéry GC nevidí, takže může třeba vyhlásit nedostatek paměti, přestože finalizér jednoho malinkého nereferencovaného objektu by ji uvolnil. Finalizéry nebudou vykonány, jen pokud program skončí, než ten objekt uvolní GC; v moderních operačních systémech se finalizace (flush, zavření souborů, uvolnění zámků ap.) vykoná automaticky při ukončení programu, takže to nevadí. Ale nikdy nedojde k situaci, kdy GC uvolní objekt a nevyvolá přitom finalizér.
Nicméně ani Javě nejde vše jen přes GC, i tam se mohou finalizéry vyvolat synchronně, pokud JIT/AOT překladač detekuje, že objekt nemůže utéct z funkce, nepoužije (pomalé) GC, ale alokuje jej s lokální referencí a tu při ukončení funkce uvolní (včetně vyvolání finalizéru; typicky tohle dělá třeba Dalvik na Androidu). Ale je to interní věc VM a není nijak zaručena, to chování se může měnit třeba i s velikostí funkce a jak často je spuštěna.