Em uma biblioteca em Java 7, tenho uma classe que fornece serviços para outras classes. Após criar uma instância dessa classe de serviço, um método pode ser chamado várias vezes (vamos chamá-lo de doWork()método). Portanto, não sei quando o trabalho da classe de serviço está concluído.

O problema é que a classe de serviço usa objetos pesados ​​e deve liberá-los. Defino essa parte em um método (vamos chamá-lo release()), mas não é garantido que outros desenvolvedores usem esse método.

Existe uma maneira de forçar outros desenvolvedores a chamar esse método depois de concluir a tarefa da classe de serviço? Claro que posso documentar isso, mas quero forçá-los.

Nota: Não posso chamar o release()método no doWork()método, porque doWork() precisa desses objetos quando for chamado a seguir.

A solução pragmática é fazer a classe AutoCloseablee fornecer um finalize()método como um pano de fundo (se apropriado ... veja abaixo!). Então você conta com os usuários da sua classe para usar o try-with-resource ou ligar close()explicitamente.

Claro que posso documentar isso, mas quero forçá-los.

Infelizmente, não existe uma maneira ¹ em Java para forçar o programador a fazer a coisa certa. O melhor que você pode esperar é escolher um uso incorreto em um analisador de código estático.

Sobre o tema dos finalizadores. Esse recurso Java possui muito poucos casos de uso bons . Se você contar com os finalizadores para arrumar, terá o problema de que pode levar muito tempo para que a arrumação aconteça. O finalizador será executado somente depois que o GC decidir que o objeto não está mais acessível. Isso pode não acontecer até que a JVM faça uma coleção completa .

Portanto, se o problema que você está tentando resolver é recuperar recursos que precisam ser liberados mais cedo , você perdeu o barco usando a finalização.

E caso você não tenha entendido o que estou dizendo acima ... quase nunca é apropriado usar finalizadores no código de produção, e você nunca deve confiar neles!

^{1 - Existem maneiras. Se você estiver preparado para "ocultar" os objetos de serviço do código do usuário ou controlar rigidamente seu ciclo de vida (por exemplo, https://softwareengineering.stackexchange.com/a/345100/172 ), o código do usuário não precisará ser chamado release(). No entanto, a API se torna mais complicada, restrita ... e IMO "feia". Além disso, isso não está forçando o programador a fazer a coisa certa . Está removendo a capacidade do programador de fazer a coisa errada!}

Esse parece ser o caso de uso da AutoCloseableinterface e a try-with-resourcesinstrução introduzida no Java 7. Se você tiver algo como

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

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

seus consumidores podem usá-lo como

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

e não precisa se preocupar em chamar um explícito, releaseindependentemente de seu código gerar uma exceção.

Resposta adicional

Se o que você está realmente procurando é garantir que ninguém se esqueça de usar sua função, você deve fazer algumas coisas

1. Assegure-se de que todos os construtores de MyServicesejam privados.
2. Defina um único ponto de entrada a ser usado para MyServicegarantir que ele seja limpo depois.

Você faria algo como

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

Você o usaria como

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

Eu não recomendo esse caminho originalmente porque é hediondo sem lambdas Java-8 e interfaces funcionais (onde MyServiceConsumerfica Consumer<MyService>) e é bastante imponente para seus consumidores. Mas se o que você deseja apenas é que release()deve ser chamado, ele funcionará.

sim você pode

Você pode absolutamente forçá-los a liberar e torná-lo 100% impossível de esquecer, impossibilitando a criação de novas Serviceinstâncias.

Se eles fizeram algo assim antes:

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

Em seguida, altere-o para que eles possam acessá-lo assim.

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

Ressalvas:

• Considere esse pseudocódigo, já faz muito tempo desde que escrevi Java.
• Pode haver variantes mais elegantes hoje em dia, talvez incluindo a AutoCloseableinterface que alguém mencionou; mas o exemplo dado deve funcionar imediatamente e, exceto pela elegância (que é um objetivo legal por si só), não deve haver motivo principal para alterá-lo. Observe que isso pretende dizer que você poderia usar AutoCloseabledentro de sua implementação privada; o benefício da minha solução em relação ao uso de seus usuários AutoCloseableé que ela pode, novamente, não ser esquecida.
• Você precisará realizá-lo conforme necessário, por exemplo, para injetar argumentos na new Servicechamada.
• Como mencionado nos comentários, a questão de saber se um construto como este (isto é, assumir o processo de criação e destruição de a Service) pertence à mão do chamador ou não está fora do escopo desta resposta. Mas se você decidir que precisa absolutamente disso, é assim que pode fazê-lo.
• Um comentarista forneceu essas informações sobre o tratamento de exceções: Google Livros

Você pode tentar usar o padrão de comando .

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

}

Isso fornece controle total sobre a aquisição e liberação de recursos. O chamador envia apenas tarefas ao seu Serviço, e você é responsável por adquirir e limpar recursos.

Há um problema, no entanto. O chamador ainda pode fazer isso:

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

Mas você pode resolver esse problema quando ele surgir. Quando houver problemas de desempenho e você descobrir que alguns chamadores fazem isso, simplesmente mostre a eles a maneira correta e resolva o problema:

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

Você pode tornar isso arbitrariamente complexo implementando promessas para tarefas que dependem de outras tarefas, mas liberar coisas também fica mais complicado. Este é apenas um ponto de partida.

Assíncrono

Como foi apontado nos comentários, o acima não funciona realmente com solicitações assíncronas. Está correto. Mas isso pode ser facilmente resolvido no Java 8 com o uso do CompleteableFuture , especialmente CompleteableFuture#supplyAsyncpara criar futuros individuais e CompleteableFuture#allOfaperfeiçoar a liberação dos recursos quando todas as tarefas forem concluídas. Como alternativa, sempre é possível usar Threads ou ExecutorServices para lançar sua própria implementação de Futuros / Promessas.

Se você puder, não permita que o usuário crie o recurso. Permita que o usuário passe um objeto de visitante para o seu método, o qual criará o recurso, passe para o método do objeto de visitante e libere depois.

Minha ideia foi semelhante à da Polygnome.

Você pode ter os métodos "do_something ()" em sua classe, apenas adicionando comandos a uma lista de comandos privada. Então, tenha um método "commit ()" que realmente faça o trabalho e chame "release ()".

Portanto, se o usuário nunca chamar commit (), o trabalho nunca será concluído. Se o fizerem, os recursos são liberados.

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

}

Você pode usá-lo como foo.doSomething.doSomethineElse (). Commit ();

Outra alternativa às mencionadas seria o uso de "referências inteligentes" para gerenciar seus recursos encapsulados de uma maneira que permita ao coletor de lixo limpar automaticamente sem liberar recursos manualmente. Sua utilidade depende, é claro, da sua implementação. Leia mais sobre este tópico nesta maravilhosa postagem no blog: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Para qualquer outra linguagem orientada a classe, eu diria que o colocaria no destruidor, mas como essa não é uma opção, acho que você pode substituir o método finalize. Dessa forma, quando a instância sair do escopo e for coletada como lixo, ela será liberada.

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

Não estou muito familiarizado com Java, mas acho que esse é o objetivo para o qual finalize () se destina.

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