Java 7のライブラリには、他のクラスにサービスを提供するクラスがあります。このサービスクラスのインスタンスを作成した後、その1つのメソッドを複数回呼び出すことができます（doWork()メソッドと呼びましょう）。したがって、サービスクラスの作業がいつ完了するかはわかりません。

問題は、サービスクラスが重いオブジェクトを使用し、それらを解放する必要があることです。この部分をメソッドに設定します（呼び出しましょうrelease()）が、他の開発者がこのメソッドを使用することは保証されません。

サービスクラスのタスクを完了した後、他の開発者にこのメソッドを強制的に呼び出す方法はありますか？もちろんそれを文書化することはできますが、私はそれらを強制したいと思います。

注：release()メソッドでメソッドを呼び出すことはできません 。これは、次に呼び出されるときにこれらのオブジェクトが必要doWork()になるためdoWork()です。

実用的な解決策は、クラスを作成し、バックストップとしてメソッドをAutoCloseable提供するfinalize()ことです（適切な場合は、以下を参照してください！）。次に、クラスのユーザーがtry-with-resourceを使用するか、close()明示的に呼び出すようにします。

もちろんそれを文書化することはできますが、私はそれらを強制したいと思います。

残念ながら、Javaにはプログラマに正しいことを強制する方法¹はありません。期待できる最善の方法は、静的コードアナライザーで誤った使用法を見つけることです。

ファイナライザーのトピックについて。このJava機能には、適切なユースケースはほとんどありません。ファイナライザを使用して片付けを行うと、片付けが完了するまでに非常に長い時間がかかるという問題が発生します。ファイナライザは、オブジェクトが到達不能であるとGCが判断した後にのみ実行されます。JVMが完全なコレクションを実行するまで、それは起こらないかもしれません。

したがって、解決しようとしている問題が、早期にリリースする必要があるリソースを回収することである場合、ファイナライズを使用してボートを見逃しています。

そして、私が上で言っていることを理解していない場合に備えて... 本番コードでファイナライザを使用することはほとんど適切ではなく、それらに頼るべきではありません！

^{1-方法があります。ユーザーコードからサービスオブジェクトを「非表示」にするか、ライフサイクルを厳密に制御する準備ができている場合（例：https : //softwareengineering.stackexchange.com/a/345100/172）、ユーザーコードを呼び出す必要はありませんrelease()。ただし、APIはより複雑になり、制限され、...および「ugい」IMOになります。また、これはプログラマーに正しいことを強いることではありません。プログラマーが間違ったことをする能力を取り除いています！}

これは、AutoCloseableインターフェースのユースケースとJava 7で導入されたtry-with-resourcesステートメントのようです。

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呼び出しに引数を挿入するなど、必要に応じて肉付けする必要があります。
• コメントで述べたように、このような構成体（つまり、 Service）が呼び出し側の手にある、この回答の範囲外です。ただし、これが絶対に必要だと判断した場合は、これを行うことができます。
• 1人のコメント提供者が例外処理に関する次の情報を提供しました：Googleブックス

コマンドパターンを使用してみてください。

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（）」メソッドを使用して、プライベートコマンドリストにコマンドを追加するだけで済みます。次に、実際に作業を行い、「release（）」を呼び出す「commit（）」メソッドを用意します。

したがって、ユーザーが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（）