Si necesito usar un trozo de memoria durante toda la vida útil de mi programa, ¿es realmente necesario liberarlo justo antes de que finalice el programa?

  

Si necesito usar un pedazo de memoria durante toda la vida útil de mi programa, ¿es realmente necesario liberarlo justo antes de que finalice el programa?

No es obligatorio, pero puede tener beneficios (así como algunos inconvenientes).

Si el programa asigna memoria una vez durante su tiempo de ejecución, y de lo contrario nunca la liberaría hasta que el proceso finalice, puede ser un método sensato no liberar la memoria manualmente y confiar en el sistema operativo. En todos los sistemas operativos modernos que conozco, esto es seguro, al final del proceso, toda la memoria asignada se devuelve de manera confiable al sistema.
En algunos casos, no limpiar la memoria asignada explícitamente puede ser notablemente más rápido que hacer la limpieza.

Sin embargo, al liberar explícitamente toda la memoria al final de la ejecución,

• durante la depuración / prueba, las herramientas de detección de fugas de mem no mostrarán "falsos positivos"
• podría ser mucho más fácil mover el código que usa la memoria junto con la asignación y la desasignación a un componente separado y luego usarlo en un contexto diferente donde el tiempo del uso de la memoria debe ser controlado por el usuario del componente

La vida útil de los programas puede cambiar. Tal vez su programa sea una pequeña utilidad de línea de comandos hoy, con una vida útil típica de menos de 10 minutos, y asigne memoria en porciones de algunos kb cada 10 segundos, por lo que no es necesario liberar ninguna memoria asignada antes de que finalice el programa. Más adelante, el programa cambia y obtiene un uso extendido como parte de un proceso de servidor con una vida útil de varias semanas, por lo que no liberar más la memoria no utilizada en el medio ya no es una opción, de lo contrario, su programa comienza a consumir toda la memoria del servidor disponible con el tiempo . Esto significa que tendrá que revisar todo el programa y agregar el código de desasignación posteriormente. Si tiene suerte, esta es una tarea fácil, si no, puede ser tan difícil que las posibilidades son altas que se pierde un lugar. Y cuando se encuentre en esa situación, deseará haber agregado el código "gratis" a su programa de antemano, en el momento en que agregó el código "malloc".

Más generalmente, la asignación de códigos de desasignación y asignaciones relacionadas siempre se contabiliza como un "buen hábito" entre muchos programadores: al hacer esto siempre, disminuye la probabilidad de olvidar el código de desasignación en situaciones donde la memoria debe ser liberado.

Liberar memoria al final de una ejecución de programas es solo una pérdida de tiempo de CPU. Es como ordenar una casa antes de matarla desde la órbita.

Sin embargo, a veces, lo que era un programa de ejecución corta puede convertirse en parte de una ejecución mucho más larga. Entonces la liberación de cosas se vuelve necesaria. Si esto no se pensó al menos en cierta medida, puede implicar una modificación sustancial.

Una solución inteligente para esto es "talloc", que te permite realizar una carga de asignaciones de memoria y luego deshacerte de ellas con una sola llamada.

Puede usar un idioma con recolección de basura (como Scheme, Ocaml, Haskell, Common Lisp , e incluso Java, Scala, Clojure).

^{(En la mayoría de los idiomas editados por GC, no hay ninguna manera para explícitamente y manualmente memoria libre. A veces, algunos valores podría estar finalizado , por ejemplo, el GC y el runtime system cerraría un valor de identificador de archivo cuando ese valor no esté disponible; pero esto no es seguro, no es confiable, y en su lugar debería cerrar explícitamente sus identificadores de archivo, ya que la finalización nunca es garantizado)}

También puede, para su programa codificado en C (o incluso C ++) utilizar el recolector de basura conservador de Boehm . Luego, reemplazarías todos tus malloc con GC_malloc y no te preocuparías por free -ing ningún puntero. Por supuesto, debe comprender las ventajas y desventajas de usar el GC de Boehm. Lea también el manual de GC .

^{La administración de memoria es una propiedad global de un programa. De alguna manera, (y la vida de algunos datos dados) es no compositivo y no modular, ya que es una propiedad completa del programa.}

Por fin, como señalan otros, explícitamente free -ing su zona de memoria C asignada al montón es una buena práctica. Para un programa de juguete que no asigna mucha memoria, incluso podría decidir no free memory (ya que cuando el proceso ha finalizado, sus recursos, incluido su espacio de direcciones virtuales , serían liberados por el sistema operativo) .

  

Si necesito usar un pedazo de memoria durante toda la vida útil de mi programa, ¿es realmente necesario liberarlo justo antes de que finalice el programa?

No, no necesitas hacer eso. Y muchos programas del mundo real no se molestan en liberar algo de memoria que se necesita en toda la vida útil (en particular, el compilador GCC no libera a algunos de su memoria). Sin embargo, cuando haces eso (por ejemplo, no molestas a free -ing una pieza particular de C asignada dinámicamente datos ), será mejor que comente ese hecho para facilitar el trabajo de los futuros programadores en el mismo proyecto. Tiendo a recomendar que la cantidad de memoria no liberada permanezca acotada y, por lo general, relativamente pequeña. a la memoria total del montón utilizado.

Observe que el sistema free a menudo no libera memoria para el sistema operativo (por ejemplo, llamando a munmap (2) en sistemas POSIX), pero generalmente se marca una zona de memoria como reutilizable por el futuro malloc . En particular, el espacio de direcciones virtuales (por ejemplo, como se ve a través de /proc/self/maps en Linux, consulte proc (5 ) ....) puede que no se reduzca después de free (por lo tanto, las utilidades como ps o top reportan la misma cantidad de memoria utilizada para su proceso).

No es necesario , ya que no fallará para ejecutar su programa correctamente si no lo hace. Sin embargo, hay razones que puede elegir, si se le da una oportunidad.

Uno de los casos más poderosos con los que me encuentro (una y otra vez) es que alguien escribe un pequeño fragmento de código de simulación que se ejecuta en su ejecutable. Dicen que "nos gustaría que este código se integrara en la simulación". Luego les pregunto cómo planean reiniciarse entre las carreras de monte-carlo, y me miran fijamente. "¿Qué quiere decir con reiniciar? ¿Acaba de ejecutar el programa con nuevas configuraciones?"

A veces, una limpieza limpia hace que sea mucho más fácil para su software. En el caso de muchos ejemplos, usted presume que nunca necesita limpiar algo, y hace suposiciones acerca de cómo puede manejar los datos y su vida útil en torno a esas presunciones. Cuando te mudas a un nuevo entorno donde esas presunciones no son válidas, es posible que los algoritmos completos ya no funcionen.