Az a gond, hogy nagyon corner esetről beszélünk. Nézzük meg, hogy milyen fő dolgok lehetnek, és ezeknek mi a következményük:
1, Socket connection: ha server socket-et csinálsz, és elfelejted lezárni. Vicces módon egyébként ha bekerül a GC hatáskörébe, akkor vagy le lesz zárva előbb vagy utóbb, vagy nem, és akkor látod a problémát, ha egy idő után nem tudsz klienssel csatlakozni. Mennyire veszélyes-általános a probléma? Az esetek legkisebb %-ban kezeljük saját kézzel a socket-eket, hanem valami framework-öt használunk. Ha mégis előjönne, akkor jó eséllyel lesz a logban egy exception, amiből aztán kapásból kiderül a probléma.
2, File socket: pontosan ugyanaz a helyzet, mint az első esetnél, valószínűleg kicsit előbb fog előjönni a probléma, ugyancsak nincs elég fileleíró szerű dolog lesz a logban, könnyen javítható.
3, Deadlock: deadlock akkor lesz, ha két külön szál próbál keresztbe foglalni erőforrást. Ha synchronized kulcsszót használunk, akkor a felszabadítás automatikusan megtörténik (persze deadlock-ot ettől még lehet csinálni), ellenkező esetben (kézzel kezelt lock és társai) valóban figyelni kell rá. De itt sokkal veszélyesebbnek érzem azt, hogy deadlockot csinál a kedves user.
Ez a három eset van, ami így eszembe jut, az első kettő szinte sosem fordul elő, a harmadiknál pedig ha synchronize-t használ, akkor sem lehet gond, egyedül ha kézzel használ lock-okat. Akkor meg sajnos oda kell figyelni. (talán a profiler egyébként mutatja a foglalt lockok számát, ha ez folyamatosan nő, akkor az jel lehet arra, hogy valahol bug vagyon...)
Cserébe a fejlesztés további részében nem kell arra figyelnem, hogy ki kit mikor szabadít fel, hogy stack-en vagy heap-en vannak-e a dolgaim, hogy referenciát vagy pointert adok át, hogy ezeket hogyan védem. Ezt a rengeteg energiát felhasználhatom arra, hogy abban a 10 osztályban, ahol a fentieket használom, helyesen kódoljak.