views:

129

answers:

5

Right now I'm reading this article regarding Java Garbage Collection: http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html?

Here is a snippet of a function in a JMS client

public void foo(){
    ...//Create Connection factory, connection, and session, topic

    TopicSubscriber tp = session.createDurableSubcriber(topic,"001");
    tp.setMessageListener(this)
}

This question isn't about JMS but more what happens with the object "tp" after foo() function call has ended. After the function ends there is no way to reference tp anymore. I'm assuming in createDurableSubscriber() that it's using the keyword "new" which means that the object is being placed on the JVM heap. However since tp can no longer be referenced is it subject to the JVM garbage collection?

+1  A: 

Possibly. It might still be referenced through some chain of pointers starting at a static variable somewhere.

Darron
+1  A: 

It could be referenced in your session as a field or passed anywhere else depending on the JMS implementation. JMS is only an API, you simply can't suppose anything about the implementation, and you can't suppose that tp isn't referenced anymore.

But to answer the question, if you "suppose" anyway that it isn't referenced, yes the GC would take care of it.

Colin Hebert
+1  A: 

An object will only be collected if no running code has a reference to it (excluding weak references, which few people generally mess with anyway -- weak references don't count for determining collectibility.).

In your example, if you assume that create... actually creates a new object, and doesn't store a reference to it for some reason, and that attaching a listener to said object doesn't require creating a link back to the observable, then yes -- tp will probably be eligible for finalization and collection.

If any of those assumptions are wrong, though, all bets are off.

cHao
+2  A: 

You need to look in the source code for session.createDurableSubcriber() to see if it doesn't store the value it will return to you somewhere.

Remember you are basically getting a pointer (called reference in Java) to the object, not the object itself, and that pointer can be stored numerous places even if you only have a single object. All these pointer references must be done with before the object can be reclaimed by the garbage collector.

Thorbjørn Ravn Andersen
So I guess there is no way to know for sure unless you look at the source code of the API your using...
Albinoswordfish
Exactly, or else if you trust the API developer.
Ashish Patil
Or trust the API. If *you're* done using something, *you* can forget about it (just lose your reference). When the rest of the app does the same, the object is garbage. If you care about being able to do something with `tp` later, keep it. Otherwise, let the API and the GC care about what to do with it. They're usually pretty good about doing that stuff right.
cHao
A big reason I ask this because I saw this code in a tutorial, so if the API doesn't remove the reference, how is the developer supposed to know how to get rid of the reference once he is done with it?
Albinoswordfish
You just drop all references to an object when you do not need it anymore. The JVM will keep global count so you don't have to worry.
Thorbjørn Ravn Andersen
Well in the example "tp" is the only reference I have to the TopicSubcriber that gets created. However after the function call ends I've lost that reference. However the API might've created a reference to that object but I have no idea how to release it.
Albinoswordfish
Basically you should not worry about that. The important thing is that _you_ forget all references you do not need anymore (as opposed to saving it in a global array list etc).
Thorbjørn Ravn Andersen
+1  A: 

It is important to distinguish between objects and variables (which holds references to objects). An object becomes eligible for garbage collection when there are no more references to it.

In you particular case, createDurableSubscriber will have kept a copy of the reference it returned, thereby preventing the object from being collected. (After all, it needs to invoke methods on that object when a new message arrives, which is hard to do without a reference),

meriton