Asignación de "nulo" a los objetos en cada aplicación después de su uso

Question

• ¿Siempre se asigna null a un objeto después de su ámbito de aplicación se ha alcanzado?

• ¿O confía en la JVM para la recolección de basura?

• ¿Lo hace para todo tipo de aplicaciones, independientemente de su longitud?

• Si es así, ¿siempre es una buena práctica?

Answer 1

• no, no hacemos eso, a excepción de casos específicos, tales como campos estáticos o cuando se sabe a/campo variable vive muchomás largo que el código de referencia que
• sí , pero con un conocimiento práctico de los límites de su máquina virtual (y cómo hacer bloques de memoria que se celebrarán accidentalmente)
• n/a

Answer 2

no es n necesario para marcar explícitamente objetos como nulos a menos que tenga una razón muy específica. Además, nunca he visto una aplicación que marque todos los objetos como nulos cuando ya no los necesiten. El principal beneficio de la recolección de basura es la administración de la memoria intrínseca.

Answer 3

Al utilizar .Net no creo que sea necesario establecer el objeto como nulo. Solo deja que la recolección de basura suceda.

Answer 4

Asignar nulo a una variable no significa implícitamente que será basura recolectada de inmediato. De hecho, lo más probable es que no lo sea. Ya sea que practique el establecimiento de variables como nulas generalmente solo es cosmético (con la excepción de variables estáticas)

Answer 5

La recolección de basura no es tan mágica como cabría esperar. Siempre que un objeto se haga referencia desde cualquier objeto alcanzable, simplemente no se puede recopilar. Por lo tanto, podría ser absolutamente necesario anular una referencia para evitar pérdidas de memoria. No digo que debas hacer esto siempre, pero siempre cuando sea necesario.

Answer 6

Como los otros han mencionado, generalmente no es necesario.

No solo eso, sino que aglomera su código y aumenta los datos que alguien necesita para leer y comprender al volver a visitar su código.

Answer 7

No practicamos esta asignación de "nulo". Si el alcance de una variable ha llegado a su fin, ya debería estar listo para GC. Puede haber algunos casos extremos en los que el alcance dura un poco más debido a una operación de larga ejecución en cuyo caso podría tener sentido establecerlo como nulo, pero me imagino que serían raros.

También es evidente que si la variable es una variable miembro o una variable estática del objeto y, por lo tanto, nunca sale realmente del alcance, es obligatorio establecerlo como nulo en GC.

Answer 8

La asignación no se hace a los objetos, se hace a las variables, y significa que esta variable contiene una referencia a algún objeto. Asignar NULL a una variable no es una forma de destruir un objeto, simplemente borra una referencia. Si la variable que está borrando abandonará su alcance de todos modos, asignar NULL es solo un ruido inútil, porque eso sucede al dejar el alcance en cualquier caso.

Answer 9

Declaro casi todas mis variables como "finales". También hago pequeños mis métodos y declaro la mayoría de las variables locales a los métodos.

Como son definitivas, no puedo asignarlas nulas después de su uso ... pero está bien, ya que los métodos son pequeños, los objetos son elegibles para la recolección de basura una vez que regresan. Como la mayoría de las variables son locales, hay menos posibilidades de retener accidentalmente una referencia por más tiempo de lo necesario (fuga de memoria).

Answer 10

La única vez que tiendo a usar esta práctica es si necesito transformar una gran Collection en alguna parte temprana de un método.

Por ejemplo:

public void foo() { 
    List<? extends Trade> trades = loadTrades(); 
    Map<Date, List<? extends Trade>> tradesByDate = groupTradesByDate(trades); 
    trades = null; // trades no longer required. 

    // Apply business logic to tradesByDate map. 
} 

Obviamente, podría reducir la necesidad de esto mediante la refactorización en este otro método: Map<Date, List<? extends Trade>>> loadTradesAndGroupByDate() por lo que realmente depende de las circunstancias/claridad de código.

Answer 11

- ¿Siempre se asigna null a un objeto después de que se haya alcanzado su alcance?

Sin

- ¿O usted confía en la JVM para la recolección de basura?

Sí

- ¿Lo haces para todo tipo de aplicaciones, independientemente de su longitud?

Sí

- Si es así, ¿es siempre una buena práctica?

N/A

Answer 12

sólo asignar una referencia a null cuando:

1. El código realmente se encuentra en una zona de memoria-crítico.
2. La referencia tiene un amplio alcance (y debe ser reutilizado más adelante). Si no es el caso, simplemente lo declaro en el bloque de código más pequeño posible. Estará disponible para la recolección de forma automática.

Eso significa que solo uso esta técnica en el proceso iterativo donde utilizo la referencia para almacenar la enorme colección de objetos entrantes. Después del procesamiento, ya no necesito la colección, pero quiero reutilizar la referencia para la próxima colección.

En ese caso (y solo en ese caso), entonces llamo al System.gc() para dar una pista al recolector de basura. Supervisé esta técnica a través de Heap Visualizer y funciona muy bien para grandes colecciones (más de 500 Mb de datos).

Answer 13

Supongo que está haciendo esta pregunta porque ha visto código con variables que se asignan a nulo en el punto donde nunca más se volverá a acceder.

No me gusta este estilo, pero otro programador lo usó ampliamente, y dijo que le enseñaron a hacerlo en un curso de programación en su universidad. El razonamiento que dio fue que evitaría errores indetectables si intentara reutilizar la variable más adelante, en lugar de un comportamiento indeterminado, obtendría una excepción de puntero nulo.

Así que si eres propenso a usar variables en las que no deberías usar variables, podría hacer que tu código sea más fácil de depurar.

Answer 14

Hubo una clase de errores de fuga de memoria que ocurrieron independientemente de si establecí la referencia en nulo: si la biblioteca que estaba utilizando estaba escrita en un lenguaje como C sin gestión de memoria, entonces simplemente establecer el objeto en nulo no necesariamente libera la memoria. Tuvimos que llamar al método close() del objeto para liberar la memoria (que, por supuesto, no pudimos hacer después de establecerlo como nulo.)

Me parece que el método de facto de administración de memoria en Java va a depender del recolector de basura a menos que el objeto/biblioteca que está utilizando tenga un método close() (o algo similar).