멀티 스레드 서비스에서 GREF가 증가/감소하는 경우 (aidl) - 이것이 의미하는 바는 무엇입니까?

Question

나는 안드로이드 활동과 aidl을 사용하여 구현 된 서비스를 운영하고 있습니다. 챔피언처럼 작동하며 일부 스레드 알림을 다시 UI에 전달하는 콜백 설정이 있으며 그 중 많은 예외를 제외하고는 제대로 작동하는 것으로 보입니다

GREF가 101, 201301401501 등으로 증가했습니다. GREF가 감소했습니다. 온라인으로 검색을 한 결과, 글로벌 참조가 필요하다는 것을 알았습니다.

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를 증가시키는 원인을 추적 할 수있는 방법을 알고 싶었습니다. 모든 생각/제안을 환영합니다. 감사!

기본 프로그램 흐름

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가 사용 가능할 때 로그 메시지가 나타납니다. 이는 엔지니어링 빌드 및 에뮬레이터에 기본적으로 사용됩니다.

메시지는 네이티브 코드가 일부 객체를 버릴 수 없다고 VM에 알려주고 있다는 것을 의미합니다. 본질적으로 전역 참조는 네이티브 코드가 GC의 루트 집합에 대한 참조를 추가하는 방법입니다. 원시 코드가 올바르게 작성되었다고 가정하면 원시 코드가 더 이상 필요하지 않으면 전역 참조가 지워집니다.

전역 참조 횟수가 계속 올라가면 전역 참조 누수가 제안되므로 걱정할 필요가있는 유일한 이유가 있습니다. VM은 객체를 해제 할 수 없기 때문에 글로벌 참조 누출로 인해 결국 VM이 메모리를 모두 소모하게됩니다. 이러한 문제를 식별 할 수 있도록 CheckJNI가 활성화 될 때 (현재 한계는 2000) 전역 참조 수에 제한이 있습니다.