问题描述
I'm debugging a memory leak and had to dive into CompletableFuture internals. There is this piece of code (CompletableFuture.uniComposeStage):
CompletableFuture<V> g = f.apply(t).toCompletableFuture();
...
CompletableFuture<V> d = new CompletableFuture<V>();
UniRelay<V> copy = new UniRelay<V>(d, g);
g.push(copy);
copy.tryFire(SYNC);
return d;
The code itself is quite clear to me: apply a function that returns CompletionStage (g
), create a relay that eventually will transfer value to another CompletableFuture (d
), then return this another future (d
). I see following reference situation:
copy
references bothd
andg
(and there is no magic in constructor, only field assignments)g
referencescopy
d
references nothing
Only d
is returned, so, in fact, both g
and copy
seem as internal method variables to me, that (on first sight) should never leave the method and be eventually gc'd. Both naive testing and the fact that it was written long ago by proven developers suggests me that i'm wrong and missing something. What is the reason that make those objects being omitted from garbage collection?
In the cited code, there is nothing preventing garbage collection of these futures and there is no need to. This code in question applies to the scenario that the first CompletableFuture
(the this
instance) has been completed and the CompletableFuture
returned by the directly evaluated compose function has not completed yet.
Now, there are two possible scenarios
There is an ongoing completion attempt. Then, the code which will eventually complete the future will hold a reference to it and when completing, it will trigger the completion of the dependent stages (registered via
g.push(copy)
). In this scenario, there is no need for the dependent stage to hold a reference to its prerequisite stage.This is a general pattern. If there is a chain
x --will complete-→ y
, there will be no reference fromy
tox
.There is no other reference to that
CompletableFuture
instanceg
andg
has not been completed yet. In this case, it will never be completed at all and holding a reference tog
internally wouldn’t change that. That would only waste resources.
The following example program will illustrate this:
public static void main(String[] args) throws Throwable {
ReferenceQueue<Object> discovered = new ReferenceQueue<>();
Set<WeakReference<?>> holder = new HashSet<>();
CompletableFuture<Object> initial = CompletableFuture.completedFuture("somevalue");
CompletableFuture<Object> finalStage = initial.thenCompose(value -> {
CompletableFuture<Object> lost = new CompletableFuture<>();
holder.add(new WeakReference<>(lost, discovered));
return lost;
});
waitFor(finalStage, holder, discovered);
finalStage = initial.thenCompose(value -> {
CompletableFuture<Object> saved = CompletableFuture.supplyAsync(()-> {
LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1));
return "newvalue";
});
holder.add(new WeakReference<>(saved, discovered));
return saved;
});
waitFor(finalStage, holder, discovered);
}
private static void waitFor(CompletableFuture<Object> f, Set<WeakReference<?>> holder,
ReferenceQueue<Object> discovered) throws InterruptedException {
while(!f.isDone() && !holder.isEmpty()) {
System.gc();
Reference<?> removed = discovered.remove(100);
if(removed != null) {
holder.remove(removed);
System.out.println("future has been garbage collected");
}
}
if(f.isDone()) {
System.out.println("stage completed with "+f.join());
holder.clear();
}
}
The first function passed to thenCompose
creates and returns a new uncompleted CompletableFuture
without any attempt to complete it, not holding nor storing any other reference to it. In contrast, the second function creates the CompletableFuture
via supplyAsync
providing a Supplier
which will return a value after a second.
On my system, it consistently printed
future has been garbage collected
stage completed with newvalue
showing that the abandoned future will not be prevented from garbage collection while the other will be held at least until completion.
这篇关于垃圾收集中的非直观对象驱逐的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!