Java 7의 라이브러리에는 다른 클래스에 서비스를 제공하는 클래스가 있습니다. 이 서비스 클래스의 인스턴스를 생성 한 후 그 중 하나의 메소드를 여러 번 호출 할 수 있습니다 (메소드라고 부릅니다 doWork()). 그래서 서비스 클래스의 작업이 언제 완료되는지 모르겠습니다.

문제는 서비스 클래스가 무거운 객체를 사용하고 해제해야한다는 것입니다. 이 부분을 메소드로 설정 release()했지만 ( 호출하자 ) 다른 개발자가이 메소드를 사용한다고 보장하지는 않습니다.

서비스 클래스 작업을 완료 한 후 다른 개발자가이 메소드를 호출하도록 할 수있는 방법이 있습니까? 물론 나는 그것을 문서화 할 수는 있지만 강제로하고 싶습니다.

참고 : 다음에 호출 할 때 해당 객체가 필요 하기 때문에 release()메소드에서 메소드를 호출 할 수 없습니다 .doWork()doWork()

실용적인 솔루션은 클래스를 만들고 백스톱 AutoCloseable으로 finalize()메소드를 제공하는 것입니다 (적절한 경우 ... 아래 참조). 그런 다음 클래스의 사용자가 리소스를 사용 하거나 close()명시 적으로 호출하도록 합니다.

물론 나는 그것을 문서화 할 수는 있지만 강제로하고 싶습니다.

불행하게도, 방법이 없습니다 ⁽¹⁾ 옳은 일을하기 위해 프로그래머를 강제로 자바있다. 정적 코드 분석기에서 잘못된 사용법을 선택하는 것이 가장 좋습니다.

종료 자의 주제에 대해. 이 Java 기능에는 유용한 사용 사례 가 거의 없습니다 . 마무리 도구를 사용하여 정리하는 경우 정리 작업을 수행하는 데 시간이 오래 걸릴 수있는 문제가 발생합니다. 종료 자는 GC가 객체에 더 이상 도달 할 수 없다고 결정한 후에 만 실행 됩니다. JVM이 전체 콜렉션을 수행 할 때까지 발생하지 않을 수 있습니다 .

따라서 해결하려는 문제가 조기 에 해제해야하는 자원을 회수하는 것이라면 종료를 사용하여 보트를 놓친 것입니다.

그리고 내가 위에서 말한 것을 얻지 못한 경우를 대비하여 ... 프로덕션 코드에서 종료자를 사용 하는 것은 거의 적합 하지 않으며 절대로 의존 해서는 안됩니다 !

^{1-방법이 있습니다. 사용자 코드에서 서비스 객체를 "숨기거나"라이프 사이클을 엄격하게 제어 할 준비가 된 경우 (예 : https://softwareengineering.stackexchange.com/a/345100/172 ) 사용자 코드는 호출 할 필요 가 없습니다 release(). 그러나 API는 더욱 복잡하고 제한적이며 "못생긴"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()받아야한다면 그것은 효과가 있습니다.

그래 넌 할수있어

그것들을 절대로 강제로 해제하고 새 Service인스턴스 를 생성하는 것을 불가능하게함으로써 100 % 잊을 수 없게 만듭니다 .

그들이 전에 이와 같은 것을 한 경우 :

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)가 호출자의 손에 속 하는지 여부에 대한 질문 은이 답변의 범위를 벗어납니다. 그러나 이것이 절대적으로 필요하다고 결정하면 이것이 가능합니다.
• 한 의견 제안자가 예외 처리에 관한 다음 정보를 제공했습니다. 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);

다른 작업에 종속 된 작업에 대한 약속을 구현하여이 작업을 임의로 복잡하게 만들 수 있지만 배포하는 작업도 더 복잡해집니다. 이것은 시작일뿐입니다.

비동기

주석에서 지적했듯이 위의 내용은 실제로 비동기 요청에서는 작동하지 않습니다. 맞습니다. 그러나 이것은 CompleteableFuture를 사용하여 Java 8에서 쉽게 해결할 수 있습니다 . 특히 CompleteableFuture#supplyAsync개별 미래를 만들고 모든 작업이 완료 CompleteableFuture#allOf되면 리소스를 공개 합니다. 또는 Threads 또는 ExecutorServices를 사용하여 자신의 Futures / Promises 구현을 롤백 할 수도 있습니다.

가능하면 사용자가 자원을 작성하지 못하게하십시오. 사용자가 메소드에 방문자 오브젝트를 전달하면 자원이 작성되고이를 방문자 오브젝트의 메소드에 전달한 후 해제됩니다.

내 생각은 Polygnome과 비슷했습니다.

클래스에서 "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 ()