내 프로그램에서 힙 덤프를 실행했다. 메모리 애널라이저 도구에서 열었을 때, 에 대한 java.lang.ref.Finalizer
이 많은 메모리를 차지하고있는 것으로 나타났습니다. 이게 왜 그렇게?은 메모리 누수입니까? 왜 java.lang.ref.Finalizer가 많은 메모리를 먹는가
답변
일부 클래스는 Object.finalize()
방법을 구현한다. 이 메소드를 오버라이드 (override)하는 객체는, 백그라운드 thread 호출 종료 자에 의해 불려 갈 필요가있어, 이것을 막을 때까지는 클린 업 할 수 없습니다. 이러한 작업이 짧고 이러한 작업을 많이 삭제하지 않으면 모두 잘 작동합니다. 그러나 이러한 개체를 많이 만들거나 종결자가 시간이 오래 걸리면 완료 할 개체의 큐가 만들어집니다. 이 큐가 모든 메모리를 사용할 수 있습니다.
이 솔루션은
- 당신이 (당신이 개체의 클래스를 작성하는 경우) 할 수 있다면 당신이 그것을 사용하는 경우
- 가 (매우 짧은 마무리하게 마무리() D 객체를 사용하지 않는)
- 는 개체마다 시간을 버리지 않는다 (
마지막 옵션을 사용하면 기존 라이브러리를 사용하는 당신을위한 가장 좋은 가능성)을 다시 사용하려고합니다.
옵션 # 4 - 파이널 라이저를 (over-) 사용하는 라이브러리 사용을 피하십시오. –
옵션 # 1;의 변형) –
문제가 Finalizer 스레드의 원인 일 수 있습니다. 하나의 클래스가 finalize 메쏘드를 오버라이드하여 Finalizer 스레드의 deadlock을 야기합니다 – fuyou001
Proxool은 JDBC 연결을위한 연결 풀입니다. 이 문제는 귀하의 응용 프로그램이 연결 풀을 오용하고 있다는 것을 나에게 암시합니다. 문 개체에 close
을 호출하는 대신 코드에서 해당 문 및/또는 부모 연결을 삭제할 수 있습니다. Proxool은 기본 드라이버 구현 객체를 닫기 위해 파이널 라이저를 사용하지만, Finalizer 인스턴스가 필요합니다. 또한 필요 이상으로 빈번히 열리거나 닫히는 (실제) 데이터베이스 연결로 인해 연결이 끊어지고 성능에 좋지 않을 수도 있습니다.
그래서 코드가 누수 된 ResultSet, Statement 및/또는 Connection 객체가 있는지 확인하고 finally
블록으로 닫는 것이 좋습니다.
메모리 덤프를 보면 898,527,228 바이트가 어디로가는 지 염려합니다. 대다수는 ID가 2aab07855e38
인 Finalizer 개체에 의해 유지됩니다. 덤프 파일이 아직 남아있는 경우 을보고Finalizer
을 참조하십시오. Proxool 객체보다 문제가 많습니다.
고마워요.하지만 JDBC 커넥션 poll memoy leak의 원인을 찾지 못했습니다. – fuyou001
소스 코드가 보이지 않는 한 글쎄요. (그리고 나는 어쨌든 그것을 통과하는 내 시간을 보내고 싶지 않다 ...) –
"이미지"링크가 내 트위터 프로필로 보이는 부분으로 이동합니다. –
@ R.MartinhoFernandes 그는 트위터로 호스팅 한 이미지로 이동합니다. – Oliver