GREF aumentando/disminuyendo en el servicio de subprocesos múltiples (helpl) - ¿qué significa?

Question

Tengo una actividad android y un servicio implementado usando aidl. Funciona como un campeón, tengo una configuración de devolución de llamada para pasar algunas notificaciones de subprocesos a la interfaz de usuario, y parece funcionar bien, con la excepción de un montón de

GREF ha aumentado a 101, 201, 301, 401, 501, etc., y GREF ha disminuido. Hice un poco de búsqueda en línea y descubrí que tiene que ver con Referencias Globales.

08-17 02:31:19.735: DEBUG/dalvikvm(2558): GREF has increased to 301 
... 
08-17 02:31:25.823: DEBUG/dalvikvm(2558): GREF has increased to 401 
... 
08-17 02:31:36.772: DEBUG/dalvikvm(2558): GREF has increased to 501 
... 
08-17 02:31:42.694: DEBUG/dalvikvm(2558): GREF has increased to 601 
... 
08-17 02:31:48.695: DEBUG/dalvikvm(2558): GREF has increased to 701 
... 
08-17 02:31:59.883: DEBUG/dalvikvm(2558): GREF has decreased to 599 
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 499 
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 399 
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 299 
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 199 

Hice algunas búsquedas y veo que la mayoría de las observaciones sobre esto son bastante antiguas. Mi preocupación es que estoy implementando mi cliente/servicio correctamente, y quería saber cómo puedo rastrear qué está causando que GREF aumente. Cualquier pensamiento/sugerencia es bienvenida. ¡Gracias!

el flujo del programa básico

Client -> Creates Callback 
Client -> Starts Service 
Service -> Inits & Starts CountDownTimer 
Service.CountDownTimer.onFinish() -> DownloadAndParse() 
DownloadAndParse() -> initialize new saxRequest(), new Handler for this request. 
Service.Handler->beginBroadcast() 
Client.CallbackStub -> updateUI() 
Client.CallbackStub -> service.startCountDownTimer() 

Esperamos que esto tiene sentido. Publicaba el código aquí, pero hay tantos archivos diferentes. Pensé que trataría de poner el flujo para ver si había algo deslumbrante ... Lo único que puedo ver es quizás volver a usar saxRequest() en lugar de crear una nueva instancia ... Lo intentaré ahora , pero realmente me gustaría saber sobre el impacto de GREF y la recolección de basura.

Answer 1

Estas son las referencias globales de JNI. Si no está escribiendo código nativo, no tiene control directo sobre ellos. Los mensajes de registro aparecen cuando CheckJNI está habilitado, que está activado por defecto para las versiones de ingeniería y el emulador.

Los mensajes solo significan que el código nativo le dice a la VM que no está permitido descartar algunos objetos. En esencia, los refs globales son una manera para que el código nativo agregue referencias al conjunto de raíz del GC. Suponiendo que el código nativo está escrito correctamente, los refs globales serán borrados cuando el código nativo ya no los necesite.

La única causa de preocupación sería si el recuento global de ref. Continuara aumentando, ya que eso sugeriría una fuga de referencia global. Como la VM no puede liberar los objetos, una fuga de ref global eventualmente hará que la VM se quede sin memoria. Para ayudar a identificar tales problemas, se coloca un límite en el número de referencias globales cuando CheckJNI está habilitado (el límite actual es 2000).