I haven't found a simple answer for these two questions:
do I have to remove a listener before deleting the property instance (the listener is not used anywhere else)?
BooleanProperty bool = new SimpleBooleanProperty(); bool.addListener(myListener); bool.removeListener(myListener); // is it necessary to do this? bool = null;
do I have to unbind a uni-directional bounded property before deleting the property instance?
BooleanProperty bool = new SimpleBooleanProperty(); bool.bind(otherBool); bool.unbind(); // is it necessary to do this? bool = null;
Case 1
Given that
myListener
"is not used anywhere else" and therefore I assume, a [method-] local variable, the answer is no. In the general case though, the answer is mostly a no but can sometimes be a yes.As long as
myListener
is strongly reachable, then it will never become eligible for finalization and it will continue to consume memory. For example, this would be the case ifmyListener
is a "normally" declaredstatic
variable (*all "normal" references in Java are strong references*). However, ifmyListener
is a local variable, then the object will not be reachable anymore after the return of the current method call andbool.removeListener(myListener)
is a bit meaningless over-engineering. Both the observer and theObservable
goes out of scope and will eventually be finalized. A quote from my own blog post about this answer might paint a better picture:Theory
To fully understand the situation here, we have to remind ourselves of the life-cycle of a Java object (source):
In the case of static variables, these will always be accessible as long as the class is loaded, thus reachable. If we didn't want a static reference to be the one that hinder the garbage collector to do his job, then we could declare the variable to use a
WeakReference
instead. JavaDoc says:Explicit management
For illustration, let's assume that we write a JavaFX space simulation game. Whenever an
Observable
planet moves into the view of a spaceship observer, the game engine register the spaceship with the planet. It is quite apparent that whenever the planet goes out of view, the game engine should also remove the spaceship as an observer of the planet by usingObservable.removeListener()
. Otherwise, as the spaceship continues to fly through space, memory will leak. Eventually, the game cannot handle five billion observed planets and it will crash with anOutOfMemoryError
.Do note that for the vast majority of JavaFX listeners and event handlers, their life-cycle is parallel to that of their
Observable
so the application developer has nothing to worry about. For example, we might construct aTextField
and register with the text field'stextProperty
a listener that validate user input. As long as the text field sticks around, we want the listener to stick around. Sooner or later, the text field is not used anymore and when he is garbage collected, the validation listener is also garbage collected.Automatic management
To continue on the space simulation example, assume that our game has limited multiplayer support and all the players need to observe each other. Perhaps each player keep a local score board of kill metrics or perhaps they need to observe broadcasted chat messages. The reason is not the important point here. What would happen when a player quit the game? Clearly, if the listeners are not explicitly managed (removed), then the player who quit will not become eligible for finalization. The other player's will keep a strong reference to the offline player. Explicit removal of the listeners would still be a valid option and probably the most preferred choice for our game, but let's say that it feels a bit obtrusive and we want to find a more slick solution.
We know that the game engine keep strong references to all players online, for as long as they are online. So we want the spaceships to listen for changes or events of each other only for as long as the game engine keep the strong references. If you read the "theory" section, then surely a
WeakReference
sounds like a solution.However, just wrapping something in a WeakReference is not the entire solution. It seldom is. It is true that when the last strong reference to the "referent" is set to
null
or otherwise become unreachable, the referent will be eligible for garbage collection (assuming that the referent cannot be reached using aSoftReference
). But the WeakReference is still hanging around. The application developer need to add some plumbing so that the WeakReference itself is removed from the data structure he was put in. If not, then we might have reduced the severity of the memory leak but a memory leak will still be present because dynamically added weak references consume memory too.Lucky for us, JavaFX added interface
WeakListener
and classWeakEventHandler
as a mechanism for "automatic removal". The constructors of all related classes accept the real listener/handler as provided by client code, but they store the listener/handler using a weak reference.If you look at the JavaDoc of
WeakEventHandler
, you'll notice that the class implementEventHandler
, so the WeakEventHandler can be used wherever an EventHandler is expected. Likewise, a known implementation of aWeakListener
can be used wherever anInvalidationListener
or aChangeListener
is expected.If you look into the source code of
WeakEventHandler
, you'll notice that the class is basically only a wrapper. When his referent (the real event handler) is garbage collected, theWeakEventHandler
"stop working" by not doing anything at all whenWeakEventHandler.handle()
is called. TheWeakEventHandler
doesn't know about which object he has been hooked up with, and even if he did, the removal of an event handler is not homogeneous. All known implementing classes ofWeakListener
has a competitive advantage though. When their callbacks are invoked, they are implicitly or explicitly provided a reference to theObservable
they are registered with. So when the referent of aWeakListener
is garbage collected, eventually theWeakListener
implementation will make sure that theWeakListener
itself is removed from theObservable
.If it is isn't already clear, the solution for our space simulation game would be to let the game engine use strong references to all online spaceships. When a spaceship goes online, all other online spaceships are registered with the new player using a weak listener such as
WeakInvalidationListener
. When a player goes offline, the game engine remove his strong reference to the player and the player will become eligible for garbage collection. The game engine doesn't have to bother about explicit removal of the offline player as a listener of the other players.Case 2
No. To better understand what I'll say next, please read my case 1 answer first.
BooleanPropertyBase
store a strong reference tootherBool
. This in itself does not causeotherBool
to always be reachable and thus potentially cause a memory leak. Whenbool
becomes unreachable, then so do all its stored references (assuming they are not stored anywhere else).BooleanPropertyBase
also works by adding itself as anObserver
of the property you bind it to. However, it does so by wrapping itself in a class that works almost exactly like theWeakListener
s described in my case 1 answer. So once you nullifybool
, it will be only a matter of time before it is removed fromotherBool
.I completely agree with the case 1 answer, but the case 2 is a bit more tricky.
The bool.unbind()
call is necessary. If ommitted, it does cause a small memory leak.If you run the following loop, the application will eventually run out of memory.
The BooleanPropertyBase, intenally, does not use a real WeakListener (an implementation of the WeakListener interface), it is using a half-baked solution. All the "p2" instances get eventually garbage-collected, but a listener holding an empty WeakReference remains in the memory forever for each "p2". The same holds for all properties, not only BooleanPropertyBase. It's explained here in detail, and they say it is fixed in Java 9.
In most cases, you do not notice this memory leak, because it leaves only a few dozen bytes for every binding that has not been unbound. But in some cases it caused me real trouble. An good example are table cells of a table that gets frequently updated. The cells then re-bind to different properties all the time, and these left-overs in the memory accumulate quickly.