What is object pooling and what is a weak object reference ?
How can we implement them using Java?
What is object pooling and what is a weak object reference ?
How can we implement them using Java?
An object pool is a collection of a particular object that an application will create and keep on hand for those situations where creating each instance is expensive. A good example would be a database connection or a worker thread. The pool checks instances in and out for users like books out of a library.
Usually object pooling is handled by a Java EE application server. If you need to do it yourself, best to use something like Apache's object pool. Don't write one yourself; thread safety and other issues can make it complicated.
Here's a good reference on weak object references.
An object pool is any collection of object which are recycled, rather than recreated each time they are needed.
There are a number of ways you can implement such an Object Pool depending on your requirements. Object pools used to help performance even for simple objects but are not as useful in Java 5+.
I suggest you only use them for objects which connection to external resources such as file, sockets or database connections.
Pooling & Object Pooling:
Pooling basically means utilizing the resources efficiently, by limiting access of the objects to only the period the client requires it.
Increasing utilization through pooling usually increases system performance.
Object pooling is a way to manage access to a finite set of objects among competing clients.
In other words, object pooling is nothing but sharing of objects between different clients.
Since object pooling allows sharing of objects, the other clients/processes need not re-instantiate the object (which decreases the load time), instead they can use an existing object.
After the usage, the objects are returned to the pool.
Weak reference object:
A weak reference is a holder for a reference to an object called the referent.
With weak references, you can maintain a reference to the referent without preventing it from being garbage collected.
When the garbage collector traces the heap, if the only outstanding references to an object are weak references, the referent becomes a candidate for GC as if there were no outstanding references and any outstanding weak references are cleared.
Remember, GC always, using some algorithms, reclaim the weakly reachable objects.
A weak reference is a kind of reference variable which is treated specially by the garbage collector.
This introduces another kind of reachability, any object may be:
(There are also Soft References and Phantom References, which I leave out here - they work similarly and introduce more levels between.)
If an object is not reachable at all, it can be garbage-collected at any time. If an object is strongly reachable, it can not be garbage-collected at all. If the garbage collector finds that an object (or a group of objects) is weakly reachable (maybe by multiple weak references), it clears all these references at once, and then the objects are not reachable (and can be garbage-collected).
(Actually there is/may be a finalization step between the "non reachable" and the collection, which also may make the object again reachable.)
For using Weak references, you can use the class java.lang.ref.WeakReference
- the actual reference is in a private variable of this class, and can only be set with the constructor, and later cleared. You can subclass this class, if you need other data apart from the reference itself, which should still be there when the reference is cleared.
For an object pool in the sense of "avoid costly instantiation", a weak reference is not the right tool.
I suspect you are trying to ask about a SoftReference cache (not WeakReference). I cannot find it right now, but I remember reading from someone who implemented a proprietary JVM begging people to not use them. His argument was that these caches suppose that the author of the garbage collector somehow knows more about your caching needs than you do (which should never be true).
What I recall seeing back in the day was that if a GC cycle did not free up enough memory, all SoftReferences subsequently got cleared at once, i.e. the cache goes from ridiculously (out of memory) full to (an equally ridiculous) totally empty. Instead, choose a cache implementation that works based on size, or age, or both, i.e. one that you can give your own sensible rules to, rather than trying to offload the decision of how your cache works to the person who wrote the garbage collector for some reason.
I implemented a simple ObjectPool in Java, see here It doesn't use weak object reference though. Purpose of weak object reference to allow collect an object memory even if there are references to the object, but they are weak. It is more useful for caches than for object pools, although can be used for them too.
The idea of object pool pattern is similar to that of library. Everyone of us know it is cheaper and easier to go to a library and borrow a book instead of buying it.Likewise, it is cheaper (with regards to system memory and speed) for a process to borrow an object rather then to instantiate it. So such process in which a process borrow an object from another process is termed as object pooling.
Check common-pools
It is generally used for objects whose creation is expensive. In order to avoid that you maintain a pool of N pre-created objects and reuse them.