Thread Factory in Java

The factory pattern is one of the most used design patterns in the object-oriented programming world. It is a creational pattern and its objective is to develop an object whose mission will be creating other objects of one or several classes. Then, when we want to create an object of one of those classes, we use the factory instead of using the new operator.
In this post, we will learn how to implement a ThreadFactory interface to create Thread objects with a personalized name while we save statistics of the Thread objects created.

With this factory, we centralize the creation of objects with some advantages:

• It's easy to change the class of the objects created or the way we create these objects.
• It's easy to limit the creation of objects for limited resources. For example, we can only have n objects of a type.
• It's easy to generate statistical data about the creation of the objects.

ThreadFactory
Java provides an interface, the ThreadFactory interface to implement a Thread object factory. Some advanced utilities of the Java concurrency API use thread factories to create threads.

ThreadFactory is an interface that is meant for creating threads instead of explicitly creating threads by calling new Thread(). An object that creates new threads on demand. Using thread factories removes hardwiring of calls to new Thread, enabling applications to use special thread subclasses, priorities, etc.

For example, assume that you often create high-priority threads. You can create a MaxPriorityThreadFactory to set the default priority of threads created by that  factory to maximum priority

With the use of ThreadFactory, you can reduce boilerplate code to set thread priority, name, thread-pool, etc.

Example

How it works...
The ThreadFactory interface has only one method called newThread. It receives a Runnable object as a parameter and returns a Thread object. When you implement a ThreadFactory interface, you have to implement that interface and override this method. Most basic ThreadFactory, has only one line.

return new Thread(r);


You can improve this implementation by adding some variants by:

• Creating personalized threads, as in the example, using a special format for the name or even creating our own thread class that inherits the Java Thread class
• Saving thread creation statistics, as shown in the previous example
• Limiting the number of threads created
• Validating the creation of the threads
• And anything more you can imagine

The use of the factory design pattern is a good programming practice but, if you implement a ThreadFactory interface to centralize the creation of threads, you have to review the code to guarantee that all threads are created using that factory.

If you know anyone who has started learning Java, why not help them out! Just share this post with them. Thanks for studying today!...

How to create cache in Java

Nearly every server application uses some form of caching. Reusing the results of a previous computation can reduce latency and increase throughput, at the cost of some additional memory usage. In this post, we'll see how to create cache efficiently for java programs with the help of examples. In order to understand this concept, you must have an idea about ConcurrentMap, ConcurrentHashMap, Future and FutureTask because these concept are going to helpful while creating Efficient and scaleable cache. This tutorial gives you the basic idea of creating cache

Cache
A cache is a component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache miss), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the greater the number of requests that can be served from the cache, the faster the overall system performance becomes.

Here we would create a Computable wrapper that remembers the results of previous computations and encapsulates the caching process
Basic Approach
The very basic approach we use for caching the result is by using HashMap and Synchronization. In this approach, our basic computation method first checks whether the desired result is already cached and returns the pre-computed values if it is. Otherwise, the result is computed and cached in the HashMap before returning  In this example, you'll see the generic approach for creating cache.
This is our computable interface which defines one method compute(), which can be implement by any class whose values we want to cache.

Cache1

As we know, HashMap is not thread-safe, so to ensure that two threads do not access the HashMap, Cache1 takes the conservative approach of synchronizing the entire compute method. This ensure thread safety but only one thread at a time can execute the compute method at all. If one thread is busy computing a result, others thread calling compute may be locked for a long time. If multiple thread are queued up waiting to compute values not already computed, compute may actually take longer time.

Before moving further, let's see how to use this example in cache1 in our program with the help of a program.

In this example, we have implemented a factorial functionality in order to cache its values. You can see how we have used our interface in generic way.

First improvement
We can improve on the aweful concurrent behaviour of cache1 by replacing HashMap with ConcurrentHashMap. Since ConcurrentHashMap is thread-safe, there is no need to synchronize when accessing the backing map, thus eliminate the need to of synchronize keyword. So our cache2 certainly has better behaviour than cache1; multiple threads can actually use it concurrently.

Cache2

