GC optimization: declarando el objeto como campo opuesto a declararlo localmente

Estoy intentando actualmente evitar las llamadas de GC_CONCURRENT, así que estoy funcionando con mi lazo principal. He notado que a menudo crear un objeto complejo para hacer cálculos.

Así que mi pregunta es declarar que el objeto como un campo de la clase opuesta a declararlo en los métodos que lo utilizan ayuda a la actuación?

O porque mi inglés probablemente te ha herido cerebro, aquí está el ejemplo de código como campo

class myclass{ private MyObject myObject; ... public void myLoopedMethod(...){ myObject = new MyObject(...); myObject.dostuff; } 

Ejemplo en el método

 class myclass{ ... public void myLoopedMethod(...){ MyObject myObject = new MyObject(...); myObject.dostuff; } 

El alcance correcto sería el método, pero mi duda es que al convertirlo en un campo, la memoria siempre se libera y se asigna en el mismo lugar. ¿Es esto cierto y ayuda a evitar las llamadas GC?

También, probablemente debería hacer algo como esto, pero estoy interesado si la lógica anterior tiene sentido.

 class myclass{ private MyObject myObject; ... public void myMethod(...){ myObject.setNewValues(...); myObject.dostuff; } } 

Pero mi duda es que al convertirlo en un campo, la memoria siempre se libera y se asigna en el mismo lugar. ¿Es esto cierto y ayuda a evitar las llamadas GC?

No hay garantía de que la memoria asignada en el mismo lugar. Es detalle de implementación.

En su caso de ejemplo, si la variable de instancia, todos los objetos referenciados por esta variable de instancia serán elegibles para GC, excepto el último objeto que todavía tiene una referencia de la variable de instancia (el último será elegible para GC cuando no tenga referencias accesibles).

En el caso de definir el método interno, todos los objetos referenciados por esta referencia serán elegibles para el GC tan pronto como se realice el bucle.

Por lo tanto, es mejor ir con la definición de método interior a menos que necesite referencia al objeto identificado en el bucle.

Llegando a la pregunta evitando GC llamadas, creo que ambos enfoques tendrán casi la misma cantidad de GC actividad. A menos que tenga problema real con la memoria que sugiero que no se preocupe por la asignación de memoria y GC, VMs son lo suficientemente inteligentes como para cuidar de esas cosas.

  1. Sí, si la creación del objeto está dentro del método a menudo llamado, resultará en más trabajo para el recolector de basura.

  2. Siempre mida en lugar de especular … Las ventajas teóricas podrían ser insignificantes.

  • Appium logcat capture failed: spawn ENOENT (sin espacios en la ruta)
  • OverridePendingTransition para actividades deslizantes dentro y fuera suavemente
  • Java.lang.ClassNotFoundException en loader dalvik.system.PathClassLoader en el lanzamiento de la aplicación
  • Android - Problema con imágenes de carga perezosa en un ListView
  • Android: redireccionar llamadas salientes
  • Faltan credenciales de autenticación de Twitter4j
  • InflateException: Línea de archivo XML binario # 22: Error al inflar la clase <unknown>
  • Intenta invocar el método virtual 'boolean com.google.android.finsky.api.model.DfeToc.isGplusSignupEnabled ()' en una referencia de objeto nulo
  • Encriptación y descifrado entre Android, PHP y node.js
  • NoClassDefFoundError al ejecutar PopupMenu usando la biblioteca android-support-v7-appcompat en android
  • Formas de proxy un InputStream
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.