W bibliotece w Javie 7 mam klasę, która świadczy usługi dla innych klas. Po utworzeniu instancji tej klasy usługi można wywołać kilka jej doWork()metod (nazwijmy ją metodą). Nie wiem więc, kiedy zakończy się praca klasy usług.

Problem polega na tym, że klasa usług używa ciężkich przedmiotów i powinna je zwolnić. Ustawiłem tę część w metodzie (nazwijmy ją release()), ale nie ma gwarancji, że inni programiści użyją tej metody.

Czy istnieje sposób zmuszenia innych programistów do wywołania tej metody po zakończeniu zadania klasy usług? Oczywiście mogę to udokumentować, ale chcę je zmusić.

Uwaga: Nie mogę wywołać release()metody w doWork()metodzie, ponieważ doWork() potrzebuje tych obiektów, gdy zostanie wywołana w następnej kolejności.

Pragmatycznym rozwiązaniem jest stworzenie klasy AutoCloseablei zapewnienie finalize()metody zabezpieczającej (w razie potrzeby ... patrz poniżej!). Następnie polegasz na użytkownikach swojej klasy, którzy używają try-with-resource lub close()jawnie dzwonią .

Oczywiście mogę to udokumentować, ale chcę je zmusić.

Niestety, nie ma sposobu, ¹ w języku Java, aby wymusić programista zrobić dobry uczynek. Najlepsze, co możesz zrobić, to wykryć nieprawidłowe użycie w statycznym analizatorze kodów.

Na temat finalistów. Ta funkcja Java ma bardzo niewiele dobrych przypadków użycia. Jeśli polegasz na finalizatorach, masz problem, że uporządkowanie może zająć bardzo dużo czasu. Finalizer będą działać tylko po GC decyduje, że obiekt nie jest już dostępne. Może się to nie zdarzyć, dopóki JVM nie wykona pełnej kolekcji.

Tak więc, jeśli problemem, który chcesz rozwiązać, jest odzyskanie zasobów, które trzeba wcześniej zwolnić , to przegapiłeś łódź, używając finalizacji.

I na wypadek, gdybyś nie miał tego, co mówię powyżej ... prawie nigdy nie jest właściwe używanie finalizatorów w kodzie produkcyjnym i nigdy nie powinieneś na nich polegać!

