我正在尝试将WeakHashMap用作弱引用的并发Set。
this.subscribers =
Collections.synchronizedSet(
Collections.newSetFromMap(
new WeakHashMap <>()
)
);
当一个元素进入垃圾收集时，我的集合继续将其报告为收集的一部分。因此，地图似乎正在不断增长。
文档说：
钥匙遗失后，其条目会从地图上有效删除，……
但是实际上似乎并非如此。
WeakHashMap是否曾经清除碎屑？
答案 0 :(得分：2)
是的，WeakHashMap确实清除了碎屑。用于垃圾回收的密钥不再按大小报告。但是您必须等待垃圾收集真正发生。
对于您的对象进行垃圾回收，您似乎不正确。也许您的对象成为了候选对象以进行垃圾收集，但尚未被收集。尝试调用垃圾收集器，然后等待它完成。但是请记住，对System.gc()的调用只是对JVM的建议，根据您的JVM实现和当前的运行时情况，可能会忽略它。
这是一个完整的示例应用程序。请注意，无论是调用Set还是让对象超出范围，size都报告Set::remove减少。
package com.basilbourque.example;
import java.util.Collections;
import java.util.Set;
import java.util.UUID;
import java.util.WeakHashMap;
public class WeakHashMapExercise {
public static void main ( String[] args ) {
WeakHashMapExercise app = new WeakHashMapExercise();
app.doIt();
}
private void doIt ( ) {
Set < UUID > set =
Collections.synchronizedSet(
Collections.newSetFromMap(
new WeakHashMap <>()
)
);
UUID uuid1 = UUID.fromString( "a8ee1e34-cead-11e8-a8d5-f2801f1b9fd1" );
UUID uuid2 = UUID.fromString( "39bda2b4-5885-4f56-a900-411a49beebac" );
UUID uuid3 = UUID.fromString( "0b630385-0452-4b96-9238-20cdce37cf55" );
UUID uuid4 = UUID.fromString( "98d2bacf-3f7f-4ea0-9c17-c91f6702322c" );
System.out.println( "Size before adding: " + set.size() );
set.add( uuid1 );
set.add( uuid2 );
set.add( uuid3 );
set.add( uuid4 );
System.out.println( "Size after adding 4 items: " + set.size() ); // Expect 4.
set.remove( uuid3 );
System.out.println( "Size after removing item # 3: " + set.size() ); // Expect 3.
uuid2 = null; // Release that UUID to garbage-collection.
// That released object may still appear in our `Set` until garbage collection actually executes.
System.gc(); // Ask the JVM to run the garbage-collection. Only a suggestion, may be ignored.
try {
Thread.sleep( 1_000 ); // Wait a moment, just for the heck of it.
} catch ( InterruptedException e ) {
e.printStackTrace();
}
System.out.println( "Size after making garbage of item # 2: " + set.size() ); // Expect 2.
for ( UUID uuid : set ) {
System.out.println( uuid.toString() );
}
}
}
请参阅此code run live at IdeOne.com。
添加前的大小：0
添加4个项目后的大小：4
删除项目3：3后的尺寸
丢弃项目2：2后的尺寸
就我而言，使用Java 10.0.2中基于OpenJDK的Zulu JVM的Azul Systems版本，垃圾收集器似乎确实是在我的请求下激活的。如果我将延迟推迟一秒钟或致电System.gc进行注释，则报告的最后一个大小将保持3而不是预期的2。
您甚至可以在running this code live at IdeOne.com时看到此行为。请注意，下面的最后一项是3但上面的是2。
添加前的大小：0
添加4个项目后的大小：4
删除项目3：3后的尺寸
丢弃项目2：3后的尺寸
答案 1 :(得分：2)
garbage-collection清除weak reference时，它将“事件”发布到参考队列。该过程为asynchronous，即使GC已“清除”您的密钥，WeakHashMap仍具有对该值的强烈引用。实际清理发生在以下情况：
WeakHashMap上调用其他任何方法-将会进行所需的清理。这里是显示正在发生的事情的示例。
public class WeakHashMapInAction {
public static void main(String[] args) {
Key key = new Key();
KeyMetadata keyMeta = new KeyMetadata("keyMeta");
WeakHashMap<Key, KeyMetadata> map = new WeakHashMap<>();
map.put(key, keyMeta);
// wrap the key into a weakReference
WeakReference<Key> keyReference = new WeakReference<>(key);
// force key to be GC-ed
key = null;
for (; keyReference.get() != null; ) {
System.gc();
}
// at this point keyReference::get returns null,
// meaning the GC has reclaimed "key";
// that does NOT mean WeakHashMap removed that entry though
// you can enable this code to see that "not yet collected" is not printed at all
// since you are giving enough time for the Reference thread to post to that ReferenceQueue
// LockSupport.parkNanos(10000000);
while (map.size() == 1) {
// if you run this enough times, you will see this sometimes is printed
// even if WeakHashMap::size calls "expungeStaleEntries" internally
// it does not mean that the event to the queue was pushed in time
// by the Reference thread
System.out.println("not yet collected");
}
System.out.println("collected");
}
static class Key {
}
@RequiredArgsConstructor
@Getter
static class KeyMetadata {
private final String someInfo;
// Constructor.
KeyMetadata ( String someInfo ) { this.someInfo = someInfo; }
}
}