WeakHashMap 在完整 GC 期间是否被清除？

Question

我在使用 Wea​​kHashMap 时遇到了一些麻烦。

考虑这个示例代码：

List<byte[]> list = new ArrayList<byte[]>();

Map<String, Calendar> map = new WeakHashMap<String, Calendar>();
String anObject = new String("string 1");
String anOtherObject = new String("string 2");

map.put(anObject, Calendar.getInstance());
map.put(anOtherObject, Calendar.getInstance());
// In order to test if the weakHashMap works, i remove the StrongReference in this object
anObject = null;
int i = 0;
while (map.size() == 2) {
   byte[] tab = new byte[10000];
   System.out.println("iteration " + i++ + "map size :" + map.size());
   list.add(tab);
}
System.out.println("Map size " + map.size());

此代码有效。在循环内部，我正在创建对象。当发生较小的 GC 时，第 1360 次迭代时映射大小等于 1。一切都好。

现在，当我评论这一行时：

//anObject = null; 

我预计会出现 OutOfMemoryError，因为 mapSize 始终等于 2。但是在第 26XXX 次迭代时，发生完整 GC，并且映射大小等于 0。我不明白为什么？

我认为地图不应该被清除，因为也有对这两个对象的强引用。

Answer 1

即时编译器分析代码，发现循环后没有使用 anObject 和 anOtherObject ，并将它们从局部变量表中删除或将它们设置为 < code>null，而循环仍在运行。这称为 OSR 编译。

随后 GC 会收集这些字符串，因为不再保留对它们的强引用。

如果您在循环后使用 anObject，您仍然会收到 OutOfMemoryError。

更新：您将找到有关的更详细讨论OSR 编译 在我的博客中。

Answer 2

深入挖掘后发现，JLS 第 12.6.1 节明确涵盖了这一点：

可以设计优化程序的转换，将可到达的对象数量减少到比天真地认为可到达的对象数量少。例如，编译器或代码生成器可能会选择将不再使用的变量或参数设置为 null，以使此类对象的存储空间可以更快地回收。

（粗体是我添加的内容） .)

http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.6.1

因此，本质上，JIT 可以在任何时候删除强引用它希望是否能够解决它们将不再被使用的问题——这正是这里发生的情况。

这是一个很好的问题，并且是一个很好的谜题，可以很容易地表明，仅仅因为一个对象似乎在范围内具有强引用，并不一定意味着它没有被垃圾收集。接下来，这意味着您明确无法保证终结器何时运行，甚至可能是在对象似乎仍在范围内的情况下！

例如：

List<byte[]> list = new ArrayList<byte[]>();

Object thing = new Object() {
    protected void finalize() {
        System.out.println("here");
    }
};
WeakReference<Object> ref = new WeakReference<Object>(thing);

while(ref.get()!=null) {
    list.add(new byte[10000]);
}
System.out.println("bam");

上面是一个更简单的示例，显示对象首先被最终确定并被 GC 处理，即使对 thing 的引用仍然存在（这里被打印，然后是 bam。）

Answer 3

只是为 Joni Salonen 和 berry120 的出色答案添加一点内容。可以看出，JIT 实际上负责“变量删除”，只需使用 -Djava.compiler=NONE 将其关闭即可。一旦你把它关掉，你就会得到 OOME。

如果我们想知道幕后发生了什么，选项 XX:+PrintCompilation 会显示 JIT 活动。将其与问题中的代码一起使用，我们得到的输出如下：

1       java.lang.String::hashCode (64 bytes)
2       java.lang.String::charAt (33 bytes)
3       java.lang.String::indexOf (151 bytes)
4       java.util.ArrayList::add (29 bytes)
5       java.util.ArrayList::ensureCapacity (58 bytes)
6  !    java.lang.ref.ReferenceQueue::poll (28 bytes)
7       java.util.WeakHashMap::expungeStaleEntries (125 bytes)
8       java.util.WeakHashMap::size (18 bytes)
1%      WeakHM::main @ 63 (126 bytes)
Map size 0

最后一个编译（带有 @ 标志）是 OSR（堆栈替换）编译（检查 https://gist.github.com/rednaxelafx/1165804#osr 了解更多详情）。简而言之，它使VM能够在运行时替换方法，并用于提高陷入循环的Java方法的性能。我猜测触发此编译后，JIT 会删除不再使用的变量。