ava is slow. Java is a memory hog. Nevertheless, using the tricks demonstrated in this article, we'll be able to improve the garbage-collection process and overall performance.
Despite the opening statements, I would not hesitate for a second to use Java to write a networked application. Why? Because Java shines in threaded, network-based applications, and because over the years, I have recognized the weaknesses of Java and have learned (the hard way) what I should do—or not do—to avoid running into too-serious problems with performance and memory usage. Recognizing these problems takes a while to learn; this is why most Java jobs require you to have at least two years of Java programming experience.
| A WeakHashMap stores the keys using WeakReference objects, which means that as soon as the key is not referenced from somewhere else in your program, the entry may be removed and is available for garbage collection. |
| One of the most common instances of memory leaks in Java is in hash maps, so Sun Microsystems has provided a WeakHashMap to minimize memory usage in caches implemented with maps. A WeakHashMap stores the keys using WeakReference objects, which means that as soon as the key is not referenced from somewhere else in your program, the entry may be removed and is available for garbage collection. (Have a look at the JavaDocs for the java.util.WeakHashMap and java.lang.ref.WeakReference for more information). It is important to note that the WeakHashMap has a WeakReference to the key—rather than, as we would expect—the value.
Say you write a middle tier that provides an OO view of your database via an application server. What you really want is for the values to be automatically released, rather than the keys. If you put all the objects into a normal HashMap, you can easily run out of memory when you access many different objects from different clients. But if you store the objects in a WeakHashMap, they will be cleared as soon as the key to the value is no longer strongly referenced. In addition, WeakReferences don't have a notion of when they were last accessed, so it could easily happen that heavily used objects are released first. Ideally, we want to have a different type of reference that is released in a "fair" order, and we need a HashMap that has references on the values, rather than the keys.
Why SoftReferences Are Probably a Better Option
Enter SoftReferences. A SoftReference should only be garbage collected when the VM is running low on memory and the object it is pointing to is not accessed from a normal (hard) reference. They should then be garbage collected in the reverse order in which they were last referenced. In my experiments, it seemed that SoftReferences may be released before WeakReferences, since VM implementers can actually treat them the same. However, it is important to note the philosophical difference and to choose the correct implementation to be ready for future versions of VMs.
Before I show you a SoftHashMap implementation, based on ideas by Sydney Redelinghuys (redsyd@yahoo.com), I offer some ideas that will make our SoftHashMap more optimal.
Each time we change the map (put, remove, clear) or ask for its size, we first want to go through the map and throw away entries for which the values have been garbage collected. It is quite easy to find out which soft references have been cleared. You can give the SoftReference a ReferenceQueue to which it is added when it is garbage collected.
As I mentioned above, the current JVM's SoftReference implementation is sub-optimal. We don't want our hash map to be bullied by the garbage collector, so we provide the option of the map itself keeping a hard link to the last couple of objects (typically 100). The SoftHashMap will use a variant of the Decorator pattern to add this functionality to an internally kept java.util.HashMap.
|
Test Code 
The SoftHashMap Itself 
