Forstå og forhindre hukommelsesudætninger i Delphi

DelphiSupport til objektorienteret programmering er rig og kraftfuld. Klasser og objekter muliggør modulær kodeprogrammering. Sammen med mere modulære og mere komplekse komponenter er de mere sofistikerede og mere komplekse bugs.

Under udvikling applikationer i Delphi er (næsten) altid sjov, der er situationer, hvor du har lyst til, at hele verden er imod dig.

Hver gang du har brug for (oprette) et objekt i Delphi, er du nødt til at frigøre den hukommelse, det forbrugte (en gang ikke længere var nødvendigt). Sikkert, kan prøve / endelig hukommelsesbeskyttelsesblokke hjælpe dig med at forhindre hukommelseslækager; det er stadig op til dig at beskytte din kode.

En hukommelse (eller ressource) lækker opstår, når programmet mister evnen til at frigøre den hukommelse, det forbruger. Gentagne hukommelseslækager får hukommelsesbrugen til en proces til at vokse uden grænser. Hukommelseslækager er et alvorligt problem - hvis du har en kode, der forårsager hukommelseslækage, i et program, der kører 24/7 vil applikationen spise op al den tilgængelige hukommelse og til sidst få maskinen til at stoppe med at svare.

Det første trin for at undgå hukommelseslækager er at forstå, hvordan de forekommer. Det følgende er en diskussion om nogle almindelige faldgruber og bedste praksis til at skrive ikke-lækkende Delphi-kode.

I de fleste (enkle) Delphi-applikationer, hvor du bruger de komponenter (knapper, memoer, redigeringer osv.), Du slipper på en formular (på designtidspunktet), behøver du ikke være meget opmærksom på hukommelsesstyring. Når komponenten er placeret på en formular, bliver formularen dens ejer og vil frigøre hukommelsen taget af komponenten, når formen er lukket (ødelagt). Formularen, som ejeren, er ansvarlig for hukommelsesfordeling af de komponenter, den har vært. Kort sagt: komponenter på en form oprettes og ødelægges automatisk

I enhver ikke-triviel Delphi-applikation skal du øjeblikkeligt Delphi-komponenter under kørsel. Du vil også have nogle af dine egne tilpassede klasser. Lad os sige, at du har en klasse TDeveloper, der har en metode DoProgram. Når du nu skal bruge TDeveloper-klassen, opretter du en forekomst af klassen ved at ringe til skab metode (konstruktør). Metoden Opret tildeler hukommelse til et nyt objekt og returnerer en henvisning til objektet.

Var
zarko: TDeveloper
begynde
zarko: = TMyObject. Skab;
Zarko. DoProgram;
ende;

Og her er en simpel hukommelseslækage!

Hver gang du opretter et objekt, skal du bortskaffe den hukommelse, den besatte. For at frigøre hukommelsen til et tildelt objekt skal du ringe til Gratis metode. For at være helt sikker skal du også bruge try / endelig-blokken:

Var
zarko: TDeveloper
begynde
zarko: = TMyObject. Skab;
prøve
Zarko. DoProgram;
endelig
Zarko. Gratis;
ende;
ende;

Dette er et eksempel på sikker hukommelsesallokering og deallokationskode.

Nogle advarselsord: Hvis du dynamisk vil instantisere en Delphi-komponent og eksplicit frigøre den engang senere, skal du altid give nil som ejer. Hvis du ikke gør det, kan det medføre unødvendig risiko samt ydelses- og kodevedligeholdelsesproblemer.

Ud over at oprette og ødelægge objekter ved hjælp af Opret og gratis-metoder, skal du også være meget forsigtig, når du bruger "eksterne" (filer, databaser osv.) Ressourcer.
Lad os sige, at du er nødt til at operere på nogle tekstfiler. I et meget simpelt scenarie, hvor AssignFile-metoden bruges til at knytte en fil på en disk til en fil variabel, når du er færdig med filen, skal du ringe til CloseFile for at frigøre filhåndtaget til at begynde Brugt. Det er her du ikke har et eksplicit opkald til "Gratis".

Var
F: TextFile;
S: streng;
begynde
AssignFile (F, 'c: \ somefile.txt');
prøve
Readln (F, S);
endelig
CloseFile (F);
ende;
ende;

Et andet eksempel inkluderer indlæsning af eksterne DLL'er fra din kode. Hver gang du bruger LoadLibrary, skal du ringe til FreeLibrary:

Var
dllHandle: THandle;
begynde
dllHandle: = Loadlibrary ('MyLibrary. DLL ');
// gør noget med denne DLL
hvis dllHandle <> 0, så er FreeLibrary (dllHandle);
ende;

Selvom med Delphi til .NET håndterer skraldesamleren (GC) de fleste hukommelsesopgaver, er det muligt at have hukommelseslækager i .NET-applikationer. Her er en artikeldiskussion GC i Delphi til .NET.

Udover at skrive modulær hukommelsessikker kode kan forhindring af hukommelseslækager gøres ved hjælp af nogle af de tilgængelige tredjepartsværktøjer. Delphi Hukommelseslækage-fixværktøjer hjælper dig med at fange Delphi-applikationen fejl såsom hukommelseskorruption, hukommelseslækager, hukommelsesallokeringsfejl, variabel initialiseringsfejl, variabel definitionskonflikter, markørfejl og mere.