avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Hainsworth" <sha...@acedsl.com>
Subject Question about static methods, thread safety, garbage collection
Date Mon, 13 May 2002 20:42:50 GMT
Certain components, i.e. FileUtil contain a private constructor and static
methods.  I have always avoided this type of construct for two reasons:

1)  With a static method, it seems possible to have thread safety issues.
If two threads access the same static method, such as contentEquals( final
File file1, final File file2 ), won't we get potentially false results.  For
example:
	Thread 1 calls contentEquals with ( fileInstance11, fileInstance11 )
	Thread 2 calls contentEquals with ( fileInstance2, fileInstance15 ) before
Thread 1 completes.  Won't our local copies of file1 and file2 be changed to
fileInstance2 and fileInstance15 respectively, therefore causing the method
to return false for Thread 1 when the correct result is true?

2)  To avoid this issue, if we provide a public constructor and non-static
methods, we then get excessive object instantiation/garbage collection.

For this reason, I have always used pooled objects, which guarantees thread
safety and controlled instantiation/garbage collection.

Is there really a thread safety issue with FileUtil, or am I missing
something.  I would really appreciate someone clearing this up for me.

I have written a collection of pooled utility objects for my own purposes
before I became aware of Avalon/Excalibur, and I am currently migrating my
system to Avalon/Excalibur.  I have written some objects, such as a
DataCache object which I would like to contribute to the sandbox when I get
deeper into the API and make sure I am not wasting anyone's time.



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message