"Nem, a leak definíciója az, hogy funkcionálisan felszabadítható memóriaterület foglalt marad. Arról, hogy időnként ráolvas-e a program vagy sem, arról a leak semmit nem mond."
Én itt önellentmondást érzek. A funkcionálisan felszabadítható területet azért nevezzük funkcionálisan felszabadíthatónak, mert biztosan nem olvasunk rá többet. Amire még ráolvashatunk, az nem szabadítható fel.
A láncolt listás példád nem leak, hanem csupán egy szuboptimális memóriastruktúra, hiszen kell a lánc összes tagja, valamikor, valahova fel fogja használni. Az, hogy emellett az új elem végére rakásához neki végig kell gyalogolnia a listán, az csak sima programozói balfaszság. Lehet láncolást a másik irányból is csinálni, foglalsz egy elemet, és az előzőleg foglalt elem címét adod meg neki, így a lánc lefele lóg, te mindig a tetejét látod, így nem kell mindig végigolvasni az utolsó elemet keresve. De ez tökmindegy, értem, hogy csak példa volt.
Szóval maradva a példádnál, van egy lánc amit mindig fel kell olvasni, mert csak. Oké. Ez milyen perfomancia vesztéssel jár? Az attól függ, hogy milyen gyakran és menyit kell olvasni a lemezről. Ha gyakran olvasod, akkor nem kerül ki a swapre. Ha kikerül, mert csak naponta egyszer olvasnak rá, akkor meg naponta egyszer villan egyet az SSD/storage oldalán a LED. Ha nagyon hosszú a lánc, és minden eleme egy külön IO, akkor igazad van, lehet, hogy érezhető lesz a várakozás.
De ez egy nagyon kisarkított példa, amit szerintem te is tudsz, hiszen írod, hogy "Ha ezt rendszeresen kiteszed swap-re, akkor percenként latency vesztésed lesz, ha nem teszed ki swap-re, akkor meg más aktív dolog fog kikerülni és felváltva latency problémáid lesznek.". Namármost amit percenként használsz, az soha nem lapozódik ki, kivéve, ha nincs elég memória a gépben. Szerintem te is képben vagy afelől, hogy napjainkban a programok rettenetesen erőforrásigényesek, de ez nem csoda, mert a programozó ideje több fabatkába kerül mint még egy giga memória, amiből 100 MB azért megy pocsékba, mert a hülyéje fix méretű timestampeket egyesével láncolgat, ahelyett, hogy értelmesen tárolná ezeket. Vagy láncot használ verem helyett. Vagy akármi, amit az ember elkövet, ha kevés idő alatt kell ha nem is készre, de működőre csinálni valamit.
A sima leak szerintem sokkal gyakoribb dolog (fun fact: google: "java leaking" 26 millió találat) mert ez ugye akkor van, amikor egy függvényben van egy malloc/new amin valamit csinál a függvény, majd a végén valamit ellenőriz, és például ha jó az érték akkor kibányássza a lefoglalt memóriából amire szüksége van, jön a free, és visszatér az eredménnyel, viszont ha az ellenőrzés során valami nem jó, akkor visszatér egy konstans hiba értékkel, és mivel ehhez már nem kell a lefoglalt memóriához nyúlni, a programozó simán elfelejti a free utasítást.
Ez a függvény csak néha fut hibára, és olyankor is csak néhány kilobyte ami elvész, viszont ez valóban leak, mert a függvény lokálisan tárolta, hogy hol volt a lefoglalt memória, így miután visszatért, ez az infó elveszett. Vagyis garantáltan nem lesz ráolvasva erre a memóriára, szemben az általad írt láncolt listára ami nem leak, hiszen minden cím elérhető, és jó eséllyel még használva is lesz, elvégre nem ok nélkül gyűjti az adatokat.
"Nincs kontrollod. Azt hiszed, hogy van kontrollod, de nincs."
Hát, lehet, hogy csak egy pillangó vagyok aki arról álmodik, hogy a gyakorlatban tök jól működik, és nemsokára felébredek, de most én tök nyugodtan alszom, mert a monitorban szépen tudom követni, hogy melyik process hány MB memóriát pazarolt el, és így azt is tudom, hogy nagyjából mennyi idő van még, amíg ez gondot okoz, így nem érnek meglepetések, miközben a hibás programok nem a drága memóriát pazarolják.
Figyelj. Értem amit mondasz. Teljesen egyet is értek veled elméletben, csak éppen a gyakorlat többnyire nem olyan tiszta és szép, mint az elmélet.