Highlander objects?

[Jan Groth]

Hi there,

hope then someone can explain the following behaviour to me:

in best Connor MacLeod - manner, I have a object which simly tries to live forever. And I really want it to die ;-)

This is the situation:

I have a class named "Data". It has a couple of private static references, one of which is a object called "DataFile" (Yes, it's the B&S assignment ;-). In the constructor of Data I'm checking whether _DataFile is still a null reference. If so, I creating a instance of DataFile and assign it. If not, I skip this part. The reason of this is that DataFile encapsulates some file i/o stuff for reading and writing to a single data file.
I also have a static counter, which I increment each time the constructor is called. As a primitive int, it's initialized with zero.

This is the behaviour:

I have a testsuite (jUnit). In the setUp() method, I create a Data object.

Data data = new Data();

From the logging I see the instance count being 1 after the constructor finished.

In any test method textXy() (way behind the scope setUp()), I create new Data objects

Data data = new Data();

From the logging I see the instance count being 2,3,4,... after the constructors finished!!!

I added a method shutDown() to Data, explicitely nulling all class members. Even the static Logger. Called it at the end of each scope. Same result like above.

I have two questions:

- why does this happen?
- how can I ensure my Data objects to be dead and gone?

Thanks and greetings from cold Berlin,
Jan.

[Logan Owen]

I am not entirely sure, but it could be (being I/O and all), that your streams are keeping the object alive. You are closing the streams, right? Also, you could have the shutDown() method write something to your System.out as its last task to make sure it is getting called, etc.

LoDown

[Jan Groth]

well, shutDown() is getting called, I did add logging output. Within this method I definitly executed _dataFile = null;

Furthermore the stream is getting closed...

I'd like to raise the more general question why an object could possibly stay alive beyond it's scope.

I assume the solution has to do something with it's static references. Can we say that a object with static references to existing (live) objects does not get garbage collected until those references are dead?

But all my classes have a static reference to a live Logger. How can this be explained?

[Layne Lund]

I'm not sure that I completely understand your question. Are you asking about the Data objects or the static DataFile object? Every time your setUp() method is called, a new Data object is created and the old one is "forgotten" and thus eligible for garbage collection. However, the DataFile object is not eligible for garbage collection until you explicitly set the static reference to null.

You don't need to null out non-static class members since they don't have anything to do with garbage collecting the enclosing object. Maybe I can illustrate with an example:

class A {
  private B b = new B();
  private static B staticB = new B();
}
 
class B {
}

Say you also have a piece of code that uses class A:

A a = new A();
a = null;

As soon as a is set to null, the object it referenced is eligible for garbage collection. The object referenced by b is also indirectly eligible for garbage colleciton since there is no way for the software to access it. However, the object referenced by staticB is NOT eligible for garbage collection since the reference is static.

I hope this captures the essential parts of your current situation, and I hope it answers your questions as well. However, if I'm completely off, please let me know. It would probably help if you post some larger pieces of code to illustrate what you are doing.

Keep Coding!

Layne

[Layne Lund]

Originally posted by Jan Groth:
I assume the solution has to do something with it's static references. Can we say that a object with static references to existing (live) objects does not get garbage collected until those references are dead?

But all my classes have a static reference to a live Logger. How can this be explained?

Perhaps this is a summary of what I said above, but I just re-read this message and see a problem with your statement above. Objects do not contain static references (at least at a conceptual level, obviously there has to be some mechanism to get them). Static members are associated with the class as a whole. That's the point!

So in short, static member references in an object's class do not affect that object's elgibility for garbage collection.

HTH

Layne

[Dirk Schreckmann]

Jan, how about some more complete relevant code?