![]() |
Was pasiert mit Speicherlecks
Hallo,
was passiert eigentlich mit Speicherplatz den man nicht wieder freigibt? Wenn man im IDE arbeitet? Wenn man es so als exe startet? Bleibt es alles einfach zurück. Tschüss Alexander PS: Jaaa, ich weis immer freigeben und das mache ich auch. |
Re: Was pasiert mit Speicherlecks
AFAIK gibts Windows die von deinem Programm genutzten Resourcen wieder frei, nachdem es beendet wurde.
Speicherlecks dürfen als nur zur Laufzeit Probleme verursachen (EOutOfMemory ^^). |
Re: Was pasiert mit Speicherlecks
|
Re: Was pasiert mit Speicherlecks
Also ich glaube ja nicht das das stimmt.
Denn dann würde sich der Ram ja nicht "Zumüllen" lassen. wenn ich z.b. einen Mediaplayer laufen hab und den dann schliese gibt das system auf keinen Fall allen Speicher wieder Frei. ( was mir mein Ram überwachungstool anzeigt ). Ich denke das funktioniert wenn überhaupt nur dann wenn der User nur statische Variablen hat. Wenn du aber hergehst und die Mega Pointer ketten aufbaust, habe ich so meine Zweifel das das Betriebsystem die Tatsächlich alle Freigeben kann wenn die exe geschlossen wird. |
Re: Was pasiert mit Speicherlecks
Hallo,
Zitat:
Das ist jedoch kein Freifahrtschein. Nur weil Windows hinter Dir herräumt, heißt das nicht, dass Du eine Sauerei veranstalten solltest. Gruß xaromz |
Re: Was pasiert mit Speicherlecks
Zitat:
|
Re: Was pasiert mit Speicherlecks
Zitat:
dass ist gar nicht möglich. Die Ram-Überwachungtools werden wohl von den Ram-Entmüller-Tool-Herstellern produziert. Speicher wird von einem Prozess erzeugt und mit dessen Ende auch wieder freigegeben. Der Mediaplayer (und ein paar andere Programme) sind dabei etwas tiefer in das System von Windows verankert. So findet man einige Programme wie den IE oder eben MediaPlayer, die sehr viel flinker als die Konkurrenz starten, weil sie zum Teil beim Start vorgeladen werden (bzw. einzelne Bibliotheken, die mehrere Prozesse verwenden können). Natürlich sieht es dann bei der Freigabe ähnlich aus, ein paar Dinge, die auch für den nächsten Start benötigt werden können bleiben einfach mal im Speicher. Mit statischen Variablen hat das mal gar nichts zu tun. In eigenen Programmen kann man sicher sein, dass spätestens mit dem Ende des Programms aller allozierter Speicher wieder als frei markiert wird. Der Nachteil daran Speicher nicht selbst frei zu geben (ein Speicherleck zu erzeugen) besteht einfach darin, dass der Speicher unnötig lange belegt ist. Gerade Windows98 hat hier gerne eine feste Grenze des virtuellen Speichers, was dann dazu führt, dass man den erwähnten Fehler sieht. Aber auch modernere Betriebssysteme profitieren nicht von Speicherleichen. Hast du z.B. viele Bilder die geöffnet werden oder Videos, so wird der RAM schnell gefüllt. Bei der Freigabe des hier allozierten Speichers kann dieser Bereich nun für andere Variablen verwendet werden. Vergisst man dies, muss erst das alte Datum aus dem Ram verdrängt werden (und Festplattenzugriffe kosten Zeit) und erst dann kann eine andere Variable den phy. RAM verwenden. Endet der Prozess, wird hier nun der komplette belegte Speicher frei gegeben (eben auch der virtuelle, der evtl. unnötig verdrängt wurde). Wichtig ist es eigentlich nur zu wissen, dass Windows sich um den tatsächlich belegten Speicher kümmert. Wer wirklich im phy. RAM und wer im virtuellen landet ist alles Sache des OS. Es gibt da kaum Möglichkeiten Einfluss darauf zu nehmen. Dass es hier keine Engpässe gibt liegt an wirklich gut arbeitetenden Systemen, die sich u.A. halt merken wer welchen Speicher reserviert und diesen damit freigeben können, wenn der entsprechende Prozess nicht mehr läuft. Gruß Der Unwissende |
Re: Was pasiert mit Speicherlecks
Der vom Programm reservierten Speicher (RAM) wird am Ende wieder freigegeben ... das ist meistens so schonmal richtig.
Anders sieht es aber mit SharedMemory aus, solange der noch von irgendeinem anderem Programm verwendert wird ... er wird erst freigegeben, wenn alle Programme die darauf zugreifen beendet sind. Dies gilt auch für den gemeinsamen Speicher in gemeinsam genutzten DLLs (wie die von Windows, also da wo auch die ganzen WinAPI-Funktionen drin sind), solange die DLLs den Speicher nicht einzeln für die Applicationen verwalten. Was das "Zumüllen" des RAMs angeht ... es laufen ja noch genug andere Anwendungen, die dafür sorgen und sowas wie die FileCache spielt da auch noch mit. PS: was die RAM-Entmüllprogramme angeht, da gibt es schon einige Threads dazu und das Fazit daraus, die sind selber Müll bringen keine wirkliche Verbesserung ... leßt da einfach nochmal genau nach :zwinker: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz