En række måder er tilgængelige til at afgøre, om et edb-program er utæt hukommelse . En programmør kan finkæmme gennem kildekoden for at sikre , at al hukommelse tildelt er deallokeret , kan han skrive et program , der tester hans software til memory leaks , kan han udtænke en hukommelse ledelse ordning, der tillader ham at holde styr på anvendt hukommelse eller han kan bruge et tredjepartsprogram program , der tester for memory leaks . Hvad er en Memory Leak ?
Hukommelsesfejl er en uønsket hukommelsesforbrug af et computerprogram , hvor programmet allokerer hukommelse til brug og ikke deallocate det, når hukommelsen er ikke længere i brug . Denne luns af hukommelsen vil ikke længere være til rådighed for edb-programmet. Et program, der utætheder nok hukommelse i tid nok kan få systemet til at køre ud af den tilgængelige hukommelse, som kan forårsage programmet eller edb-system til at mislykkes. Memory leaks kan også forårsage et system til at bremse ned til en utilfredsstillende hastighed , på grund af hukommelsen prygle . Programmer, der kører i lange perioder , udføre mange tildelinger eller tildele hukommelse i store bidder kan være særligt tilbøjelige til farlige memory leaks .
Udvis god kodning praksis
bedste måde at sikre , at dit program ikke lækker hukommelse er at skrive god kode , der korrekt styrer systemets ressourcer. Sørg for, at for hver funktion opkald , der tildeler hukommelse, er der en tilsvarende opkald, deallocates hukommelsen. Nogle sprog som Java , C # og VB.NET , give garbage collection , hvor systemet kontrollerer regelmæssigt , at allokerede hukommelse er stadig i brug . Selv om disse systemer ikke forhindrer memory leaks fuldstændigt , er det mindre sandsynligt, at de vil indtræffe . Andre sprog, såsom C + +, så stak allokering , hvor en luns af hukommelse deallokeret automatisk, når den variabel, dokumentation den går ud af rækkevidde. Ved at bruge det korrekte sprog for opgaven og bevare gode software skrivning praksis , kan mange memory leaks undgås helt.
Opret en Memory manager
Nogle computer programmer kræver så meget kode til at køre , at læsning gennem programmet for at finde, hvor hukommelsen er sivet er simpelthen ikke muligt . I disse tilfælde kan det give mening at skrive en hukommelse leder komponent til programmet. Softwaren vil så have en ensartet grænseflade for allokering eventuelle bidder af hukommelsen, og holder styr på , hvor og hvordan disse klumper er fordelt . I sin enkleste form blot lederen giver feedback , så programmøren at se, hvor meget hukommelse der er brugt, og hvilke komponenter bruger det. Det kan også give garbage collection og kontrol , hvordan hukommelsen er allokeret, og deallokeret , hvilket giver en programmør kun ét sted at lede efter memory leaks , i stedet for al koden for hele programmet.
Opret et testprogram
Man kan ofte se på hukommelse, der bruges af et program med et system værktøj, såsom Windows Task manager eller "top" på Unix /Linux til at afgøre, om hukommelsen bliver lækket. Dette er ikke altid tegn på en hukommelsesfejl , men kan give nogle indledende feedback . Undertiden er det muligt at skrive et simpelt program , der tester de forskellige elementer i et stykke software til at bestemme , om hukommelsen er utæt . Testen Programmet kan dynamisk bestemme eller gives forudgående kendskab til , hvor meget hukommelse et edb-program skal bruge. Det sikrer derefter , at den anvendte mængde er den mængde , der skal anvendes . Hvis opstår en hukommelsesfejl , testprogrammet giver feedback på, hvordan det skete , så programmøren at fastsætte lækagen.
Tredjeparts software
Programmører kan bruge mange tredjedel - parts programmer og biblioteker for at teste, om deres software er utæt hukommelse. I Microsoft. NET Framework , kan man aktivere memory tæthedsprøvning ved hjælp af debug versioner af hukommelse tildeling funktioner. På Linux , Unix og Mac , kan du bruge værktøjer, såsom Valgrind , dmalloc og Forsikring + + til at isolere en hukommelsesfejl . Mange hukommelse debuggers er også tilgængelige for Windows. Det bedste værktøj til jobbet , afhænger af udviklingsmiljøet og sproget bliver brugt , samt særlige karakteristika i programmet til debug , såsom størrelse , hastighed krav og de måde, det interagerer med systemet. Der er mange værktøjer at vælge imellem , og de kan være en velsignelse for frustreret programmør træt af at søge efter den sidste undvigende lækage.
