GREF увеличивается/уменьшается в многопоточном сервисе (helpl) - что это значит?

Question

У меня есть активность android и сервис, реализованный с помощью helpl. Работает как чемпион, у меня есть функция обратного вызова, чтобы передать некоторые уведомления о потоке обратно в пользовательский интерфейс, и, похоже, работает нормально, за исключением лотов

GREF увеличился до 101, 201,301,401, 501 .. и т. Д. и GREF уменьшился. Я сделал поиск в Интернете и обнаружил, что он должен делать w/Global References.

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 

Я сделал несколько поисков и увидел, что большинство замечаний на этом довольно старые. Меня беспокоит, что я правильно внедряю свой клиент/сервис и хочу знать, как я могу отслеживать, что вызывает увеличение GREF. Любые мысли/предложения приветствуются. Благодаря!

Основной программа Flow

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() 

Надеется, что это имеет смысл. Я бы опубликовал код здесь, но есть так много во многих разных файлах. Я решил, что попробую поставить поток, чтобы увидеть, есть ли что-то вопиющее ... Единственное, что я вижу, это, возможно, повторное использование saxRequest(), а не создание нового экземпляра ... Я попробую сейчас , но я бы очень хотел узнать о влиянии GREF и коллекции мусора.

Answer 1

Это глобальные ссылки JNI. Если вы не пишете собственный код, у вас нет прямого контроля над ними. Сообщения журнала появляются, когда включена функция CheckJNI, которая по умолчанию включена для инженерных сборок и эмулятора.

Сообщения просто означают, что собственный код сообщает виртуальной машине, что ей не разрешено отбрасывать некоторые объекты. По сути, глобальные ссылки - это способ для собственного кода добавлять ссылки на корневой набор GC. Предполагая, что собственный код написан правильно, глобальные refs будут очищены, когда родной код больше не понадобится.

Единственная причина для беспокойства заключается в том, что глобальный подсчет продолжает расти, поскольку это предполагает глобальную утечку ссылок. Поскольку виртуальная машина не может освобождать объекты, глобальная утечка ref в конечном итоге приведет к тому, что виртуальная машина закончится из памяти. Чтобы выявить такие проблемы, при включении CheckJNI (ограничение по току - 2000) колпачок помещается в число глобальных ссылок.