2017-12-13 29 views
0

을 사용하는 일부 library code이 있습니다. 내 응용 프로그램에서이 코드 조각이 많이 호출되므로 메모리는 DeleteOnExitHook에 계속 축적됩니다. 이로 인해 내 힙이 무기한 증가하고 결국 OutOfMemoryErrors이됩니다. 클래스가 완전히 패키지로 보호되어 있으므로 삭제 대기중인 파일을 중간에 삭제하는 간단한 메커니즘이 있습니다. 나는 반사 마법으로이 목록을 비울 수 있습니까?File.deleteOnExit을 통해 삭제 대기중인 파일 정리

+1

조금 읽은 후에'deleteOnExit()'는 매우 이상하고 부분적으로 위험한 방법 인 것 같습니다. '정상 종료'에서 삭제할 파일의 문자열 만 저장합니다.이 파일은'System.exit (0)'과 비슷합니다. 하드 종료 나'kill '또는'System.exit (1)'과 같은 다른 종료와 함께 파일은 삭제되지 않습니다. 그래서 나는'deleteOnExit()'를 사용하지 않도록 노력할 것이다. 사용 된 라이브러리를 다른 라이브러리로 교체 할 수 있습니까? 실제로 반사를 사용하여 가시성을 변경하고 일반 '삭제'로 메소드를 덮어 쓸 수 있습니다. – Korashen

+1

Alternativly, 가장 좋아하는 것은별로 좋지 않지만, 라이브러리를 포크로 만들고, 코드를 다시 작성하고 직접 빌드하십시오. (아마도 풀 요청을 만드시겠습니까?) – Korashen

+0

나는 거기에 패치를 기꺼이 제출할 것이지만, 아마도 그 패치가 합쳐지기까지는 오래 걸릴 것입니다. 해킹 해킹은 멋질 것입니다. –

답변

1

내가 알기에, 당신은 더러운 해킹이 필요하므로 충분해야합니다. files 필드 값을 복원해야 정상 종료 (또는 다음에이 해킹을 사용할 때)가 정상적으로 작동합니다.

참고 : 다른 라이브러리에서 예약 한 파일을 포함하여 모든 항목이 삭제됩니다. 귀하의 경우 안전한지 확인하십시오.

java.lang.reflect.Method run = Class.forName ("java.io.DeleteOnExitHook").getDeclaredMethod ("runHooks"); 
    java.lang.reflect.Field files = Class.forName ("java.io.DeleteOnExitHook").getDeclaredField ("files"); 

    run.setAccessible (true); 
    files.setAccessible (true); 

    run.invoke (null); 
    files.set (null, new java.util.LinkedHashSet <String>()); 

는 다른 방법으로, 당신이가는대로 또한 세트에서 이름을 삭제
files.get (null) 

이 세트를 반복하고 수동으로 파일을 삭제하여 예약 된 파일을 검색 할 수 있습니다. 이렇게하면 자신을 삭제할 파일을 결정할 수 있습니다.