Hi, 2008/5/28 Alexey Varlamov <[EMAIL PROTECTED]>: > Generally speaking, using WeakReference for caching is just wrong - > cache entry will be removed as long as it's key has no more strong > references thus such cache does not fulfil it's destination. > SoftReference is more sensible for implementing caches as it will > survive until memory is short (well, AFAIR drlvm does not obey this > contract yet). >
Agreed. However we have a WeakHashMap (but no SoftHashMap), so just pick up and use. And just a guess, I think this may be a kind of cache that keeps a balance of memory and performance? it lost its contents faster than SoftReference so that the heap won't grow too large, and cache the contents while its key is still strong-referenced (possibility of re-using is still high). > FYI, there is handy org.apache.harmony.luni.util.ThreadLocalCache > which also should help to avoid synchronization overhead. > > Regards, > Alexey > > 2008/5/28, Jimmy,Jing Lv <[EMAIL PROTECTED]>: >> Hi, >> >> I see a memory leak using Harmony Beans, looking into heap there >> are many objects of WeakHashMap.Entry, and in hours they were never >> GCed. And at last I find it was in java.beans.Introspector, using a >> WeakHashMap as a cache: >> >> private static Map<Class<?>, StandardBeanInfo> theCache = >> Collections.synchronizedMap(new WeakHashMap<Class<?>, >> StandardBeanInfo>(DEFAULT_CAPACITY)); >> >> Unfortunately, we see it uses Class objects as WeakHashMap.Entry >> key, which is always referenced by vm (only can be GCed when a class >> is unloaded). but WeakHashMap.Entry extends >> java.lang.ref.WeakReference, which requires a weak reference as its >> key, as a result, using Class object shall always keep Entries in >> heap, cause a memory in that way. >> A quick search I also find in java.util.ResourceBundle, it defines >> its cache as: >> >> private static final WeakHashMap<Object, Hashtable<String, >> ResourceBundle>> cache = new WeakHashMap<Object, Hashtable<String, >> ResourceBundle>>(); >> >> and in code it uses ClassLoader objects as key. >> However as we know, ClassLoader objects are handled by vm as well >> and may not be released, this as well may cause memory leak. >> >> I suggest if we want to use WeakHashMap(and don't want to cause a >> memory leak), we may set its key carefully and avoid using objects >> that are referenced in other area (especially vm) that we can not >> handle, like Class, etc. And I have a a little approach for String >> objects, we know they are handled by vm with a pool, so directly use >> String as key seems also cause a leak, however if we put it into >> WeakHashMap as: >> >> WeakHashMap.put(new String(oldString), valueObject); >> >> Run a few minutes I see no leak. Maybe some VM guru can tell us >> what's going on with the string pool do in VM? >> >> To fix these 2 problem, I suggest create a new inner class and use >> it as Key of WeakHashMap (don't know if "new String(oldString)" should >> work? ). >> And anyone saw the same problem in Harmony code? Any >> comments/suggests? Thanks! >> >> -- >> >> Best Regards! >> >> Jimmy, Jing Lv >> China Software Development Lab, IBM >> > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
