Il ne sert à rien de libérer des blocs à la fin du programme?

Dupliquer possible:
La libération de la mémoire allouée est-elle nécessaire lors de la sortie d’un programme en C

Je lisais la page “Libérer la mémoire allouée avec malloc ” et parcourais cette phrase:

Il est inutile de libérer des blocs à la fin d’un programme, car tout l’espace du programme est rendu au système à la fin du processus.

Je comprends ce que l’auteur essaie de dire, mais la phrase ne devrait-elle pas être:

Il est inutile de libérer des blocs à la fin d’un programme, car tout l’espace du programme est rendu au système à la fin du processus. Vous devez toutefois vous assurer que le programme libère toute la mémoire en malloc avant de quitter .

Ou est-ce une pratique courante de ne pas dé-allouer de la mémoire avant la fin du processus?

J’ai pris beaucoup de chaleur pour cela, mais ma position est que déployer des efforts pour libérer de la mémoire juste avant la sortie du programme devrait être considéré comme néfaste . D’une part, c’est du code supplémentaire à maintenir et à déboguer – mais probablement pas trop, ce n’est donc qu’un petit problème. Le problème beaucoup plus vaste concerne les effets pratiques.

Supposons que vous ayez un programme de longue durée qui alloue des structures de données complexes / profondes. Pensez, par exemple, à un navigateur Web. Il est probable qu’une grande partie de ces données n’ont pas été utilisées depuis un moment et qu’elles ont ensuite été échangées sur un disque. Si vous venez de exit , les données échangées sur le disque sont simplement marquées comme inutilisées et ne sont plus touchées. Mais si vous parcourez toutes les structures de données de votre programme pour les libérer, vous toucherez toutes les pages permutées , ce qui provoquera:

  • access disque pour lire les données échangées
  • expulsion de données réellement importantes d’autres programmes
  • et un access disque correspondant pour échanger lesdites données appartenant à d’autres programmes.

Tout cela gaspille:

  • le temps de l’utilisateur
  • porter sur le disque dur (ou pire, sur SSD / flash)

Ce comportement est facilement observable si vous surchargez votre système avec suffisamment d’applications de bureau gonflées (Firefox, OpenOffice, GIMP, etc. ou l’équivalent Windows) pour le permuter, puis essayez de fermer l’une d’entre elles. Vous passerez plusieurs secondes (peut-être même environ 30 secondes si la permutation est assez grave) pour l’attendre. Si le programme venait d’appeler directement la exit (après vérification des documents non enregistrés et autres), il se serait immédiatement fermé.

(Ceci est une réponse hautement subjective, alors prenez-le comme vous voudrez.)

Je pense que c’est une bonne pratique dans le cas où vous finirez par append au processus, auquel cas vous voudrez peut-être libérer la mémoire après tout.

Je pense qu’il est toujours bon de conserver une mémoire dynamic aussi longtemps que vous en avez besoin, puis de la libérer. D’habitude, j’aime écrire free dans mon code immédiatement après avoir écrit malloc , puis mettre le code dont j’ai besoin entre les deux.

Ma préférence personnelle est de ne pas libérer de mémoire à la fin du programme – le code ne sert à rien, mais peut quand même avoir / causer des bugs s’il est mal fait.

En même temps, le fait de laisser la mémoire allouée déclenchera des rapports à partir de presque tous les détecteurs de fuite automatiques. Par conséquent, si vous en utilisez un (ou si vous en avez la possibilité), il est généralement préférable de libérer de la mémoire pour éviter que de véritables fuites ne soient perdues / ignorées. Compte tenu de leur prévalence actuelle, il serait difficile (voire possible) de ne jamais utiliser une telle chose.

Il est très courant de quitter un programme sans libérer sa mémoire.

Il est certainement intéressant de discuter de la question de savoir si c’est une bonne pratique – très souvent, un main () dans un programme évolue en un appel de fonction dans un autre programme plus important et, le cas échéant, vous souhaitiez que votre mémoire (de) allocation soit nette. Là encore, dans le cas de petits programmes, il peut s’agir d’un travail fastidieux et inutile.

La meilleure raison de libérer de la mémoire à la fin d’un programme est de rechercher des fuites. Certains profileurs, comme purify, prétendent que tout est divulgué si vous ne libérez pas avant la fin du programme. Maintenant, vous savez que le fait que la mémoire soit libérée dans le système d’exploitation importe peu, mais il est beaucoup plus difficile de dire s’il y a quelque chose que vous avez réellement l’intention de libérer mais que vous n’avez pas accidentellement. Ceci est important pour les processus de longue durée, comme un processus de serveur, un démon, etc. dans lesquels des memory leaks peuvent causer des problèmes majeurs. Pour les programmes simples qui font un travail et puis sortent immédiatement, je ne pense vraiment pas que ce soit important si vous libérez explicitement.

Il y a des choses que j’essaie très fort de ne pas libérer explicitement. Les pools d’objects de communication inter-thread, par exemple. Je souhaite que le système d’exploitation les libère, car tous mes threads (ceux susceptibles d’écrire sur les objects) seront toujours arrêtés, avant de libérer la mémoire de processus.

Si je ne le fais pas, j’éprouve tous ces problèmes en essayant de mettre fin aux threads bloqués par le blocage d’appels ou l’exécution de boucles. Je ne peux pas être dérangé par tout ce tracas 🙂

Rgds, Martin