Question

I have some objects that are created/destroyed very often and that can exist in many lists at the same time. To ensure I have no references left to them the objects have a flag isDestroyed, and if this is set, each list is responsible for removing the object from the list.

However this is ofcourse a growing ground for memory leaks. What if I forget to remove objects from one of the lists? To visually monitor that the program behaves correctly, I override finalize and increase a global variable to track destructions (not a formal test, only to get an idea). However as I have no control over the GC, I could in theory wait forever until something is destroyed.

So the question is two-fold: When having objects that are in multiple lists, is a “isDestroyed” considered a good way to control the object lifetime? It forces everyone who uses the object to take care to remove it from their lists, which seems bad.

And, is there any good way to see when the reference count reaches zero on an object, ie when its scheduled for destruction?

EDIT: To be more specific, in my case I my objects represent physical entities in a room. And I have one manager class that draws each object, therefore it is in one list. Another list contains all the objects that are clickable, so there I have another list. Having all objects in one list and using polymorphism or instance of is not an option in this case. When a object is “destroyed”, it should neither be shown or clickable in any way, therefore I want to remove it from both lists.

Answer 1

You should have a look at the java.lang.ref Package.

And, is there any good way to see when the reference count reaches
zero on an object, ie when its scheduled for destruction?

You can use the ReferenceQueue Object

From JavaDoc of java.lang.ref.ReferenceQueue

Reference queues, to which registered reference objects are appended
by the garbage collector after the appropriate reachability changes
are detected.