^{1 - Istnieją sposoby. Jeśli jesteś gotów „ukryć” obiekty usług przed kodem użytkownika lub ściśle kontrolować ich cykl życia (np. Https://softwareengineering.stackexchange.com/a/345100/172 ), to kod użytkownika nie musi dzwonić release(). Jednak interfejs API staje się bardziej skomplikowany, ograniczony ... i „brzydki” IMO. Ponadto nie zmusza to programisty do robienia właściwych rzeczy . Usuwa zdolność programisty do robienia złych rzeczy!}

Wydaje się, że jest to przypadek użycia AutoCloseableinterfejsu i try-with-resourcesinstrukcja wprowadzona w Javie 7. Jeśli masz coś takiego

public class MyService implements AutoCloseable {
    public void doWork() {
        // ...
    }

    @Override
    public void close() {
        // release resources
    }
}

wtedy Twoi konsumenci mogą go używać jako

public class MyConsumer {
    public void foo() {
        try (MyService myService = new MyService()) {
            //...
            myService.doWork()
            //...
            myService.doWork()
            //...
        }
    }
}

i nie musisz się martwić wywołaniem jawnego, releaseniezależnie od tego, czy jego kod zgłasza wyjątek.

Dodatkowa odpowiedź

Jeśli naprawdę szukasz, aby nikt nie mógł zapomnieć o korzystaniu z tej funkcji, musisz zrobić kilka rzeczy

1. Upewnij się, że wszystkie konstruktory MyServicesą prywatne.
2. Zdefiniuj pojedynczy punkt wejścia do użycia, MyServicektóry zapewni, że zostanie on później wyczyszczony.

Zrobiłbyś coś takiego

public interface MyServiceConsumer {
    void accept(MyService value);
}

public class MyService implements AutoCloseable {
    private MyService() {
    }


    public static void useMyService(MyServiceConsumer consumer) {
        try (MyService myService = new MyService()) {
            consumer.accept(myService)
        }
    }
}

Użyłbyś go jako

public class MyConsumer {
    public void foo() {
        MyService.useMyService(new MyServiceConsumer() {
            public void accept(MyService myService) {
                myService.doWork()
            }
        });
    }
}

Początkowo nie polecałem tej ścieżki, ponieważ jest obrzydliwa bez lambd Java-8 i interfejsów funkcjonalnych (gdzie MyServiceConsumersię Consumer<MyService>pojawia) i jest dość imponująca dla twoich konsumentów. Ale jeśli potrzebujesz tylko tego, release()aby zadzwonić, zadziała.

tak, możesz

Możesz absolutnie zmusić ich do wydania i sprawić, że będzie w 100% niemożliwe do zapomnienia, uniemożliwiając im tworzenie nowych Serviceinstancji.

Jeśli zrobili coś takiego wcześniej:

Service s = s.new();
try {
  s.doWork("something");
  if (...) s.doWork("something else");
  ...
}
finally {
  s.release(); // oops: easy to forget
}

Następnie zmień go, aby mieli do niego dostęp w ten sposób.

// Their code

Service.runWithRelease(new ServiceConsumer() {
  void run(Service s) {
    s.doWork("something");
    if (...) s.doWork("something else");
    ...
  }  // yay! no s.release() required.
}

// Your code

interface ServiceConsumer {
  void run(Service s);
}

class Service {

   private Service() { ... }      // now: private
   private void release() { ... } // now: private
   public void doWork() { ... }   // unchanged

   public static void runWithRelease(ServiceConsumer consumer) {
      Service s = new Service();
      try {
        consumer.run(s);
      }
      finally {
        s.release();
      } 
    } 
  }

Ostrzeżenia:

• Rozważ ten pseudokod, minęło wiele lat, odkąd napisałem Javę.
• W dzisiejszych czasach mogą istnieć bardziej eleganckie warianty, być może zawierające AutoCloseableinterfejs, o którym ktoś wspomniał; ale podany przykład powinien zadziałać od razu po wyjęciu z pudełka i poza elegancją (która sama w sobie jest przyjemnym celem) nie powinno być żadnego ważnego powodu, aby to zmienić. Zauważ, że zamierza to powiedzieć, że możesz użyć AutoCloseablew swojej prywatnej implementacji; zaletą mojego rozwiązania nad korzystaniem z niego przez użytkowników AutoCloseablejest to, że znowu nie można go zapomnieć.
• Będziesz musiał go dopracować w razie potrzeby, na przykład, aby wprowadzić argumenty do new Servicewywołania.
• Jak wspomniano w komentarzach, pytanie, czy konstrukcja tego typu (tj. Podejmowanie procesu tworzenia i niszczenia a Service) należy do osoby dzwoniącej, czy nie, jest poza zakresem tej odpowiedzi. Ale jeśli zdecydujesz, że jest to absolutnie potrzebne, możesz to zrobić w ten sposób.
• Jeden komentator podał te informacje dotyczące obsługi wyjątków: Książki Google

Możesz spróbować użyć wzorca poleceń .

class MyServiceManager {

    public void execute(MyServiceTask tasks...) {
        // set up everyting
        MyService service = this.acquireService();
        // execute the submitted tasks
        foreach (Task task : tasks)
            task.executeWith(service);
        // cleanup yourself
        service.releaseResources();
    }

}

Daje to pełną kontrolę nad pozyskiwaniem i uwalnianiem zasobów. Dzwoniący przekazuje tylko zadania do Twojej Usługi, a Ty sam jesteś odpowiedzialny za pozyskiwanie i czyszczenie zasobów.

Jest jednak pewien haczyk. Dzwoniący nadal może to zrobić:

MyServiceTask t1 = // some task
manager.execute(t1);
MyServiceTask t2 = // some task
manager.execute(t2);

Ale możesz rozwiązać ten problem, gdy się pojawi. Gdy wystąpią problemy z wydajnością i okaże się, że niektórzy dzwoniący to robią, po prostu pokaż im właściwy sposób i rozwiąż problem:

MyServiceTask t1 = // some task
MyServiceTask t2 = // some task
manager.execute(t1, t2);

Możesz to dowolnie skomplikować, wdrażając obietnice dla zadań zależnych od innych zadań, ale późniejsze wydawanie rzeczy również staje się bardziej skomplikowane. To tylko punkt wyjścia.

Asynchronizacja

Jak wskazano w komentarzach, powyższe tak naprawdę nie działa z żądaniami asynchronicznymi. To jest poprawne. Ale można to łatwo rozwiązać w Javie 8 za pomocą CompleteableFuture , szczególnie w CompleteableFuture#supplyAsynccelu tworzenia indywidualnych przyszłości i CompleteableFuture#allOfzapewnienia uwolnienia zasobów po zakończeniu wszystkich zadań. Alternatywnie, zawsze można użyć Threads lub ExecutorServices do opracowania własnej implementacji kontraktów futures / obietnic.

Jeśli możesz, nie zezwalaj użytkownikowi na tworzenie zasobu. Pozwól użytkownikowi przekazać obiekt gościa do metody, która utworzy zasób, przekaże go do metody obiektu gościa, a następnie zwolni.

Mój pomysł był podobny do Polygnome.

Możesz mieć metody „do_something ()” w swojej klasie, po prostu dodając polecenia do prywatnej listy poleceń. Następnie zastosuj metodę „commit ()”, która faktycznie działa, i wywołuje „release ()”.

Jeśli więc użytkownik nigdy nie wywoła metody commit (), praca nigdy nie zostanie wykonana. Jeśli tak, zasoby zostaną uwolnione.

public class Foo
{
  private ArrayList<ICommand> _commands;

  public Foo doSomething(int arg) { _commands.Add(new DoSomethingCommand(arg)); return this; }
  public Foo doSomethingElse() { _commands.Add(new DoSomethingElseCommand()); return this; }

  public void commit() { 
     for(ICommand c : _commands) c.doWork();
     release();
     _commands.clear();
  }

}

Następnie możesz użyć go jak foo.doSomething.doSomethineElse (). Commit ();

Inną alternatywą dla tych wymienionych byłoby użycie „inteligentnych referencji” do zarządzania enkapsulowanymi zasobami w sposób, który umożliwia automatycznemu czyszczeniu śmieci bez ręcznego zwalniania zasobów. Ich przydatność zależy oczywiście od wdrożenia. Przeczytaj więcej na ten temat w tym cudownym poście na blogu: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

W przypadku każdego innego języka zorientowanego na klasy umieściłbym go w destruktorze, ale ponieważ nie jest to opcja, myślę, że można zastąpić metodę finalizacji. W ten sposób, gdy instancja wyłączy się z zakresu i zostanie wyrzucona, zostaną zwolnione.

@Override
public void finalize() {
    this.release();
}

Nie znam się zbytnio na Javie, ale myślę, że jest to cel, dla którego przeznaczona jest finalize ().

http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#finalize ()