В библиотеке Java 7 у меня есть класс, который предоставляет сервисы другим классам. После создания экземпляра этого класса обслуживания один его метод может вызываться несколько раз (назовем его doWork()методом). Поэтому я не знаю, когда работа класса обслуживания будет завершена.

Проблема в том, что класс обслуживания использует тяжелые объекты и должен их освобождать. Я установил эту часть в методе (давайте назовем его release()), но не гарантируется, что другие разработчики будут использовать этот метод.

Есть ли способ заставить других разработчиков вызывать этот метод после выполнения задачи класса обслуживания? Конечно, я могу это задокументировать, но я хочу заставить их.

Примечание: я не могу вызвать release()метод в doWork()методе, потому что doWork() нуждается в тех объектах, когда он вызывается в следующем.

Прагматичное решение состоит в том, чтобы создать класс AutoCloseableи предоставить finalize()метод в качестве поддержки (если это уместно ... см. Ниже!). Затем вы полагаетесь на то, что пользователи вашего класса будут использовать try-with-resource или close()явно вызывать .

Конечно, я могу это задокументировать, но я хочу заставить их.

К сожалению, нет никакого способа ¹ в Java , чтобы заставить программиста сделать правильную вещь. Лучшее, на что вы можете надеяться, это обнаружить неправильное использование в статическом анализаторе кода.

По теме финализаторов. Эта функция Java имеет очень мало хороших вариантов использования. Если вы упорядочиваете финализаторы, вы сталкиваетесь с проблемой того, что приведение в порядок может занять очень много времени. Финализатор будет запущен только после того, как ГХ решит, что объект больше недоступен. Этого может не произойти, пока JVM не выполнит полную коллекцию.

Таким образом, если проблема, которую вы пытаетесь решить, состоит в том, чтобы вернуть ресурсы, которые должны быть выпущены раньше , то вы пропустили лодку, используя финализацию.

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

^{1 - Есть способы. Если вы готовы «спрятать» объекты службы от кода пользователя или жестко контролировать их жизненный цикл (например, https://softwareengineering.stackexchange.com/a/345100/172 ), тогда код пользователя не должен вызывать release(). Тем не менее, API становится более сложным, ограниченным ... и "некрасивым" IMO. Кроме того, это не заставляет программиста поступать правильно . Это устраняет способность программиста делать неправильные вещи!}

Это похоже на сценарий использования AutoCloseableинтерфейса и try-with-resourcesоператор, введенный в Java 7. Если у вас есть что-то вроде

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

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

тогда ваши потребители могут использовать его как

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

и не нужно беспокоиться о вызове явного releaseнезависимо от того, вызывает ли их код исключение.

Дополнительный ответ

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

1. Убедитесь, что все конструкторы MyServiceявляются частными.
2. Определите единственную точку входа для использования, MyServiceкоторая обеспечит ее очистку после.

Вы бы сделали что-то вроде

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)
        }
    }
}

Вы бы тогда использовали его как

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

Первоначально я не рекомендовал этот путь, потому что он отвратителен без лямбда-выражений Java-8 и функциональных интерфейсов (где это MyServiceConsumerделается Consumer<MyService>), и это довольно навязывает потребителям. Но если то, что вы хотите, это то, что вам release()нужно позвонить, это сработает.

Да, ты можешь

Вы можете абсолютно заставить их выпустить и сделать так, чтобы их было на 100% невозможно забыть, лишив их возможности создавать новые Serviceэкземпляры.

Если они сделали что-то подобное раньше:

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

Затем измените его, чтобы они могли получить к нему доступ таким образом.

// 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();
      } 
    } 
  }

Предостережения:

• Рассмотрим этот псевдокод, прошло уже много лет с тех пор, как я написал Java.
• В наши дни могут быть более элегантные варианты, возможно, включая AutoCloseableинтерфейс, который кто-то упоминал; но данный пример должен работать «из коробки», и кроме элегантности (которая сама по себе является хорошей целью) не должно быть никаких серьезных причин для ее изменения. Обратите внимание, что это означает, что вы можете использовать AutoCloseableвнутри вашей частной реализации; Преимущество моего решения перед использованием ваших пользователей AutoCloseableзаключается в том, что оно, опять же, не может быть забыто.
• Вы должны будете уточнить это по мере необходимости, например, чтобы ввести аргументы в new Serviceвызов.
• Как упоминалось в комментариях, вопрос о том, принадлежит ли подобная конструкция (т. Е. Берет процесс создания и уничтожения a Service) в руки вызывающей стороны или нет, выходит за рамки этого ответа. Но если вы решите, что вам это абсолютно необходимо, это то, как вы можете это сделать.
• Один комментатор предоставил эту информацию об обработке исключений: Google Книги

Вы можете попытаться использовать шаблон Command .

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();
    }

}

Это дает вам полный контроль над приобретением и выпуском ресурсов. Вызывающий абонент только отправляет задачи в вашу Службу, а вы сами несете ответственность за приобретение и очистку ресурсов.

Однако есть одна загвоздка. Абонент все еще может сделать это:

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

Но вы можете решить эту проблему, когда она возникнет. Когда возникают проблемы с производительностью, и вы обнаруживаете, что некоторые абоненты делают это, просто покажите им правильный путь и решите проблему:

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

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

асинхронный

Как было отмечено в комментариях, вышеприведенное не работает с асинхронными запросами. Правильно. Но это легко может быть решено в Java 8 с использованием CompleteableFuture , особенно CompleteableFuture#supplyAsyncдля создания отдельных вариантов будущего и CompleteableFuture#allOfдля освобождения ресурсов после завершения всех задач. В качестве альтернативы, всегда можно использовать Threads или ExecutorServices для развертывания собственной реализации Futures / Promises.

Если вы можете, не позволяйте пользователю создавать ресурс. Позвольте пользователю передать объект посетителя вашему методу, который создаст ресурс, передаст его методу объекта посетителя и впоследствии освободит его.

Моя идея была похожа на идею Полигнома.

Вы можете использовать методы do_something () в своем классе, просто добавляя команды в личный список команд. Затем используйте метод commit (), который фактически выполняет эту работу и вызывает метод release ().

Таким образом, если пользователь никогда не вызывает commit (), работа никогда не завершается. Если они это сделают, ресурсы будут освобождены.

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();
  }

}

Затем вы можете использовать его как foo.doSomething.doSomethineElse (). Commit ();

Другой альтернативой упомянутым может быть использование «умных ссылок» для управления инкапсулированными ресурсами таким образом, чтобы сборщик мусора автоматически очищался без освобождения ресурсов вручную. Их полезность зависит, конечно, от вашей реализации. Подробнее об этой теме читайте в этом замечательном сообщении в блоге: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Для любого другого языка, ориентированного на класс, я бы сказал, поместите его в деструктор, но, поскольку это не вариант, я думаю, вы можете переопределить метод finalize. Таким образом, когда экземпляр выходит из области видимости и собирается мусором, он будет освобожден.

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

Я не слишком знаком с Java, но я думаю, что это цель, для которой предназначена finalize ().

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