private static Object bigObject;
public static void test(int size) {
long startTime = System.currentTimeMillis();
long numObjects = 0;
while (true) {
//bigObject = null; //explicit nulling
//SizableObject could simply be a large array, e.g. byte[]
//In the JavaGaming discussion it was a BufferedImage
bigObject = new SizableObject(size);
long endTime = System.currentTimeMillis();
++numObjects;
// We print stats for every two seconds
if (endTime - startTime >= 2000) {
System.out.println("Objects created per 2 seconds = " + numObjects);
startTime = endTime;
numObjects = 0;
}
}
}
这个例子有个简单的循环，创建一个大型对象并且将它赋给同一个变量，每隔两秒钟报告一次所创建的对象个数。现在的 Java 虚拟机采用 generational 垃圾收集机制，新的对象创建之后放在一个内存空间（取名 Eden）内，然后将那些在第一次垃圾收集以后仍然保留的对象转移到另外一个内存空间。在 Eden，即创建新对象时所在的新一代空间中，收集对象要比在“老一代”空间中快得多。但是如果 Eden 空间已经满了，没有空间可供分配，那么就必须把 Eden 中的对象转移到老一代空间中，腾出空间来给新创建的对象。如果没有显式地赋空变量，而且所创建的对象足够大，那么 Eden 就会填满，并且垃圾收集器就不能收集当前所引用的这个大型对象。所产生的后果是，这个大型对象被转移到“老一代空间”，并且要花更多的时间来收集它。
通过显式地赋空变量，Eden 就能在新对象创建之前获得自由空间，这样垃圾收集就会更快。实际上，在显式赋空的情况下，该循环在两秒钟内创建的对象个数是没有显式赋空时的5倍――但是仅当您选择创建的对象要足够大而可以填满 Eden 时才是如此, 在 Windows 环境、Java虚拟机 1.4 的默认配置下大概需要 500KB。那就是一行赋空操作产生的 5 倍的性能差距。但是请注意这个性能差别产生的原因是变量的作用域不正确，这正是赋空操作发挥作用的地方，并且是因为所创建的对象非常大。
最佳实践
这是一个有趣的例子，但是值得强调的是，最佳实践是正确地设置变量的作用域，而不要显式地赋空它们。虽然显式赋空变量一般应该没有影响，但总有一些反面的例子证明这样做会对性能产生巨大的负面影响。例如，迭代地或者递归地赋空集合内的元素使得这些集合中的对象能够满足垃圾收集的条件，实际上是增加了系统的开销而不是帮助垃圾收集。请记住这是个有意弄错作用域的例子，其实质是一个无意识的对象保留的例子。