But still there is problem with this program, there is chance of vulnerability in which two thread might call the compute method at the same time could end up computing the same value. This is not what we want from our caching - the purpose of a cache is to prevent the same data from being computed multiple times. The problem with cache2 is that if one thread starts an expensive computation, other threads are not aware that computation is in progress and so may start the same computation. 
Figure shows that Thread X is currently computing f(5) in the mean time other thread Y might need to compute f(5) and it sees that f(5) is not in cache and it think let's calculate f(5).

Second improvement
As you have seen in the previous image that Thread X is currently computing f(5), so that if another thread arrives looking for f(5), it knows that most efficient way to find it is to head over Thread X house, hang out there until X is finished and then ask "Hey dude, what did you get for f(5)?"

Now, here come FutureTask into picture. FutureTask is a cancellable asynchronous computation. FutureTask represents a computational process that may or may not already have completed. FutureTask.get methods returns the result of the computation immediately if it is available; otherwise it blocks until the result has been computed and then returns it.
Now, for instead of storing the cache value we use Future<R> in ConcurrentHashMap. In this program, we first checks to see if the requested calculation has been started. If not, we create a FutureTask, register with the map and starts the computation; otherwise waits for the result of the existing calculation. The result might be available immediately or in the process of being computed.

Cache3

The cache3 is almost perfect; it exhibits very good concurreny, the result is returned efficiently if is known and if the computation is in process by another thread, the newly thread wait patiently for the result. It has only one defect  there is still a chance of vulnerability in which two threads might compute the same value. The if block in compute is still not-atmoic like first check and then act type of sequence, it is possible for two threads to call compute with same value, both see that the cache does not contain the desired result and both start computation.

Third improvement
Cache3 is vulnerable because a compound action is performed on the backing map that cannot be made atomic using locking. Two Thread thread might see result == null at the same time and starting calculating the same value.
In order to avoid this we take advantage of atomic putIfAbsent method of concurrentMap.

V putIfAbsent(K key,V value)

Cache4

Final Improvement
Caching a Future instead of a value creates the possibility of cache pollution; if a computation is cancelled or fails, future attempts to compute the result will also indicate cancellation or failure. To avoid this, we remove Future from cache if computation cancelled or upon RuntimeException if the computation might succeed on a future attempt

This is our final cache program. I hope you understood the basic concept of writing cache program in Java. Even you can further improve this program by adding cache expiration time with each result by using a subclass of FutureTask and periodically scanning the cache for expired entries. 


If you know anyone who has started learning Java, why not help them out! Just share this post with them.Thanks for studying today!...

StrongReference, WeakReference, SoftReference, and PhantomReference in Java

In this post, we'll look into the different type of references in Java such StrongReference, WeakReference, SoftReference, and PhantomReference with detail knowledge of its working, its uses, its applications in real life. 

Java provides reference-object classes, which support a limited degree of interaction with the garbage collector. A program may use a reference object to maintain a reference to some other object in such a way that the latter object may still be reclaimed by the collector. A program may also arrange to be notified some time after the collector has determined that the reach-ability of a given object has changed.

Package java.lang.ref
A reference object encapsulates a reference to some other object so that the reference itself may be examined and manipulated like any other object. Three types of reference objects are provided, each weaker than the last: soft, weak, and phantom. Each type corresponds to a different level of reachability, as defined below. Soft references are for implementing memory-sensitive caches, weak references are for implementing canonicalizing mappings that do not prevent their keys (or values) from being reclaimed, and phantom references are for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.

Object Life Cycle (without Reference Objects)

An object's life can be summed up by the simple picture below: it's created, it's used, it becomes eligible for collection, and eventually it's collected.

Enter Reference Objects
JDK 1.2 introduced the java.lang.ref package, and three new stages in the object life cycle: softly-reachable, weakly-reachable, and phantom-reachable. These states only apply to objects eligible for collection — in other words, those with no strong references

Strong reference : A normal Java object reference
A strong reference is a normal reference that protects the referred object from collection by a garbage collector. The term is used to distinguish the reference from weak references. An object is strongly reachable if it can be reached by some thread without traversing any reference objects. A newly-created object is strongly reachable by the thread that created it.

