Почему метод finalize называется 2 раза в калитки модели

Question

В моем приложении у меня есть класс, который расширяет калитки и переопределяет окончательный метод (просто удалите файл, который генерируется асинхронным). Проблема заключается в том, что завершенный метод вызывается сразу после того, как калитка страница загружаются в первый раз, а затем еще раз

public class TournamentFileReadOnlyModel<I> extends AbstractReadOnlyModel<File> { 

    private static final long serialVersionUID = 1L; 

    private CallableService callableService; 
    private String uuid; 

    public TournamentFileReadOnlyModel(CallableService callableService, I input, 
      Class<? extends AbstractPdfCallable<I>> callableClass) { 
     this.uuid = UUID.randomUUID().toString(); 
     this.callableService = callableService; 
     callableService.createFile(uuid, WicketApplication.getFilesPath(), input, callableClass); 
    } 

    @Override 
    public File getObject() { 
     return callableService.getFile(uuid); 
    } 

    @Override 
    protected void finalize() throws Throwable { 
     super.finalize(); 
     callableService.finalizeFile(uuid); 
    } 
} 

Я создал связь с этой моделью:

private void addPrintGroupButton() { 
     add(new DownloadModelLink("printGroup", new TournamentFileReadOnlyModel<GroupPageDto>(callableService, 
       groupPageDto, GroupPdfCallable.class))); 
    } 

журнал:

1. время вызвано для меня без причины, потому что я просто загружаю веб-страницу и все еще имею ссылку для модели

   17: 50: 45,493 [Финалайзер] INFO org.tahom.processor.service.callable.CallableService - Очистка файла из кэша с UUID: 61286bf6-da4c-4905-B65D-d6061eb1466f

2. время загрузки для меня нормально, потому что я загрузить другую веб-страницу, и уже потеряли ссылку на эту модель

   17: 51: 10,913 [Финалайзер] INFO org.tahom.processor.service.callable.CallableService - Ошибка при очистке файла из кэша с uuid: 61286bf6-da4c-4905-b65d-d6061eb1466f java.lang.NullPointerException at org.tahom.processor. service.callable.CallableService.finalizeFile (CallableService.java:65) [tahom-processor-0.2.0-SNAPSHOT.jar :?] на WICKET_org.tahom.processor.service.callable.CallableService $$ FastClassByCGLIB $$ 82eb5c9b.invoke() [cglib-3.1.jar :?] at net.sf.cglib.proxy.MethodProxy.invoke (MethodProxy.java:204) [cglib-3.1.jar :?] на org.apache.wicket.proxy. LazyInitProxyFactory $ AbstractCGLibInterceptor.intercept (LazyInitProxyFactory.java:350) [wicket-ioc-7.1.0.jar: 7.1.0] на WICKET_org.tahom.processor.service.callable.CallableService $$ EnhancerByCGLIB $$ 41212df1.finalizeFile() [cglib-3.1.jar :?] at org.tahom.web.model.TournamentFileReadOnlyModel.finalize (TournamentFileReadOnlyModel.java:33) [classes/:?] at java.lang.ref.Finalizer.invokeFinalizeMethod (Native Method) ~ [?: 1.7.0_25] в java .lang.ref.Finalizer.runFinalizer (Finalizer.java:101) [?: 1.7.0_25] at java.lang.ref.Finalizer.access $ 100 (Finalizer.java:32) [?: 1.7.0_25] at java.lang.ref.Finalizer $ FinalizerThread.run (Finalizer.java:190) [: 1.7.0_25]

UPDATE

гм вы правы. Существует еще одна модель. Но тогда я не знаю, как может быть такой же uuid, который разделяют разные модели. Но это уже другой вопрос

21: 08: 55,980 [qtp13530976-43] DEBUG org.tahom.processor.service.callable.CallableService - Создание файла с uuidb485a4d1-ef67-4255-af64-4d7df6001b09 21: 08: 55,980 [qtp13530976-43] ОТЛАДКА org.tahom.web.model.TournamentFileReadOnlyModel - UUID b485a4d1-ef67-4255-af64-4d7df6001b09 генерируется для classorg.tahom.web.model.TournamentFileReadOnlyModel@1ba03be

21: 8:56.794 [Финалайзер] ОТЛАДКА org.tahom.web.model.TournamentFileReadOnlyModel - Класс org.tahom.web.model.TournamentFileReadOnlyModel@14be425 21: 08: 56,907 [Финалайзер] INFO org.tahom.processor.service.callable.CallableService - очистка файла из кэша с UUID: b485a4d1-ef67-4255-af64-4d7df6001b09

21: 09: 23,696 [Финалайзер] WARN org.tahom.processor.service.callable.CallableService - Ошибка при очистка файла от кэш с UUID: b485a4d1-ef67-4255-af64-4d7df6001b09 21: 09: 23,696 [Финалайзер] DEBUG org.tahom.web.model.TournamentFileReadOnlyModel - Класс org.tahom.web.model.TournamentFileReadOnly Модель @ 1d76f52

Answer 1

Коэффициенты: вы имеете дело с (в других областях вашего кода) двумя экземплярами TournamentFileReadOnlyModel.

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

В любом случае, вставка обязательной логики в блоке завершенности является известным «действительно плохим шаблоном», и, хотя вам может возникнуть соблазн найти причину, по которой ваш класс построен дважды, вместо этого подумайте, не используя блок finalize.

Это может означать использование другого подхода для управления временными файлами, о которых вы говорили; но с другим подходом вы можете явно детализировать политику вместо того, чтобы надеяться, что JVM (которая не имеет никаких гарантий для этого) будет следовать вашей политике.