SoftReference and finalize()

I am maintaining a set of objects where there is a header object that stays persistantly in memory, and it contains a soft reference to a volatile object (by volatile, I simply mean it could be deallocated by the garbage collector). The volatile object contains a BufferedImage which is potentially quite large (and hence can be discarded when memory runs low). However, the BufferedImage can be modified, so if I need to discard it, I first want to write it's data to a temporary file.

Overriding the finalize() method of my volatile class seems to be the best place to cache the data. However, there seems to be no guarantee that finalize will actually be called. I'm also worried that in between the SoftReference being cleared and finalize() being called a state will exist where it will appear that the volatile object has been discarded. I might then attempt to recreate the object before its data has been written to the temporary file.

Is there a way I can be certain that the finalize() method for my softly referenced object is called before I attempt to recreate it? Can I force finalize() to be called as soon as the SoftReference is cleared?

[1177 byte] By [Mark_McKaya] at [2007-10-3 7:45:39]
# 1
You could use phantom references in addition to the soft references to tell when an object has been finalised.
YAT_Archivista at 2007-7-15 2:47:02 > top of Java-index,Core,Core APIs...
# 2

The finalize method WILL be called when your object is deallocated and garbage collected at runtime. However, there is no guarantee that gc will ever occur on your object. There is a method in java.lang.System or java.lang.Runtime (can't remember which) that forces the VM to call all finalize methods when the VM shuts down. The method is deprecated with good reason, but if you have limited inter-thread communication in your app, it may be safe for you to use.

Besides that, it sounds like you've got a pickle of a problem. You might want to set yourself up a timed cache. The way this would work is you have a thread running against your cache that checks the entries every so often to see how long ago they were last accessed. If the access time is older than a threshold you set, the cache entity goes from a strong reference to a soft reference and its data is written to the file. If your app attempts to access it again, the cache would check to see if the object has been gc'd and if not, it returns it and "renews" the reference, making it a strong reference again. Hope that helps.

Updownquarka at 2007-7-15 2:47:02 > top of Java-index,Core,Core APIs...
# 3
I don't know what everybody is worried about. If the object is GC'd its finalize() method will be executed. If it isn't GC'd there is nothing to do.
ejpa at 2007-7-15 2:47:02 > top of Java-index,Core,Core APIs...
# 4

I think OP's architecture is such that he fears that in the window between the soft references being cleared and the object being GC'd he has an inconsistent state. (Yes, that does sound like a dodgy architecture which could benefit from a complete rethink, but I don't think we have enough details to do that in this thread. We have enough information to suggest hacks, because that's what OP seems to be requesting).

YAT_Archivista at 2007-7-15 2:47:02 > top of Java-index,Core,Core APIs...