이 기사의 코드는 GitHub에서 찾을 수 있습니다.
예제를 보기 전에 내부적으로 어떻게 작동하는지 이해하고 싶은 프로그래머라면
소개 후 현장 뒤편의 클리너로 바로 이동할 수 있습니다.
외부 리소스(파일, 소켓 등)에 대한 참조를 보유하는 개체가 있는 시나리오를 생각해 보세요. 그리고 보유 객체가 더 이상 활성/액세스 가능하지 않을 때 이러한 리소스가 해제되는 방법을 제어하고 싶습니다. Java에서 이를 어떻게 달성합니까? Java 9 이전에는 프로그래머가 객체 클래스 finalize() 메서드를 재정의하여 종료자를 사용할 수 있었습니다. Finalizer에는 느리고, 신뢰할 수 없으며, 위험한 등 많은 단점이 있습니다. JDK를 구현하는 사람이나 사용하는 사람 모두가 싫어하는 기능 중 하나입니다.
Java 9부터 Finalizer는 더 이상 사용되지 않으며 프로그래머는 Cleaners에서 이를 달성할 수 있는 더 나은 옵션을 갖게 되었으며 Cleaners는 정리/마무리 작업을 관리하고 처리하는 더 나은 방법을 제공합니다. 클리너는 리소스 보유 개체가 자신과 해당 정리 작업을 등록하도록 하는 패턴으로 작동합니다. 그런 다음 애플리케이션 코드에서 해당 객체에 액세스할 수 없으면 Cleaners가 정리 작업을 호출합니다.
이것은 Cleaner가 Finalizer보다 나은 이유를 설명하는 기사는 아니지만 몇 가지 차이점을 간략하게 나열하겠습니다.
파이널라이저 대 클리너
| Finalizers | Cleaners |
|---|---|
| Finalizers are invoked by one of Garbage Collector’s threads, you as a programmer don’t have control over what thread will invoke your finalizing logic | Unlike with finalizers, with Cleaners, programmers can opt to have control over the thread that invokes the cleaning logic. |
| Finalizing logic is invoked when the object is actually being collected by GC | Cleaning logic is invoked when the object becomes Phantom Reachable, that is our application has no means to access it anymore |
| Finalizing logic is part of the object holding the resources | Cleaning logic and its state are encapsulated in a separate object. |
| No registration/deregistration mechanism | Provides means for registering cleaning actions and explicit invocation/deregistration |
충분한 잡담을 통해 청소부들의 활약을 지켜보세요.
ResourceHolder
import java.lang.ref.Cleaner;
public class ResourceHolder {
private static final Cleaner CLEANER = Cleaner.create();
public ResourceHolder() {
CLEANER.register(this, () -> System.out.println("I'm doing some clean up"));
}
public static void main(String... args) {
ResourceHolder resourceHolder = new ResourceHolder();
resourceHolder = null;
System.gc();
}}
몇 줄의 코드지만 여기서는 많은 일이 일어나고 있습니다. 분석해 보겠습니다
애플리케이션을 실행하면 표준 출력 어딘가를 정리하고 있다는 것을 알 수 있기를 바랍니다.
? 주의
클리너를 사용하는 가장 간단한 방법부터 시작하여 단순화된 방식으로 사용법을 보여드릴 수 있습니다. 하지만 이는 클리너를 사용하는 효과적인 방법도 올바른 방법도 아니라는 점을 명심하세요
첫 번째 예는 Cleaners가 실제로 작동하는 모습을 볼 수 있을 만큼 훌륭했습니다.
하지만 경고했듯이 실제 애플리케이션에서 Cleaner를 사용하는 올바른 방법은 아닙니다.
우리가 한 일에 어떤 문제가 있는지 살펴보겠습니다.
ResourceHolder의 클래스 멤버로 Cleaner 객체를 시작했습니다. 앞서 언급했듯이 Cleaner는 클래스 간에 공유되어야 하며 개별 클래스에 속해서는 안 됩니다. 각 Cleaner 인스턴스가 존재하는 이유는 제한된 기본 리소스인 스레드를 유지 관리하기 때문입니다. , 네이티브 리소스를 소비할 때는 주의해야 합니다.
실제 애플리케이션에서는 일반적으로
와 같은 싱글톤 클래스나 유틸리티에서 Cleaner 객체를 얻습니다.
private static CLEANER = AppUtil.getCleaner();
청소 작업으로 람다를 전달했습니다. 청소 작업으로 람다를 절대 전달하면 안 됩니다.
그 이유를 이해하려면
인쇄된 메시지를 추출하여 이전 예제를 리팩터링하고 이를 인스턴스 변수로 만들어 보겠습니다
ResourceHolder
public class ResourceHolder {
private static final Cleaner CLEANER = Cleaner.create();
private final String cleaningMessage = "I'm doing some clean up";
public ResourceHolder() {
CLEANER.register(this, () -> System.out.println(cleaningMessage));
}
}
애플리케이션을 실행하고 어떤 일이 일어나는지 확인하세요.
무슨 일이 일어나는지 알려드릴게요
애플리케이션을 몇 번이나 실행하더라도 정리 작업은 호출되지 않습니다.
그 이유를 살펴보겠습니다
? 참고
첫 번째 예에서 청소 작업이 람다임에도 불구하고 어떻게 호출되는지 궁금하다면. 그 이유는 첫 번째 예의 람다는 어떤 인스턴스 변수에도 액세스하지 않으며 내부 클래스와 달리 Lambda는 강제로 수행하지 않는 한 포함 객체 참조를 암시적으로 유지하지 않기 때문입니다.
올바른 방법은 청소 작업을 필요한 상태와 함께 정적 중첩 클래스에 캡슐화하는 것입니다.
? 경고
내부 클래스 익명을 사용하지 마십시오. 내부 클래스 인스턴스는 인스턴스 변수에 액세스하는지 여부에 관계없이 외부 클래스 인스턴스에 대한 참조를 보유하므로 람다를 사용하는 것보다 더 나쁩니다.
We didn't make use of the return value from the Cleaner.create(): The create() actually returns something very important.a Cleanable object, this object has a clean() method that wraps your cleaning logic, you as a programmer can opt to do the cleanup yourself by invoking the clean() method. As mentioned earlier, another thing that makes Cleaners superior to Finalizers is that you can actually deregister your cleaning action. The clean() method actually deregisters your object first, and then it invokes your cleaning action, this way it guarantees the at-most once behavior.
Now let us improve each one of these points and revise our ResourceHolder class
ResourceHolder
import java.lang.ref.Cleaner;
public class ResourceHolder {
private final Cleaner.Cleanable cleanable;
private final ExternalResource externalResource;
public ResourceHolder(ExternalResource externalResource) {
cleanable = AppUtil.getCleaner().register(this, new CleaningAction(externalResource));
this.externalResource = externalResource;
}
// You can call this method whenever is the right time to release resource
public void releaseResource() {
cleanable.clean();
}
public void doSomethingWithResource() {
System.out.printf("Do something cool with the important resource: %s \n", this.externalResource);
}
static class CleaningAction implements Runnable {
private ExternalResource externalResource;
CleaningAction(ExternalResource externalResource) {
this.externalResource = externalResource;
}
@Override
public void run() {
// Cleaning up the important resources
System.out.println("Doing some cleaning logic here, releasing up very important resource");
externalResource = null;
}
}
public static void main(String... args) {
ResourceHolder resourceHolder = new ResourceHolder(new ExternalResource());
resourceHolder.doSomethingWithResource();
/*
After doing some important work, we can explicitly release
resources/invoke the cleaning action
*/
resourceHolder.releaseResource();
// What if we explicitly invoke the cleaning action twice?
resourceHolder.releaseResource();
}
}
ExternalResource is our hypothetical resource that we want to release when we’re done with it.
The cleaning action is now encapsulated in its own class, and we make use of the CleaniangAction object, we call it’s clean() method in the releaseResources() method to do the cleanup ourselves.
As stated earlier, Cleaners guarantee at most one invocation of the cleaning action, and since we call the clean() method explicitly the Cleaner will not invoke our cleaning action except in the case of a failure like an exception is thrown before the clean method is called, in this case the Cleaner will invoke our cleaning action when the ResourceHolder object becomes Phantom Reachable, that is we use the Cleaner as our safety-net, our backup plan when the first plan to clean our own mess doesn’t work.
❗ IMPORTANT
The behavior of Cleaners during System.exit is implementation-specific. With this in mind, programmers should always prefer to explicitly invoke the cleaning action over relying on the Cleaners themselves..
By now we’ve established the right way to use Cleaners is to explicitly call the cleaning action and rely on them as our backup plan.What if there’s a better way? Where we don’t explicitly call the cleaning action, and the Cleaner stays intact as our safety-net.
This can be achieved by having the ResourceHolder class implement the AutoCloseable interface and place the cleaning action call in the close() method, our ResourceHolder can now be used in a try-with-resources block. The revised ResourceHolder should look like below.
ResourceHolder
import java.lang.ref.Cleaner.Cleanable;
public class ResourceHolder implements AutoCloseable {
private final ExternalResource externalResource;
private final Cleaner.Cleanable cleanable;
public ResourceHolder(ExternalResource externalResource) {
this.externalResource = externalResource;
cleanable = AppUtil.getCleaner().register(this, new CleaningAction(externalResource));
}
public void doSomethingWithResource() {
System.out.printf("Do something cool with the important resource: %s \n", this.externalResource);
}
@Override
public void close() {
System.out.println("cleaning action invoked by the close method");
cleanable.clean();
}
static class CleaningAction implements Runnable {
private ExternalResource externalResource;
CleaningAction(ExternalResource externalResource) {
this.externalResource = externalResource;
}
@Override
public void run() {
// cleaning up the important resources
System.out.println("Doing some cleaning logic here, releasing up very important resources");
externalResource = null;
}
}
public static void main(String[] args) {
// This is an effective way to use cleaners with instances that hold crucial resources
try (ResourceHolder resourceHolder = new ResourceHolder(new ExternalResource(1))) {
resourceHolder.doSomethingWithResource();
System.out.println("Goodbye");
}
/*
In case the client code does not use the try-with-resource as expected,
the Cleaner will act as the safety-net
*/
ResourceHolder resourceHolder = new ResourceHolder(new ExternalResource(2));
resourceHolder.doSomethingWithResource();
resourceHolder = null;
System.gc(); // to facilitate the running of the cleaning action
}
}
? NOTE
To understand more and see how Cleaners work, checkout the OurCleaner class under the our_cleaner package that imitates the JDK real implementation of Cleaner. You can replace the real Cleaner and Cleanable with OurCleaner and OurCleanable respectively in all of our examples and play with it.
Let us first get a clearer picture of a few, already mentioned terms, phantom-reachable, PhantomReference and ReferenceQueue
Consider the following code
Object myObject = new Object();
In the Garbage Collector (GC) world the created instance of Object is said to be strongly-reachable, why? Because it is alive, and in-use i.e., Our application code has a reference to it that is stored in the myObject variable, assume we don’t set another variable and somewhere in our code this happens
myObject = null;
The instance is now said to be unreachable, and is eligible for reclamation by the GC.
Now let us tweak the code a bit
Object myObject = new Object(); PhantomReference<Object> reference = new PhantomReference<>(myObject, null);
Reference is a class provided by JDK to represent reachability of an object during JVM runtime, the object a Reference object is referring to is known as referent, PhantomReference is a type(also an extension) of Reference whose purpose will be explained below in conjunction with ReferenceQueue.
Ignore the second parameter of the constructor for now, and again assume somewhere in our code this happens again
myObject = null;
Now our object is not just unreachable it is phantom-reachable because no part of our application code can access it, AND it is a referent of a PhantomReference object.
After the GC has finalized a phantom-reachable object, the GC attaches its PhantomReference object(not the referent) to a special kind of queue called ReferenceQueue. Let us see how these two concepts work together
Object myObject = new Object(); ReferenceQueue<Object> queue = new ReferenceQueue<>(); PhantomReference<Object> reference1 = new PhantomReference<>(myObject, queue); myObject = null; PhantomReference<Object> reference2 = (PhantomReference)queue.remove()
We supply a ReferenceQueue when we create a PhantomReference object so the GC knows where to attach it when its referent has been finalized. The ReferenceQueue class provides two methods to poll the queue, remove(), this will block when the queue is empty until the queue has an element to return, and poll() this is non-blocking, when the queue is empty it will return null immediately.
With that explanation, the code above should be easy to understand, once myObject becomes phantom-reachable the GC will attach the PhantomReference object to queue and we get it by using the remove() method, that is to say reference1 and reference2 variables refer to the same object.
Now that these concepts are out of the way, let’s explain two Cleaner-specific types
From this point on understanding the internals of Cleaner should be straight forward.
Cleaner Life-Cycle Overview
Let us look at the life-cycle of a Cleaner object
The static Cleaner.create() method instantiates a new Cleaner but it also does a few other things
By adding itself into the list, the cleaner ensures that its thread runs at least until the cleaner itself becomes unreachable
For each Cleaner.register() call, the cleaner creates an instance of PhantomCleanable with the resource holder as the referent and the cleaning action will be wrapped in the clean() method, the object is then added to the aforementioned linked list.
The Cleaner’s thread will be polling the queue, and when a PhantomCleanable is returned by the queue, it will invoke its clean() method. Remember the clean() method only calls the cleaning action if it manages to remove the PhantomCleanable object from the linked list, if the PhantomCleanable object is not on the linked list it does nothing
The thread will continue to run as long as the linked list is not empty, this will only happen when
위 내용은 Java Cleaners: 외부 리소스를 관리하는 현대적인 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
