How many objects are eligible for garbage collector in this example

Question

public class Currency {
    String name = new String();
    static Integer value = new Integer();
    static void getCurrency(Integer v) {
        Currency c = new Currency();
        c.value = v;
    }
    public static void m() {
        Currency.getCurrency(50);
        Currency.getCurrency(100);
    }
    public static void main(String[] argv) {
        Currency.m();
    }
}

I count 5 elements eligible for garbage collector when m() exits. The exercise says 6 is the correct answer. Can you help me?

Answer 1

The two calls made to getCurrency() each will create two Currency objects in total. Each call requires:

• an Integer object as parameter, later assigned to value
• a Currency object
• a name string object (not static, i.e. each Currency object has one)

3 × 2 = 6

Update:

The big question seems to be as to whether a new Integer object will be created for each call to the Currency constructor. Autoboxing a primitive int into an Integer will call Integer.valueOf(). And the Javadoc has this to say about Integer.valueOf():

Returns an Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values. This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range.

So values in the range -128 to 127 get cached. But the catch is that in your code, you are working with two different values, 50 and 100, so caching won't avoid creation of a new Integer object AFAIK.

Answer 2

I disagree with the accepted answer. I believe your answer of five objects being eligible for garbage collection is actually correct, and the exercise you are working from is wrong (Although if anyone can explain how I'm mistaken, I'd greatly appreciate it).

Here are the objects that are referenced by your program:

1. Integer #0 - The Integer created by static Integer value = new Integer()*
2. Currency #1 - The Currency created by Currency.getCurrency(50).
3. Integer #1 - The Integer returned by the autoboxing of 50.
4. String #1 - The String created by String name = new String() in Currency #1's creation.
5. Currency #2 - The Currency created by Currency.getCurrency(100).
6. Integer #2 - The Integer returned by the autoboxing of 100.
7. String #2 - The String created by String name = new String() in Currency #2's creation.

*this doesn't actually compile, but I'll assume it's replaced by valid code which doesn't otherwise affect the program.

---

So seven objects are required for your code to function. The object initially referenced by value becomes eligible for garbage collection when value is overwritten with 50. The first and second Currencys are eligible at the end of m when their only references go out of scope. The first and second Strings are eligible at the end of m, when their only referencing objects, Currencys 1 and 2, go out of scope. The autoboxed Integer from 100 is clearly still referenced at the end by the static reference value, and so is not eligible for garbage collection. That's 5 objects eligible, 1 ineligible, and one not yet discussed.

The last object is the Integer returned by the autoboxing of 50. Your code obviously no longer references it, since value is set to reference 100 instead. This would seem to indicate that it's eligible for garbage collection, but I disagree. The Integer class is know to cache values at least in the range -128 to 127 in order to conform to JLS 5.1.7. So when m exits, the cache will still contain a reference to the boxed Integer from 50, causing it to be ineligible for garbage collection.

---

I attempted to test this behavior with this program:

public class Test{
    public static final WeakReference<Integer> inCache = new WeakReference<>(50);
    public static final WeakReference<Integer> outOfCache = new WeakReference<>(10000);
    public static void main(String[] args){
        System.gc();
        System.out.println(inCache.get());
        System.out.println(outOfCache.get());
    }
}

Which outputs

50
null

showing that, at least in this case, the uncached Integer was garbage collected and the cached one was not. This suggests that even with no explicit reference to 50, it is still ineligible for garbage collection because of the stored reference in the cache.

I'll admit that this doesn't prove anything since, for one, System.gc() does not guarantee that it will collect all (or any) available memory. However, I think this should show that the problem isn't as straightforward as one might assume and, on the most common JDK/JVMs, it's plausible that the sixth value is not eligible for garbage collection.

---

TL;DR - I don't think the Integer returned by boxing 50 is eligible for garbage collection, because it is still referenced by the cache maintained by the Integer class.