A strong reference is an ordinary Java reference, the kind you use every day. For example, the code:
StringBuffer ref = new StringBuffer("JavaLatte);
creates a new StringBuffer() and stores a strong reference to it in the variable ref.

The important part about strong references is how they interact with the garbage collector. Specifically, if an object is reachable via a chain of strong references, it is not eligible for garbage collection. As you don't want the garbage collector destroying objects you're working on, this is normally exactly what you want.

Problem with Strong reference
Manual memory de-allocation
There are many situation where we can't extend classes, it might be these simply be marked final it could be something more complicated. Suppose you have to use class FacebookUser and for whatever reason, it isn't possible or practical to extend FacebookUser to add new functionality.

What happens when you need to keep track of extra information about the object? In this case, suppose we find ourselves needing to keep track of each FacebookUser's serial number, but the FacebookUser class doesn't actually have a serial number property -- and because FacebookUser isn't extensible, we can't add one. No problem at all, that's what HashMaps are for:
hashMap.put(FacebookUser,userSerialNumber);
This might look okay, but strong reference to FacebookUser certainly cause problems. We have to know (with 100% certainty) when a particular Widget's serial number is no longer needed, so we can remove its entry from the map. Otherwise we're going to have a memory leak or we may face missing serial number if remove FacebookUser that we are still using. We are not supposed to have to worry about this in a more civilized language like Java.

Caching
Another common problem with strong references is caching, particular with very large structures like images. Suppose you have an application which has to work with user-supplied images. Naturally you want to cache these images, because loading them from disk is very expensive and you want to avoid the possibility of having two copies of the image in memory at once.

Because an image cache is supposed to prevent us from reloading images when we don't absolutely need to, you will quickly realize that the cache should always contain a reference to any image which is already in memory. With ordinary strong references, though, that reference itself will force the image to remain in memory, which requires you (just as above) to somehow determine when the image is no longer needed in memory and remove it from the cache, so that it becomes eligible for garbage collection. Once again you are forced to duplicate the behavior of the garbage collector and manually determine whether or not an object should be in memory.

Summary : 

• Garbage collector will not reclaim an object that has a strong reference

Example : In this example, we try to add lots of data into Arraylist which would be more then available memory and we see what would happen in case of strong reference. Obviously, out program will crash or we get OutOfMemoryError.  
We also try to print the status of garbage collection with our program with the help of -XX:+PrintGCDetails

Note : This program may not be perfect elaboration of this concept.
Output

Total memory = 58
Free memory = 58
In btw Free memory = 57
[GC [PSYoungGen: 15744K->2616K(18368K)] 15744K->7416K(60352K), 0.0164850 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
In btw Free memory = 47
[GC [PSYoungGen: 18360K->2599K(31488K)] 23160K->14671K(73472K), 0.0190850 secs] [Times: user=0.05 sys=0.02, real=0.02 secs] 
[GC [PSYoungGen: 31463K->2593K(31488K)] 43535K->28161K(73472K), 0.0294520 secs] [Times: user=0.07 sys=0.03, real=0.03 secs] 
[GC [PSYoungGen: 31457K->2624K(31488K)] 57025K->41682K(73472K), 0.0280270 secs] [Times: user=0.06 sys=0.01, real=0.02 secs] 
[Full GC [PSYoungGen: 2624K->0K(31488K)] [PSOldGen: 39058K->41669K(68288K)] 41682K->41669K(99776K) [PSPermGen: 2573K->2573K(21248K)], 0.0607430 secs] [Times: user=0.06 sys=0.00, real=0.07 secs] 
[GC [PSYoungGen: 28864K->2624K(31488K)] 70533K->55557K(99776K), 0.0337830 secs] [Times: user=0.10 sys=0.01, real=0.03 secs] 
[Full GC [PSYoungGen: 2624K->0K(31488K)] [PSOldGen: 52933K->55554K(68288K)] 55557K->55554K(99776K) [PSPermGen: 2573K->2573K(21248K)], 0.0793230 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] 
[Full GC [PSYoungGen: 28864K->3118K(31488K)] [PSOldGen: 55554K->68287K(68288K)] 84418K->71406K(99776K) [PSPermGen: 2573K->2573K(21248K)], 0.1138420 secs] [Times: user=0.11 sys=0.00, real=0.12 secs] 
...many similar lines 
[Full GCException in thread "main"  [PSYoungGen: 28864K->28864K(31488K)] [PSOldGen: 68287K->68287K(68288K)] 97151K->97151K(99776K) [PSPermGen: 2565K->2565K(21248K)], 0.1767070 secs] [Times: user=0.16 sys=0.01, real=0.17 secs] 
[Full GC [PSYoungGen: 28864K->28863K(31488K)] [PSOldGen: 68287K->68287K(68288K)] 97151K->97151K(99776K) [PSPermGen: 2565K->2565K(21248K)], 0.1771830 secs] [Times: user=0.17 sys=0.01, real=0.18 secs] 
[Full GC [PSYoungGen: 28864K->28864K(31488K)] [PSOldGen: 68287K->68287K(68288K)] 97151K->97151K(99776K) [PSPermGen: 2566K->2566K(21248K)], 0.1767730 secs] [Times: user=0.17 sys=0.00, real=0.18 secs] 
[Full GC [PSYoungGen: 28864K->28863K(31488K)] [PSOldGen: 68287K->68287K(68288K)] 97151K->97151K(99776K) [PSPermGen: 2566K->2566K(21248K)], 0.1747700 secs] [Times: user=0.16 sys=0.01, real=0.17 secs] 
[Full GC [PSYoungGen: 28863K->28863K(31488K)] [PSOldGen: 68287K->68287K(68288K)] 97151K->97151K(99776K) [PSPermGen: 2566K->2566K(21248K)], 0.1761940 secs] [Times: user=0.16 sys=0.01, real=0.18 secs] 
[Full GC [PSYoungGen: 28863K->28862K(31488K)] [PSOldGen: 68287K->68287K(68288K)] 97151K->97150K(99776K) [PSPermGen: 2566K->2565K(21248K)], 0.2105580 secs] [Times: user=0.20 sys=0.01, real=0.21 secs] 
Heap
 PSYoungGen      total 31488K, used 28864K [0x00000000fdeb0000, 0x0000000100000000, 0x0000000100000000)
  eden space 28864K, 100% used [0x00000000fdeb0000,0x00000000ffae0000,0x00000000ffae0000)
  from space 2624K, 0% used [0x00000000ffae0000,0x00000000ffae0000,0x00000000ffd70000)
  to   space 2624K, 0% used [0x00000000ffd70000,0x00000000ffd70000,0x0000000100000000)
 PSOldGen        total 68288K, used 68287K [0x00000000f9c00000, 0x00000000fdeb0000, 0x00000000fdeb0000)
  object space 68288K, 99% used [0x00000000f9c00000,0x00000000fdeaffd8,0x00000000fdeb0000)
 PSPermGen       total 21248K, used 2573K [0x00000000f4a00000, 0x00000000f5ec0000, 0x00000000f9c00000)
  object space 21248K, 12% used [0x00000000f4a00000,0x00000000f4c837b8,0x00000000f5ec0000)


You can notice from the above output that out program even didn't completed as we got exception.

Referent
Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of these subclasses encapsulates a single reference to a particular object, called the referent.
Every reference object provides methods for getting and clearing the reference. Aside from the clearing operation reference objects are otherwise immutable, so no set operation is provided. A program may further subclass these subclasses, adding whatever fields and methods are required for its purposes, or it may use these subclasses without change.


Soft reference : java.lang.ref.SoftReference
An object is softly reachable if it is not strongly reachable but can be reached by traversing a soft reference.

Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches. A soft reference is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable  will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while.
SoftReferences aren't required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, such as the image cache, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will never be removed from the cache) and how badly it needs the memory they are consuming.

How SoftReference works
Suppose that the garbage collector determines at a certain point in time that an object is softly reachable. At that time it may choose to clear atomically all soft references to that object and all soft references to any other softly-reachable objects from which that object is reachable through a chain of strong references. At the same time or at some later time it will enqueue those newly-cleared soft references that are registered with reference queues.

All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. Otherwise no constraints are placed upon the time at which a soft reference will be cleared or the order in which a set of such references to different objects will be cleared. Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references.

Direct instances of this class may be used to implement simple caches; this class or derived subclasses may also be used in larger data structures to implement more sophisticated caches. As long as the referent of a soft reference is strongly reachable, that is, is actually in use, the soft reference will not be cleared. Thus a sophisticated cache can, for example, prevent its most recently used entries from being discarded by keeping strong referents to those entries, leaving the remaining entries to be discarded at the discretion of the garbage collector.

Summary : 

• Garbage collector is allowed to reclaim an object that has a soft reference but no strong references
• Can be used, for example, to create a cache of objects that clears itself of no-longer-needed objects if necessary to make room in the heap
• When memory is not enough, GC can release soft reachable objects.
• Good implement to data cache.

Soft Reference as Circuit Breaker

A better use of soft references is to provide a "circuit breaker" for memory allocation: put a soft reference between your code and the memory it allocates, and you avoid the dreaded OutOfMemoryError

Example :  Here we use the modified version of above example. In this case, we wrap the ArrayList into SoftReference. When It going to be run of memory, it tries to release the soft reference. In this case, throw out Exception instead of JVM exception.
We also try to print the status of garbage collection with our program with the help of -XX:+PrintGCDetail. As in case of  soft reference, JVM won't claim the space in first pass, that we can verified from the output string "Free memory"

Output

Total memory = 58
Free memory = 58
In btw Free memory = 48
[GC [PSYoungGen: 15744K->2600K(18368K)] 15744K->7424K(60352K), 0.0162960 secs] [Times: user=0.03 sys=0.01, real=0.02 secs] 
In btw Free memory = 47
[GC [PSYoungGen: 18344K->2599K(34112K)] 23168K->14671K(76096K), 0.0171280 secs] [Times: user=0.05 sys=0.01, real=0.02 secs] 
[GC [PSYoungGen: 34087K->2609K(34112K)] 46159K->29417K(76096K), 0.0270800 secs] [Times: user=0.06 sys=0.02, real=0.03 secs] 
[Full GC [PSYoungGen: 2609K->0K(34112K)] [PSOldGen: 26808K->29416K(66048K)] 29417K->29416K(100160K) [PSPermGen: 2573K->2573K(21248K)], 0.0436730 secs] [Times: user=0.05 sys=0.00, real=0.04 secs] 
.. many similar lines
[Full GC [PSYoungGen: 56960K->56960K(113792K)] [PSOldGen: 341376K->341376K(341376K)] 398336K->398336K(455168K) [PSPermGen: 2573K->2573K(21248K)], 0.6748630 secs] [Times: user=0.66 sys=0.01, real=0.68 secs] 
[Full GC [PSYoungGen: 56960K->0K(113792K)] [PSOldGen: 341376K->108K(160384K)] 398336K->108K(274176K) [PSPermGen: 2573K->2566K(21248K)], 0.0952940 secs] [Times: user=0.09 sys=0.00, real=0.09 secs] 
java.lang.RuntimeException:  Ran out of memory Heap
 PSYoungGen      total 113792K, used 1340K [0x00000000f5960000, 0x0000000100000000, 0x0000000100000000)
  eden space 56960K, 2% used [0x00000000f5960000,0x00000000f5aaf250,0x00000000f9100000)
  from space 56832K, 0% used [0x00000000f9100000,0x00000000f9100000,0x00000000fc880000)
  to   space 56832K, 0% used [0x00000000fc880000,0x00000000fc880000,0x0000000100000000)
 PSOldGen        total 160384K, used 108K [0x00000000e0c00000, 0x00000000ea8a0000, 0x00000000f5960000)
  object space 160384K, 0% used [0x00000000e0c00000,0x00000000e0c1b090,0x00000000ea8a0000)
 PSPermGen       total 21248K, used 2575K [0x00000000dba00000, 0x00000000dcec0000, 0x00000000e0c00000)
  object space 21248K, 12% used [0x00000000dba00000,0x00000000dbc83e70,0x00000000dcec0000)
at References.SoftReferenceDemo.fillList(SoftReferenceDemo.java:23)
at References.SoftReferenceDemo.main(SoftReferenceDemo.java:11)

At this point, you may wonder why need to throw out Exception instead OutOfMemoryError as program is going to abort in either case why not just let the out-of-memory error do the job?
The answer is that your application may not be the only thing affected. If you're running on an application server, your memory usage could take down other applications. Even in an unshared environment, a circuit-breaker improves the robustness of your application, because it confines the problem and gives you a chance to recover and continue.


Weak reference : java.lang.ref.WeakReference
An object is weakly reachable if it is neither strongly nor softly reachable but can be reached by traversing a weak reference. When the weak references to a weakly-reachable object are cleared, the object becomes eligible for finalization

Weak reference functionality is to handle a lot of data without worrying about running out of memory. This works well in lazy-initialization situation where you want to read a potentially large amount of data, but that data is not important enough to be available immediately. For instance, say you are reading 10MB image from the disk in order to determine its feature such as it size, read metadata and for other purposes. But, you don't care about the original data stay in memory. In some situation, we do for from performance perspective.
By default, all java references are strong references- the object on the other end of a strong reference is not garbage collected until the object containing the reference is collected.  That is where WeakReference comes in. Instead of keeping your strong reference in your object, you give it to a WeakReference instance instead. It does the dirty work of allowing the reference to be collected.
Weak reference objects, which do not prevent their referents from being made finalizable, finalized, and then reclaimed. Weak references are most often used to implement canonicalizing mappings. 
Suppose that the garbage collector determines at a certain point in time that an object is weakly reachable. At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references. At the same time it will declare all of the formerly weakly-reachable objects to be finalizable. At the same time or at some later time it will enqueue those newly-cleared weak references that are registered with reference queues.

In order to understand weak references, you can check WeakHashMap for more detail.

Example :  Here we use the modified version of above example. In this case, we wrap the ArrayList into WeakReference. As in case of  weak reference every-time when GC start weak reachable object are collected, that we can verified from the output string "Free memory"

Code will similar to above program instead of these line :
static WeakReference<ArrayList<String>> ref = new WeakReference<ArrayList<String>>(new ArrayList<String>());

//throw new RuntimeException(" Ran out of memory ");
Output

Total memory = 58
Free memory = 58
In btw Free memory = 48
[GC [PSYoungGen: 15744K->240K(18368K)] 15744K->240K(60352K), 0.0006910 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
In btw Free memory = 55
[GC [PSYoungGen: 15984K->192K(18368K)] 15984K->192K(60352K), 0.0019730 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 15936K->160K(18368K)] 15936K->160K(60352K), 0.0004610 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 15904K->192K(34112K)] 15904K->192K(76096K), 0.0014990 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
... same similar lines
[GC [PSYoungGen: 86944K->32K(83328K)] 87092K->180K(125312K), 0.0001590 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Free memory = 89
Heap
 PSYoungGen      total 83328K, used 35130K [0x00000000f5960000, 0x0000000100000000, 0x0000000100000000)
  eden space 83264K, 42% used [0x00000000f5960000,0x00000000f7ba6988,0x00000000faab0000)
  from space 64K, 50% used [0x00000000fffe0000,0x00000000fffe8000,0x00000000ffff0000)
  to   space 64K, 0% used [0x00000000ffff0000,0x00000000ffff0000,0x0000000100000000)
 PSOldGen        total 41984K, used 148K [0x00000000e0c00000, 0x00000000e3500000, 0x00000000f5960000)
  object space 41984K, 0% used [0x00000000e0c00000,0x00000000e0c25060,0x00000000e3500000)
 PSPermGen       total 21248K, used 2581K [0x00000000dba00000, 0x00000000dcec0000, 0x00000000e0c00000)
  object space 21248K, 12% used [0x00000000dba00000,0x00000000dbc85560,0x00000000dcec0000)

You can notice in this output that after PSYoungGen collection, memory increased from 48 to 55 which is not the case with previous references. Even there is not FullGC happened as weak references are claimed in first pass.

Summary  : 

• Weaker than soft reference
• Garbage collector must reclaim an object that has a weak reference but no soft or strong references
• Can be used, for example, to create a data structure that automatically deletes its own elements when all other references to its elements go away
• Every time when GC stats, weak reachable objects are collected
• Disposable objects.

Phantom reference : java.lang.ref.PhantomReference
An object is phantom reachable if it is neither strongly, softly, nor weakly reachable, it has been finalized, and some phantom reference refers to it.

Phantom references can be used to perform pre-garbage collection actions such as freeing resources. Instead, people usually use the finalize() method for this which is not a good idea. Finalizers have a horrible impact on the performance of the garbage collector and can break data integrity of your application if you're not very careful since the "finalizer" is invoked in a random thread, at a random time.
In the constructor of a phantom reference, you specify a ReferenceQueue where the phantom references are enqueued once the referenced objects becomes "phantom reachable". Phantom reachable means unreachable other than through the phantom reference. The initially confusing thing is that although the phantom reference continues to hold the referenced object in a private field (unlike soft or weak references), its getReference() method always returns null. This is so that you cannot make the object strongly reachable again. 
From time to time, you can poll the ReferenceQueue and check if there are any new PhantomReferences whose referenced objects have become phantom reachable. In order to be able to to anything useful, one can for example derive a class from java.lang.ref.PhantomReference that references resources that should be freed before garbage collection. The referenced object is only garbage collected once the phantom reference becomes unreachable itself.

How is that different from WeakReference
WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened; in theory the object could even be alive again by an unorthodox finalize() method, but the WeakReference would remain dead.
PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to alive an almost-dead object.

What good are PhantomReferences
They allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn't generally that useful, but might come in handy in certain very specific circumstances like manipulating large images.

PhantomReferences vs finalize
PhantomReferences avoid a fundamental problem with finalization: finalize() methods can alive objects by creating new strong references to them.  Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the possibility that the object was alive during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage.

With PhantomReference, this situation is impossible - when a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object. Because PhantomReference cannot be used to alive an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.

Arguably, the finalize() method should never have been provided in the first place. PhantomReferences are definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler.

Summary : 

• Weakest reference
• Garbage collector must reclaim an object that has a phantom reference but no weak, soft, or strong references
• Can be used, for example, to do post-mortem actions after an object is reclaimed (the object itself cannot be accessed)
• Work with ReferenceQueue class
• When the garbage collector determines an object is Phantomly reachable, the PhantomReference object is placed on its ReferenceQueue.
• The PhatomReference object referred to has been finalized and is ready to be collected.
• Phantom reference are useful for implementing cleanup operations that are necessary before an object get garbage collected. They are sometime more flexible than the finalize() method.

Difference 

• Strong Reference
  Purpose : An ordinary reference. Keeps objects alive as long as they are referenced
  Use : normal reference
  When Garbage collected : Any object not pointed to can be reclaimed.
  Implementing Class : default
• Soft Reference
  Purpose : Keeps objects alive provided there’s enough memory
  Use : to keep objects alive even after clients have removed their references (memory-sensitive caches), in case clients start asking for them again by key.
  When Garbage collected : After a first gc pass, the JVM decides it still needs to reclaim more space
  Implementing Class : java.lang.ref.SoftReference
• Weak Reference
  Purpose : Keeps objects alive only while they’re in use (reachable) by clients.
  Use : Containers that automatically delete objects no longer in use.
  When Garbage collected : After gc determines the object is only weakly reachable
  Implementing Class : java.lang.ref.WeakReference, java.util.WeakHashMap
• Phantom reference
  Purpose : Lets you clean up after finalization but before the space is reclaimed (replaces or augments the use of finalize())
  Use : Special clean up processing
  When Garbage collected : After finalization.
  Implementing Class : java.lang.ref.PhantomReference

If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...

Constructor multiple choice questions in Java

In this post, I have created a few questions on understanding of constructors in Java. If you are new to constructor concept in Java and you want to read about constructor before taking this test please check constructor article or otherwise you can refer to it later after the test. Please let me know your feedback after the test. All the Best!

1. What is the return type of Constructors?

int
float
void
None of the above

The correct answer is the None of the above. Constructors does not have any return type, not even void.

2. Which operator is used by Java to free the memory of an object when it is no longer needed?

null
free
new
None of the above

The correct answer is the None of the above. Garbage collection take care of memory management in java.

3. Predict the output of the following program?

class employee{
private String name;
public employee(String name) {
this.name=name;
}
}

public class Constructor1 {
public static void main(String[] JavaLatte) {
employee e = new employee("JavaDeveloper");
System.out.println("Emp Name : "+e.name);
}
}

Emp Name : JavaDeveloper
JavaDeveloper
Compile time error
Run time error

The correct answer is the Compile time error because String name is private.

4. Predict the output of the following program?

class person{
person(){
System.out.println("Hello constructor!");
return;
}
}

public class Constructor2 {
public static void main(String[] JavaLatte) {
person p = new person();
}
}

Hello constructor!
No output
Compile time error
Run time error

The correct answer is the Hello constructor! because we are not returning anything from constructor

5. Predict the output of the following program?

class Animal{
}

public class Constructor4 {
public static void main(String[] JavaLatte) {
Animal a = new Animal();
}
}

Run with error
Run without error
Compile time error
Run time error

The correct answer is the Run without error because default constructor will be created if we are thinking that constructor is not there

6. Predict the output of the following program?

class manager{
String name;
public manager(String name) {
this.name=name;
}
void welcomeMessage(){
System.out.println("Welcome to Java-Latte");
}
}

public class Constructor3 {
public static void main(String[] args) {
manager m = new manager();
}
}

Welcome to Java-Latte
No output
Compile time error
Run time error

The correct answer is the Compile time error because in this case default constructor in not created.

7. Will this class compile?

class Overloaded{
Overloaded(){
System.out.println("Constructor is initialised");
}
protected Overloaded(){
System.out.println("Constructor is initialised");
}
}

Yes
No

The correct answer is the No because Overloaded constructors can’t be defined by just a change in the access modifiers

8. Predict the output of the following program?

class Rectangle{
int len;
int width;
void Rectangle(int len, int width){
this.len=len;
this.width=width;
}
}
public class Constructor5 {

public static void main(String[] JavaLatte) {
Rectangle r = new Rectangle();
r.Rectangle(5, 7);
System.out.println(r.width+" "+r.len);
}
}

5 7
7 5
0 0
Error

The correct answer is the 7 5.

9. Can we define a constructor using all four access modifiers: public,protected, default, and private.

Yes
No

The correct answer is the Yes.

10. Predict the output of the following program?

class Square{
Square(){
System.out.println("Constructor is initialised");
}
{
System.out.println("Square is initialised");
}
}

public class Constructor6 {
public static void main(String[] JavaLatte) {
new Square();
}
}

Square is initialised
     Constructor is initialised
Constructor is initialised
     Square is initialised
Compile time error
Run time error

The correct answer is the A An initializer block is defined within a class, not as a part of a method. It executes for every object that’s created for a class

11. Predict the output of the following program?

class Square{
Square(){
System.out.println("Constructor is initialised");
}
{
System.out.println("Square is initialised");
}
}

public class Constructor7 {
public static void main(String[] JavaLatte) {
new Square();
new Square();
}
}

Square is initialised
     Square is initialised
     Constructor is initialised
     Constructor is initialised
Constructor is initialised
     Constructor is initialised
     Square is initialised
     Square is initialised
Square is initialised
     Constructor is initialised
     Square is initialised
     Constructor is initialised
Square is initialised   
     Constructor is initialised

The correct answer is the C because An initializer block is defined within a class, not as a part of a method. It executes for every object that’s created for a class

12. Predict the output of the following program?

class Employe{
String name;
Employe(){
Employe("JavaLatte");
}
Employe(String name){
this.name = name;
}
}

public class Constructor8 {
public static void main(String[] JavaLatte) {
new Employe();
}
}

JavaLatte
No output
Compile time error
Run time error

The correct answer is the Won’t compile—you can’t invoke a constructor within a class by using the class’s name. Because a constructor is defined using the name of its class, it’s a common mistake to try to invoke a constructor from another constructor using the class’s name

13.  Predict the output of the following program?

class Employe{

String name;

Employe(){

System.out.println("JavaLatte");

}

Employe(String name){

this.name = name;

this();

}

}

public class Constructor9 {

public static void main(String[] JavaLatte) {

new Employe();

}

}

JavaLatte
No output
Compile time error
Run time error

The correct answer is the Won’t compile— the call to the overloaded constructor must be the first statement in a constructor.

Show me the answers!

You are suppose to answer all the question!

Well done! You answered them all right!

If you know anyone who has started learning java, why not help them out! Just share this post with them. Thanks for studying today!...