sirven - que es una direccion de memoria en c++
¿Hasta dónde pueden llegar las pérdidas de memoria? (9)
Como han dicho los demás, la mayoría de los sistemas operativos recuperarán la memoria asignada al finalizar el proceso (y probablemente otros recursos como conectores de red, manejadores de archivos, etc.).
Una vez dicho esto, es posible que la memoria no sea lo único de lo que deba preocuparse cuando trate con new / delete (en lugar de raw malloc / free). La memoria asignada en nuevo puede recuperarse, pero las cosas que se pueden hacer en los destructores de los objetos no ocurrirán. Quizás el destructor de alguna clase escriba un valor centinela en un archivo después de la destrucción. Si el proceso simplemente termina, el identificador del archivo puede eliminarse y recuperar la memoria, pero ese valor centinela no se escribirá.
Moraleja de la historia, siempre limpia después de ti. No dejes que las cosas cuelguen. No confíe en la limpieza del sistema operativo después de usted. Limpia después de ti mismo.
Me he encontrado con pérdidas de memoria muchas veces. Por lo general, cuando estoy malloc -ing como si no hubiera un mañana, o colgaba FILE * como ropa sucia. Generalmente asumo (léase: espero desesperadamente) que toda la memoria se limpia al menos cuando el programa termina. ¿Hay alguna situación en la que no se recopile la memoria filtrada cuando el programa finaliza o se bloquea?
Si la respuesta varía mucho de un idioma a otro, entonces centrémonos en C (++).
Tenga en cuenta el uso hiperbólico de la frase, "como si no hubiera mañana", y "colgando ... como ropa sucia". El mal uso inseguro puede dañar a los que ama. Además, tenga cuidado con la ropa sucia.
Como todas las respuestas han cubierto la mayoría de los aspectos de su pregunta en sistemas operativos modernos, pero históricamente, hay uno que vale la pena mencionar si alguna vez ha programado en el mundo de DOS. Los programas Residente y Permanencia Residente (TSR) por lo general devolverían el control al sistema, pero residirían en la memoria, que podría ser revivida por una interrupción de software / hardware. Era normal ver mensajes como "sin memoria, intente descargar algunos de sus TSR" cuando trabaje en estos sistemas operativos.
Entonces, técnicamente, el programa finaliza , pero debido a que aún reside en la memoria, cualquier fuga de memoria no se liberaría a menos que descargue el programa.
Por lo tanto, puede considerar que se trata de otro caso aparte de los sistemas operativos que no reclaman memoria, ya sea porque tiene errores o porque el sistema operativo incorporado está diseñado para hacerlo.
Recuerdo un ejemplo más. El Sistema de control de información del cliente (CICS), un servidor de transacciones que se ejecuta principalmente en mainframes de IBM, es pseudo-conversacional. Cuando se ejecuta, procesa los datos ingresados por el usuario, genera otro conjunto de datos para el usuario, se transfiere al nodo terminal del usuario y finaliza. Al activar la tecla de atención, vuelve a activarse para procesar otro conjunto de datos. Debido a la forma en que se comporta, técnicamente de nuevo, el sistema operativo no reclamará memoria de los programas CICS finalizados, a menos que recicle el servidor de transacciones CICS.
El estándar C no especifica que la memoria asignada por malloc se libera cuando finaliza el programa. Esto hecho por el sistema operativo y no todos los sistemas operativos (generalmente estos están en el mundo integrado) liberan la memoria cuando termina el programa.
Es más probable que esto dependa del sistema operativo que del lenguaje. En definitiva, cualquier programa en cualquier idioma obtendrá su memoria del sistema operativo.
Nunca he oído hablar de un sistema operativo que no recicla la memoria cuando un programa se cierra / falla. Entonces, si su programa tiene un límite superior en la memoria que necesita asignar, entonces solo asignar y nunca liberar es perfectamente razonable.
La memoria compartida en sistemas compatibles con POSIX persiste hasta que se llame a shm_unlink o se reinicie el sistema.
No. Los sistemas operativos liberan todos los recursos que tienen los procesos cuando salen.
Esto se aplica a todos los recursos que mantiene el sistema operativo: memoria, archivos abiertos, conexiones de red, controladores de ventanas ...
Dicho esto, si el programa se ejecuta en un sistema integrado sin un sistema operativo o con un sistema operativo muy simple o defectuoso, la memoria podría quedar inutilizable hasta que se reinicie. Pero si estuvieras en esa situación, probablemente no harías esta pregunta.
El sistema operativo puede tomar mucho tiempo para liberar ciertos recursos. Por ejemplo, el puerto TCP que usa un servidor de red para aceptar conexiones puede tardar minutos en liberarse, incluso si el programa lo cierra correctamente. Un programa en red también puede contener recursos remotos como objetos de bases de datos. El sistema remoto debe liberar esos recursos cuando se pierde la conexión de red, pero puede llevar incluso más tiempo que el sistema operativo local.
Si el programa alguna vez se convierte en un componente dinámico ("complemento") que se carga en el espacio de direcciones de otro programa, será problemático, incluso en un sistema operativo con administración ordenada de la memoria. Ni siquiera tenemos que pensar en el código que se transporta a sistemas menos capaces.
Por otro lado, liberar toda la memoria puede afectar el rendimiento de la limpieza de un programa.
En un programa en el que estaba trabajando, un determinado caso de prueba requirió 30 segundos o más para que el programa saliera, ya que estaba recurriendo a través del gráfico de toda la memoria dinámica y liberándola pieza por pieza.
Una solución razonable es tener la capacidad allí y cubrirla con casos de prueba, pero desactívela en el código de producción para que la aplicación se cierre rápidamente.
Si tiene comunicación entre procesos, esto puede llevar a que otros procesos nunca completen y consuman recursos dependiendo del protocolo.
Para dar un ejemplo, una vez experimenté con la impresión en una impresora PDF en Java cuando terminé la JVM en medio de un trabajo de impresión, el proceso de cola de PDF permaneció activo, y tuve que matarlo en el administrador de tareas antes de poder reintentar imprimir.
Todos los sistemas operativos que merecen el título limpiarán el desorden que su proceso generó después de la terminación. Pero siempre hay eventos imprevistos, ¿y si de alguna manera se le negó el acceso y algún programador pobre no previó la posibilidad y entonces no vuelve a intentarlo un poco más tarde? Siempre es más seguro que simplemente se limpie si las pérdidas de memoria son críticas para la misión; de lo contrario, realmente no vale la pena el esfuerzo de la OMI si ese esfuerzo es costoso.
Editar: Necesita limpiar las pérdidas de memoria si están en el lugar donde se acumularán, como en los bucles. Las pérdidas de memoria de las que hablo son las que se acumulan en un tiempo constante a lo largo del curso del programa, si tiene una fuga de cualquier otro tipo, es muy probable que tarde o temprano sea un problema grave.
En términos técnicos, si sus fugas son de memoria ''complejidad'' O (1) están bien en la mayoría de los casos, O (logn) ya es desagradable (y en algunos casos fatal) y O (N) + intolerable.