2009-05-14 2 views
0

응용 프로그램에서 메모리 오류를 찾고 있는데 ServerSocketChannel.accept()에 의해 생성 된 byte [] 버퍼와 관련이있는 것으로 보입니다. jvisualvm에 따르면, 응용 프로그램에서 사용중인 505 meg 중 메모리의 90 % 이상이 byte [] 배열에 사용되고 있습니다. 그것을 더 자세히 살펴보면, byte []의 68k + 인스턴스가 있으며, 가장 일반적인 크기는 16681입니다.Java 서버 소켓 버퍼가 Mac에서 가비지 수집되지 않습니다.

이러한 바이트 배열의 무작위 샘플링을 수행했는데 예외없이 모두 InputRecord 또는 OutputRecord. 모든 참고 문헌을 따르는 경우 Finalizer로 연결되지 않는 항목을 찾을 수 없습니다. 필자의 제한된 이해로는 개체가 가비지 수집 될 준비가되었지만 어떤 이유로 든 그렇지 않은지를 의미합니다. .

jvisualvm 출력의 화면 캡처를 첨부하고 싶습니다. 어쨌든, 지시 대상 객체는 다음과 같습니다

  • InputRecord을
  • AppInputStream
  • SSLSocketImpl
  • SocketInputStream
  • SocksSocketImpl
  • SocketOutputStream
  • AppOutputStream
  • DelegateHttpsURLConnection
  • ,
  • HttpsURLConnectionImpl

이는 Apple의 VM을 사용하는 고객에게만 발생하는 것으로 보입니다. 아무도 왜 이러한 버퍼가 가비지 수집되지 않습니다 어떤 생각을 가지고 있니? 힙 프로파일을 잘못 읽었습니까? 해킹 또는 해결 방법?

+0

이러한 객체 또는 관련 객체에서 close()를 호출했다고 가정합니다. VisualVM에서 GC를 요청한 경우 메모리 소비가 줄어 듭니까? – akarnokd

+0

비슷한 문제가 발생했습니다. 여기에 설명되어 있습니다 : http://stackoverflow.com/questions/14610567/memory-leak-spring-3-2-0-release-httpcomponents-4-2-3 – user2023507

답변

1

finalize 가비지 컬렉터가 개체를 발견 한 후 언젠가 호출됩니다. Sun 구현은 java.lang.ref과 섞여 있습니다. 리소스를 적절히 닫으면 메모리를 해제해야합니다. finalize을 가진 객체가 닫혀있을 때 버퍼에 대한 참조를 null로 만들지 못하면 finalizers가 실행 된 후 관련 GC가 실행될 때까지 해당 버퍼가 중단됩니다.

일반적으로 하나의 파이널 라이저 스레드가 있지만 사양에서 많은 수 있습니다. 차단 조작, 부적절한 보류 잠금 또는 기타 이유로 차단 된 경우 최종 개체의 GC가 보류됩니다. 나는 그것이 차단되었는지보기 위해 visualvm에서 finalizer 스레드를 검사하는 것이 좋습니다.

관련 문제