Tuesday, July 30

for-each loop limitations

Three scenarios where you can not use for each loop

for each loop provides a way to iterate over a collection of objects of class implementing Iterable interface. It provides little better performance as compared to traditional for loop and is a cleaner way to iterate over a collection. It removes the chances of error that could be introduced while iterating over multiple collection through traditional for loop . Developer could got wrong in updating and traversing over changing indexes of objects in collection . This kind of error is unlikely in for each loop

But there are situations where for-each can't be used

1. If you want to remove an element of collection while iterating for-each provides no remove method. So you can't use it in such scenario

2. If you want to replace some element in collection while iterating over collection You can't do that as there is no replace or update method here neither you have control to access the element with its index value .

3.A situation where you are working in parallel with multiple collections have to do a lot of operation with current index value of iterable collection. You don't have access to element index while iterating with for-each loop So you can't use it.


Semaphore in java concurrency package

What is Semaphore?

Let us understand simple concept of semaphore with an real time practical example .

Everyone at some point of time would have worked on database connection pool. In connection pool we maintain maximum number of connections allowed. So how do we control that. 

Let's say maximum number of allowed connection for a database is 10 and If 10 connection exhaust next thread will have to wait until one of the connection gets released. 

Semaphore provides a very simple way to implement this . 

Semaphore is nothing but a way of code synchronization with a specific counter. 

Let's understand this with a code snippet 

Public class ConnectionManager {

Semaphore sem =new Semaphore(10);

    public Connection getConnection(){
                 sem.acquire();
                 useConnection();
                 sem.release();
           }

    public void useConnection(){
          }



Through semaphone we maintain the counter limit for connection as 10. Any thread that needs database connection will invoke getConnection() method . 
When sem.acquire() is invoked sem counter is decreased by one . Everytime sem.acquire() method is invoked sem counter is decreased by one. So every thread that will invoke getConnection() method will decrease the sem counter by one.

When counter reaches 0 , sem.acquire() returns false and connection can not be obtained as maximum limit of allowed connection is already reached. 

Now every time sem.release() method is invoked sem counter is increased by one . This means it makes the connection available for reuse . So Client may continue trying to acquire the connection and may succeed if sem counter value become greater than 0

So semaphore helps in managing the maximum no of permits through a counter . Its value changes with critical area access acquire and release. 

That's how semaphore works. It just a better and clean way (with much lesser lines of code) to implement synchronization for situations where a counter based implementation can be useful.


Atomic variables in java


Atomic variables are introduced in java in version 5.0

To understand why atomic variables are introduced lets get through a piece of code 

Public class Calculator {
int i=0;
public int get (){
return i++;
   }
}

This is pretty simple code and work as expected in single threaded environment. 

But does it behave the same way in multithreaded environment as well.

i++ is not a single step operation instead it happens in three steps

1) value to be updated is read
2) manipulation is performed
3) new value is set in variable 

So if mutiple threads call get method simultaneously they will result in operating over i in inconsistent state . one thread might be in progress of incrementing the value and at same time other thread might access the variable and perform increment on same value . So multi step operation results in highly inconsistent data state .

How do we resolve this problem ?

Way to resolve this problem is to allow only one thread at a time to access get methods and perform all three steps completely only then allow other thread to access the method. 

How do we achieve that ? 

Way to achieve that is synchronization. 

public int synchronized get (){
return i++;
}

This will allow only one thread to access method at one time . Thread will take the lock on the object and will release lock while exiting the method . then other thread will take the lock. 

Here multiple threads are working in sequential manner. Although data inconsistency issue is resolved But it has degraded the performance a lot . Now multiple threads are taking as much time as many number of threads execute the get() method.

Way to overcome that is atomic variables . 


 JVM compiles these classes with the better operations provided by the hardware machine, CAS or a Java implementation of the operation using a lock. 

Atomic classes in java are 


  • AtomicInteger
  • AtomicLong
  • AtomicBoolean
  • AtomicReference


All these classes supports compare-and-set (via the compareAndSet() method) . The setters operations are implemented using compareAndSet. These classes supports multi-threaded access and have a better scalability than synchronizing  the operations.

what is compareAndSet?

Quickly read that here 

http://efectivejava.blogspot.in/2013/07/what-is-compare-and-swap-and-compare.html

Here is how we can rewrite our get() method using an AtomicInteger :


public class Calculator{

    private final AtomicInteger var= new AtomicInteger(0);
          public int get(){
            return  var.incrementAndGet();
      }
}

The incrementAndGet()  method is  provided by the AtomicLong and AtomicInteger classes. there are many other methods for other operations like decrementandget() , getandset();

This is faster than the synchronized one and is also thread safe.

Monday, July 29

What is reifiable and non-reifiable java

What is reifiable and non-reifiable java ?

a reifiable type is one whose runtime representation contains same information than its compile-time representa-tion

a non-reifiable type is one whose runtime representation contains less information than its compile-time representa-tion

Arrays are reifiable as arrays remains as it is at runtime While generic information attached with List is erased at runtime by erasures

So List<String> list=new ArrayList<String>

at runtime will be

List list=new ArrayList();

all generic information is erased. This is done to support the legacy code that is written without using generics.

But in case of arrays

Object[] ojb=new Object[0]

will remain the same at runtime as well. Generics are not mixed with arrays.



ITEM 25: PREFER LISTS TO ARRAYS

                             PREFER LISTS TO ARRAYS


Reason:

Lists, if implemented correctly, can save us from ClassCastException but arrays can not.

How does that happen ?

lets start it with a statement

List in invariant while arrays are covariant .

Now what is this invariant covariant difference

read the difference quickly here

http://efectivejava.blogspot.in/2013/07/what-is-covarient-and-invarient.html

Let's go through a simple example

Let's declare and instantiate an array

Object[] objectArray = new Integer[1];

assign a string value to first place in array

objectArray[0] = "str";

What happens here. This does not fail at compile time although it will throw arrayStoreException at runtime

Now let us declare and instantiate a list

List<Object> ol = new ArrayList<Integer>();

assign a string value to first place in list
ol.add("str");

what happens here. It won't compile at all. Compiler will complain You can not store String in Integer type list. So it is providing opportunity to amend the program at compile time itself instead of having a surprised burst at runtime.


Conclusively Arrays provide runtime type safety while List provides compile time type safety and we always wish to identify the error at earliest opportunity. So List should be preferred over Arrays from type safety perspective although on performance scale there can be different views depending upon the specific scenario and uage in code.