Siento que los desarrolladores hablan de fugas de memoria, pero cuando les preguntas qué significa eso, muchos no tienen ni idea. Para evitar estas situaciones, decidamos una.La mejor definición de fuga de memoria
Por favor, no hay definiciones de Wikipedia ...
¿Cuál es su mejor definición de una memoria fugas y cuál es la mejor manera para prevenirlos?
Hay dos definiciones (al menos para mí):
definición Naive: no soltar inalcanzable memoria, que ya no puede ser asignado de nuevo por cualquier proceso durante la ejecución del proceso de distribución del trabajo. Esto se puede curar principalmente mediante el uso de técnicas GC (recolección de basura) o detectar mediante herramientas automatizadas.
definición sutil: no soltar alcanzable de memoria que ya no se necesita para su correcto funcionamiento del programa. Esto es casi imposible de detectar con herramientas automáticas o por programadores que no están familiarizados con el código. Si bien técnicamente no es una filtración, tiene las mismas implicaciones que la ingenua. Esta no es solo mi propia idea. Puede encontrar proyectos que están escritos en un lenguaje recogido de basura, pero aún mencionar la posibilidad de corregir fugas de memoria en sus registros de cambios.
Es posible encontrar fugas de memoria en la categoría "Sutil" con bastante facilidad en http://www.eclipse.org/mat. – kohlerm
Definición: Si no se libera la memoria después de la asignación
Mozilla tiene una gran page en las herramientas para la localización de fugas de memoria.
Eso es solo una pérdida si es memoria, no necesita más. –
Es cierto, definitivamente una visión excesiva por mí mismo. Noté que también estás en Rochester, NY ... mundo pequeño. –
El enlace no funciona. ¿Puedes actualizar el enlace? –
Proceso en el que los recursos de memoria se asignan y no se lanzan correctamente una vez que ya no son necesarios, a menudo introducidos a través de malas prácticas de codificación.
Existen algunos modos en algunos idiomas para ayudar a prevenirlos, aunque la mejor manera de evitarlos es a través de la observación diligente de rutas de ejecución de código y revisiones de código. Mantener los métodos cortos y singularmente propuestos ayuda a mantener el uso de los recursos estrechamente delimitado y menos propenso a perderse en la confusión.
Memoria que no se desasigna cuando ya no es necesaria, y ya no es "alcanzable". Por ejemplo, en código no administrado, si uso "nuevo" para crear una instancia de un objeto, pero no uso "eliminar" cuando termine con él (y mi puntero se ha salido del alcance o algo así).
La mejor manera de prevenirlos probablemente dependa de a quién pregunte y el idioma que está utilizando. La recolección de basura es una buena solución, por supuesto, pero puede haber algunos gastos generales asociados a esto, que no es un gran problema a menos que el rendimiento sea su principal preocupación. La recolección de basura no siempre está disponible, de nuevo, dependiendo del idioma que esté usando.
Como alternativa, puede asegurarse de que tiene las eliminaciones y/o destructores apropiados en su lugar. También hay muchos métodos y herramientas para detectar fugas de memoria, pero esto dependerá del idioma y/o IDE que esté utilizando.
Existen dos formas de definir una pérdida de memoria.
En primer lugar, si los datos no se liberan cuando ya no hay referencias, no se puede acceder a esos datos (a menos que tenga algún puntero dañado o lea los datos en un búfer o algo así). Básicamente, si no libera/elimina los datos asignados en el montón, se vuelve inutilizable y simplemente desperdicia memoria.
Puede haber casos en los que se pierde un puntero pero los datos aún están accesibles. Por ejemplo, si almacena el puntero en un int, o almacena un desplazamiento en el puntero (usando la aritmética del puntero), aún puede recuperar el puntero original.
En esta primera definición, los datos son manejados por recolectores de basura, que realizan un seguimiento del número de referencias a los datos.
En segundo lugar, la memoria se pierde esencialmente si no se libera/elimina la última vez que se usó. Se puede referenciar, e inmediatamente libre, pero se ha cometido el error de no hacerlo. Puede haber una razón válida (por ejemplo, en el caso en que un destructor tiene algún extraño efecto secundario), pero eso indica un mal diseño del programa (en mi opinión).
Este segundo tipo de pérdida de memoria a menudo ocurre cuando se escriben pequeños programas que usan archivos IO. Abre el archivo, escribe sus datos, pero no lo cierra una vez que haya terminado. El ARCHIVO * aún puede estar dentro del alcance y fácilmente cerrable. Nuevamente, puede haber alguna razón para hacer esto (como bloquear el acceso de escritura por otros programas), pero para mí eso es una bandera de mal diseño.
En esta segunda definición, los recolectores de basura no manejan los datos, a menos que el compilador/intérprete sea inteligente (o tonto) lo suficiente como para saber que ya no se usará más, y esto liberará los datos. efectos secundarios.
Sí, he golpeado varios programas que no cierran un identificador de archivo cuando deberían. Incluso tuve un intercambio de varios mensajes con alguien que pensó que escribir/renombrar/cerrar era una programación aceptable ya que se sale con la suya en un sistema de archivos de Windows. –
Memoria asignada que no se puede utilizar porque se ha perdido la referencia a la misma.
Me gusta, pero no creo que sea bastante exacto.Incluso en los sistemas de GC, a veces las cosas se llaman "fugas" porque aunque la memoria aún es alcanzable, "no debería ser", porque ya no es necesaria. –
Creo que este es el mejor: las referencias a la memoria se pueden perder incluso en idiomas con la recolección de basura. – Foredecker
No tiene que perder la referencia a la memoria para tener una fuga. Si ya no necesita la memoria, pero no puede desasignarla, incluso si mantiene una referencia, es una pérdida de memoria en mi libro. –
editar: Esta respuesta es incorrecta. Lo dejo como un ejemplo de lo fácil que es confundirse con algo que crees que sabes muy bien. Gracias a todos los que señalaron mi error.
Una pérdida de memoria es: Un error de programación. Su software toma prestada parte de la memoria del sistema, la usa y luego no la devuelve al sistema cuando finaliza. Esto significa que ese pedazo particular de memoria nunca puede ser utilizado por ningún otro programa hasta que el sistema se reinicie. Muchas de estas fugas podrían agotar toda la memoria disponible, lo que daría como resultado un sistema completamente inútil.
Para evitar fugas de memoria, practique RIIA y siempre pruebe su software. Hay muchas herramientas disponibles para esta tarea.
No tengo conocimiento de ningún SO moderno que no devuelva toda la memoria de una aplicación a la lista libre del sistema inmediatamente después de la finalización. –
Estoy con Just Some Guy. Toda la memoria de un programa se devuelve al sistema cuando se cancela el proceso. Los restos de los datos están allí, tal vez incluidos los datos de caché de los archivos abiertos, pero eso es manejado por el sistema operativo de todos modos, no el programa en sí. – strager
Ustedes obviamente nunca han trabajado en dispositivos integrados. –
pérdida de memoria: La falta de memoria libre que ya no se necesita antes de que cualquiera:
mejor manera de prevenir pérdidas de memoria: memoria libre tan pronto como ya no se necesita.
Liberar memoria antes de la terminación no es un problema. Se pierde memoria mientras el programa todavía se está ejecutando y causa problemas. –
Usted, como programador de un programa, no puede liberar memoria asignada por su programa después de que dicho programa finaliza. Simplemente está más allá de tu control. Entonces el primer punto es redundante. No importa si usted asigna más memoria después de haber iniciado una fuga, tampoco. – strager
En el primer punto, si no les liberas la memoria antes de que finalice la aplicación, estás parado para crear una fuga de memoria en la gran mayoría de las computadoras que existen (pista: el mundo no es una PC). –
Todas las definiciones dadas aquí (en el momento de escribir este, que han conseguido mejores respuestas ya) no abordan un caso límite:
Usted tiene un producto único que se asigna memoria sobre la creación y esta memoria se lleva a cabo normalmente siempre que el programa se esté ejecutando aunque el uso actual esté hecho y no se sabe si se realizará o no un uso futuro. Esto generalmente se hace debido a la sobrecarga de recrearlo.
Con el estándar "no se puede liberar cuando se termine con esto", esto se consideraría una fuga y he visto que las herramientas de informe de fugas llaman tales cosas porque la memoria todavía estaba en uso. (Y, de hecho, el código puede no contener código capaz de limpiar el objeto).
Sin embargo, he encontrado código de esta naturaleza en las bibliotecas de compilación incluso cuando el costo de la recreación del objeto no es tan bueno.
¿Fugas o no?
Los Singleton son una pérdida de memoria por definición; esta es solo una de las razones por las que nunca debe usarlos. –
Falta el aspecto _unintencional_ de la pérdida de memoria. Y un singleton, podría tener un método de lanzamiento que libera la memoria asignada. – philant
Definiría algo como "pérdida de memoria" si provoca un programa que debería poder procesar una secuencia infinita de entradas usando una cantidad limitada de memoria, para requerir una cantidad ilimitada de memoria. Un singleton que requiere una cantidad limitada de almacenamiento no causará una pérdida de memoria. – supercat
En informática, una pérdida de memoria es un tipo particular de consumo de memoria involuntaria mediante un programa informático en el que el programa no puede liberar memoria cuando ya no sean necesarios. Esta condición es normalmente el resultado de un error en un programa que le impide liberar memoria que ya no necesita.
Espera un minuto, Wikipedia cita Stackoverflow en su definición ... ¡Me atrevo a decir que hace que la definición sea una referencia circular! – Jon
Estas son algunas de las técnicas de prevención/detección de fugas de memoria:
Tenga en cuenta su algoritmo en términos de consumo de memoria. Otros encuestados han mencionado el hecho de que no tiene que perder el puntero a un elemento asignado para perder memoria. Incluso si su implementación contiene errores de puntero cero, de todos modos puede perder memoria de manera efectiva si mantiene los elementos asignados mucho después de que realmente los necesite.
Perfile su aplicación. Puede usar herramientas de depuración de memoria como Valgrind o Purify para buscar fugas.
Prueba de caja negra. Mire lo que sucede con el código compilado después de alimentarlo con grandes conjuntos de datos, o permita que se ejecute durante largos períodos de tiempo. Vea si su huella de memoria tiene una tendencia a crecer sin límite.
I belive La respuesta de Brian Gianforcaro es la mejor y más sucinta. – Foredecker
¿Por qué no aceptas la definición de Wikipedia? –
@Joshua Swink: Porque eso sería un policía sin respuesta. :) – Spoike